{"type":"rich","version":"1.0","author_name":"npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","author_url":"https://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 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"}