Add opt-in transaction avoidance using well known P2SH address #127

jcansdale · 2017-09-29T13:37:54Z

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.

@gavinandresen

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.

jcansdale · 2017-09-29T14:06:03Z

Here's an example replay protected tx that outputs the minim 2730 satoshi amount for a standard transaction.

{
  "hash": "5ef96f4831c2ff41867670cf40152326eaa12116d15350a912fbde2a8319cbef",
  "ver": 1,
  "vin_sz": 0,
  "vout_sz": 1,
  "lock_time": 0,
  "size": 42,
  "in": [],
  "out": [
    {
      "value": "0.00002730",
      "scriptPubKey": "OP_HASH160 e77dfed888d33a87c2f48849f54dc55f4e63e7b4 OP_EQUAL"
    }
  ]
}

Here's an example tx that redeems one of these replay protected outputs:

{
  "hash": "9e6d108ac28e747217669ef0e4b0e5b7b4c33814595b96dc2d49d6eb5f79f979",
  "ver": 1,
  "vin_sz": 1,
  "vout_sz": 0,
  "lock_time": 0,
  "size": 56,
  "in": [
    {
      "prev_out": {
        "hash": "5ef96f4831c2ff41867670cf40152326eaa12116d15350a912fbde2a8319cbef",
        "n": 0
      },
      "scriptSig": "03165c4d"
    }
  ],
  "out": []
}

This transaction is 56 bytes and looks like:
0100000001efcb19832adefb12a95053d11621a1ea26231540cf70768641ffc231486ff95e00000000050403165c4dffffffff0000000000

In this case all output is being spent as a fee, which comes out as 2730 / 56 = 48 (satoshi / byte). It would be in the economic interest of miners to sweep up these outputs individually when fee levels are below 48 satoshi / byte. Users could consume these outputs and receive free (or better) replay protection. These outputs won't remain in the UTXO set for long. 😉

UPDATE: The proposal has been changed to use the following:

scriptAddress: 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi
scriptSig: 04148f33be
scriptPubKey: OP_HASH160 6e0b7d51f9f68ba28cc33a6844d41a1880c58a19 OP_EQUAL

Sjors · 2017-09-30T17:43:29Z

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.

Sjors · 2017-09-30T17:46:05Z

Can you clarify (1): do you mean such a transaction is non-standard for btc1 nodes?

jcansdale · 2017-09-30T22:04:51Z

@Sjors,

This might result in phishers publishing tutorials, but with a visually similar address.

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:

Sending BTC to an address they own
Sending 0.00002730 BTC to a special address

Can you clarify (1): do you mean such a transaction is non-standard for btc1 nodes?

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.

prusnak · 2017-10-01T09:15:18Z

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.

jgarzik · 2017-10-01T15:30:40Z

@prusnak Read the code - it prevents the transaction from being included in a block.

JaredR26 · 2017-10-01T20:26:18Z

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.

jcansdale · 2017-10-01T21:25:35Z

@JaredR26,

All of the ones that invalidate a transaction 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 (OP_CHECKBLOCKATHEIGHT maybe) or if this rule should be renewed.

jcansdale · 2017-10-01T21:41:42Z

Also I like the more neutral addresses you found like 3Bit1x...

I've updated this PR to use the following:

scriptAddress: 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi
scriptSig: 04148f33be
scriptPubKey: OP_HASH160 6e0b7d51f9f68ba28cc33a6844d41a1880c58a19 OP_EQUAL

The TestNet version of this address 2N3H65h66CHVLtYsv8AN11smtKLoGFvJymb. To spend, simply use the scriptSig 04148f33be.

jgarzik · 2017-10-04T02:50:08Z

Manually merged into segwit2x-dev as a3c4125

apoelstra · 2017-10-04T13:15:15Z

There is already user confusion about this:
https://www.reddit.com/r/Bitcoin/comments/745jlm/segwit2x_merges_in_optin_transaction_replay/dnvwiim/?context=3

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.

Sjors · 2017-10-04T13:33:09Z

@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.

…n into 2017_optin_replay_jcansdale

jgarzik and others added 2 commits August 23, 2017 09:06

jcansdale mentioned this pull request Sep 29, 2017

[consensus] Add opt-in transaction avoidance #117

Closed

jcansdale added 2 commits September 29, 2017 18:56

Change FromHex to ParseHex

e2d8c6c

Use hex_str_to_bytes(hex_string)

23ac764

jcansdale mentioned this pull request Oct 1, 2017

Opt-in, one-way replay protection without any consensus rule changes #123

Closed

NiKiZe mentioned this pull request Oct 2, 2017

Opt-in segwit2x-only transactions #125

Closed

jcansdale mentioned this pull request Oct 3, 2017

[WIP] Add opt-in transaction avoidance (for legacy chain) using well known P2SH address BitcoinUnlimited/BitcoinUnlimited#790

Closed

jgarzik closed this Oct 4, 2017

jgarzik mentioned this pull request Oct 4, 2017

Anti-replay / Replay protection #34

Closed

jcansdale referenced this pull request Oct 5, 2017

Merge branch '2017_optin_replay' of git://github.com/jcansdale/bitcoi…

a3c4125

…n into 2017_optin_replay_jcansdale

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add opt-in transaction avoidance using well known P2SH address #127

Add opt-in transaction avoidance using well known P2SH address #127

jcansdale commented Sep 29, 2017 •

edited

jcansdale commented Sep 29, 2017 •

edited

Sjors commented Sep 30, 2017

Sjors commented Sep 30, 2017

jcansdale commented Sep 30, 2017 •

edited

prusnak commented Oct 1, 2017

jgarzik commented Oct 1, 2017

JaredR26 commented Oct 1, 2017 •

edited

jcansdale commented Oct 1, 2017 •

edited

jcansdale commented Oct 1, 2017

jgarzik commented Oct 4, 2017

apoelstra commented Oct 4, 2017

Sjors commented Oct 4, 2017 •

edited

Add opt-in transaction avoidance using well known P2SH address #127

Add opt-in transaction avoidance using well known P2SH address #127

Conversation

jcansdale commented Sep 29, 2017 • edited

jcansdale commented Sep 29, 2017 • edited

Sjors commented Sep 30, 2017

Sjors commented Sep 30, 2017

jcansdale commented Sep 30, 2017 • edited

prusnak commented Oct 1, 2017

jgarzik commented Oct 1, 2017

JaredR26 commented Oct 1, 2017 • edited

jcansdale commented Oct 1, 2017 • edited

jcansdale commented Oct 1, 2017

jgarzik commented Oct 4, 2017

apoelstra commented Oct 4, 2017

Sjors commented Oct 4, 2017 • edited

jcansdale commented Sep 29, 2017 •

edited

jcansdale commented Sep 29, 2017 •

edited

jcansdale commented Sep 30, 2017 •

edited

JaredR26 commented Oct 1, 2017 •

edited

jcansdale commented Oct 1, 2017 •

edited

Sjors commented Oct 4, 2017 •

edited