{"type":"rich","version":"1.0","author_name":"npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n","author_url":"https://nostr.ae/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-05-09\n📝 Original message:An OP_TRUE-only script with a low value seems like a good example of where the \nweight doesn't reflect the true cost: it uses a UTXO forever, while only \ncosting a weight of 4.\n\nI like Johnson's idea to have some template (perhaps OP_2-only, to preserve \nexpected behaviour of OP_TRUE-only) that when combined with a 0-value is \nalways valid only if spent in the same block.\n\nI wonder if it would make sense to actually tie it to a transaction version \nbit, such that when the bit is set, the transaction is serialised with +1 on \nthe output count and 00000000000000000181 is simply injected into the \ntransaction hashing... But for now, simply having a consensus rule that a bit \nMUST be set for the expected behaviour, and the bit may ONLY be set when the \nlast output is exactly 00000000000000000181, would allow us to code the \ntransaction serialisation up later. (Maybe it should be the first output \ninstead of the last... Is there any legitimate reason one would have multiple \nsuch dummy outputs?)\n\nLuke\n\n\nOn Tuesday 08 May 2018 23:57:11 Rusty Russell via bitcoin-dev wrote:\n\u003e Hi all,\n\u003e\n\u003e         The largest problem we are having today with the lightning\n\u003e protocol is trying to predict future fees.  Eltoo solves this elegantly,\n\u003e but meanwhile we would like to include a 546 satoshi OP_TRUE output in\n\u003e commitment transactions so that we use minimal fees and then use CPFP\n\u003e (which can't be done at the moment due to CSV delays on outputs).\n\u003e\n\u003e Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is\n\u003e non-standard.  Are there any reasons not to suggest such a policy\n\u003e change?\n\u003e\n\u003e Thanks!\n\u003e Rusty.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"}