BTC1 with replay protection
MrHash opened this issue · 19 comments
I have taken the liberty of forking btc1 to https://github.com/btc2x/bitcoin and adding a first attempt at replay protection by merging pull request #46 provided by @jameshilliard. Since I am not a competent Bitcoin dev and not affiliated with any camp i'd kindly ask developers from either community to come together to complete the patch so that it may be offered as an safe option for the market.
As the privileged holder of <1 bitcoin I care about it enough that I and thousands of others like me need it to work in the long run either as an investment vehicle and/or as a cash. It seems to me that holders of large amounts of Bitcoin have lost sight of the potential value Bitcoin can bring in future to the majority of small stakeholders.
Perhaps you should give away your holdings and think again about what you need from Bitcoin?
Donations welcome: 1CVEYFNR3axC4BrSWeYUKpbnSX5mcLVPwv :) Feedback welcome.
@MrHash The chain with the highest POW will not need replay protection. Maybe you should merge this into core?
Not wanting to get into a pissing match, but I am the privileged holder of <10K bitcoin.
@Buck-Rogers well actually i think it makes sense to create a fork of core with the necessary replay protection. I asked github for /bitcoin1 but it's not dormant, so yes i think someone should do that. Perhaps core devs can implement replay protection on btc2x and btc1 devs can implement on bitcoin1x?
Replay protection works against the goal of keeping one united Bitcoin. It prevents proper reorgs.
@schildbach let's be honest here, Bitcoin is not united at all is it? I understand the sentiment though but the 'collateral damage' to the network is too risky to not at least have the options of clients with replay protection? I'm not saying you should merge the pull here.
@MrHash The option is already in the code – any user can create transactions that are only valid one side of the fork (after it happened). What replay protection usually means is that the separation is mandatory and users cannot opt to create transactions that are valid on both sides.
@schildbach thanks i appreciate the clarification. Could you explain why there is an assumption people would want to execute a transaction on both chains as a default?
In the spirit of fairness I have forked bitcoin to https://github.com/bitcoin1x/bitcoin so if any btc1 devs would like to provide PRs over there then that would be great.
@JaredR26 as I understand it the btc1/2x chain doesn't even exist yet so I don't see it can be claimed that it has any formal consensus? It may well be that your chain has such a consensus in future but riding on that assumption is high order hubris. Anyway it has been made clear neither core nor btc1 will add the protection to their own clients, so i'm asking btc1 to add it to core at /bitcoin1x and i'm asking core to add it to btc1 at /btc2x so the market can decide instead of the developers. Surely this is an ideal form of decentralized development.
-
Replay protection is tracked in Issue #34
-
Opt-out replay protection creates chain splits and eliminates the method that @schildbach described; it breaks SPV wallets that would otherwise work.
-
Opt-in replay protection seems reasonable (at least to me; not speaking for the group). We can create a PR for that to invite criticism and review.
You are welcome to submit anti-replay PRs for discussion and reviews.
@JaredR26 as I understand it the btc1/2x chain doesn't even exist yet so I don't see it can be claimed that it has any formal consensus?
By that logic, it doesn't exist yet, so it doesn't need replay protection.
It may well be that your chain has such a consensus in future but riding on that assumption is high order hubris.
Pushing a change to remove companies from bitcoin.org for saying bad things about the Theymos-favored chain is high order hubris. Looking at readily available evidence and statistics to determine likely outcomes is called common sense.
so i'm asking btc1 to add it to core at /bitcoin1x and i'm asking core to add it to btc1 at /btc2x so the market can decide instead of the developers.
Go ahead and do it yourself. UASF made their coin and claim it worked very well. You can too.
Ok Roger this wasn't about who's right or wrong, it's about protecting the users. It's sad that the community will suffer over these power plays.
There is no power plays, this is a very simple thing. The NYA was not very complicated. As a result, ONLY the following things will be done:
- Constant for maximum block size changes from 1,000,000 bytes to 2,000,000 bytes or constant for maximum block weight changes from 4,000,000 to 8,000,000 for SegWit clients.
- Constant for maximum amount of sigops changes from 20,000 to 40,000 for non-SegWit clients, and from 80,000 to 160,000 for SegWit clients.
It's that simple. Well over 90% of the miners are still on board, despite concerted efforts to FUD things up. If you, or Bitcoin Core or anybody disagrees with the above changes, go ahead and write code you think some or all of the ecosystem will adopt. I will happily buy MrHashCoins if you succeed and MrHashCoins are worth something someday. But if you advocating for changes other than the two above, this is the wrong place.
Ok Roger this wasn't about who's right or wrong, it's about protecting the users.
There are two easy ways that those requesting that we break compatibility could "protect the users."
- Actually accept the compromise reached by everyone who isn't them
- Add replay protection and pursue their small-block vision without holding an entire ecosystem back
No one has provided me with any valid reasons why Core cannot do either of those things right now. I've even proposed that both chains add replay protection at the same moment and guarantee that the ecosystem makes a choice. If they choose not to take the actions they claim to want to "protect the users," that's on them. Based on all the real data I've seen, btc1 does not represent a threat to any users period except those who are irrationally opposed to blocksize hardforks. The legacy chain is likely to have less than 2 blocks a day, less than BCH had before its difficulty adjustments kicked in.
@mpatc Well Bitcoin Hash does have a nice ring to it.. :)
I've even proposed that both chains add replay protection at the same moment and guarantee that the ecosystem makes a choice.
Obviously both sides are proud of their lineage so it's understandable neither side will implement or release the modifications in their own client of their own volition, hence my suggestion to actually prepare replay protected releases on each side by opposing teams. If we consider the possibility that not all signalling miners will immediately jump chain there could be a much more contentious outcome than you are envisioning.
If we consider the possibility that not all signalling miners will immediately jump chain
btc1 is built on the assumption and around the goal that it has consensus from the ecosystem. If that turns out to have been an incorrect assumption, the intention for btc1 is to fail rather than creating a third coin. btc1 is the choice of many moderates precisely because it seems to have the best chance of holding the ecosystem together, despite the fractures that are guaranteed between Luke's PoW change and BCC's rejection of segwit.
Ok thanks for clarifying the goals.