Johnson Lau [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-22 📝 Original message: > On 22 Mar 2019, at 9:59 ...
📅 Original date posted:2019-03-22
📝 Original message:
> On 22 Mar 2019, at 9:59 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Good morning aj,
>>
>> If you are committing to the script code, though, then each settlement
>> sig is already only usable with the corresponding update tx, so you
>> don't need to roll the keys. But you do need to make it so that the
>> update sig requires the CLTV; one way to do that is using codeseparator
>> to distinguish between the two cases.
>>
>>> Also, I cannot understand `OP_CODESEPARATOR`, please no.
>>
>> If codeseparator is too scary, you could probably also just always
>> require the locktime (ie for settlmenet txs as well as update txs), ie:
>>
>> OP_CHECKLOCKTIMEVERIFY OP_DROP
>> <muSig(A_u,B_u)> OP_CHECKDLSVERIFY <Q> OP_CHECKDLS
>>
>> and have update txs set their timelock; and settlement txs set a absolute
>> timelock, relative timelock via sequence, and commit to the script code.
>>
>> (Note that both those approaches (with and without codesep) assume there's
>> some flag that allows you to commit to the scriptcode even though you're
>> not committing to your input tx (and possibly not committing to the
>> scriptpubkey). BIP118 doesn't have that flexibility, so the A_s_i and
>> B_s_i key rolling is necessary)
>
> I think the issue I have here is the lack of `OP_CSV` in the settlement branch.
>
> Consider a channel with offchain transactions update-1, settlement-1, update-2, and settlement-2.
> If update-1 is placed onchain, update-1 is also immediately spendable by settlement-1.
> But settlement-1 cannot be spent by update-2 and thus the invalidation of older state fails.
>
> The `OP_CSV` in the settlement branch of the update transaction outputs exists to allow later update transactions have higher priority over settlement transactions.
>
> To ensure that a settlement signature can only take the settlement branch, we need a distinct public key for the branch, so at least `A_s` and `B_s` without rolling them for each `i`, if we use `nLockTime` on the settlement transactions and enforce it with `OP_CHECKLOCKTIMEVERIFY`.
> It might be possible to do this with `OP_CODESEPARATOR`, but we do need the `OP_CSV` in the settlement branch.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
OP_CSV (BIP112) is not needed. Only BIP68 relative-time is needed.
With this script:
<t> OP_CHECKLOCKTIMEVERIFY OP_DROP <muSig(A,B)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG
For update purpose, A and B will co-sign the muSig with nLockTime = t, not committing to the scriptCode, and no BIP68 lock time
For settlement purpose, A and B will co-sign the muSig with nLockTime = t, committing to the scriptCode, and with an agreed BIP68 locktime
Without committing to the scriptCode and BIP68 lock time, the update sig could be bind to any previous update tx immediately.
OTOH, the settlement sig will only bind to a specific update tx (thought scriptCode), and only after the relative locktime is passed.
The eltoo paper is wrong about using OP_CSV. That’s a common mistake even for experienced bitcoin developer. OP_CSV is needed only if one party could single handedly decide the relative-lock-time. However, this is not the case here as it is a muSig.
(With some risks of distracting the discussion, please note that even this script: <t> OP_CHECKLOCKTIMEVERIFY OP_DROP <A> OP_CHECKSIGVERIFY <B> OP_CHECKSIG doesn’t need OP_CSV, despite not using muSig. It is because the 2 sigs must use the same relative locktime, or the tx is invalid.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190322/3337a8f8/attachment.html>;
📝 Original message:
> On 22 Mar 2019, at 9:59 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Good morning aj,
>>
>> If you are committing to the script code, though, then each settlement
>> sig is already only usable with the corresponding update tx, so you
>> don't need to roll the keys. But you do need to make it so that the
>> update sig requires the CLTV; one way to do that is using codeseparator
>> to distinguish between the two cases.
>>
>>> Also, I cannot understand `OP_CODESEPARATOR`, please no.
>>
>> If codeseparator is too scary, you could probably also just always
>> require the locktime (ie for settlmenet txs as well as update txs), ie:
>>
>> OP_CHECKLOCKTIMEVERIFY OP_DROP
>> <muSig(A_u,B_u)> OP_CHECKDLSVERIFY <Q> OP_CHECKDLS
>>
>> and have update txs set their timelock; and settlement txs set a absolute
>> timelock, relative timelock via sequence, and commit to the script code.
>>
>> (Note that both those approaches (with and without codesep) assume there's
>> some flag that allows you to commit to the scriptcode even though you're
>> not committing to your input tx (and possibly not committing to the
>> scriptpubkey). BIP118 doesn't have that flexibility, so the A_s_i and
>> B_s_i key rolling is necessary)
>
> I think the issue I have here is the lack of `OP_CSV` in the settlement branch.
>
> Consider a channel with offchain transactions update-1, settlement-1, update-2, and settlement-2.
> If update-1 is placed onchain, update-1 is also immediately spendable by settlement-1.
> But settlement-1 cannot be spent by update-2 and thus the invalidation of older state fails.
>
> The `OP_CSV` in the settlement branch of the update transaction outputs exists to allow later update transactions have higher priority over settlement transactions.
>
> To ensure that a settlement signature can only take the settlement branch, we need a distinct public key for the branch, so at least `A_s` and `B_s` without rolling them for each `i`, if we use `nLockTime` on the settlement transactions and enforce it with `OP_CHECKLOCKTIMEVERIFY`.
> It might be possible to do this with `OP_CODESEPARATOR`, but we do need the `OP_CSV` in the settlement branch.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
OP_CSV (BIP112) is not needed. Only BIP68 relative-time is needed.
With this script:
<t> OP_CHECKLOCKTIMEVERIFY OP_DROP <muSig(A,B)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG
For update purpose, A and B will co-sign the muSig with nLockTime = t, not committing to the scriptCode, and no BIP68 lock time
For settlement purpose, A and B will co-sign the muSig with nLockTime = t, committing to the scriptCode, and with an agreed BIP68 locktime
Without committing to the scriptCode and BIP68 lock time, the update sig could be bind to any previous update tx immediately.
OTOH, the settlement sig will only bind to a specific update tx (thought scriptCode), and only after the relative locktime is passed.
The eltoo paper is wrong about using OP_CSV. That’s a common mistake even for experienced bitcoin developer. OP_CSV is needed only if one party could single handedly decide the relative-lock-time. However, this is not the case here as it is a muSig.
(With some risks of distracting the discussion, please note that even this script: <t> OP_CHECKLOCKTIMEVERIFY OP_DROP <A> OP_CHECKSIGVERIFY <B> OP_CHECKSIG doesn’t need OP_CSV, despite not using muSig. It is because the 2 sigs must use the same relative locktime, or the tx is invalid.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190322/3337a8f8/attachment.html>;