Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[POLICY] Make sending to future native witness outputs standard #15846

Merged
merged 1 commit into from Apr 27, 2019

Conversation

@sipa
Copy link
Member

@sipa sipa commented Apr 18, 2019

As discussed in the April 18 2019 IRC meeting.

This makes sending to future Segwit versions via native outputs (bech32) standard for relay, mempool acceptance, and mining. The reasons are:

  • This may interfere with smooth adoption of future segwit versions, if they're defined (by the sender wallet/node).
  • It violates BIP173 ("Version 0 witness addresses are always 42 or 62 characters, but implementations MUST allow the use of any version."), though admittedly this code was written before BIP173.
  • It doesn't protect much, as P2SH-embedded segwit cannot be filtered in this way.
  • As a general policy, the sender shouldn't care what the receiver likes his outputs to be.

Note that spending such outputs (including P2SH-embedded ones) remains nonstandard, as that is actually required for softfork safety.

@MarcoFalke
Copy link
Member

@MarcoFalke MarcoFalke commented Apr 18, 2019

utACK c634b1e

@jnewbery
Copy link
Member

@jnewbery jnewbery commented Apr 18, 2019

IRC discussion here: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-18-19.00.log.html#l-77

Concept ACK this change. I agree that the mempool should accept and relay txs with outputs to any segwit version.

It violates BIP173 ("Version 0 witness addresses are always 42 or 62 characters, but implementations MUST allow the use of any version."), though admittedly this code was written before BIP173.

This isn't relevant to the change here. BIP173 describes an address format and how to decode that into a scriptPubKey. The node/mempool has no concept of addresses.

I think your last three points are actually arguments to not stop the wallet from sending to segwit v1+ addresses, rather than arguments to allow the mempool to accept/relay those txs.

I'd prefer to prevent the Bitcoin Core wallet from sending to v1+ addresses, or at least to warn. We can't prevent all classes of sending insecure or unspendable addresses, but I think it makes sense to do so when we can.

I think the main concern that people have with that is that it might slow down segwit v1 adoption. I disagree - bech32 adoption has mostly been slowed down by large exchanges or other services not implementing send-to-bech32. That's something that is outside our control.

@luke-jr
Copy link
Member

@luke-jr luke-jr commented Apr 18, 2019

utACK

1 similar comment
@gmaxwell
Copy link
Contributor

@gmaxwell gmaxwell commented Apr 18, 2019

utACK

@harding
Copy link
Member

@harding harding commented Apr 24, 2019

Tested ACK c634b1e

Separately tested a bc1p... v1 address with sendrawtransaction and the wallet GUI on mainnet. Transactions were accepted to the local mempool, relayed to a remote peer I controlled, and entered that peer's mempool (both peers running this PR).

(Hint for anyone else testing, if you want to empty your mempool so you can run abandontransaction, you need to restart with -persistmempool=0 -walletbroadcast=0, run the savemempool RPC, abandon your transaction either via the RPC or the GUI, and then restart again. If you don't savemempool, your node will restore the mempool from the run before you set persistmempool=0 and that mempool will contain your wallet transaction.)

@gmaxwell
Copy link
Contributor

@gmaxwell gmaxwell commented Apr 24, 2019

utACK

@sdaftuar
Copy link
Member

@sdaftuar sdaftuar commented Apr 25, 2019

utACK

1 similar comment
@instagibbs
Copy link
Member

@instagibbs instagibbs commented Apr 25, 2019

utACK

@meshcollider
Copy link
Member

@meshcollider meshcollider commented Apr 27, 2019

utACK c634b1e

@meshcollider meshcollider merged commit c634b1e into bitcoin:master Apr 27, 2019
2 checks passed
meshcollider added a commit that referenced this issue Apr 27, 2019
…standard

c634b1e [POLICY] Make sending to future native witness outputs standard (Pieter Wuille)

Pull request description:

  As discussed in the April 18 2019 IRC meeting.

  This makes sending to future Segwit versions via native outputs (bech32) standard for relay, mempool acceptance, and mining. The reasons are:
  * This may interfere with smooth adoption of future segwit versions, if they're defined (by the sender wallet/node).
  * It violates BIP173 ("Version 0 witness addresses are always 42 or 62 characters, but implementations MUST allow the use of any version."), though admittedly this code was written before BIP173.
  * It doesn't protect much, as P2SH-embedded segwit cannot be filtered in this way.
  * As a general policy, the sender shouldn't care what the receiver likes his outputs to be.

  Note that _spending_ such outputs (including P2SH-embedded ones) remains nonstandard, as that is actually required for softfork safety.

ACKs for commit c634b1:
  MarcoFalke:
    utACK c634b1e
  harding:
    Tested ACK c634b1e
  meshcollider:
    utACK c634b1e

Tree-SHA512: e37168a1be9f445a04d4280593f0a92bdae33eee00ecd803d5eb16acb5c9cfc0f1f0a1dfbd5a0cc73da2c9928ec11cbdac7911513a78f85b789ae0d00e1b5962
sidhujag added a commit to syscoin/syscoin that referenced this issue May 1, 2019
…utputs standard

c634b1e [POLICY] Make sending to future native witness outputs standard (Pieter Wuille)

Pull request description:

  As discussed in the April 18 2019 IRC meeting.

  This makes sending to future Segwit versions via native outputs (bech32) standard for relay, mempool acceptance, and mining. The reasons are:
  * This may interfere with smooth adoption of future segwit versions, if they're defined (by the sender wallet/node).
  * It violates BIP173 ("Version 0 witness addresses are always 42 or 62 characters, but implementations MUST allow the use of any version."), though admittedly this code was written before BIP173.
  * It doesn't protect much, as P2SH-embedded segwit cannot be filtered in this way.
  * As a general policy, the sender shouldn't care what the receiver likes his outputs to be.

  Note that _spending_ such outputs (including P2SH-embedded ones) remains nonstandard, as that is actually required for softfork safety.

ACKs for commit c634b1:
  MarcoFalke:
    utACK c634b1e
  harding:
    Tested ACK c634b1e
  meshcollider:
    utACK bitcoin@c634b1e

Tree-SHA512: e37168a1be9f445a04d4280593f0a92bdae33eee00ecd803d5eb16acb5c9cfc0f1f0a1dfbd5a0cc73da2c9928ec11cbdac7911513a78f85b789ae0d00e1b5962
Sjors added a commit to Sjors/libwally-core that referenced this issue Jun 11, 2019
BIP173 permits witness versions up to 16.

Sending to future native witness outputs will be standard in the 0.19 Bitcoin Core release: bitcoin/bitcoin#15846
greenaddress added a commit to ElementsProject/libwally-core that referenced this issue Jun 28, 2019
BIP173 permits witness versions up to 16.

Sending to future native witness outputs will be standard in the 0.19 Bitcoin Core release: bitcoin/bitcoin#15846
MarcoFalke added a commit to MarcoFalke/bitcoin-core that referenced this issue Jul 16, 2019
fa89bad test: Require standard txs in regtest (MarcoFalke)
fa9b419 test: Add test that mainnet requires standard txs (MarcoFalke)
fa613ca chainparams: Remove unused fMineBlocksOnDemand (MarcoFalke)

Pull request description:

  I don't see a reason why regtest should allow non-standard txs, as it makes testing mainnet behaviour such as bitcoin#15846 unnecessarily hard and unintuitive.

  Of course, testnet policy remains unchanged to allow propagation of non-standard txs.

ACKs for top commit:
  ajtowns:
    ACK fa89bad

Tree-SHA512: c4c675affb054868850bd2683aa07f4c741a448cbacb2ea8334191e105f426b0790fe6a468be61e9c5880d24154f7bf1c7075051697172dce92180c1bc3a1c90
sidhujag added a commit to syscoin/syscoin that referenced this issue Jul 29, 2019
fa89bad test: Require standard txs in regtest (MarcoFalke)
fa9b419 test: Add test that mainnet requires standard txs (MarcoFalke)
fa613ca chainparams: Remove unused fMineBlocksOnDemand (MarcoFalke)

Pull request description:

  I don't see a reason why regtest should allow non-standard txs, as it makes testing mainnet behaviour such as bitcoin#15846 unnecessarily hard and unintuitive.

  Of course, testnet policy remains unchanged to allow propagation of non-standard txs.

ACKs for top commit:
  ajtowns:
    ACK fa89bad

Tree-SHA512: c4c675affb054868850bd2683aa07f4c741a448cbacb2ea8334191e105f426b0790fe6a468be61e9c5880d24154f7bf1c7075051697172dce92180c1bc3a1c90
rustyrussell added a commit to rustyrussell/lightning-rfc that referenced this issue Sep 18, 2019
In bitcoin 0.19.0, standardness rules are going to be relaxed to allow
future witness versions.  Once this is widely deployed, it will be safe
to accept them, smoothing use of future segwit versions.

See: bitcoin/bitcoin#15846

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell added a commit to rustyrussell/lightning-rfc that referenced this issue Aug 20, 2020
In bitcoin 0.19.0, standardness rules are going to be relaxed to allow
future witness versions.  Once this is widely deployed, it will be safe
to accept them, smoothing use of future segwit versions.

See: bitcoin/bitcoin#15846

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
cdecker added a commit to rustyrussell/lightning-rfc that referenced this issue Dec 22, 2020
In bitcoin 0.19.0, standardness rules are going to be relaxed to allow
future witness versions.  Once this is widely deployed, it will be safe
to accept them, smoothing use of future segwit versions.

See: bitcoin/bitcoin#15846

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
cdecker added a commit to rustyrussell/lightning-rfc that referenced this issue Dec 22, 2020
In bitcoin 0.19.0, standardness rules are going to be relaxed to allow
future witness versions.  Once this is widely deployed, it will be safe
to accept them, smoothing use of future segwit versions.

See: bitcoin/bitcoin#15846

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell added a commit to rustyrussell/lightning-rfc that referenced this issue Feb 18, 2021
In bitcoin 0.19.0, standardness rules are going to be relaxed to allow
future witness versions.  Once this is widely deployed, it will be safe
to accept them, smoothing use of future segwit versions.

See: bitcoin/bitcoin#15846

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell added a commit to rustyrussell/lightning-rfc that referenced this issue Feb 18, 2021
In bitcoin 0.19.0, standardness rules are going to be relaxed to allow
future witness versions.  Once this is widely deployed, it will be safe
to accept them, smoothing use of future segwit versions.

See: bitcoin/bitcoin#15846

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell added a commit to rustyrussell/lightning-rfc that referenced this issue Feb 18, 2021
In bitcoin 0.19.0, standardness rules are going to be relaxed to allow
future witness versions.  Once this is widely deployed, it will be safe
to accept them, smoothing use of future segwit versions.

See: bitcoin/bitcoin#15846

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell added a commit to rustyrussell/lightning-rfc that referenced this issue Feb 18, 2021
In bitcoin 0.19.0, standardness rules are going to be relaxed to allow
future witness versions.  Once this is widely deployed, it will be safe
to accept them, smoothing use of future segwit versions.

See: bitcoin/bitcoin#15846

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell added a commit to lightningnetwork/lightning-rfc that referenced this issue May 24, 2021
In bitcoin 0.19.0, standardness rules are going to be relaxed to allow
future witness versions.  Once this is widely deployed, it will be safe
to accept them, smoothing use of future segwit versions.

See: bitcoin/bitcoin#15846

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

10 participants