Re: [Lightning-dev] Splicing Proposal: Feedback please!
Good morning lisa, This is a good observation. Before, I'd already considered the rationale, for why channels have a single 2-of-2 UTXO as funding output. And it seems I should have considered this, prior to accepting the "parallel" construction as feasible. For sake of posterity, I leave the below writeup as a tangential to the design of splice (and to the design of Lightning having a single 2-of-2 UTXOs): # 0-conf is Unsafe, Yet Lightning is Safe; Why? To accept a 0-conf transaction output, is known to be unsafe. Replace-by-fee is always a possibility, regardless of whether the transaction opts in to RBF or not: a rational miner will always accept the higher feerate, disregarding any "opt-in" flag that is set or not set on the transaction. Thus we reject any advice that claims that 0-conf is tenable, even for tiny amounts. Yet when viewed solely in terms of transactions, Lightning protocol uses transactions that are not on any block (are kept offchain). Since they are not in a block, they are indistinguishable from 0-conf transactions, which are accepted by the receiver, yet are also not on any block. One might argue the distinction, that a "real" 0-conf transaction exists on some mempool somewhere, and thus has a chance to be on a block in the future, but mempools have no consensus, and the existence of a transaction on some mempool is not a safe assurance of it existing in the mempool of the next winning miner. So why is Lightning safe, when 0-conf transactions are in general not safe? Again, we should focus on why 0-conf transactions in general are not safe: transaction replacement. Thus, 0-conf transactions can be made safe, if you are somehow able to ensure that replacement transactions cannot be made. For example, if you are part of an n-of-n federation that signs the transaction, you can always safely accept a 0-conf transaction from that federation paying only to you, because you can always veto any replacement (by simply refusing to sign) that is not in your interests. This is in fact how Lightning works: a 2-of-2 federation (the channel counterparties) are the signatories of the 0-conf transactions that are the commitment transactions of the Lightning protocol. Replacement of the commitment transactions is strictly guided by the protocol; both sides have veto rights, since the source transaction output is 2-of-2. Thus, Lightning, though it uses 0-conf transactions, is safe, because it prevents the replacement of a 0-conf transaction without the receiver allowing it, by the simple expedient of including the receiver in the 2-of-2 multisig guarding its single funding TXO. ## The Implications for Splice Proposals Some splice proposals involve creating the equivalent of multiple funding TXOs for a single channel. Such constructions are unsafe-by-default on Poon-Dryja. In reality, every commitment transaction (or update transaction in Decker-Osuntokun-Russell) is replaceable by any other commitment (or update) transaction for that channel. Under Poon-Dryja older transactions are revoked (and hence one side risks loss of their collateral) while under Decker-Osuntokun-Russell older transactions may be "gainsaid" (i.e. newer update transactions may be reanchored to consume the TXO of the older update transaction, thus preventing that update from truly being committed to). This is relevant since before a splice, the channel has a single funding TXO, while after the splice, the channel has multiple. In particular, a commitment (or update) transaction, that has multiple inputs (to consume the multiple funding TXOs), can be replaced with a commitment (or update) transaction that was created before the splice. Under Poon-Dryja, such a commitment transaction may be revoked, but this leaves the other funding TXOs unuseable. Under Decker-Osuntokun-Russell, as long as the sequence number is preserved across the splice, it is possible for a later update transaction with multiple inputs to simply gainsay the old single-input update with the new multiple-input update transaction. (I suppose, that this is another advantage that Decker-Osuntokun-Russell has). Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, October 17, 2018 9:09 AM, lisa neigut wrote: > To add some context to this, if you start accepting HTLC's for the new > balance after the parallel commitment is made, but before the re-anchor is > buried, there's the potential for a race condition between a unilateral close > (or any revoked commitment transaction) and the re-anchoring commitment > transaction, that spends the 'pre-committed' UTXO of splicing in funds and > the original funding transaction. > > You can get around this by waiting until both the pre-commitment UTXO and the > re-anchor have cleared a minimum depth before accepting HTLC's for the new > balance totals, but that's twice as long
Re: [Lightning-dev] Splicing Proposal: Feedback please!
To add some context to this, if you start accepting HTLC's for the new balance after the parallel commitment is made, but before the re-anchor is buried, there's the potential for a race condition between a unilateral close (or any revoked commitment transaction) and the re-anchoring commitment transaction, that spends the 'pre-committed' UTXO of splicing in funds and the original funding transaction. You can get around this by waiting until both the pre-commitment UTXO and the re-anchor have cleared a minimum depth before accepting HTLC's for the new balance totals, but that's twice as long of a wait as the first, synchronized re-commitment scheme that Rusty originally proposed. It also makes leaving the original funding transaction 'exposed' (ie Rene's version of parallel splice) untenable, as there's always the risk of an old state being published to consume that input. This foobars your current HTLC commitments. On Tue, Oct 16, 2018 at 3:31 PM Rusty Russell wrote: > 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: > > OP_DEPTH 3 OP_EQUAL OP_IF > > OP_CHECKMULTISIG > > OP_ELSE > > OP_CHECKLOCKTIMEVERIFY OP_DROP > > OP_CHECKSIG > > OP_ENDIF > > > > 1. type: 40 (`splice_in`) (`option_splice`) > > 2. data: > >* [`32`:`channel_id`] > >* [`8`: `satoshis`] > >* [`32`: `txid`] > >* [`4`: `txoutnum`] > >* [`4`: `blockheight`] > >* [`33`: `myrescue_pubkey`] > > > > 1. type: 137 (`update_splice_in_accept`) (`option_splice`) > >data: > >* [`32`:`channel_id`] > >* [`32`: `txid`] > >* [`4`: `txoutnum`] > > > > 1. 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
Re: [Lightning-dev] Splicing Proposal: Feedback please!
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: > OP_DEPTH 3 OP_EQUAL OP_IF > OP_CHECKMULTISIG > OP_ELSE > OP_CHECKLOCKTIMEVERIFY OP_DROP > OP_CHECKSIG > OP_ENDIF > > 1. type: 40 (`splice_in`) (`option_splice`) > 2. data: >* [`32`:`channel_id`] >* [`8`: `satoshis`] >* [`32`: `txid`] >* [`4`: `txoutnum`] >* [`4`: `blockheight`] >* [`33`: `myrescue_pubkey`] > > 1. type: 137 (`update_splice_in_accept`) (`option_splice`) >data: >* [`32`:`channel_id`] >* [`32`: `txid`] >* [`4`: `txoutnum`] > > 1. 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
Re: [Lightning-dev] Splicing Proposal: Feedback please!
> > This is one of the cases where a simpler solution (relatively > speaking ^^) is to be preferred imho, allowing for future > iterations. > I think we should strive to splice in 1 on-chain tx, as if not the biggest benefit really is lost compared to just closing and reopening the channel. Complexity wise I don't think it will be that much to gain from the 2-tx proposal as (if I understand the proposal correctly) there will be even more transaction types with new scripts to code up and maintain. On Tue, Oct 16, 2018 at 5:38 AM Christian Decker wrote: > ZmnSCPxj via Lightning-dev > writes: > > >> One thing that I think we should lift from the multiple funding output > >> approach is the "pre seating of inputs". This is cool as it would allow > >> clients to generate addresses, that others could deposit to, and then > have > >> be spliced directly into the channel. Public derivation can be used, > along > >> with a script template to do it non-interactively, with the clients > picking > >> up these deposits, and initiating a splice in as needed. > > > > I am uncertain what this means in particular, but let me try to > > restate what you are talking about in other terms: > > > > 1. Each channel has two public-key-derivation paths (BIP32) to create > onchain addresses. One for each side of the channel. > > 2. When somebody sends to one of the onchain addresses in the path, > their client detects this. > > 3. The client initiates a splice-in automatically from this UTXO paying > to that address into the channel. > > > > It seems to me naively that the above can be done by the client > > software without any modifications to the Lightning Network BOLT > > protocol, as long as the BOLT protocol is capable of supporting *some* > > splice-in operation, i.e. it seems to be something that a client > > software can implement as a feature without requiring a BOLT change. > > Or is my above restatement different from what you are talking about? > > > > How about this restatement? > > > > 1. Each channel has two public-key-derivation paths (BIP32) to create > onchain addresses. One for each side of the channel. > > 2. The base of the above is actually a combined private-public keypair > of both sides (e.g. created via MuSig or some other protocol). Thus the > addresses require cooperation of both parties to spend. > > 3. When somebody sends to one of the onchain addresses in the path, > their client detects this. > > 4. The client updates the current transaction state, such that the new > commit transaction has two inputs ( the original channel transaction and > the new UTXO). > > > > The above seems unsafe without trust in the other peer, as, the other > > peer can simply refuse to create the new commit transaction. Since > > the address requires both parties to spend, the money cannot be spent > > and there is no backoff transaction that can be used. But maybe you > > can describe some mechanism to ensure this, if this is what is meant > > instead? > > This could easily be solved by making the destination address a Taproot > address, which by default is just a 2-of-2, but in the uncooperative > case it can reveal the script it commits to, which is just a timelocked > refund that requires a single-sig. The only problem with this is that > the refund would be non-interactive, and so the entirety of the funds, > that may be from a third-party, need to be claimed by one endpoint, > i.e., there is no splitting the funds in case of an uncollaborative > refund. Not sure how important that is though, since I don't think > third-party funds will come from unrelated parties, e.g., most of these > funds will come from an on-chain wallet that is under the control of > either parties so the refund should go back to that party anyway. > > Cheers, > Christian > ___ > 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
Re: [Lightning-dev] Splicing Proposal: Feedback please!
Good morning Laolu, > Is there a fundamental reason that CL will never allow nodes to create > multiple channels? It seems unnecessarily limiting. The architecture of c-lightning assigns a separate process to each peer. For simplicity this peer process handles only a single channel. Some of the channel initiation and shutdown protocols are written "directly", i.e. if the BOLT spec says this must happen before that, we literally write in the C code this_function(); that_function();. It would be possible to change this architecture with significant difficulty. However personally I do not really see the need to create multiple channels to a single peer, or increase the capacity with a specific peer (via splice or dual-funding). As Christian says in the other mail, this consideration, is that it becomes less a network and more of some channels to specific big businesses you transact with regularly. But I suppose, that we will have to see how the network evolves eventually; perhaps the goal of decentralization is simply doomed regardless, and Lightning will indeed evolve into a set of channels you maintain to specific big businesses you regularly work with. >>* [`4`:`feerate_per_kw`] > > What fee rate is this? IMO we should do commitmentv2 before splicing as then > we can more or less do away with the initiator distinction and have most > fees be ad hoc. I worry about doing away with initiator distinction, as I worry that an initiatee may be forced to pay fees they did not really voluntarily consider paying, when they are given funds on a channel initiated by someone else in exchange for funds on a separate channel; but this is probably a separate topic. >If you think any of these items is a higher priority than splicing then you >can simply start working on them! There's no agency that prescribes what >should and shouldn't be pursued or developed, just your willingness to >write some code. While true, for me personally I can only devote a limited amount of time to coding for Lightning, and thus I must always worry whether my priorities are even correct. I find it very common that people want to prioritize splicing over AMP or watchtowers, which puzzles me, and I wonder if I am incorrect in my prioritization. > One thing that I think we should lift from the multiple funding output > approach is the "pre seating of inputs". This is cool as it would allow > clients to generate addresses, that others could deposit to, and then have > be spliced directly into the channel. Public derivation can be used, along > with a script template to do it non-interactively, with the clients picking > up these deposits, and initiating a splice in as needed. I am uncertain what this means in particular, but let me try to restate what you are talking about in other terms: 1. Each channel has two public-key-derivation paths (BIP32) to create onchain addresses. One for each side of the channel. 2. When somebody sends to one of the onchain addresses in the path, their client detects this. 3. The client initiates a splice-in automatically from this UTXO paying to that address into the channel. It seems to me naively that the above can be done by the client software without any modifications to the Lightning Network BOLT protocol, as long as the BOLT protocol is capable of supporting *some* splice-in operation, i.e. it seems to be something that a client software can implement as a feature without requiring a BOLT change. Or is my above restatement different from what you are talking about? How about this restatement? 1. Each channel has two public-key-derivation paths (BIP32) to create onchain addresses. One for each side of the channel. 2. The base of the above is actually a combined private-public keypair of both sides (e.g. created via MuSig or some other protocol). Thus the addresses require cooperation of both parties to spend. 3. When somebody sends to one of the onchain addresses in the path, their client detects this. 4. The client updates the current transaction state, such that the new commit transaction has two inputs ( the original channel transaction and the new UTXO). The above seems unsafe without trust in the other peer, as, the other peer can simply refuse to create the new commit transaction. Since the address requires both parties to spend, the money cannot be spent and there is no backoff transaction that can be used. But maybe you can describe some mechanism to ensure this, if this is what is meant instead? Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
