Topic: Looking ahead to the next ill-advised hard fork.... (Read 638 times)

While certainly better than nothing, this also means somebody could just keep replaying and slowly bleed you out via miner fees. Worst case scenario, the chains get jammed up due to this. (Not Armory's fault, obviously.)


My instinct is to go with whatever will let users know that there could be turbulence, with the option for users to turn off the warning. Crappy, I know, but I have a bad feeling this fork is going to be jammed through with very little external testing, if any. Also, I believe it was Bitpay who surreptitiously tried to get miners to use btc1 when upgrading to handle SegWit. Who knows what other tricks signatories will use to get people to install some frankennode. When (not if) these come knocking and asking for help, it'd be good to have a plan.

As for wipeout protection, I seriously doubt that it does. The few PRs I've looked at gave me the impression that they're trying to do the bare minimum to meet their dumb agreement.

No idea. How can I tell SINCE THERE'S NO TESTNET TO WORK AGAINST?


1) The OP_RETURN stuff makes the tx non standard, not invalid. In other words, nodes won't propagate it, but angry enough attackers can choose to mine them anyways.

2) With any form of opt-in tainting, the only sane path forward is sending coins back to yourself on both ends until you can verify your UTXO set divergence has confirmed on both sides of the split. Whether you do this with their convenience OP_RETURN method, or through RBF, LockTime, using coinbase transactions or whatever else you can think of, the end result is the same:

You can only demonstrably prove your coins are tainted after you have confirmations of a divergent UTXO on both chains.

Bitcoin transactions are final, replay attacks are a real threat! Therefor, there is no reasonable argument for simply trusting the opt-in protection when you can actually verify its effect.

I believe that that is their plan, but there isn't a spec for anything that they are doing and that plan may not actually happen as they hoped so. Jeff Garzik has been repeatedly confused by/conflating block weight and block size such that the first time he tried to increase the maximum block size in btc1, he failed to do so because he had changed some constant related to block size not block weight. A lot of things in btc1 seem to be related to block size rather than block weight which is very stupid as segwit defines the limit by block weight and not size. So I wouldn't be surprised if Jeff Garzik failed to properly write code that makes a block have a weight greater than 4 million because he was thinking of things in terms of size rather than weight.

... This piece of the puzzle is easy and already well-understood. I had assumed that btc1 was going to insist on it's forking-block being over 4MB in weight, a simple and elegant solution to the wipeout risk.... They couldn't possibly be stupid enough to not do that, could they?

I don't understand?  If I have a pre-split UTXO, and I send it back to myself with their magic value in an OP_RETURN the transaction is not valid on the btc1 chain, and the resulting UTXO may be spent freely with no risk of replay, and can also be used to taint other UTXOs [At the expense of privacy]. Once the BTC transaction is confirmed, the same UTXO may be spent freely on btc1 with no risk as the UTXO is already spent on Bitcoin....

I'm not adding GUI elements to hand hold if that's what you're referring to. The opt-out is simple enough to use: send coins back to yourself until you're sure you have correctly tainted, regardless of the tainting method.

If a users lack the patience to execute this, or the knowledge to understand what he is doing, he will need to take time to educate himself on the matter. I'll put out a guide as with BCH.

What I could do, since 2x insists upon the lack of 2 way replay protection, could be to detect the fork by its fork point and issue a message box warning whenever someone is trying to spend a UTXO that predates the fork point. However, not knowing if 2x has wipeout protection, detection may get a whole lot harder than just hardcoding a header hash and checking against it.


Both are shit. The bare minimum requirements for a clean HF are (in descending order):

1) wipeout protection
2) 2-way mandatory replay protection
3) make testnet available about a year before the HF (you should FF then)
4) change script hash prefixes to reflect the new mainnet and testnet, and change network ports

I don't even know if 2X is trying to get 1) right.

As for the details, the second method is sensibly worst than the first since it naturally suggests a UTXO consolidation strategy that will result in a massive privacy leak. Fungibility be damned!

Both methods fail anyways, since they do not provide a strong guarantee of replay protection to begin with. Therefor you are left with spending coins back to yourself until you get lots of confirmations on an actual taint. Therefor, these methods, whichever they end up going with, are basically pointless shortcuts that do not significantly impact the complexity of a "raw" tainting procedure.

I vote for the fewest possible changes involving the least-possible amount of programming time to enable users to split their UTXOs. BCH announced to the world that the wallet community will bend over backwards to support whatever broken shit the hard-forkers spew out at the last moment.  I'd suggest not reinforcing that message.

The two proposals I've seen are a magic OP_RETURN value [which is not supported by most wallets, but is supported by Armory], or an output to a magic P2SH address [Much more bloat, and it bloats the UTXO-set too], which can be done with any existing wallet.

The question ultimately cannot be answered until we actually know for sure what will be implemented.

Good lord, will anybody be able to test the final code more than, say, two days before it's supposed to go live? Yet another reason marketers have no business setting these ridiculous deadlines in the first place. Doesn't anybody remember how people auto-scanned transactions when the Android RNG bug meant you could brute force coins into any address you wanted? I suppose the 2X people would say that somebody setting up a server that drains BTC addresses whenever a 2X transaction goes out is a feature.

In any event, on the off chance that the fork goes through and is actually used, I suppose this opens up an interesting question for Armory. Should Armory enforce the opt-in (if it gets added, which I suppose will happen at the last minute), and explicitly require users to opt out? My initial thought is that the stakes are too high to risk people getting burned, especially considering how...challenging it is to communicate instructions to some Armory users. But, I'm open to ideas.

Their current proposal (not yet merged into the btc1 repo) is to have opt-in replay protection by marking transactions containing an OP_RETURN output with the string "RP=!>1x". This is still just a proposal and is not finalized. The github thread about this discussion is here: https://github.com/btc1/bitcoin/pull/117 (and its a complete shitshow).

I believe it's some sort of OP_RETURN output. You can create those in Armory if you are set to expert mode.

My understanding is btc1 has implemented one-way replay protection, where transactions that include some magic value are not valid on the btc1 chain.

Does anyone know any details about how this is implemented, and what the status of Armory support for it will be?