I am considering a slightly different approach, to mitigate the partitioning risk completely.
A stage 0 is needed. This stage should detect prevalence of SegWILL nodes on the network, and only invoke stage 1 once a 51% activation threshold has been reached and maintained for X blocks. It seems to me that the version bits could be used to signal this. Maybe it would be a good idea, for transparency's sake, to code all 3 stages into a single client, and use the same mechanism for invoking the 2nd (BU blocks not relayed) and 3rd (non Segwit signalling blocks not relayed) stages.
This means abandoning the strategy of preventing SegWILL nodes from being detected and mistreated on the network, as realistically, this is an "all-or-nothing" strategy overall, a majority of nodes must run SegWILL for the strategy to work at all, and so the issue of counter attacks against identifiable SegWILL nodes is not relevant in that necessary outcome.
Thanks for all the comments so far.
Topic: [RFC] Multi-stage client fork: SegWILL (Read 1418 times)
Now, even if this is enforced by users first and not miners, I don't see how this is a hard fork. Nodes simply punish non-complying miners, in stages (the punishment becomes more severe as time goes on), and eventually non-complying blocks become invalid. No hard forking needed.
I think you're right actually, as the contents of the version string added to coinbase transactions isn't part of the consensus rules, I'm not sure if this is even a soft fork (using the definition of soft forks the Bitcoin developers use). It would, though, eventually fork non-compliant miners from the chain that enforces this, so it's perhaps better described as an unorthodox soft fork.
The only field that should be present in the coinbase string according to consensus is the height of the current block (and the byte that says how long the field is), as far as I know. I also think this is a soft fork by definition, currently the coinbase must have the block height, and has no other restrictions aside from its maximum size (100 bytes?), after the change is done, the coinbase still must contain the block height, and also must not contain anything else that nodes do not expect to find there (which would be the current graffiti).
I agree that this is more aggressive than most soft forks Bitcoin went through. Another point to make is what if eventually we do want to extend the consensus properties of the coinbase? There will have to be a mechanism to soft fork those in already baked into the original implementation, sounds pretty hard now that I think about it. A simpler solution would be to make use of these coinbase bytes right now, one that can't be used for arbitrary messages and that has consensus weight, and keep that as the final implementation (sort of like what the 1MB block limit is).
Now, even if this is enforced by users first and not miners, I don't see how this is a hard fork. Nodes simply punish non-complying miners, in stages (the punishment becomes more severe as time goes on), and eventually non-complying blocks become invalid. No hard forking needed.
I think you're right actually, as the contents of the version string added to coinbase transactions isn't part of the consensus rules, I'm not sure if this is even a soft fork (using the definition of soft forks the Bitcoin developers use). It would, though, eventually fork non-compliant miners from the chain that enforces this, so it's perhaps better described as an unorthodox soft fork.
"saving block space" was meant as a bit of a pun (saving the block space from malicious actors) 
, I don't really mean that coinbase being filled with data or not will make more room for transactions in a block. And sure, there are other ways to fill a block. This proposal isn't about those.
Now, even if this is enforced by users first and not miners, I don't see how this is a hard fork. Nodes simply punish non-complying miners, in stages (the punishment becomes more severe as time goes on), and eventually non-complying blocks become invalid. No hard forking needed.
, I don't really mean that coinbase being filled with data or not will make more room for transactions in a block. And sure, there are other ways to fill a block. This proposal isn't about those.Now, even if this is enforced by users first and not miners, I don't see how this is a hard fork. Nodes simply punish non-complying miners, in stages (the punishment becomes more severe as time goes on), and eventually non-complying blocks become invalid. No hard forking needed.
saving block space and helping to keep the chain clean of all sorts of garbage some mining pool might try to promote.
This is useless.1) This can be implemented only by a soft-fork with a voting by... by... miners?
Or a hard fork by.... by..... users?
2) There are a lot of ways to waste the block space with a garbage
https://bitcointalksearch.org/topic/storing-large-data-in-blockchain-1023190
https://bitcointalksearch.org/topic/storing-large-data-in-blockchain-1023190
off topic
Do you have a useful contribution to make, amaclin?
Nice idea, Arubi.
Using a broader reason that includes rejection of BU blocks as a subset is highly desirable, as taking the opportunity to solve multiple problems at once is expedient.
Can anyone think of possible downsides to this approach? What legitimate reason is there for miners to include arbitrary information in their coinbase transactions at all?
Using a broader reason that includes rejection of BU blocks as a subset is highly desirable, as taking the opportunity to solve multiple problems at once is expedient.
Can anyone think of possible downsides to this approach? What legitimate reason is there for miners to include arbitrary information in their coinbase transactions at all?
One idea for a UASF I had was taking control of blocks' coinbase string, where usually you'd see the name of the pool that mined the block, or in BU's case it's where they put their EB/AD/whatever parameters. Ignoring BU for a moment, miners having this power to "graffiti" all over coinbase is getting annoying. When Bitcoin moons, this block space might become prime advertising real estate (Blocka-Cola?) or worse, used for politics.
Currently, coinbase has to hold some specific data (this block's height), and almost all miners add their own strings after that. It might be beneficial for nodes to allow only useful and consensus critical data (like the current height) in coinbase, saving block space and helping to keep the chain clean of all sorts of garbage some mining pool might try to promote.
Mining pools who still would like to signal for specific parameters can use version bits, and for arbitrary data there is op_return.
Nodes might beging applying relay penalties on blocks that have useless data in coinbase, and at a later point stop relaying these blocks completely. At a much later point, nodes might consider any non consensus data in coinbase to be invalid.
This type of UASF has a small benefit of being pretty safe for all users of the network, except for non-complying miners.
Currently, coinbase has to hold some specific data (this block's height), and almost all miners add their own strings after that. It might be beneficial for nodes to allow only useful and consensus critical data (like the current height) in coinbase, saving block space and helping to keep the chain clean of all sorts of garbage some mining pool might try to promote.
Mining pools who still would like to signal for specific parameters can use version bits, and for arbitrary data there is op_return.
Nodes might beging applying relay penalties on blocks that have useless data in coinbase, and at a later point stop relaying these blocks completely. At a much later point, nodes might consider any non consensus data in coinbase to be invalid.
This type of UASF has a small benefit of being pretty safe for all users of the network, except for non-complying miners.
Now we're talking!
This is exactly what I'm looking for, smart ideas about how to utilise Bitcoin Core's overwhelming node majority to neuter the BU threats, and to quell the misuse of the activation mechanism to hold Segwit back.
If you don't have any thing like that to offer, you're off topic
This is exactly what I'm looking for, smart ideas about how to utilise Bitcoin Core's overwhelming node majority to neuter the BU threats, and to quell the misuse of the activation mechanism to hold Segwit back.
If you don't have any thing like that to offer, you're off topic
But BU depends on using it's version string for it's divergent consensus mechanism (ExcessiveBlock and AcceptanceDepth signalling is taken from the user string, AFAIA), so faking the version string breaks the mechanism BU can use to disrupt the network.
Maybe we should just change our version string to make them fork into their own network, based on fake information?!
The BIP9 flags are more reliable because the soft-fork activation mechanism directly depends on those flags.
Right.
But BU depends on using it's version string for it's divergent consensus mechanism (ExcessiveBlock and AcceptanceDepth signalling is taken from the user string, AFAIA), so faking the version string breaks the mechanism BU can use to disrupt the network. They're damned if they do, and damned if they don't.
My opinion is not the result of a risk analysis. It's more a personal thing that I don't like to base my reaction on unreliable information. The agent string can be easily faked. The BIP9 flags are more reliable because the soft-fork activation mechanism directly depends on those flags.
I expect that we need such a mechanism even if the BU attack is failing. I predict that we will see the next hard-fork campaign shortly after it turns out that BU failed. What we learned from XT and Classic is that the attackers will never give up until all other users surrender and give them the key to the system.
This is entirely my attitude also.
They're not going to give up, ever. The next campaign is highly likely already being planned. The tactics employed are so aggressive that we're really being left with no choice but to play the antagonist's card; it's exceptionally likely that messy chain re-organisations, network partitioning and chain forks will happen at one point or another.
Preempting messy splits in the network with a decisive, and aggressive, counter move is the best way to handle this (IMO). We've tried being conciliatory, and of course, those who wish to disrupt Bitcoin are too determined, too pathological to simply say "well, I suppose that's reasonable, we'll play nice instead". They will play every dirty tactic, over and over and over again.
The real danger when the disruptors are so hell-bent on forcing extreme conflict, is an invocation of the classic "thesis (bitcoin) <-> antithesis (BU) -> synthesis (neoBU)" dialectic.
In practical terms: prepare a very, very subtly bad idea to be presented as "the ultimate compromise", and to only present that idea to the Bitcoin community when they are in a weak position to think rationally (BU forks, Bitpay Coinbase & DNmarkets follow them, exchange rate crashing, BU forks into BUthis and BUthat.... etc).
If you start with (a modified) step 3 it should not have a major effect on the network: Do not relay new blocks without your preferred BIP 9 bit(s) set. If another block with the same height and the preferred bit(s) set is received, this block is accepted and relayed. There should be no impact to the network if only a few nodes use this policy. If a large number of nodes use this policy this will lead to bad luck for the hostile pool owners.
If a large number of nodes take step 1, the same effect will be realised (gradual erosion of non-compliant mining node's ability to get their blocks into the chain). And the risk of large re-orgs, chain splits and partitioning would exist with both methods, but it seems to me that targeting ~8% of the network that constitute BU nodes initially carries less risk than targeting the ~75% of nodes that constitute non-BIP9 signalers.
Why do you believe starting with a larger proportion of the network carries fewer such risks?
If you start with (a modified) step 3 it should not have a major effect on the network: Do not relay new blocks without your preferred BIP 9 bit(s) set. If another block with the same height and the preferred bit(s) set is received, this block is accepted and relayed. There should be no impact to the network if only a few nodes use this policy. If a large number of nodes use this policy this will lead to bad luck for the hostile pool owners.
I expect that we need such a mechanism even if the BU attack is failing. I predict that we will see the next hard-fork campaign shortly after it turns out that BU failed. What we learned from CT and Classic is that the attackers will never give up until all other users surrender and give them the key to the system.
I expect that we need such a mechanism even if the BU attack is failing. I predict that we will see the next hard-fork campaign shortly after it turns out that BU failed. What we learned from CT and Classic is that the attackers will never give up until all other users surrender and give them the key to the system.
I highly recommend that you don't due this because it can cause network partitioning, potentially persistent chain forks, and further the polarization of the debate.
I understand that risk. I don't believe the issue is insurmountable, and the staged approach reflects this. The risks can be mitigated, and will in the end be worthwhile.
Are you also planning on changing the user agent string used by your software?
No. SegWILL should be indistinguishable from regular nodes of the corresponding version of Bitcoin Core. This is part of the partitioning mitigation, to prevent counter measures against the overall strategy.
I highly recommend that you don't do this because it can cause network partitioning, potentially persistent chain forks, and further the polarization of the debate.
Are you also planning on changing the user agent string used by your software?
Are you also planning on changing the user agent string used by your software?
I will be distributing gitian signed builds.
Anyone who wishes to contribute a gitian signature will be welcome to do so (this is currently a WIP)
Anyone who wishes to contribute a gitian signature will be welcome to do so (this is currently a WIP)
I'm going to attempt to modify the 0.14.x clients, try to popularise the modified client so as to put this nonsense to an end.
I'm done talking with these cowards
Stage 1: BU is pushed to the edges of the network
Add a condition to net_processing::ProcessMessage that detects BU client strings and set the maximum banscore, invoking net::SetBan()
As more nodes run the SegWILL client, BU nodes become pushed to the edge of the network topology, isolating them from the vast majority of nodes (the obvious counter measure is to use regular Core clients as proxies for BU nodes to stay connected to the rest of the Bitcoin nodes, so this simply places the BU nodes around the edge, to make Stage 2 as effective as possible)
...when the effect of this is seen to be sufficient (judged manually by the proportion of nodes running SegWILL), we go to....
Stage 2: BU blocks are no longer relayed
Add a condition to validation::CheckBlock() that detects BU blocks, and rejects them.
BU miners either switch to a Satoshi-consensus client, or go down with the sinking ship
...when the effect of this is seen to be sufficient (judged manually by the proportion of BU blocks entering the chain being sufficiently low), we go to....
Stage 3: Non-BIP9 signalled blocks are no longer relayed
Add a condition to validation::CheckBlock() that detects blocks that lack BIP9 signalling, and rejects them.
If the miners aren't getting the message by this point, this will help them out further; start doing as the network wills, or prepare to enter the paperweight business
IF we can build high levels of support for this plan, and once it is sufficiently refined, I believe we can draw a line under this whole soap opera. We can demonstrate that the people who are actually supporting and or using Bitcoin are ultimately the arbiters of what gets accepted and what gets rejected vis a vis the Bitcoin protocol.
My Personal Message settings are set not to e-mail me any PM's, if that concerns you should you wish to PM me about this. A moderator can hopefully confirm this.
Please comment, on-topic
I'm done talking with these cowards
Stage 1: BU is pushed to the edges of the network
Add a condition to net_processing::ProcessMessage that detects BU client strings and set the maximum banscore, invoking net::SetBan()
As more nodes run the SegWILL client, BU nodes become pushed to the edge of the network topology, isolating them from the vast majority of nodes (the obvious counter measure is to use regular Core clients as proxies for BU nodes to stay connected to the rest of the Bitcoin nodes, so this simply places the BU nodes around the edge, to make Stage 2 as effective as possible)
...when the effect of this is seen to be sufficient (judged manually by the proportion of nodes running SegWILL), we go to....
Stage 2: BU blocks are no longer relayed
Add a condition to validation::CheckBlock() that detects BU blocks, and rejects them.
BU miners either switch to a Satoshi-consensus client, or go down with the sinking ship
...when the effect of this is seen to be sufficient (judged manually by the proportion of BU blocks entering the chain being sufficiently low), we go to....
Stage 3: Non-BIP9 signalled blocks are no longer relayed
Add a condition to validation::CheckBlock() that detects blocks that lack BIP9 signalling, and rejects them.
If the miners aren't getting the message by this point, this will help them out further; start doing as the network wills, or prepare to enter the paperweight business
IF we can build high levels of support for this plan, and once it is sufficiently refined, I believe we can draw a line under this whole soap opera. We can demonstrate that the people who are actually supporting and or using Bitcoin are ultimately the arbiters of what gets accepted and what gets rejected vis a vis the Bitcoin protocol.
My Personal Message settings are set not to e-mail me any PM's, if that concerns you should you wish to PM me about this. A moderator can hopefully confirm this.
Please comment, on-topic
Jump to: