📅 Original date posted:2018-05-16
📝 Original message:Luke Dashjr <luke at dashjr.org> writes:
> An OP_TRUE-only script with a low value seems like a good example of where the
> weight doesn't reflect the true cost: it uses a UTXO forever, while only
> costing a weight of 4.
>
> I like Johnson's idea to have some template (perhaps OP_2-only, to preserve
> expected behaviour of OP_TRUE-only) that when combined with a 0-value is
> always valid only if spent in the same block.
>
> I wonder if it would make sense to actually tie it to a transaction version
> bit, such that when the bit is set, the transaction is serialised with +1 on
> the output count and 00000000000000000181 is simply injected into the
> transaction hashing... But for now, simply having a consensus rule that a bit
> MUST be set for the expected behaviour, and the bit may ONLY be set when the
> last output is exactly 00000000000000000181, would allow us to code the
> transaction serialisation up later. (Maybe it should be the first output
> instead of the last... Is there any legitimate reason one would have multiple
> such dummy outputs?)
Your zero-val-OP_TRUE-can't-be-spent-after-same-block SF is interesting,
but if we want a SF just give us SIGHASH_NOINPUT and we'll not need this
at all (though others still might). It's nicer than the previous
discussions on after-the-fact feebumping[1] though.
Meanwhile, our best mitigation against UTXO bloat is:
1. Make the fees as low as possible[2]
2. Put a CSV delay on the to-remote output (currently there's asymmetry)
3. Attach more value to the OP_TRUE output, say 1000 satoshi.
But turns out we probably don't want an OP_TRUE output nor P2SH, because
then the spending tx would be malleable. So P2WSH is is.
This brings us another theoretical problem: someone could spend our
OP_TRUE with a low-fee non-RBF tx, and we'd not be able to use it to
CPFP the tx. It'd be hard to do, but possible. I think the network
benefits from using OP_TRUE (anyone can clean, and size, vs some
only-known-to-me pubkey) outweighs the risk, but it'd be nice if OP_TRUE
P2WSH spends were always considered RBF.
Thanks,
Rusty.
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015864.html
[2] Because bitcoin core use legacy measurements, this is actually 253
satoshi per kilosipa for us, see https://github.com/ElementsProject/lightning/commit/2e687b9b352c9092b5e8bd4a688916ac50b44af0
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-07 18:11:57
in reply to nevent1q…m30a
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-07 18:11:57Event JSON
{
"id": "808d2d1cd268e0dd60bd8e8a5be0067ac23d0deeb935940a49e8c4b0f6e05f52",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686161517,
"kind": 1,
"tags": [
[
"e",
"caee4e3828cad70a0aa9bfba9569480bc6157a528d4896eeab11f571613a9d97",
"",
"root"
],
[
"e",
"0f2353b9c22f3218cec441cca1d8c408a17b766cce9a5ed463074f1496dc6b6a",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-05-16\n📝 Original message:Luke Dashjr \u003cluke at dashjr.org\u003e writes:\n\u003e An OP_TRUE-only script with a low value seems like a good example of where the \n\u003e weight doesn't reflect the true cost: it uses a UTXO forever, while only \n\u003e costing a weight of 4.\n\u003e\n\u003e I like Johnson's idea to have some template (perhaps OP_2-only, to preserve \n\u003e expected behaviour of OP_TRUE-only) that when combined with a 0-value is \n\u003e always valid only if spent in the same block.\n\u003e\n\u003e I wonder if it would make sense to actually tie it to a transaction version \n\u003e bit, such that when the bit is set, the transaction is serialised with +1 on \n\u003e the output count and 00000000000000000181 is simply injected into the \n\u003e transaction hashing... But for now, simply having a consensus rule that a bit \n\u003e MUST be set for the expected behaviour, and the bit may ONLY be set when the \n\u003e last output is exactly 00000000000000000181, would allow us to code the \n\u003e transaction serialisation up later. (Maybe it should be the first output \n\u003e instead of the last... Is there any legitimate reason one would have multiple \n\u003e such dummy outputs?)\n\nYour zero-val-OP_TRUE-can't-be-spent-after-same-block SF is interesting,\nbut if we want a SF just give us SIGHASH_NOINPUT and we'll not need this\nat all (though others still might). It's nicer than the previous\ndiscussions on after-the-fact feebumping[1] though.\n\nMeanwhile, our best mitigation against UTXO bloat is:\n1. Make the fees as low as possible[2]\n2. Put a CSV delay on the to-remote output (currently there's asymmetry)\n3. Attach more value to the OP_TRUE output, say 1000 satoshi.\n\nBut turns out we probably don't want an OP_TRUE output nor P2SH, because\nthen the spending tx would be malleable. So P2WSH is is.\n\nThis brings us another theoretical problem: someone could spend our\nOP_TRUE with a low-fee non-RBF tx, and we'd not be able to use it to\nCPFP the tx. It'd be hard to do, but possible. I think the network\nbenefits from using OP_TRUE (anyone can clean, and size, vs some\nonly-known-to-me pubkey) outweighs the risk, but it'd be nice if OP_TRUE\nP2WSH spends were always considered RBF.\n\nThanks,\nRusty.\n[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015864.html\n[2] Because bitcoin core use legacy measurements, this is actually 253\nsatoshi per kilosipa for us, see https://github.com/ElementsProject/lightning/commit/2e687b9b352c9092b5e8bd4a688916ac50b44af0",
"sig": "b5fc6fcce6cb8cc2537383bef15e17c6bc67c69da42d931640a5be01eb78f52b247fb226bf5190f13a54fdccd898a111b4e257d6ed4a15d9e17b9fb527a3578f"
}