Hi Rusty et al,

Would this work?


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 

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 

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.


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, October 17, 2018 6:30 AM, Rusty Russell <ru...@rustcorp.com.au> 

> Rusty Russell ru...@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:
> >     <funding_pubkey1> <funding_pubkey2> OP_CHECKMULTISIG
> >     OP_ELSE
> >     <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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Lightning-dev mailing list

Reply via email to