sipa
commented at 7:58 pm on April 18, 2019:
member
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.
[POLICY] Make sending to future native witness outputs standardc634b1e207
MarcoFalke
commented at 8:02 pm on April 18, 2019:
member
utACKc634b1e2076d8e15a8284638475e26c691d4e100
MarcoFalke added this to the milestone 0.19.0
on Apr 18, 2019
DrahtBot added the label
Tests
on Apr 18, 2019
DrahtBot added the label
TX fees and policy
on Apr 18, 2019
jnewbery
commented at 8:53 pm on April 18, 2019:
member
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
commented at 9:13 pm on April 18, 2019:
member
utACK
gmaxwell
commented at 9:33 pm on April 18, 2019:
contributor
utACK
harding
commented at 2:37 pm on April 24, 2019:
contributor
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
commented at 6:17 pm on April 24, 2019:
contributor
utACK
sdaftuar
commented at 2:25 pm on April 25, 2019:
member
utACK
instagibbs
commented at 5:29 pm on April 25, 2019:
member
utACK
meshcollider
commented at 9:47 am on April 27, 2019:
contributor
This is a metadata mirror of the GitHub repository
bitcoin/bitcoin.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2024-11-21 15:12 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me