From rusty at rustcorp.com.au  Wed Jan 25 00:53:24 2017
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Wed, 25 Jan 2017 11:23:24 +1030
Subject: [Lightning-dev] Commitment transaction format suggestions/proposals.
Message-ID: <87ziigq7sr.fsf@rustcorp.com.au>

Hi all,

        There are a couple of changes which are being proposed for
commitment transactions, and I wanted to bring the conversation outside
github to a wider audience:

1. To-remote output is currently P2PKH: should we make it P2WPKH and
   save some bytes?

2. Fabrice proposed we make commitment transaction outputs directly
   spendable by the penalty transaction; currently can only use the
   revocation key with the HTLC-success or HTLC-timeout transactions.
  
        https://github.com/lightningnetwork/lightning-rfc/issues/88

I've included my reply to that PR here, for further discussion:

Fabrice Drouin <notifications at github.com> writes:
> We would like to propose a small modification of the commiment
> transaction HTLC scripts, which would make it possible, when the other
> party publishes a revoked commit transaction, to create penalty
> transactions that spend the HTLC outputs. With  the current design the
> penalty transaction spends the second-stage HLTC-timeout and
> HTLC-success transactions.

Interesting!  Tadge pointed out we could eliminate that, and we did
without actually measuring the complexity cost.

> This does not change the way external channel monitors would work, but for node which do their own monitoring this has several advantages:
> - for htlcs offered by the counterparty: we don't need to know the counterparty's HTLC-timeout signature, which simplifies BOLT2 and saves the burden of storing the signatures

More importantly, it relieves us of having to generate and send those
signatures, which is a potential bottleneck.  Especially for Tadge's
Raspberry Pi!

> - 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.

So I think most of the complexity is still there, though the penalty
doesn't need to wait.

> ## 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.

> ## Changes to the Received HTLC Output script
> We use  additonal IF branch  (there is probably a better way to do this?):
>
> ```
> <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?

>         # 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 did a quick recalculate the weights of the commitment tx in Appendix
A.  offered_htlc_script goes from 104 bytes to 138 bytes,
accepted_htlc_script from 109 bytes to 152 bytes (assuming OP_SIZE
OP_NOTIF works).

HTLC-timeout weight goes from 634 to 668, HTLC-success from 671 to 714.
That's about 6%, which is pretty small.

Tadge was optimizing for the smallest possible on-chain footprint, which
I think is a valid concern.  But let's please discuss the tradeoffs...

Thanks!
Rusty.