Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2017-01-24 📝 Original message: Hi all, There are a ...
📅 Original date posted:2017-01-24
📝 Original message:
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.
📝 Original message:
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.