Fork address versions #101
Comments
|
ACK We have reports of people accidentally sending Bcash to BTC addresses and vice-versa, resulting in losses that would have been easily avoidable if Bcash had properly used a different address type. Again, note how all wallet software needs to be updated to safely support this proposed hard fork, so changing addresses can added as part of this necessary update. |
|
NACK This appears to be yet another attempt by a competing development team to cause a portion of the ecosystem to default to following the minority chain which may not even be a viable chain at all. If the competing development team wishes to implement this on the minority chain, they are free to do so. This could possibly be added as an optional opt-in feature on both chains simultaneously, but like other changes intended to cause clients confusion or to cause them to default to the minority chain, this shouldn't be implemented unilaterally on the majority chain. |
|
Giving users a choice of chains is clearly better than accidentally losing money. |
So the minority chain and the majority chain can both do this, yes? If the answer is not yes, this discussion is over. |
|
@petertodd do you mean Bitcoin Cash? (bcash isn't released yet) Only core clients will need to be updated the majority will already follow the upgraded chain by default. If Core want to make sure they survive on the minority fork they must add necessary changes to it's software to give users the choice that is asked here. |
|
Strong ACK. We have seen several instances where users unintentionally send BTC to BCH addresses which has resulted in a loss of funds in some cases since certain exchanges refuse to recover the funds, or because they do not control the private key of the destination address. Before chalking this up as a simple "user error", responsible action should be taken to avoid loss of user funds due to such easily preventable mishaps. Therefore, a unique address format must be a prerequisite for any looming fork attempts. This responsibility lies solely on the entity designing the fork attempt. This is no time for deceptive bickering. |
Then both Core and btc1 can implement this simultaneously and activate it at the same blockheight. If they choose not to, that's on them.
You mean like banning everyone who doesn't agree with your agenda? |
|
@JaredR26 Please take your politics elsewhere. |
|
NACK @petertodd if you're concerned about preventing people from wasting their money, how is this a thing? https://blockchain.info/address/1BitcoinEaterAddressDontSendf59kuE The fact that people can be stupid doesn't mean we need to work to save them from their stupidity. |
|
This project is not the first hard fork, not likely the last, and no hard fork will every get 100% of the hash rate. Every time any project hard forks the Bitcoin chain, they should do so responsibly by making it clear to users which chain they are transacting with. I would expect Core to do the same if/when they ever need to hard fork. |
Do you have any actual txids to support this statement, or are you basing this on reddit comments?
The single bitcoin eater address I linked to above has over $45K wasted on it. There are many others. If preventing user error like this is so important to you, why haven't I seen a Bcore PR to validate send addresses before sending? Or Bcore could simply reject transactions that contain provably unspendable outputs, but you haven't implemented that. But a similar problem is really important in this case because.... ??? |
Core does validate addresses before sending. The address you linked is a valid address.
The address you linked is not provably unspendable, nor would be any current Segwit2x addresses. |
|
@betawaffle, IIRC OpenBazaar has implemented bitcoin burn addresses as a reputation-building system, and these address are provably unspendable. I'm not a cryptographer, but I would suspect the bitcoin eater address is not a valid hash of a public key. |
If you can prove that, please do. |
|
Not that particular one, but here you go: |
|
The point is, the information necessary to prove something like the linked address being unspendable is not available. Especially not to node software in any generalized sense. But the topic is not sending to burn addresses, it is about sending to perfectly valid addresses on the wrong chain. |
No, the point is the core network currently offers many ways for users to "mess up" and lose their coin. People can (intentionally or otherwise) provably burn their bitcoin, and bcore allows this. There are many potential areas we could put training wheels on the protocol to help minimize user error, but this isn't a priority, unless there is evidence that it's a real problem. I still have yet to see a single txid of this happening in the wild, or any significant loss due to this. It's all just reddit claims at this point.
These are essentially the same thing. This seems like a solution in search of a problem, since it's a pretty difficult "mistake" to actually make. |
wrong |
Fundamentally this issue comes down to differing visions for what Bitcoin is and should become. Core should have recognized these differences over a year ago and offered people - particularly the markets - a choice; Instead they went with the default course of action and force people to follow them or be kicked out of the communities that predated the issue. Those days are over. Competing development teams have sprung up and stuck around to get past the blockade. Enough people have been banned from the major communities due to censorship to form their own vibrant and rapidly growing community, and have become big enough that now the original community brigades them instead of the other way around. Overwhelming consensus has been reached outside core by compromise, as it should have been reached a year ago. If Core wishes to reject all compromises and try to have as much of the community follow their fork by default, that is not the fault of the outside super-majority who are trying to arrange the smoothest transition. If Core wishes to implement the very features they are demanding of this project, we could have fruitful discussions on a clean fork. But pretending it is the responsibility of the super-majority to allow all existing systems to default to the minority chain (again) is deceptive. If Core truly wants to take the steps for a clean fork, most of the demanded changes can be done as opt-in or could be done simultaneously on each side as a forcing function. One side, especially the supermajority, doing the change that benefits the other side unilaterally is not going to fly, no matter how much you pretend that it is really all about the users. If it was about the users, Core could implement the changes just as easily. |
|
Fundamentally, this issue is about giving users a clear view into which chain they are transacting on. The NYA2X hard fork will survive for awhile even if users know when they are transacting on a bloated 2X chain. No good would be served by tricking users into following a hard fork. |
Let's keep it professional, we should always assume good faith. Nobody here is trying to trick users. This is a straw-man argument. |
And this can be done on both chains if it is truly a problem, there is no reason not to do so.
In my eyes, this issue is very similar to the numerous other issues raised that encouraged hardfork version bits to be changed, or encouraged transaction compatibility to be broken in a non-optional manner, or encouraged non-upgraded clients to be disconnected from nodes. The issue with all of those is what happens with the default users, and how much difficulty it adds for the ecosystem if the legacy chain is not viable and dies. This concept adds difficulty to the fork if the legacy chain dies, and it breaks compatibility that would otherwise work fine. If the minority chain is not willing to add this, it must not be a big enough problem to be added here either. |
|
@JaredR26 stop with your bizarre tirades, conspiracy theories and trolling. |
|
The overwhelming body of bitcoin users HAVE decided in favor of the Core devs' version. Careful, deliberative, well-tested code has brought bitcoin through thick and thin, and will continue to do so henceforth. It's not Core's job to fix rushed, irresponsible code dumped onto the network by forkers. It IS Core's job to protect users' considerable investments from hostile takeover attempts by implementing measures they deem necessary, imo. |
|
@CosmicHemorroid Not the place for personal attacks. Please do it somewhere else. |
|
What about the children? Won't anyone think of the children? |
This is false. They have followed the default client that the current set of core developers inherited when the schism originally happened in late 2015.
It isn't the job of the majority fork to cater to the minority fork. Core refusing to compromise is the source of this problem, not the overwhelming majority fork. Also this fork isn't rushed by comparison with any other examples of other hardforks, including BCC/BCH or ETC/ETH. The only people calling this fork "rushed" are the same set of core developers who have opposed every other fork in the past. Color me surprised. If this is a big enough issue to warrant inclusion here, it is a big enough issue to warrant inclusion in the minority fork. If it isn't there, it isn't here. |
|
@mpatc Your bias is showing. This whole bizarre conspiracy tirade belongs on reddit, not here.---> "Fundamentally this issue comes down to differing visions for what Bitcoin is and should become. Core should have recognized these differences over a year ago and offered people - particularly the markets - a choice; Instead they went with the default course of action and force people to follow them or be kicked out of the communities that predated the issue. Those days are over. Competing development teams have sprung up and stuck around to get past the blockade. Enough people have been banned from the major communities due to censorship to form their own vibrant and rapidly growing community, and have become big enough that now the original community brigades them instead of the other way around. Overwhelming consensus has been reached outside core by compromise, as it should have been reached a year ago. If Core wishes to reject all compromises and try to have as much of the community follow their fork by default, that is not the fault of the outside super-majority who are trying to arrange the smoothest transition. If Core wishes to implement the very features they are demanding of this project, we could have fruitful discussions on a clean fork. But pretending it is the responsibility of the super-majority to allow all existing systems to default to the minority chain (again) is deceptive. If Core truly wants to take the steps for a clean fork, most of the demanded changes can be done as opt-in or could be done simultaneously on each side as a forcing function. One side, especially the supermajority, doing the change that benefits the other side unilaterally is not going to fly, no matter how much you pretend that it is really all about the users. If it was about the users, Core could implement the changes just as easily." |
|
Ok, point taken. We are not trying to trick users, so to make it clear to users which chain they are transacting on, the hard-forking chain should fork the address version. |
|
@CosmicHemorroid my "bias" is irrelevant. You need to treat others with respect if you want to participate here. Calling other people's ideas "bizarre" or "conspiracies", labeling those stating their opinions as going on "tirades" and accusations of trolling do not belong here. Please follow the rules and be nice to others, even if you strongly disagree. |
|
@NiKiZe you keep thinking that. |
|
OK, let's try again: @rodasmith your request is insufficient, because it would default users to the legacy chain. The legacy chain is being abandoned, closed down, and replaced, like those old tiny subway tubes through which the new trains no longer travel. This upgrade has been planned more than a year ago. It is an upgrade, and its goal is to break backwards compatibility as little as possible. So far you are rehashing the same argument. Not constructive. Merely amusing. |
|
The 1X chain is certainly not going to be abandoned. Only 1 adjustment interval is required to fix the economics. You cannot hijack users onto your chain as easily as you think. Users control bitcoin. Give them the choice of which chain to follow by forking address versions. |
As we've stated, this is not acceptable. We can discuss backwards compatible changes, but backwards incompatible changes are not going to be accepted here, as has been stated several times.
This is not true for most users. They don't know or care about these forks or either philosophy. Most users don't even care enough to sell their BCC. They just want Bitcoin to be usable. |
|
@rodasmith whenever we have these discussions the Bitcoin Core supporters pretty much always come with an argument that goes like this:
So, this abstract entity "the users", who must be consulted somehow, comes often. Who are these users? How do you measure their support or lack thereof for changes? Let's try...
Some of these groups are hard to quantify. But among those that aren't are: industry, that itself represents many other subgroups (a wallet provider or exchange represents its users), and miners. Those have voices, large user bases that can boycott these companies in case they support something that is not favourable to them. They have overwhelmingly agreed to upgrade. If you are not happy with it, go gather all the support you can, get some mining equipment and start pouring some hashpower into the network supporting your opinion. In order words: put your money where your mouth is, because that's the way we vote around here. |
|
One good way to measure their support would be by forking the address version. Another would be to watch which chain gets traded up, and which gets traded down. |
Absolutely but with 10% hashrate and 864 blocks left (when the upgrade happens) until re-target that means going from 10minutes blocks to 100minutes blocks. That will take around 60 days, with 20% hashrate it will take around 30 days. So it will take quite some time for the "economics" to be fixed on a chain that do not follow this upgrade. |
|
@NiKiZe you forget that the mempool can be a miner bounty. |
|
@NiKiZe not only that, but add that the chain would be at a high risk of getting wiped out by even a sliver of the majority hashrate. Would you trust your transactions on a chain that you know can be double-spent because it has only a tiny proportion of the hash power available for that algorithm? The legacy chain is not viable after the upgrade, and we all better accept that and move on. |
|
I just want to quote this because it is so incredibly well said. Many people are so focused on what they want from Bitcoin and what they think Bitcoin is that they forget to see the larger picture of how other people use Bitcoin:
Very very well said @XenoG. |
|
Why do people take support from miners, or anyone else for that matter, for granted if btc1 chose to break the NY agreement? Protection against double spending, and spending on the wrong fork by accident, is an absolute necessity for a safe fork. We can discuss how this can be done in the least intrusive manner possible, but it must be done. If btc1 choose to violate the agreement, I am afraid the only part we will see activated is segwit. |
Because if the agreement is widely abandoned, the fork should fail. The premise of this project is that we have the agreement and we have consensus. We aren't BCC who are willing to fork off at any costs because we loathe Segwit. Different project goals, different project requirements. |
|
Users did not all agree to the fork, but the "industry" (corporations and miners) did. So the industry should hard fork safely, by forking the address version and letting users choose their chain. |
|
"Users" have the same ability as miners to get some ASICs and vote with hash power. the issue here seems to not be about "agreements", but rather the outcome is unfavorable to you because you cannot afford to "vote". |
|
Miners don't really "vote". They order users' transactions and lock them into the blockchain, following whatever rules the users want. Users vote by spending or acquiring coins. |
|
NACK. I hope Jeff shuts this thread down soonish. |
/shrug but to get back on topic, the onus should be on the minority client to implement their own protection. |
|
ACK, the inclusion of this fix would enable users to differentiate between their chain versions, especially during a transition period. Visually, It presents the cleanest point of recognition to the end user as to which chain they are about to transact on, especially when sending to legacy users that may not have upgraded their systems yet; for whatever reason. I am certainly not interested in creating a calamity amongst end users ignorant of what is going on, and it is preferable to prevent them from making that mistake in the first place. I notice plenty of mention of support levels in the industry, as far as the NYA agreement is concerned. Unfortunately, contrary to assertations here, it is not nearly as clear-cut as many would like us to believe: From the Coin Dance political monitoring, we can see that Segwit, now locked, has 54% support with a further 33% readiness for a total of 87% of the industry. Only 6% were in opposition. In terms of the Segwit2X agreement itself, we have 21% in favour with 2% opposed, with the remainder being uncommitted. I do not find this an encouraging indication of overall industry support, contrary to popular belief. As matters currently stand, normally we would simply do the Segwit deployment, let everyone catch up, test everything properly, and mitigate problems that arise. That way, following testing, a much more comprehensive Hard fork could be deployed with far more interesting technologies than a simple block size increase; I am not against block size increases, I am simply calling for a more engineer orientated strategy with less likelihood of trouble, a call to sensibility and for people to cool down a bit. |
You're referencing the unweighted numbers. That counts BFGMiner, a dead project that no one uses, the same as Coinbase with more U.S. customers than any other company. Enable weighting, the picture changes drastically. Why does it change so drastically? Well, you tell me how so many pet projects of core developers/supporters like Bitcoin Knots, https://bitcoinembassy.ca/, https://bitkonan.com/, http://epiphyte.com/, http://docs.qbitninja.apiary.io/, and http://yogh.io/ got onto the list. That's why they had to create the weighting system without censoring people's opinions. After you enable weighting segwit2x has 46% support, 0% opposed. Segwit support drops to 28% - Right in line with the 33% of miners who were signaling it prior to segwit2x, with 10% opposed.
How about now? Or did you come here with your mind already made up and like some others whose goal seems to be just to make this project look bad? |
|
@JaredR26 Hello Mr Ver, your reputation precedes you. The weighting change does change the picture from one of the entities having equal voting to those with the most influence as you say; somewhat similar to the system known as a monarchy, but I digress. One thing that strikes me most about the figures is that, with the weighting, the changes currently underway would actually be being carried out by a minority of support. I know that with you having grown up in a representative republic that this may not seem strange, but to those of us who have grown up and voted in democracies this would be seen as a lack of support. From this, and the actual action we are seeing in the field, I can only surmise that no-one can really conclude anything from any figures presented; regardless of source. When working in such a situation, the best approach is the one that does the least harm; I'm not sure if you have had a family member who worked in politics, but I can assure you it is never a simple process. The biggest takeaway from any process is for all sides to compromise, this particular offering (101) is a compromise that reduces harm, and does not increase it. As for this project overall, for the industry, we need all projects to be able to stand on their own two feet, without chopping the legs out from everyone else. The Segwit2X project does have its issues, as does any project, the main aim should be to fix them before they produce an irreparable result that could damage it fatally; both technically and politically. |
46% in favor, 0% opposed, heavily skewed by shell projects without weighting enabled... Yep, absolutely no conclusions can be drawn here!
It is a well known fact that Coinbase's CEO is in fact a King. Jihan is too young, he is merely a Prince. I'm a Knight, Ser JaredR26.
Not invalidating a massive number of existing addresses across the entire ecosystem == least harm.
Uh, you might want to go talk to the core developers about that...
Not breaking our own compatibility has nothing to do with this. You might talk to Bitcoin Core about their recent merge to blacklist competing clients prematurely, though.
Well, I guess I got the answer. |
|
Strong ACK @jgarzik recently tweeted this:
Source: https://twitter.com/jgarzik/status/893133969314721793 I could not agree more. Easy jumping is a huge positive. Lets make it as easy as possible. I think freedom and markets are great. Lets support the freedom of choice and seamless trading between BTC and S2X. In order to facilitate the free markets and freedom of choice, lets implement: 1. New P2P layer - Rolled out before the hardfork, rather than expecting new p2p systems to emerge in an instant when the first hardfork block happens 2. New address formats - To prevent errors and confusion of people sending to the wrong address 3. Strong 2 way replay protection enabled by default - To prevent customers and exchanges from losing funds 4. A modification to the block header, ensuring all wallets need to upgrade - To ensure wallets follow the same chain their transactions are valid on Luckily the exchanges and businesses in the space are starting to show strong support these changes, to help free markets and freedom of choice: On strong two way replay protection Bitfinex/Bitstamp/Bittrex/BTCC/Kraken/ShapeShift + others
Source: https://www.bitfinex.com/bitcoin_hardfork_statement Poloniex
Source: https://poloniex.com/press-releases/2017.03.17-Hard-Fork/ BitGo
Source: https://blog.bitgo.com/bitgos-approach-to-handling-a-hard-fork-71e572506d7d BitMEX
Source: https://blog.bitmex.com/policy-on-bitcoin-hard-forks/ On modifications to the block header BitMEX
Source: https://blog.bitmex.com/policy-on-bitcoin-hard-forks/ @jgarzik please implement these changes. Or industry will have no choice but to reject supporting the S2X token, as they clearly explained |
|
It seems like this issue is settled? I think this should be closed.
…On Aug 8, 2017 11:14 PM, "jonny1000" ***@***.***> wrote:
Strong ACK
@jgarzik <https://github.com/jgarzik> recently tweeted this:
It is GREAT for free market and competition that users can easily jump
between ETH / ETC, BTC / BCC, BTC / LTC #interoperability #open
Source: https://twitter.com/jgarzik/status/893133969314721793
I could not agree more. I think freedom and markets are great. Lets
support the freedom of choice and seamless trading between BTC and S2X.
In order to facilitate the free markets and freedom of choice, lets
implement:
*1. New P2P layer* - Rolled out before the hardfork, rather than
expecting new p2p systems to emerge in an instant when the first hardfork
block happens
*2. New address formats* - To prevent errors and confusion of people
sending to the wrong address
*3. Strong 2 way replay protection enabled by default* - To prevent
customers and exchanges from losing funds
*4. A modification to the block header, ensuring all wallets need to
upgrade* - To ensure wallets follow the same chain their transactions are
valid on
Luckily the exchanges and businesses in the space are starting to show
strong support these changes, to help free markets and freedom of choice:
*On strong two way replay protection*
*Bitfinex/Bitstamp/Bittrex/BTCC/Kraken/ShapeShift + others*
we insist that the Bitcoin Unlimited community (*or any other consensus
breaking implementation*) build in strong two-way replay protection
Source: https://www.bitfinex.com/bitcoin_hardfork_statement
*Poloniex*
At a minimum, any new fork must include built-in replay protection
Source: https://poloniex.com/press-releases/2017.03.17-Hard-Fork/
*BitGo*
The hard fork must provide strong 2-way replay protection. This means that
transactions valid on one chain should be invalid on the other
Source: https://blog.bitgo.com/bitgos-approach-to-handling-a-hard-
fork-71e572506d7d
*BitMEX*
Strong two-way replay protection, enabled by default, such that
transactions on each chain are invalid on the other chain.
Source: https://blog.bitmex.com/policy-on-bitcoin-hard-forks/
*On modifications to the block header*
**BitMEX **
A modification to the block header such that all wallets (including light
clients) are required to upgrade to follow the new chain.
Source: https://blog.bitmex.com/policy-on-bitcoin-hard-forks/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#101 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/APNcvuBO5evmj_pmZzuwGngJ8B5I7cjAks5sWSQygaJpZM4Ou32f>
.
|
|
Sorry I didn't reply. I was sleeping. Conversations with four-year-old children go like: – Jhonny: Mommy, I want ice cream Now Internt trolls are just like Jhonny. My daughter will be four in a couple of years, and I am training, preparing for that. This thread is doing a great job. So I will continue playing mommy, you small-block fundamentalists carry on playing Jhonny, what do you think? Today it will have to be after work though. We grown-ups have jobs. Alternatively we can have an adult conversation that moves forward about replay protection in the smaller chain, and then we may consider adding replay protection to the larger chain, so that when chicken block day comes, users are confronted with a choice that they cannot refuse to make, for which there is no default action that favours a particular chain. |
Also the jhonnies, together with all the best whiners, will have a job, at blockstream. |
|
@XenoG If this is what you mean by "adult conversation", it says a lot about you an your parents. johnny1000 has some very good points, and both I and others are concerned due to lack of clear signals from the btc1 project that they are going to follow up on the rest of the NY agreement after activating segwit, making both miners and exchanges withdraw their signatures. Some of the singatories have already deviated by supporting "Bitcoin Cash" as an alternative, and this is also getting mining support from an unknown entity which some suspect to have signed the agreement as well. I don't think a chaotic hard fork supported by a minority of the hashrate and almost no exchanges will be very successful. jgarzik seem to be the only developer in this project. He has still not made clear how btc1 will make sure the hard fork is deployed safely, albeit giving positive signals on Twitter earlier. |
Reading the agreement it is about the future after upgrading to greater then 1MB blocks.
Who are now supporting Bitcoin Cash instead?
Looking at https://coin.dance/blocks just now the minority you are talking about has over 90% of the hash rate - in my dictionary that is a majority. |
|
Not a compatible change. |
and others
Problem
Addresses for standard transactions in the 2X chain look like addresses in the 1X chain, so users may not realize which chain to use to send to a given P2PKH, P2SH, or bech32 address. Anyone who sends to an address on the wrong chain could lose money, so it should be clear from an address which chain it belongs to.
Mitigation option
Change the version for P2PKH addresses (the number that results in the "1..." prefix for addresses in the 1X chain), P2SH addresses (the version number that makes "3..." addresses in the 1X chain), and bech32 (future state SegWit addresses prefixed "bc1..." in the 1X chain).
[removed technically inaccurate secondary detail]
The text was updated successfully, but these errors were encountered: