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.