ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-05-10 📝 Original message:Good morning Luke and ...
📅 Original date posted:2018-05-10
📝 Original message:Good morning Luke and list,
> 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 understand the issue. On Lightning side, if this rule is used, we would have the two options below:
1. Commitment transactions always use the minimum feerate, but always have the above OP_TRUE output. Then to confirm the commitment transaction we would have to always spend the OP_TRUE output in CPFP transaction that pays for actual fee at unilateral close. This consumes more blockchain space for unilateral closes, as the second transaction is always mandatory.
2. We store two commitment transactions and associated paraphernalia (further transactions to claim the HTLCs). One version has a negotiated feerate without the OP_TRUE output. The other version has a slightly increased feerate and an OP_TRUE output as above. At unilateral close, we see if the negotiated feerate is enough and use that version if possible, but if not we RBF it with other version and in addition also CPFP on top. As mentioned before, we do not have transaction packages, so we need to RBF with higher feerate the commitment transaction, then submit the CPFP transaction which makes the first transaction valid to include in a block as per the rule. This requires that the fallback always have both an RBF bump and a CPFP bump.
>
>(Maybe it should be the first output
>
> instead of the last... Is there any legitimate reason one would have multiple
>
> such dummy outputs?)
It seems there are indeed none.
Regards,
ZmnSCPxj
📝 Original message:Good morning Luke and list,
> 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 understand the issue. On Lightning side, if this rule is used, we would have the two options below:
1. Commitment transactions always use the minimum feerate, but always have the above OP_TRUE output. Then to confirm the commitment transaction we would have to always spend the OP_TRUE output in CPFP transaction that pays for actual fee at unilateral close. This consumes more blockchain space for unilateral closes, as the second transaction is always mandatory.
2. We store two commitment transactions and associated paraphernalia (further transactions to claim the HTLCs). One version has a negotiated feerate without the OP_TRUE output. The other version has a slightly increased feerate and an OP_TRUE output as above. At unilateral close, we see if the negotiated feerate is enough and use that version if possible, but if not we RBF it with other version and in addition also CPFP on top. As mentioned before, we do not have transaction packages, so we need to RBF with higher feerate the commitment transaction, then submit the CPFP transaction which makes the first transaction valid to include in a block as per the rule. This requires that the fallback always have both an RBF bump and a CPFP bump.
>
>(Maybe it should be the first output
>
> instead of the last... Is there any legitimate reason one would have multiple
>
> such dummy outputs?)
It seems there are indeed none.
Regards,
ZmnSCPxj