Closed prusnak closed 6 years ago
Wouldn't that make it incompatible with for example existing SPV wallet, that otherwise would work just fine with abc and other nodes which does not have a crippling block-size limit?
I don't agree. SPV wallet needs to know on which chain it is operating in order to function properly. Also try to keep the discussion civil, nobody is interested in your snarky remarks.
@prusnak no, the only thing that a client needs to change to be compatible is to allow for bigger blocks. and SPV clients and some other do not have any such limitation added so they will work just fine on both chains. (unless Bitcoin-UAHF/spec#17 gets merged and then it will indeed be a full altcoin that will need this change)
I guess this is something that if so should be discussed more in the spec and not in specific clients ?
OK to be frank, this has merit but it's waaaaaayyyyyyy down on the priority list. I don't think it is very important. We may or may not come back to it after Aug, 1 , when things settle down a bit.
It is a one line change and it makes sense to do it BEFORE the release. Once you have software used in the wild, this is really hard to change.
It is a one line change and it makes sense to do it BEFORE the release. Once you have software used in the wild, this is really hard to change.
Totally agree with this it should be done before Aug 1, or not at all. If it's going to change later you will have to add compatibility so that it tries multiple ports when using seeds for example.
Your motivation should be also avoid BCC network split; considering there's much more BTC nodes than BCC, the scenario that two BCC nodes don't see each other, because both are connected to BTC is likely.
lol 3 days delaying for a 1 line edit that would help everyone :D rofl
@slush0 would a service-bit exchanges in the p2p handshake be useful for that?
Bump. Should be really done ASAP.
Some facts;
you can run multiple nodes on the same host with zero conflicts in port number. You can run all of them with -listen=0
, or maybe keep one to listen.
you can change the port number your node listens on in the GUI or in the config file with no issues. Has been configurable for years.
the BCC clients use different seed DNS entries to avoid new clients connecting to the wrong nodes.
A BCC-only node will not broadcasts the address of a node that it has banned, for instance because it is not compatible. There is not to be expected any bleed-over between networks.
I would suggest to check if this is an issue in a week or two.
zander got me thinking Consider the following:
-listen=8335
DNS seeds for both networks will find these, but since there is no way to give port number for the DNS seeds both networks will try to connect to the Legacy node. (or are the DNS seeds now somehow sending ports, or at least checking that the correct node is available before adding it to the list?)
This gets even more interesting if you from the beginning switch which client is listening on which port. Or what if I start a Cash node that is found by the DNS seeds, but then it is closed and a legacy node is started instead. Also consider the above but each node is running on separate computers behind NAT with port forwarding.
Couldn't it very well turn out that such a user get's banned from most peers?
DNS seeds only list very highly ranked nodes. Which implies that they have a very good uptime and naturally that they use the proper port.
So was the port number for bitcoin cash nodes use changed? I'd like to run both, a bitcoin and bitcoin cash node behind my router.
@tbrannt : No, the default port numbers for Bitcoin Cash nodes are unchanged so far, so you'll have to adapt one or the other if you want to run both.
You can run both without problems. You just need to pass listen=0
on your legacy node.
@zander You are a joke!
Based on what I've seen so far, I don't think committers here care about one humble community member's opinion, but I'll offer it for the community anyway...
It is clear to anyone even remotely capable of running a full node that you can run both on a single machine, but the lack of port differentiation makes it unfeasible (impossible?) to run both on a single DNS name. With a port forward based on incoming host name it is possible but adds complexity and further reduces the number of people that can operate a full node due to the required skills and tech.
@zander 's point that "DNS seeds only list very highly ranked nodes" that have "very good uptime" seems to be in direct contrast to decentralization that is another principle of BCH.
So +1 for changing ABC's default port to be different from Bitcoin (and by extension likely the BCH default port). Secondly, a little disheartening to see the "core" BCH committers so hastily dismissing community requests from us little guys.
@activescott
The quarrel around 'port' is a pure political issue, so there is no need to pretend that it has any technical concern. Yeah I don't say that 'political' necessarily means 'evil'.
Now that it's a political, or more appropriately it's a social issue, there is no absolute 'right' or 'wrong'., so there is no need to use such sarcastic tone to argue while claiming to be 'humble'. Human skills come before technical skills.
Please don't bring the BSCore-style toxcity here. That has been proven not only destructive but also devastating and finally splitted original Bitcoin community into two different communities.
Conclusion: If you hate Bitcoin Cash, the genuine Bitcoin chain, it's better for you to stay away from this community. Don't try to attack us with stupid tricks while claiming 'let me belp you'. Don't defame youself by degrading into another troll like OP. It's a shame.
If you are neutral or you want to give a hand, please keep polite and don't be abusive to others. It's a basic requirement for any talk on this planet.
Anyway, welcome to Bitcoin Cash. Thank you for your interest.
@jli225 First, I apologize for my tone. I agree it wasn't constructive. However, I don't hate Bitcoin Cash and I never said anything to leave you concluding that - only that I found the reaction to the requests disheartening.
Now, the one thing you didn't address was the technical issue that I did raise. Again, it is clear that you can technically "run both on a single machine, but the lack of port differentiation makes it unfeasible (impossible?) to run both on a single DNS name."
Am I missing something here or is that technically accurate?
@activescott So the point I missed when I tried to run both instances and connect to them with an other program written by me is that I can still change one of the ports with the -rpcport flag
Hey @tbrannt, I get that I can change the port on each client, but my open question is the following: How to get both clients to accept incoming peer connections on the same public IP address?
@activescott right, didn't read this thread for a few month.. I thought it was about the RPC port. I'm not sure how to do that and I would also still appreciate if the port was changed.
How to get both clients to accept incoming peer connections on the same public IP address?
Its pretty easy to write a proxy process that looks at the first bytes of an incoming request and forwards packages to either the Cash or the legacy client based on the magic.
I have never seen anyone actually need this, practically all people complaining about this are saying someone else may need it (or worse).
Bottom line is that this is possible for those that need it.
This issue is stale and is being closed. If there is still a need for this, please reopen.
If the default ports were not changed, reopen the issue.
i'm buying new IP just to make bch running smooth, fiddling with proxy is not solution, BCH changed address format, why not port then ? There is still a need for this, please reopen.
@schancel in what way has this become stale, other then this issue not being seriously considered? As long as both legacy and cash is still alive and both are using the same port this is an ongoing issue that causes unnecessary pain for everyone.
Since this wasn't fixed before Aug 1, now you need to implement a new default port, and add support to check both old and new port when using DNS seeds.
I agree.. I'm totally pro BCH (in my eyes it is the real Bitcoin) but having the same port as the Segwit chain is just unnecessary. If BCH can be Bitcoin even though it changed the difficulty adjustment algo then changing the port number will also not weaken it's position.
Imo it's petty, this has nothing to do with what's the real bitcoin - this is a problem that operators of crypto services will run into.
This is silly guys. Change the port number or create another solution that lets me run a bitcoin node and bitcoin cash node from the same server.
I would like one of you to propose a mechanism for migrating the port to a new value, and then submit a pull request to do so.
This change should not be made, any changes to code create risk, we should not be altering our code because of the existence of a forked version of our protocol. Please go and propose this change to the Core devs, the response here should be the same as I imagine you will get there.
@schancel very easy: it can be done during the next hard fork. Regular hard forks are scheduled for BCH anyway
I propose 8433 and 8432 for mainnet and 18433 and 18432 for testnet. Looks like they're free.
Yes ! please split TCP port (and default configuration files, too...) from Bitcoin Core !
to something else than 8333 so it will not collide with Bitcoin.