Adding command-line arg to hide segwit2x service bit #109
Conversation
|
I think also appearing as a |
|
This would be dangerous option to use, since the node may suddenly get banned from all connected nodes when the hard fork happens. Almost all nodes on the network are Bitcoin nodes, and btc1 should try hard to be connected to only those nodes which will follow the btc1 fork. Since version 0.15.0 will be the first version with this function, there is no risk of not getting transactions or blocks relayed. Most Bitcoin nodes are running older versions than current. |
As far as I understand it, btc1 already has preferential peering logic to address that concern. After all, 0.14.x Core peers would disconnect us at hard fork time just as much as 0.15 peers. We can't (and don't) rely on the behaviour of core peers to achieve a connected graph of 2x nodes. |
|
Right, this is simply a failsafe measure to ensure 2x nodes have the ability to peer with 0.15.x nodes in case of a significant number of upgrades. |
|
NYA miners de-facto agreed to run btc1 nodes, so what Bitcoin Core users may encounter after they perform this upgrade to version 0.15 is that their transactions are no longer confirming as they aren't seen by most miners. A more disastrous possibility is that transactions broadcast exclusively to Bitcoin Core nodes could be double-spent in the btc1 network, where they'll be more likely to be mined. I don't think that btc1 nodes need to stealth themselves. If anything it would get btc1 users closer to miners in terms of hops. |
|
@XenoG It is unlikely that many users will have upgraded to 0.15 by November. Most Bitcoin users have still not upgraded to 0.14.2, which is the current version, so there will not be a lack of peers. Users upgrading to Bitcoin 0.15, instead of switching to btc1, have made a choice of which fork to follow. It doesn't make sense to upgrade to 0.15 to use the new features, just to downgrade to btc1 after two months. It would be best to not connect to those nodes. |
|
NYA miners de-facto switched to bitcoin cash |
|
@mk229797 That's definitively not true. Looking at the hash rate ~93% of the blocks over the last 1k blocks are signalling segwit & 95% of blocks in the last 144 blocks are signalling for SegWit 2x (source). Meaning that even when accounting for Bitcoin Cash's hashrate; SegWit 2x is still supported by a super majority. |
|
@christophebiocca ... of miners. In the end infrastructure and users have the decision which blockchain is used |
|
@mk229797 Miners are infrastructure. One would be completely naive to ignore the intention of miners. |
|
@jheathco all miners could be replaced by couple of CPU/GPUs and the network tps would be as is after difficulty adjusting, which will cause heavy-invested in hardware miners to switch back to original software, that supports only SegWit at this stage |
|
NACK Bitcoin Core 0.15.0 disconnects all nodes with service bit SegWit2x set. All current Bitcoin nodes MUST upgrade to 0.15.0 BEFORE SegWit2x. What does this mean? It means that the split cannot be avoided and your proposal guarantees that SegWit and SegWit2x nodes will be cross talking. This is a solution to a problem that cannot exist. |
|
@argon2 I'm not sure what you're talking about in regards to a split. Of course a split cannot be avoided - the point of this PR is to assist in preventing a premature split prior to the scheduled hard fork. Once the first block > 1MB is mined, SegWit2x nodes and 1x nodes will disconnect from each other regardless due to disagreement in consensus rules. As others have stated, this shouldn't even be necessary as the rollout of 0.15+ will likely be slow and many other clients (BU, etc.) won't drop btc1 clients. |
|
Please merge this. Awesome dick move to be hated by the community even more. I'm not surprised a bit that it's even considered... |
|
@lra hopefully you're well aware that there are two sides to this debate, and much of the "community" to which you refer is in full support of 2x (myself included). |
Sure... That's why you need to try to sneak 2x in without replay protection and hiding the service bit. See you in Nov ;) |
|
@gmaxwell explained the rationale for bitcoin#10982 in this talk. As @XenoG points out "if anything it would get btc1 users closer to miners in terms of hops". This flag should come with good documentation if merged. |
|
This is pathetic and petty. No one want's 2x so you have to resort to lying to people? Y'all are just a sad bunch of failures. |
|
"People dont want our shit, but they are wrong imo!! So lets just force it for people that dont want it and possibly cause issues on the way". Fucking autistic. |
It seems that, similarly to Brian Armstrong, Erik Voorhees and anyone running a service that supports this mess, in your delusional minds you think that John Doe, which uses your exchange to buy 50 bucks worth of BTC to speculate with alts on Poloniex, even knows what 2x is, let alone is knowledgeable enough to make a decision and support it. If there is such a thing as a Bitcoin community, anyone involved is obviously not supporting 2x. Just because a bunch of clueless people use Coinbase, doesn't mean all of them support 2x, and pretending otherwise is delusional and misleading. Claiming that all these people are on your side is an huge act of hypocrisy that will cost you, and anyone involved, the brutal lifetime judgement of the actual Bitcoin community (you know, people that actually know what a fork is and care enough to hold their own BTC outside online wallets and exchanges). The only thing we know is, this unnecessary uncertainty will cause loses on actual Bitcoin holders, and you will be responsible for that, but im sure you are not telling your customers about it. The mempool is empty and spammers have been exposed. BCash can't even fill 100kb blocks. Pretending this abortion of a rushed hardfork is a good idea is an act of insanity with only obvious negatives. If you still want to go through with this, consider the consequences of crashing the holdings of everyone, including people that have been here before any of these corporations existed, and with more BTC and resources than anyone that signed the so called "New York Agreement" combined. |
Yeah, so by the time of the fork most people will switch to btc1 instead of core and this pr is not needed at all. |
|
My 5cts: There are clear reasons why to disconnect such peers from the perspective of Bitcoin: |
|
Having 2x avoid being rejected by 15.0.1 by disguising itself as something else is.... uncanny to say the least. There's really no point in doing this. As soon as the first >1mb block (non-witness data) gets mined the 2x blockchain will become invalid in 0.15.0.1 nodes from that point on anyway. This just delays the chain split for a bit. It is clearly not well-thought assuming good intentions. It can be used to download the blockchain from 15+ btc core nodes given a pre-ban but that is moot. The only reason you wouldn't be able to download the blockchain from non-2x cores in the first place is if most/all the running nodes are 15+ core with pre-ban. If that's the case then 2x has already failed at that point and there's no use in downloading the blockchain in a couple of clients. |
|
Based on past efforts - Bitcoin XT, Bitcoin Classic and Bitcoin Unlimited - clients that signal something other than Bitcoin Core have been DDoS'd and otherwise attacked on the network. It's also generally wise to support personal privacy. Past experience has shown have defenses against griefing and other network attacks can be valuable. |
|
To further masquerade btc1 as core you can consider rejecting 2MB blocks. This way you can stay connected to core nodes even after the fork. As a bonus you also wouldn't need replay protection. |
And you wonder why? Stop attacking Bitcoin and you will stop getting enemies.
How this PR helps support personal privacy in any way?
Again stop pissing people off and those attacks will stop. It's the internet and those are p2p nodes, you will prevent possible attacks by doing either:
|
|
@lra you define this hard fork as an attack... many others define it as an upgrade. Your best bet to "protect" the legacy chain would be to convince hashing power to stick to it, as ~94% are continuing to signal s2x. For such a "contentious" hard fork, I'm sure surprised at the lack of investment into any new mining equipment for the legacy chain. |
Hashing power never mattered, hashing power decentralization does. Difficulty adjustments are there for a reason. Bitcoin doesn't belong to miners, it belongs to users. The best way to protect the "legacy chain" is to get the users to use that chain and not 2x. |
If it's such an incredible upgrade, why does not everyone use it then? Why do you need to put effort into forcing it onto people that do not see it as an upgrade? Clearly the bitcoin community would love to freely accept upgrades, right? |
|
Hashing power doesn't matter? What an absurd statement. And yes, of course mining decentralization is something we should all want. However, this is a open market, and anyone is free to launch a mining operation or pool (a la Slush) that allows individual participants to signal which chain they'd like to signal support for. People are also free to fork away from the current PoW to something else to kill the current mining operators (something suggested by many current legacy supporters) if they so desire. Bitcoin "belongs" to everyone in the ecosystem: businesses, users, miners, etc. I'm so tired of people vilifying the miners in this space - they've invested an incredible amount into bitcoin and should be recognized for their contributions to Bitcoin's success. Sure, there are likely some "evil" miners, but to group them all together as some evil regime is ridiculous. |
As it is this is not an hard fork, this is a trojan. Grow some balls and make it a real hard fork, with replay protection, a new name, a new user agent, convince actors to follow you, like the bcash guys did. Apparently it's gonna be easy to bring bitpay and coinbase with you, so what's the issue? You, @jgarzik and I all know you can't do this because the supposed "NYA 90% support" is not really that supportive. So instead, you have to change the behavior of your nodes to act as trojan horses. I don't know a better name for a node that states to be compatible with the network but that intends to change the rules without consent. |
|
@lra Grow some balls? Classy. Let's keep the conversation technical in nature shall we? Again, if there is little support for s2x as you assert, you have absolutely nothing to worry about and you're wasting your time here. |
This conversation and this PR have 0 technical ground, this is just political BS. But you evaded my question: If you know you have support, why don't you cleanly fork and ask your supporters to follow you?
I'm not worried about the support, it's not there, I'm worried about the harm your trojan horse can do to non technical people. |
|
@jheathco You don't fool anyone but yourself. If you actually believed users would switch to btc1, there would be no reason whatsoever to include this workaround. If users switched, there would simply not be any Bitcoin 0.15 nodes to disconnect from. Read your own reasoning in the pull request. 50% of all recent BCH blocks signal NYA as well. The miners are mocking it. I bet > 50% of BTC blocks will signal NYA after S2X has forked off. The signal doesn't mean anything. If you thought it did, you wouldn't make this change to btc1. @jgarzik Those BU/BC/XT/etc nodes have been knocked out due to implementation specific bugs which didn't exist in Bitcoin Core. Bitcoin Core users are attacked as well, but the nodes themselves are harder to knock out. My own broker service got hit by a 35 Gbps DDoS attack shortly after I warned against BU, and declared I was not going to support BU coin in case of a hard fork. The attack continued until I had moved everything to new VPS providers, hid everything i could behind CloudFlare, and used IPv6 and Tor only for my main Bitcoin node. I never heard from the attacker (except for enormous amounts of unrelated email spam), and can not prove that my BU statement is the reason for the DDoS attack. If user support for btc1 is as high as claimed, there will only be a few Bitcoin Core nodes left in November. Almost everyone (>90%) will have switched to btc1, and trying to knock them out will be just as hard as to DDoS every current Bitcoin node. Again: The only reason to hide, is because you don't believe users will switch from BTC to S2X. |
You say it's an absurd statement, but you don't provide any reasons? If big miners leave, difficulty gets adjusted eventually and if users/transactions stay on the core chain, miners will eventually go back to core because ironically that's where the money would be given the premise, doesn't matter how long it takes. As long as it's not an abrupt switch where one entity has more than 50% of the total hashpower in core, it's not a very dangerous scenario. |
|
@Gaspa79 Let's assume for a moment 2x gets 90% and 1x gets 10% and we'll ignore other variables that may shift hashing power one way or the other (both before and after the fork). That means that blocks on 1x chain will be mined at 10% the current rate, producing them approximately every 100 minutes. Difficulty adjustment occurs every 2016 blocks, so we'd be looking at an initial difficulty adjustment after 201,600 minutes or 140 days (well over 4 months) [edit: not sure where we'll fall in the middle of the existing difficulty adjustment period, so this is not entirely accurate]. Assuming a transactional pattern similar to what we've had going into the fork, you can expect the mempool to explode and a vast majority of transactions to expire and be dropped (I believe it's after 3 days). I seriously doubt most users are going to want to continue "using" this chain. You're welcome to, but just be ready for a high probability that your transaction either drops or takes days to confirm with ridiculously high fees. Hashing power most certainly matters - not sure how this is even a discussion. |
We can agree there 100%. You don't get that the difficulty adjustment is the bottom-line as to why hashing power doesn't matter. The main point is that miners will follow the money, and with no users = no money. Hence hashing power doesn't matter, but users and transactions do. Also, 90% vs 10% of the hashing power as an assumption? Please. Anyway we're getting off track of the topic of this pull request. I've got nothing against you, and I'm gonna leave this discussion to end here since we are not gonna reach a conclusion due to different premises most likely. All the best. |
|
@jheathco You aren't taking into account Core and their supporters purchasing hash in addition to "shadow hash". Besides if there's any truth to what Charlie says here, stick a fork in it, you're done: |
That's your ideal scenario, I doubt you will get more than 50%, which is what abandoned the ship when bcash forked. Some miners already hinted that they won't follow.
We got it, your camp is just threatening the other camp, and your weapon is the miners. As said, people are not HODLing for a hashrate, they believe in a roadmap and a collective group of independent contributors, and few are gonna give those up for your bizcoin: there are already 1000+ copycats with different parameters. You'll see how the market price your 1001th copycat. I thought you guys would have learned with bcash, XT, BU, ... |
|
Manually merged / superceded by 28ebbdb |
Generally agree on that. |
|
The sad truth is, you're trying to tell egoistic people that dont care about others (Core) to stop trying to break it. They are very well aware of the bullshit they do, and i hope they fail miserably just like every single time before. |
|
For future reference: bitcoin#11446 would still result in getting banned (which is separate from DDOS concerns). |
In response to bitcoin#10982 - optional disabling of segwit2x service bit to prevent core >0.15.0 clients from prematurely disconnecting 2x nodes before the hard fork.