Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-18 Thread ZmnSCPxj via Lightning-dev
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  

> Rusty Russell 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:
> >
> > 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`: 

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

2018-10-18 Thread Fabrice Drouin

> 1.  Rather than trying to agree on what fees will be in the future, we
 > should use an OP_TRUE-style output to allow CPFP (Roasbeef)

We could also use SIGHASH_ANYONECANPAY|SIGHASH_SINGLE for HTLC txs, without
adding the "OP_TRUE" output to the commitment transaction. We would still
need the update_fee message to manage onchain fees for the commit tx (but
not the HTLC txs) but there would be no reason anymore to refuse fee rates
that are too high and channels would not get closed anymore when there's a
spike in onchain fees.


Lightning-dev mailing list