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 <ru...@rustcorp.com.au>
wrote:
> 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:
> > 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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
