[Lightning-dev] Commitment transaction format suggestions/proposals.

[Fabrice Drouin]

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