Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2015-10-06 📝 Original message:On Mon, Oct 05, 2015 at ...
📅 Original date posted:2015-10-06
📝 Original message:On Mon, Oct 05, 2015 at 06:46:28PM +0200, Mike Hearn via bitcoin-dev wrote:
> The example is this: find someone that accepts 1-block confirmed
> transactions in return for something valuable. There are plenty of them out
> there. Once the soft fork starts, send a P2SH transaction that defines a
> new output controlled by OP_CLTV. It will be incorporated into the UTXO set
> by all miners because it's opaque (p2sh).
>
> Now send a transaction that pays the merchant, and make it spend your
> OP_CLTV output with an invalid script. New nodes will reject it as a rule
> violator. Old nodes won't.
Old nodes running bitcoind will see it as OP_NOP2, and will reject it
unless they've manually disabled SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS,
which (aiui) has been available since bitcoin 0.10 [0], but not backported
to 0.8 or 0.9.
[0] https://github.com/bitcoin/bitcoin/commit/0391423
That covers about 4700/5880 nodes going by bitnodes.21.co; but I can't
tell how many miners it covers.
Further, AIUI, nodes running 0.8 or 0.9 will still apply IsStandard()
checks to scripts attempting to spend p2sh outputs [1], so will also
fail to either mine or relay your OP_NOP2 payment.
[1] https://github.com/bitcoin/bitcoin/commit/6259937
> So at some point an old miner will create a
> block containing your invalid transaction, the merchant will think they got
> paid, they'll give you the stuff and the fraud is done.
My understanding is that this isn't supposed to be a problem because you
won't be able to find an old miner that will do that; released versions
of bitcoin already block it by default.
Sure, someone could disable those checks and not pay attention to a soft
fork that will cause their blocks to be orphaned, but I'm not seeing why
that's any different a threat compared to someone deliberately mining
invalid blocks to do 1-confirmation doublespends against merchants not
running a full node.
At least, that's my understanding, and I'm not an expert, so corrections
appreciated.
Cheers,
aj
📝 Original message:On Mon, Oct 05, 2015 at 06:46:28PM +0200, Mike Hearn via bitcoin-dev wrote:
> The example is this: find someone that accepts 1-block confirmed
> transactions in return for something valuable. There are plenty of them out
> there. Once the soft fork starts, send a P2SH transaction that defines a
> new output controlled by OP_CLTV. It will be incorporated into the UTXO set
> by all miners because it's opaque (p2sh).
>
> Now send a transaction that pays the merchant, and make it spend your
> OP_CLTV output with an invalid script. New nodes will reject it as a rule
> violator. Old nodes won't.
Old nodes running bitcoind will see it as OP_NOP2, and will reject it
unless they've manually disabled SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS,
which (aiui) has been available since bitcoin 0.10 [0], but not backported
to 0.8 or 0.9.
[0] https://github.com/bitcoin/bitcoin/commit/0391423
That covers about 4700/5880 nodes going by bitnodes.21.co; but I can't
tell how many miners it covers.
Further, AIUI, nodes running 0.8 or 0.9 will still apply IsStandard()
checks to scripts attempting to spend p2sh outputs [1], so will also
fail to either mine or relay your OP_NOP2 payment.
[1] https://github.com/bitcoin/bitcoin/commit/6259937
> So at some point an old miner will create a
> block containing your invalid transaction, the merchant will think they got
> paid, they'll give you the stuff and the fraud is done.
My understanding is that this isn't supposed to be a problem because you
won't be able to find an old miner that will do that; released versions
of bitcoin already block it by default.
Sure, someone could disable those checks and not pay attention to a soft
fork that will cause their blocks to be orphaned, but I'm not seeing why
that's any different a threat compared to someone deliberately mining
invalid blocks to do 1-confirmation doublespends against merchants not
running a full node.
At least, that's my understanding, and I'm not an expert, so corrections
appreciated.
Cheers,
aj