Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-13 📝 Original message:On Mon, Jul 11, 2022 at ...
📅 Original date posted:2022-07-13
📝 Original message:On Mon, Jul 11, 2022 at 08:21:40PM -0400, Russell O'Connor via bitcoin-dev wrote:
> Oops, you are right. We need the bribe to be the output of the coinbase,
> but due to the maturity rule, it isn't really a bribe.
> Too bad coinbases cannot take other coinbase outputs as inputs to bypass
> the maturity rule.
Sufficiently advanced tx introspection could be used for this; spend the
fees in the coinbase to address A, but also create a 0sat output via a
regular tx to the scriptPubKey "1 CSV". Note that tx's txid as B. The
next miner claims the bribe B, by spending the 0sat output to itself
with a 1-in, 1-out tx, with scriptPubKey C.
nVersion = 1
inputs = [txid=B, vout=0, scriptSig="", nSeq=1]
outputs = [value=0, scriptPubKey=C]
nLocktime = 0
Now we get back to A, and say that it's scriptPubKey uses a script that
takes "C" as input, has "B" hardcoded, calculates the txid of the tx
above, call it D, and then uses tx introspection to check that one of
the inputs of the tx has D as the txid.
> I guess that means the bribe has to be by leaving transactions in the
> mempool.
You *could* make that work if you allow tx's to use the annex to commit
to a recent block.
That is, if you just mined block 740,000 and its hash was
00000000000000000005f28764680afdbd8375216ff8f30b17eeb26bd98aac63,
you construct a bribe tx paying to "OP_1", but when you sign it,
you add "50ee070b4aa0d98aac63" as the annex (tag=ee, length=07,
value[0:3]=height=0b4aa0=470k, value[3:]=d98aac63), and (via a soft fork)
nodes then only consider that tx valid if the block at "height" ends in
"d98aac63". There's then only a 1-in-4B chance that someone who extends
a competitor to your block could claim the bribe, at a cost of 11 extra
witness bytes.
But such txs (and anything that descends from them) would become invalid
with as little as a 1-block reorg, which would pretty much defeat the
entire purpose of the maturity delay...
Cheers,
aj
Published at
2023-06-07 23:11:42Event JSON
{
"id": "f389d5be48b9b397a08d93103ba61c0c4b918bf32bd838b668426a12d2ce2729",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686179502,
"kind": 1,
"tags": [
[
"e",
"7243614b5a040fbb87601bd8f41b59830667774e947157f62a858774b716e8e6",
"",
"root"
],
[
"e",
"e591000026a29f4858a5f12ca26a7c8795e81fb00c9b3ca534312e44ef4f760e",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2022-07-13\n📝 Original message:On Mon, Jul 11, 2022 at 08:21:40PM -0400, Russell O'Connor via bitcoin-dev wrote:\n\u003e Oops, you are right. We need the bribe to be the output of the coinbase,\n\u003e but due to the maturity rule, it isn't really a bribe.\n\u003e Too bad coinbases cannot take other coinbase outputs as inputs to bypass\n\u003e the maturity rule.\n\nSufficiently advanced tx introspection could be used for this; spend the\nfees in the coinbase to address A, but also create a 0sat output via a\nregular tx to the scriptPubKey \"1 CSV\". Note that tx's txid as B. The\nnext miner claims the bribe B, by spending the 0sat output to itself\nwith a 1-in, 1-out tx, with scriptPubKey C.\n\n nVersion = 1\n inputs = [txid=B, vout=0, scriptSig=\"\", nSeq=1]\n outputs = [value=0, scriptPubKey=C]\n nLocktime = 0\n\nNow we get back to A, and say that it's scriptPubKey uses a script that\ntakes \"C\" as input, has \"B\" hardcoded, calculates the txid of the tx\nabove, call it D, and then uses tx introspection to check that one of\nthe inputs of the tx has D as the txid.\n\n\u003e I guess that means the bribe has to be by leaving transactions in the\n\u003e mempool.\n\nYou *could* make that work if you allow tx's to use the annex to commit\nto a recent block.\n\nThat is, if you just mined block 740,000 and its hash was\n00000000000000000005f28764680afdbd8375216ff8f30b17eeb26bd98aac63,\nyou construct a bribe tx paying to \"OP_1\", but when you sign it,\nyou add \"50ee070b4aa0d98aac63\" as the annex (tag=ee, length=07,\nvalue[0:3]=height=0b4aa0=470k, value[3:]=d98aac63), and (via a soft fork)\nnodes then only consider that tx valid if the block at \"height\" ends in\n\"d98aac63\". There's then only a 1-in-4B chance that someone who extends\na competitor to your block could claim the bribe, at a cost of 11 extra\nwitness bytes.\n\nBut such txs (and anything that descends from them) would become invalid\nwith as little as a 1-block reorg, which would pretty much defeat the\nentire purpose of the maturity delay...\n\nCheers,\naj",
"sig": "8e026c2546efbcc15f3ad845a613d93f4d4449f7ac9f34ef1dfbee568a6d7fa1718d2b72951a37c5461687054ccee5002fda3041c09df24e50febac31949f541"
}