-
Notifications
You must be signed in to change notification settings - Fork 55
Add opt-in transaction avoidance using well known P2SH address #127
Conversation
Based on a gist by @gavinandresen at https://gist.github.com/gavinandresen/2a7474a3dd5b834ed3a7d10c74ec84c5 Transactions may contain a marker, a transaction output (txout) constructed as: OP_RETURN 'RP=!>1x' 1) All transactions containing this marker are considered non-standard, and not relayed or mined by default. They may appear in a block ("valid"), but the software will not do this by default. This is normal behavior for any valid-but-nonstandard transaction. 2) After the BIP102 hard fork point (fSegwitSeasoned), transactions containing this marker are considered invalid. Blocks must not contain transactions with a 'RP=!>1x' marker.
Transactions may contain a marker output (txout) constructed as: `OP_HASH160 e77dfed888d33a87c2f48849f54dc55f4e63e7b4 OP_EQUAL` This is a P2SH output with the vanity address: `3No2xBD2uteCaTNGLpFkyoin4ctgeGMRLs`. To avoid indefinitely expanding the UTXO set, these outputs can be spent by anyone using the intentionally concise scriptSig `03165c4d`. 1) All transactions containing this marker are considered non-standard, and not relayed or mined by default. They may appear in a block ("valid"), but the software will not do this by default. This is normal behavior for any valid-but-nonstandard transaction. 2) After the BIP102 hard fork point (fSegwitSeasoned), transactions containing this marker are considered invalid. Blocks must not contain outputs to the `3No2xBD2uteCaTNGLpFkyoin4ctgeGMRLs` address.
Here's an example replay protected tx that outputs the minim 2730 satoshi amount for a standard transaction.
Here's an example tx that redeems one of these replay protected outputs:
This transaction is 56 bytes and looks like: In this case all output is being spent as a fee, which comes out as UPDATE: The proposal has been changed to use the following:
|
This might result in phishers publishing tutorials, but with a visually similar address. They would then promote those using google adwords. Google is notoriously lazy in removing those. Even legit tutorial authors might find their blog hacked. I think it's safer to build replay protection into wallets using a method that's non-trivial for a normal users to do manually. |
Can you clarify (1): do you mean such a transaction is non-standard for btc1 nodes? |
The prefix is meant only as a partial mitigation for copy-paste errors. Building replay protection into wallets would be better, but realistically (if Bitcoin Cash is anything to go by) this is going to take a while. Doing it this way makes it non-scary for anyone with a little bitcoin experience:
Such a transaction would be non-standard before the fork and invalid after the fork. Perhaps it should simply be non-standard and invalid after the fork? Perhaps @jgarzik could comment. |
The `3No2x` prefix only makes sense for explicitly Segwit2x supporting nodes. There are other nodes that support larger blocks that will follow the 2x mined chain. Change to a more neutral `3Bit1x` prefix that also makes sense for them.
Opt-in replay protection is not enough as it does not prevent transaction from being included in the block. And with malicious behavior of miners we see today (triggering EDA on Bitcoin Cash by not mining, then mining blocks as fast as possible with lowered difficulty), they cannot be trusted not to include these transactions in their blocks. |
@prusnak Read the code - it prevents the transaction from being included in a block. |
I like the concept and the approaches. I don't personally see anything wrong with providing multiple methods, even if the methods make eachother redundant, which is something I have seen suggested elsewhere. Also I like the more neutral addresses you found like 3Bit1x... All of the approaches that invalidate a transaction on 2x need to have a sunset clause. I suggest 18-24 months out based on blockheight. |
I'm definitely in favor of a sunset clause. If this rule turns out still to be necessary, we can easily soft-fork it back in. That's a lot better than committing to this added complexity forever. Since this form of replay protection doesn't require any special software and can easily be done by the user, my preference would be to have a sunset date that is easily described and meaningful. The next halving happens on block 630000 (roughly 15 Jun 2020). This is something that would be memorable to many bitcoin users and easy to describe. We can take a view before this date arrives whether there are better options available ( |
I've updated this PR to use the following: scriptAddress: 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi The TestNet version of this address |
Manually merged into |
There is already user confusion about this: It is important that users understand that spending to this address before the split doesn't do anything; and that spending to the address after the split will not protect their entire wallet unless they spend all of their coins at once. |
@jgarzik how does BitcoinUnlimited/BitcoinUnlimited#790 (which only uses non-standardness) to your manual merge in a3c4125 (which also makes the transaction invalid)? Update: never mind, that was a PR for BU, not for btc1. |
Based on #117 by @gavinandresen and @jgarzik.
Transactions may contain a marker output (txout) constructed as:
OP_HASH160 6e0b7d51f9f68ba28cc33a6844d41a1880c58a19 OP_EQUAL
This is a P2SH output with the vanity address:
3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi
.To avoid indefinitely expanding the UTXO set, these outputs can be
spent by anyone using the intentionally concise scriptSig
03165c4d
.All transactions containing this marker are considered non-standard,
and not relayed or mined by default. They may appear in a block
("valid"), but the software will not do this by default. This is
normal behavior for any valid-but-nonstandard transaction.
After the BIP102 hard fork point (fSegwitSeasoned), transactions
containing this marker are considered invalid. Blocks must not contain
outputs to the
3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi
address.