Fabrice Drouin [ARCHIVE] on Nostr: 📅 Original date posted:2017-01-25 📝 Original message: On 25 January 2017 at ...
📅 Original date posted:2017-01-25
📝 Original message:
On 25 January 2017 at 01:53, Rusty Russell <rusty at rustcorp.com.au> wrote:
>> - for htlcs received we don't need to wait for the htlc timeout refund to claim the funds and we don't need to watch for HTLC-success transactions.
>
> For offered htlcs we still need to handle both the HTLC-success and
> commit tx cases though, since it can race with the other side.
> Similarly with received htlcs and HTLC-timeout transactions.
That's right, I removed the last part about not watching for HTLC
success transactions from the issue description
>> ## Changes to the Offered HTLC Output script:
>>
>> The solution we propose is to use a multisig 2-of-3 with `localkey`, `remotekey` and `revocationkey` for the Offered HTLC Output script:
>> ```
>> <remotekey> OP_SWAP
>> OP_SIZE 32 OP_EQUAL
>> OP_NOTIF
>> # To me via HTLC-timeout transaction (timelocked) or to you with revocation key.
>> OP_DROP 2 OP_SWAP <localkey> <revocationkey> 3 OP_CHECKMULTISIG
>> OP_ELSE
>> # To you with preimage.
>> OP_HASH160 <ripemd-of-payment-hash> OP_EQUALVERIFY
>> OP_CHECKSIG
>> OP_ENDIF
>> ```
>>
>> This output can be spent, as before, with the remote key and payment preimage, or with the remote key and local key,
>> but it can be spent also be spent with the remote key and revocation key, with the following witness script:
>
> Clever abuse of multisig :) It can also be spent with the local and
> revocation keys, but that should never happen. OK.
Yes, because of the very clever way revocation keys are computed: you
don't know the revocation key that can be used to take all your funds
if you publish a revoked commit tx. This is one of the many
improvements in the new specs :)
>> <remotekey> OP_SWAP
>> OP_SIZE 32 OP_EQUAL
>> OP_IF
>> # To me via HTLC-success transaction.
>> OP_HASH160 <ripemd-of-payment-hash> OP_EQUALVERIFY
>> 2 OP_SWAP <localkey> 2 OP_CHECKMULTISIG
>> OP_ELSE
>> OP_SIZE 0 OP_EQUAL
>> OP_IF
>
> Would OP_SIZE OP_NOTIF work here as an optimization?
Not any more because of the "minimal IF constraints" which was added a
few months ago (see
https://github.com/bitcoin/bitcoin/commit/c72c5b1e3bd42e84465677e94aa83316ff3d9a14)
>> # To you after timeout.
>> OP_DROP <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP
>> OP_CHECKSIG
>> OP_ELSE
>> # To you if you have the revocation key
>> OP_SWAP 2 OP_SWAP <revocationkey> 2 OP_CHECKMULTISIG
>> OP_ENDIF
>> OP_ENDIF
>> ```
>>
>> This output can be spent, as before, with the payment preimage and the remote and local keys, with the remote key after a delay,
>> but it can also be spent with the remote key and revocation key, with the following witness script:
>>
>> ```
>> 0 <remote-sig> <revocation-sig>
I can be improved like this:
<remotePubkey> OP_SWAP
OP_SIZE 32 OP_EQUAL
OP_IF
OP_HASH160 paymentHash) <ripemd-of-payment-hash> OP_EQUALVERIFY
OP_2 OP_SWAP <localKey> OP_2 OP_CHECKMULTISIG
OP_ELSE
OP_SIZE OP_0 OP_EQUAL
OP_IF
OP_DROP <lockTime> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG
OP_ELSE
OP_SWAP OP_DROP <revocationPubKey> OP_CHECKSIG
OP_ENDIF
OP_ENDIF
It can now be spent with: <revocation-sig>
Cheers,
Fabrice
📝 Original message:
On 25 January 2017 at 01:53, Rusty Russell <rusty at rustcorp.com.au> wrote:
>> - for htlcs received we don't need to wait for the htlc timeout refund to claim the funds and we don't need to watch for HTLC-success transactions.
>
> For offered htlcs we still need to handle both the HTLC-success and
> commit tx cases though, since it can race with the other side.
> Similarly with received htlcs and HTLC-timeout transactions.
That's right, I removed the last part about not watching for HTLC
success transactions from the issue description
>> ## Changes to the Offered HTLC Output script:
>>
>> The solution we propose is to use a multisig 2-of-3 with `localkey`, `remotekey` and `revocationkey` for the Offered HTLC Output script:
>> ```
>> <remotekey> OP_SWAP
>> OP_SIZE 32 OP_EQUAL
>> OP_NOTIF
>> # To me via HTLC-timeout transaction (timelocked) or to you with revocation key.
>> OP_DROP 2 OP_SWAP <localkey> <revocationkey> 3 OP_CHECKMULTISIG
>> OP_ELSE
>> # To you with preimage.
>> OP_HASH160 <ripemd-of-payment-hash> OP_EQUALVERIFY
>> OP_CHECKSIG
>> OP_ENDIF
>> ```
>>
>> This output can be spent, as before, with the remote key and payment preimage, or with the remote key and local key,
>> but it can be spent also be spent with the remote key and revocation key, with the following witness script:
>
> Clever abuse of multisig :) It can also be spent with the local and
> revocation keys, but that should never happen. OK.
Yes, because of the very clever way revocation keys are computed: you
don't know the revocation key that can be used to take all your funds
if you publish a revoked commit tx. This is one of the many
improvements in the new specs :)
>> <remotekey> OP_SWAP
>> OP_SIZE 32 OP_EQUAL
>> OP_IF
>> # To me via HTLC-success transaction.
>> OP_HASH160 <ripemd-of-payment-hash> OP_EQUALVERIFY
>> 2 OP_SWAP <localkey> 2 OP_CHECKMULTISIG
>> OP_ELSE
>> OP_SIZE 0 OP_EQUAL
>> OP_IF
>
> Would OP_SIZE OP_NOTIF work here as an optimization?
Not any more because of the "minimal IF constraints" which was added a
few months ago (see
https://github.com/bitcoin/bitcoin/commit/c72c5b1e3bd42e84465677e94aa83316ff3d9a14)
>> # To you after timeout.
>> OP_DROP <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP
>> OP_CHECKSIG
>> OP_ELSE
>> # To you if you have the revocation key
>> OP_SWAP 2 OP_SWAP <revocationkey> 2 OP_CHECKMULTISIG
>> OP_ENDIF
>> OP_ENDIF
>> ```
>>
>> This output can be spent, as before, with the payment preimage and the remote and local keys, with the remote key after a delay,
>> but it can also be spent with the remote key and revocation key, with the following witness script:
>>
>> ```
>> 0 <remote-sig> <revocation-sig>
I can be improved like this:
<remotePubkey> OP_SWAP
OP_SIZE 32 OP_EQUAL
OP_IF
OP_HASH160 paymentHash) <ripemd-of-payment-hash> OP_EQUALVERIFY
OP_2 OP_SWAP <localKey> OP_2 OP_CHECKMULTISIG
OP_ELSE
OP_SIZE OP_0 OP_EQUAL
OP_IF
OP_DROP <lockTime> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG
OP_ELSE
OP_SWAP OP_DROP <revocationPubKey> OP_CHECKSIG
OP_ENDIF
OP_ENDIF
It can now be spent with: <revocation-sig>
Cheers,
Fabrice