ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-18 📝 Original message: Hi Rusty et al, Would ...
📅 Original date posted:2018-10-18
📝 Original message:
Hi Rusty et al,
Would this work?
Glossary
--------
Old funding output - the TXO that the channel uses pre-splice. This must be a SegWit 2-of-2.
New funding output - the TXO that the channel will use post-splice. This must be a SegWit 2-of-2.
Old commitment transaction - a Poon-Dryja-revocable commitment transaction that consumes the old funding output.
New commitment transaction - a Poon-Dryja-revocable commitment transaction that consumes the new funding output.
Spliced input - a TXO wholly controlled solely by one channel party, which is intended for splicing into the channel. This must be SegWit.
Splicing transaction - a transaction that consumes the old funding output and one or more spliced inputs, and outputs the new funding output.
oldfunding --> [splicing]--> newfunding
/\
||
splicedin ==++
Splice Preparation Protocol
---------------------------
1. Both sides provide a list of spliced inputs. They confirm that the transactions are either confirmed or on their mempool.
2. Both sides maintain a separate pair of division of their money. One pair is the amount of money that can be currently used during the splice, and is initialized to the current state of the channel (money-during-splice). The other pair is the amount of money each has that will be added after the splice is confirmed (money-added-to-splice).
3. Both sides generate (but do not provide signatures or broadcast) the splicing transaction.
4. Both sides sign the new commitment transaction of the opposing side (which spends the new funding transaction of the splicing transaction).
5. Both sides now sign the splicing transaction, providing signatures for their nominated spliced inputs, and broadcast the fully signed splicing transaction.
Operation During Splice
-----------------------
While the splicing transaction is not sufficiently confirmed but is validly in their mempool or confirmed lightly, the channel is in "currently splicing" mode and changes to commitment transactions can be changed only according to these rules:
1. Both old commitment transactions and new commitment transactions are updated in parallel.
2. Each side can only use money that is theirs during the splice (money-during-splice) to offer HTLCs. They cannot use spliced-in money yet to offer HTLCs.
Failure Modes
-------------
If the splicing transaction becomes invalidated from the mempool, and was not confirmed/included in the block, then the splice has failed. Both sides should inform this splice failure to the other.
1. If any old commitment transaction was spent to invalidate the splice transaction, then the channel has closed and both sides drop to tracking the channel closure as unilateral close.
2. Otherwise, the splicing transaction became invalidated either due to a spend of any spliced input, or by invalidation of spliced input via transaction replacement (RBF). In this case, the protocol moves to splice failure.
Splice Failure
--------------
1. One side notices the splice failure and claims that the splice has failed.
2. The other side monitors its own mempool for invalidation of the splicing transaction, with a timeout.
3. If the other side also notices the splice failure, then both sides can drop the (money-added-to-splice) and revert back to the pre-splice channel. Spliced inputs should be considered by their owner to be spendable again for other onchain purposes.
3. Otherwise if the other side times out without seeing the splicing transaction getting invalidated, it will publish the latest old commitment transaction and the latest new commitment transaction and consider the channel as closing and tracking it as a unilateral close, checking for either the old funding output or the new funding output to be spent.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, October 17, 2018 6:30 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Rusty Russell rusty at rustcorp.com.au writes:
>
> > If we're going to do side splice-in like this, I would use a very
> > different protocol: the reason for this protocol was to treat splice-in
> > and splice-out the same, and inline splice-in requires wait time. Since
> > splice-out doesn't, we don't need this at all.
> > It would look much more like:
> >
> > 1. Prepare any output with script of specific form. eg:
> > OP_DEPTH 3 OP_EQUAL OP_IF
> > <funding_pubkey1> <funding_pubkey2> OP_CHECKMULTISIG
> > OP_ELSE
> > <blockheight> OP_CHECKLOCKTIMEVERIFY OP_DROP
> > <myrescue_pubkey> OP_CHECKSIG
> > OP_ENDIF
> >
> > 2. type: 40 (`splice_in`) (`option_splice`)
> >
> > 3. data:
> > - [`32`:`channel_id`]
> > - [`8`: `satoshis`]
> > - [`32`: `txid`]
> > - [`4`: `txoutnum`]
> > - [`4`: `blockheight`]
> > - [`33`: `myrescue_pubkey`]
> > 4. type: 137 (`update_splice_in_accept`) (`option_splice`)
> > data:
> > - [`32`:`channel_id`]
> > - [`32`: `txid`]
> > - [`4`: `txoutnum`]
> > 5. type: 138 (`update_splice_in_reject`) (`option_splice`)
> > data:
> > - [`32`:`channel_id`]
> > - [`32`: `txid`]
> > - [`2`:`len`]
> > - [`len`:`errorstr`]
> >
> > The recipient of `splice_in` checks that it's happy with the
> > `blockheight` (far enough in future). Once it sees the tx referred to
> > buried to its own `minimum_depth`, it checks output is what they
> > claimed, then sends `update_splice_in_accept`; it's followed up
> > `commitment_signed` like normal, but from this point onwards, all
> > commitment txs signatures have one extra sig.
>
> Lisa started asking pointed questions, and so I noticed that parallel
> splice doesn't work with Poon-Dryja channels.
>
> The counterparty can spend the old funding txout with a revoked spend.
> Sure, I can take all the money from that, but what about the spliced
> input?
>
> I came up with increasingly elaborate workarounds, but nothing stuck.
>
> Back to Plan A...
> Rusty.
>
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
Hi Rusty et al,
Would this work?
Glossary
--------
Old funding output - the TXO that the channel uses pre-splice. This must be a SegWit 2-of-2.
New funding output - the TXO that the channel will use post-splice. This must be a SegWit 2-of-2.
Old commitment transaction - a Poon-Dryja-revocable commitment transaction that consumes the old funding output.
New commitment transaction - a Poon-Dryja-revocable commitment transaction that consumes the new funding output.
Spliced input - a TXO wholly controlled solely by one channel party, which is intended for splicing into the channel. This must be SegWit.
Splicing transaction - a transaction that consumes the old funding output and one or more spliced inputs, and outputs the new funding output.
oldfunding --> [splicing]--> newfunding
/\
||
splicedin ==++
Splice Preparation Protocol
---------------------------
1. Both sides provide a list of spliced inputs. They confirm that the transactions are either confirmed or on their mempool.
2. Both sides maintain a separate pair of division of their money. One pair is the amount of money that can be currently used during the splice, and is initialized to the current state of the channel (money-during-splice). The other pair is the amount of money each has that will be added after the splice is confirmed (money-added-to-splice).
3. Both sides generate (but do not provide signatures or broadcast) the splicing transaction.
4. Both sides sign the new commitment transaction of the opposing side (which spends the new funding transaction of the splicing transaction).
5. Both sides now sign the splicing transaction, providing signatures for their nominated spliced inputs, and broadcast the fully signed splicing transaction.
Operation During Splice
-----------------------
While the splicing transaction is not sufficiently confirmed but is validly in their mempool or confirmed lightly, the channel is in "currently splicing" mode and changes to commitment transactions can be changed only according to these rules:
1. Both old commitment transactions and new commitment transactions are updated in parallel.
2. Each side can only use money that is theirs during the splice (money-during-splice) to offer HTLCs. They cannot use spliced-in money yet to offer HTLCs.
Failure Modes
-------------
If the splicing transaction becomes invalidated from the mempool, and was not confirmed/included in the block, then the splice has failed. Both sides should inform this splice failure to the other.
1. If any old commitment transaction was spent to invalidate the splice transaction, then the channel has closed and both sides drop to tracking the channel closure as unilateral close.
2. Otherwise, the splicing transaction became invalidated either due to a spend of any spliced input, or by invalidation of spliced input via transaction replacement (RBF). In this case, the protocol moves to splice failure.
Splice Failure
--------------
1. One side notices the splice failure and claims that the splice has failed.
2. The other side monitors its own mempool for invalidation of the splicing transaction, with a timeout.
3. If the other side also notices the splice failure, then both sides can drop the (money-added-to-splice) and revert back to the pre-splice channel. Spliced inputs should be considered by their owner to be spendable again for other onchain purposes.
3. Otherwise if the other side times out without seeing the splicing transaction getting invalidated, it will publish the latest old commitment transaction and the latest new commitment transaction and consider the channel as closing and tracking it as a unilateral close, checking for either the old funding output or the new funding output to be spent.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, October 17, 2018 6:30 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Rusty Russell rusty at rustcorp.com.au writes:
>
> > If we're going to do side splice-in like this, I would use a very
> > different protocol: the reason for this protocol was to treat splice-in
> > and splice-out the same, and inline splice-in requires wait time. Since
> > splice-out doesn't, we don't need this at all.
> > It would look much more like:
> >
> > 1. Prepare any output with script of specific form. eg:
> > OP_DEPTH 3 OP_EQUAL OP_IF
> > <funding_pubkey1> <funding_pubkey2> OP_CHECKMULTISIG
> > OP_ELSE
> > <blockheight> OP_CHECKLOCKTIMEVERIFY OP_DROP
> > <myrescue_pubkey> OP_CHECKSIG
> > OP_ENDIF
> >
> > 2. type: 40 (`splice_in`) (`option_splice`)
> >
> > 3. data:
> > - [`32`:`channel_id`]
> > - [`8`: `satoshis`]
> > - [`32`: `txid`]
> > - [`4`: `txoutnum`]
> > - [`4`: `blockheight`]
> > - [`33`: `myrescue_pubkey`]
> > 4. type: 137 (`update_splice_in_accept`) (`option_splice`)
> > data:
> > - [`32`:`channel_id`]
> > - [`32`: `txid`]
> > - [`4`: `txoutnum`]
> > 5. type: 138 (`update_splice_in_reject`) (`option_splice`)
> > data:
> > - [`32`:`channel_id`]
> > - [`32`: `txid`]
> > - [`2`:`len`]
> > - [`len`:`errorstr`]
> >
> > The recipient of `splice_in` checks that it's happy with the
> > `blockheight` (far enough in future). Once it sees the tx referred to
> > buried to its own `minimum_depth`, it checks output is what they
> > claimed, then sends `update_splice_in_accept`; it's followed up
> > `commitment_signed` like normal, but from this point onwards, all
> > commitment txs signatures have one extra sig.
>
> Lisa started asking pointed questions, and so I noticed that parallel
> splice doesn't work with Poon-Dryja channels.
>
> The counterparty can spend the old funding txout with a revoked spend.
> Sure, I can take all the money from that, but what about the spliced
> input?
>
> I came up with increasingly elaborate workarounds, but nothing stuck.
>
> Back to Plan A...
> Rusty.
>
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev