Re: [Lightning-dev] Splicing Proposal: Feedback please!
Good morning Laolu, >> I worry about doing away with initiator distinction > > Can you re-phrase this sentence? I'm having trouble parsing it, thanks. The initiator of an action is the node which performs the first step in an action. For instance, when opening a channel, the node which initiates the channel open is the initiator. Even in a dual-funding channel open, we should distinguish the initiator. What I want to preserve (as for current channel opening) is that the initiator of an action should be the one to pay any costs or fees to that action. For instance, when opening a channel, the channel opener is the one who pays for all onchain fees related to opening and closing the channel, as the opening node is the initiator of the action. Similarly, for channel splicing, I think it would be wiser to have the initiator of the splice be the one, to pay for any onchain fees related to splicing (and any backoff/failure path if some backoff is needed), even if the other side then also decides to splice in/out some funds together with the splice. To my mind, this is wiser as it reduces the surface of potential attacks in case of a bad design or implementation of dual-fund-opening and splicing; to engage in the attack, one must be willing to shoulder all the onchain fees, which hopefully should somewhat deter all but the most egregious or lopsided of attacks. Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Splicing Proposal: Feedback please!
Olaoluwa Osuntokun writes: >> 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. > > I made no reference to any "big businesses", only the utility that arises > when one has multiple channels to a given peer. Consider an easier example: > given the max channel size, I can only ever send 0.16 or so BTC to that > peer. If I have two channels, then I can send 0.32 and so on. Consider the > case post AMP where we maintain the current limit of the number of in flight > HTLCs. If AMP causes most HTLCs to generally be in flight within the > network, then all of a sudden, this "queue" size (outstanding HTLCS in a > commitment) becomes more scarce (assume a global MTU of say 100k sat for > simplicity). This may then promote nodes to open additional channels to > other nodes (1+) in order to accommodate the increased HTLC bandwidth load > due to the sharded multi-path payments. I think I see the issue now, thanks for explaining. However I get the feeling that this is a rather roundabout way of increasing the limitations that you negotiated with your peer (max HTLC in flight, max channel capacity, ...), so wouldn't those same limits also apply across all channels that you have with that peer? Isn't the real solution here to lift those limitations? > Independent on bolstering the bandwidth capabilities of your links to other > nodes, you would still want to maintain a diverse set of channels for fault > tolerance, path diversity, and redundancy reasons. Absolutely agree, and it was probably my mistake for assuming that you would go for the one peer only approach as a direct result of increasing bandwidth to one peer. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Splicing Proposal: Feedback please!
Olaoluwa Osuntokun writes: >> Mainly limitations of our descriptor language, TBH. > > I don't follow...so it's a size issue? Or wanting to avoid "repeated" > fields? Not that smart: tools/extract-formats.py extracts descriptions from the spec for each message. It currently requires constants in the field lengths, and these would be variable. We'd have to teach it about messages within messages, eg: 1. subtype: 1 (`splice_add_input`) 2. data: * [`8`: `satoshis`] * [`32`: `prevtxid`] * [`4`: `prevtxoutnum`] * [`2`: `wscriptlen`] * [`wscriptlen`: `wscript`] * [`2`: `scriptlen`] * [`scriptlen`: `scriptpubkey`] 1. subtype: 2 (`splice_add_output`) 2. data: * [`32`:`channel_id`] * [`8`: `satoshis`] * [`2`: `scriptlen`] * [`scriptlen`: `outscript`] 1. type: 40 (`splice_add`) (`option_splice`) * [`32`:`channel_id`] * [`2`: `num_splice_in`] * [`num_splice_in*splice_add_input`: `inputs`] * [`2`: `num_splice_out`] * [`num_splice_out*splice_add_output`: `outputs`] >> We're basically co-generating a tx here, just like shutdown, except it's >> funding a new replacement channel. Do we want to CPFP this one too? > > It'd be nice to be able to also anchor down this splicing transaction given > that we may only allow a single outstanding splicing operation to begin > with. Being able to CPFP it (and later on provide arbitrary fee inputs) > allows be to speed up the process if I want to queue another operation up > right afterwards. That has some elegance (we would whatever fee scheme we will use for commitment txs), but means we will almost always *have* to CPFP, which is unfortunate for chain bloat. Cheers, 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!
> Mainly limitations of our descriptor language, TBH. I don't follow...so it's a size issue? Or wanting to avoid "repeated" fields? > I thought about restarting the revocation sequence, but it seems like that > only saves a tiny amount since we only store log(N) entries Yeah that makes sense, forgetting the HTLC state is a big enough win in and of itself. >>> Splice Signing >> >> It seems that we're missing some fields here if we're to allow the splicing >> of inputs to be done in a non-blocking manner. We'll need to send two >> revocation points for the new commitment: one to allow it to be created, and >> another to allow updates to proceed right after the signing is completed. In >> this case we'll also need to update both commitments in tandem until the >> splicing transaction has been sufficiently confirmed. > >I think we can use the existing revocation points for both. Yep, if we retain the existing shachain trees, then we just continue to extend the leaves! > We're basically co-generating a tx here, just like shutdown, except it's > funding a new replacement channel. Do we want to CPFP this one too? It'd be nice to be able to also anchor down this splicing transaction given that we may only allow a single outstanding splicing operation to begin with. Being able to CPFP it (and later on provide arbitrary fee inputs) allows be to speed up the process if I want to queue another operation up right afterwards. -- Laolu On Wed, Oct 17, 2018 at 9:31 AM Rusty Russell wrote: > Olaoluwa Osuntokun writes: > > Hi Rusty, > > > > Happy to get the splicing train rolling! > > > >> We've had increasing numbers of c-lightning users get upset they can't > >> open multiple channels, so I guess we're most motivated to allow > splicing > > of > >> existing channels > > > > Splicing isn't a substitute for allowing multiple channels. Multiple > > channels allow nodes to: > > > > * create distinct channels with distinct acceptance policies. > > * create a mix of public and non-advertised channels with a node. > > * be able to send more than the (current) max HTLC amount > > using various flavors of AMP. > > * get past the (current) max channel size value > > * allow a link to carry more HTLCs (due to the current super low max > HTLC > > values) given the additional HTLC pressure that > > AMP may produce (alternative is a commitment fan out) > > These all seem marginal to me. I think if we start hitting max values, > we should discuss increasing them. > > > Is there a fundamental reason that CL will never allow nodes to create > > multiple channels? It seems unnecessarily limiting. > > Yeah, we have a daemon per peer. It's really simple with 1 daemon, 1 > channel. My own fault: I was the one who insisted we mux multiple > connections over the same transport; if we'd gone for independent > connections our implementation would have been trivial. > > >> Splice Negotiation: > > > > Any reason to now make the splicing_add_* messages allow one to add > several > > inputs in a single message? Given "acceptable" constraints for how large > the > > witness and pkScripts can be, we can easily enforce an upper limit on the > > number of inputs/outputs to add. > > Mainly limitations of our descriptor language, TBH. > > > I like that the intro messages have already been designed with the > > concurrent case in mind beyond a simpler propose/accept flow. However is > > there any reason why it doesn't also allow either side to fully > re-negotiate > > _all_ the funding details? Splicing is a good opportunity to garbage > collect > > the prior revocation state, and also free up obsolete space in watch > towers. > > I thought about restarting the revocation sequence, but it seems like > that only saves a tiny amount since we only store log(N) entries. We > can drop old HTLC info post-splice though, and (after some delay for > obscurity) tell watchtowers to drop old entries I think. > > > Additionally, as the size of the channel is either expanding or > contracting, > > both sides should be allowed to modify things like the CSV param, > reserve, > > max accepted htlc's, max htlc size, etc. Many of these parameters like > the > > CSV value should scale with the size of the channel, not allowing these > > parameters to be re-negotiated could result in odd scenarios like still > > maintain a 1 week CSV when the channel size has dipped from 1 BTC to 100k > > satoshis. > > Yep, good idea! I missed that. > > Brings up a side point about these values, which deserves its own > post... > > >> 1. type: 40 (`splice_add_input`) (`option_splice`) > > > > In order to add nested p2sh inputs, we'll need to also expose the redeem > > script here, or add additional fields to allow sides to set a sig script > as > > well as witness during the signing phase. > > > >> - scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> > EQUAL' > > > > So no P2SH? :( > > Another omission, yeah, we'd want that too I think. >
Re: [Lightning-dev] Splicing Proposal: Feedback please!
> 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. I made no reference to any "big businesses", only the utility that arises when one has multiple channels to a given peer. Consider an easier example: given the max channel size, I can only ever send 0.16 or so BTC to that peer. If I have two channels, then I can send 0.32 and so on. Consider the case post AMP where we maintain the current limit of the number of in flight HTLCs. If AMP causes most HTLCs to generally be in flight within the network, then all of a sudden, this "queue" size (outstanding HTLCS in a commitment) becomes more scarce (assume a global MTU of say 100k sat for simplicity). This may then promote nodes to open additional channels to other nodes (1+) in order to accommodate the increased HTLC bandwidth load due to the sharded multi-path payments. Independent on bolstering the bandwidth capabilities of your links to other nodes, you would still want to maintain a diverse set of channels for fault tolerance, path diversity, and redundancy reasons. In the splicing case, if only a single in flight splice is permitted, and me as users wants to keep all their funds in channels, the more channels I have, the more concurrent on-chain withdraws/deposits I'll be able to service. > I worry about doing away with initiator distinction Can you re-phrase this sentence? I'm having trouble parsing it, thanks. > which puzzles me, and I wonder if I am incorrect in my prioritization. Consider that not all work items are created equal, and they have varying levels of implementation and network wide synchronization. For example, I think we all consider multi-hop decor to be a high priority. However, it has the longest and hardest road to deployment as it effectively forces us to perform a "slow motion hard-fork" within the network. On the other hand, if lnd wanted to deploy a flavor of non-interactive (no invoice) payments *today*, we could do that without *any* synchronization at the implementation of network level, as it's purely an end-to-end change. > I am uncertain what this means in particular, but let me try to restate > what you are talking about in other terms: Thought about it a bit more (like way ago) and this is really no different than having a donation page where people use public derivation to derive addresses to deposit directly to your channel. All the Lightning node needs to do, is recognize that any coins send to these derived addresses should be immediately spliced into an available channel (doesn't have any other outstanding splices). > It seems to me naively that the above can be done by the client software > without any modifications to the Lightning Network BOLT protocol Sticking with that prior version yes, this would be able to be seamlessly included in the async splce proposal. The one requirement is a link-level protocol that allows both sides to collaboratively create and recognize these outputs. > Or is my above restatement different from what you are talking about? You're missing the CLTV timeout clause. It isn't a plain p2wkh, it's a p2wsh script. Either they splice this in before the timeout, or it times out and it goes back to one party. In this case, it's no different than the async concurrent commitment splice in double spend case. -- Laolu On Tue, Oct 16, 2018 at 10:16 PM ZmnSCPxj wrote: > 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
Re: [Lightning-dev] Splicing Proposal: Feedback please!
Conner Fromknecht writes: > In light of this, and if I'm following along, it seems our hand is forced in > splicing via a single on-chain transaction. In my book, this is preferable > anyway. I'd much rather push complexity off-chain than having to do a > mutli-stage splicing pipeline. Agreed. As Christian pointed out, at least our design space is reduced now? > I would propose sending a distinct message, which references the > `active_channel_id` and a `splice_channel_id` for the pending splice: > > 1. type: XXX (`commitment_splice_signed`) (`option_splice`) > 2. data: >* [`32`:`active_channel_id`] >* [`32`:`splice_channel_id`] >* [`64`:`signature`] >* [`2`:`num_htlcs`] >* [`num_htlcs*64`:`htlc_signature`] > > This more directly addresses handling multiple pending splices, as well as > preventing us from running into any size constraints. The purpose of > including the `active_channel_id` would be to remote node locate the > spliced channel, since it may not be populated indexes containing > active channels. If we don't want to include this, the existing message > can be used without modification. Yes, I like this! I don't think the `splice_channel_id` helps us much, since we need to wait we receive all pending commitement_splice_signed before sending revoke_and_ack, and I think we should simply insist they be in splice order which makes implementation easier (simple counter). >> We shouldn't allow more than one pending splice operation anyway, as >> stated in your proposal initially. We are already critically reliant on > our >> transaction being confirmed on-chain, so I don't see this as much of an >> added issue. > > IMO there's no reason to limit ourselves to one pending splice at the > message > level. I think it'd be an oversight to not to plan ahead with RBF in mind, > given that funding transactions have gone unconfirmed precisely because of > improperly chosen fee rates. Arguably, funding flow should be extended to > support this as well. Good reminder re: RBF and funding. I've put this on the brainstorming list with your name next to it ;) > Adding a splice-reject message/error code should be sufficient to allow > implementations to signal that their local tolerance for number of pending > splices has been reached. It's likely we'd all start with getting one splice > working, but then the messages won't need to modified if we want to > implement > additional pending splices via RBF. > > A node that wants to RBF but receives a reject can then proceed with CPFP > as a > last resort. > > Are there any downsides I'm overlooking with this approach? No, I think you've covered it. >> | Bit Position | Name | Field > | >> | - | - | > | >> | 0 | `option_channel_htlc_max` | `htlc_maximum_msat` > | >> | 1 | `option_channel_moving` | `moving_txid > | >> >> The `channel_update` gains the following field: >> * [`32`: moving_txid`] (option_channel_moving) > > Do we actually need to send the `moving_txid` via a channel update? I think > it's > enough for both parties to send `channel_update`s with the > `option_channel_moving` bit set, and continue to keep the channel in our > routing > table. It helps because they can't broadcast the new channel for 6 confirms. OTOH, that's probably not too long to wait. > If we receive later receive two `channel_update`s whose `short_channel_id`s > reference the spending transaction (and the node pubkeys are the same), we > assume the splice was successful and that this channel has been > subsumed. So rule would be: if we've seen both channel_updates with option_channel_moving set, we remember the txid which closed it, and start a 100-block countdown the "real close". If we a (valid) channel_announce for that closing tx with same node pubkeys, we simply delete the 100-block countdown. > I > think this works so long as the spending transaction doesn't contain > multiple > funding outputs, though I think the current proposal is fallible to this as > well. I think variant above works even in that case? > To me, this proposal has the benefit of not bloating gossip bandwidth with > an > extra field that would need to parsed indefinitely, and gracefully > supporting > RBF down the road. Otherwise we'd need to gossip and store each potential > txid. > > With regards to forwarding, both `short_channel_id`s would be accepted by > the > splicers for up to 100 blocks (after splice confirm?), at which point they > can > both forget the prior `short_channel_id`. Technically, the need to remember for some grace period after they announce the block. We have a similar recommendation for old fee values, though it's soft. 100 seems overkill. I think we can assume gossip will propagate widely within 6 blocks and say they should accept it at least up to 6 blocks after announcing? Or 1 hour, though I prefer using the
Re: [Lightning-dev] Splicing Proposal: Feedback please!
Good evening lightning-dev, > If we receive later receive two `channel_update`s whose `short_channel_id`s > reference the spending transaction (and the node pubkeys are the same), we > assume the splice was successful and that this channel has been subsumed. I > think this works so long as the spending transaction doesn't contain multiple > funding outputs, though I think the current proposal is fallible to this as > well. Thought about this some more. The main difference seems to be whether the gossiped data is forward or backward looking. By forward looking, I mean that we gossip where the splice will move to, and backward looking gossips where the splice moved from. If we want to make the original proposal work w/ multiple funding outputs on one splice, I think it can be accomplished by sending the funding outpoint as opposed to just the txid. For the backward looking proposal, the `channel_update` could be modified to include the `short_channel_id` of the prior funding output. IMO we probably want to include the extra specificity even if we don't plan to have multiple funding outputs on a commitment implemented tomorrow, since outputs are what we truly care about. Of the two, it still seems like the backward looking approach results in less gossiped data since are able to reference a single confirmed output by location (8 bytes), instead of N unconfirmed outputs by outpoint (N*34 bytes). Another advantage I see with the backward looking splice announcments is that they can be properly verified before forwarding to the network by examining the channel lineage. In contrast, one can't be sure if the outpoint in a forward looking announcement will ever confirm, or even if it spends from the original channel point unless one also has the transaction. Until a splice does confirm, a node has to store multiple potential splice outpoints. Seeing this, it seems to me that backward looking announcements are less susceptible to abuse and DOS in this regard. Thoughts? Cheers, Conner On Thu, Oct 18, 2018 at 8:04 PM Conner Fromknecht wrote: > Good evening all, > > Thank you Rusty for starting us down this path :) and to ZmnSCPxj and Lisa > for > your thoughts. I think this narrows down the design space considerably! > > In light of this, and if I'm following along, it seems our hand is forced > in > splicing via a single on-chain transaction. In my book, this is preferable > anyway. I'd much rather push complexity off-chain than having to do a > mutli-stage splicing pipeline. > > > 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 > > Indeed, I'm not aware of any splicing mechanism that enables off-chain use > of > spliced-in funds before the new funding output confirms. Even in the async, > single-txn case, the new funds cannot be spent until the new funding output > confirms sufficiently. > > From my POV, the desired properties of a splice are: > 1. non-blocking (asynchronous) usage of the channel > 2. single on-chain txn > 3. ability to RBF (have multiple pending splices) > > Of these, it seems we've solidified 1 and 2. I understand the desire to not > tackle RBF on the first attempt given the additional complexity. However, > I > do believe there are ways we can proceed in which our first attempt largely > coincides with supporting it in the future. > > With that in mind, here are some thoughts on the proposals above. > > ## RBF and Multiple Splices > > > 1. type: 132 (`commitment_signed`) > > 2. data: > >* [`32`:`channel_id`] > >* [`64`:`signature`] > >* [`2`:`num_htlcs`] > >* [`num_htlcs*64`:`htlc_signature`] > >* [`num_htlcs*64`:`htlc_splice_signature`] (`option_splice`) > > This will overflow the maximum message size of 65535 bytes for num_htlcs > > 511. > > I would propose sending a distinct message, which references the > `active_channel_id` and a `splice_channel_id` for the pending splice: > > 1. type: XXX (`commitment_splice_signed`) (`option_splice`) > 2. data: >* [`32`:`active_channel_id`] >* [`32`:`splice_channel_id`] >* [`64`:`signature`] >* [`2`:`num_htlcs`] >* [`num_htlcs*64`:`htlc_signature`] > > This more directly addresses handling multiple pending splices, as well as > preventing us from running into any size constraints. The purpose of > including the `active_channel_id` would be to remote node locate the > spliced channel, since it may not be populated indexes containing > active channels. If we don't want to include this, the existing message > can be used without modification. > > > We shouldn't allow more than one pending splice operation anyway, as > > stated
Re: [Lightning-dev] Splicing Proposal: Feedback please!
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 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 > > OP_CHECKMULTISIG > > OP_ELSE > > OP_CHECKLOCKTIMEVERIFY OP_DROP > > 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`:
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!
Olaoluwa Osuntokun writes: > Hi Rusty, > > Happy to get the splicing train rolling! > >> We've had increasing numbers of c-lightning users get upset they can't >> open multiple channels, so I guess we're most motivated to allow splicing > of >> existing channels > > Splicing isn't a substitute for allowing multiple channels. Multiple > channels allow nodes to: > > * create distinct channels with distinct acceptance policies. > * create a mix of public and non-advertised channels with a node. > * be able to send more than the (current) max HTLC amount > using various flavors of AMP. > * get past the (current) max channel size value > * allow a link to carry more HTLCs (due to the current super low max HTLC > values) given the additional HTLC pressure that > AMP may produce (alternative is a commitment fan out) These all seem marginal to me. I think if we start hitting max values, we should discuss increasing them. > Is there a fundamental reason that CL will never allow nodes to create > multiple channels? It seems unnecessarily limiting. Yeah, we have a daemon per peer. It's really simple with 1 daemon, 1 channel. My own fault: I was the one who insisted we mux multiple connections over the same transport; if we'd gone for independent connections our implementation would have been trivial. >> Splice Negotiation: > > Any reason to now make the splicing_add_* messages allow one to add several > inputs in a single message? Given "acceptable" constraints for how large the > witness and pkScripts can be, we can easily enforce an upper limit on the > number of inputs/outputs to add. Mainly limitations of our descriptor language, TBH. > I like that the intro messages have already been designed with the > concurrent case in mind beyond a simpler propose/accept flow. However is > there any reason why it doesn't also allow either side to fully re-negotiate > _all_ the funding details? Splicing is a good opportunity to garbage collect > the prior revocation state, and also free up obsolete space in watch towers. I thought about restarting the revocation sequence, but it seems like that only saves a tiny amount since we only store log(N) entries. We can drop old HTLC info post-splice though, and (after some delay for obscurity) tell watchtowers to drop old entries I think. > Additionally, as the size of the channel is either expanding or contracting, > both sides should be allowed to modify things like the CSV param, reserve, > max accepted htlc's, max htlc size, etc. Many of these parameters like the > CSV value should scale with the size of the channel, not allowing these > parameters to be re-negotiated could result in odd scenarios like still > maintain a 1 week CSV when the channel size has dipped from 1 BTC to 100k > satoshis. Yep, good idea! I missed that. Brings up a side point about these values, which deserves its own post... >> 1. type: 40 (`splice_add_input`) (`option_splice`) > > In order to add nested p2sh inputs, we'll need to also expose the redeem > script here, or add additional fields to allow sides to set a sig script as > well as witness during the signing phase. > >> - scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> EQUAL' > > So no P2SH? :( Another omission, yeah, we'd want that too I think. >>* [`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. We're basically co-generating a tx here, just like shutdown, except it's funding a new replacement channel. Do we want to CPFP this one too? >> Splice Signing > > It seems that we're missing some fields here if we're to allow the splicing > of inputs to be done in a non-blocking manner. We'll need to send two > revocation points for the new commitment: one to allow it to be created, and > another to allow updates to proceed right after the signing is completed. In > this case we'll also need to update both commitments in tandem until the > splicing transaction has been sufficiently confirmed. I think we can use the existing revocation points for both. > Also, what about change addresses? Are they to be explicitly specified as > splice outs? They'd be splice-outs, yeah. >> 1. type: 43 (`splice_commitment_signature`) (`option_splice`) > > It may be worth pointing out there that we're able to transfer all existing > HTLCs over to the new commitment as additional context. Yeah, I think people missed that it was non-blocking like that. >> 1. type: 45 (`splice_witness`) (`option_splice`) > > Should also allow either side to specify the sig script here if we're to > allow nested p2sh (which we should IMO!). Yep. >> * [`2`:`len`] >> * [`len`:`witnesses`] > > Is the extra length needed if all the witness elements themselves are length > delimited? Yes, we always length-delimit fields so we can add options later. > > It isn't clear in the
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!
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
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
Re: [Lightning-dev] Splicing Proposal: Feedback please!
Olaoluwa Osuntokun writes: > Splicing isn't a substitute for allowing multiple channels. Multiple > channels allow nodes to: > > * create distinct channels with distinct acceptance policies. > * create a mix of public and non-advertised channels with a node. > * be able to send more than the (current) max HTLC amount > using various flavors of AMP. > * get past the (current) max channel size value > * allow a link to carry more HTLCs (due to the current super low max HTLC > values) given the additional HTLC pressure that > AMP may produce (alternative is a commitment fan out) While these are all good points, I think they are equally well served if by creating channels to other peers. This has the added benefit of reducing the node's reliance on a single peer. In fact it seems we are currently encouraging users to have a small number of fat channels that are manually maintained (dual-funding, splicing, multiple channels per peer), rather than making the default to create a diverse set of channels that allow indirectly routed payments. Instead of obsessing about that one peer and hoping that that peer is online when we need it, we should make routed payments a first-class citizen. If we can route correctly and with confidence we can stop worrying about that one peer and our connectivity to it. On the other hand, if routing doesn't work, and people have to worry about that one channel that connects them directly to the destination, then we're not much of a network, but rather a set of disjoint channels. Ultimately users should stop caring about individual channels or peer relationships, and multipath routing gets us a long way there. I'd really like to have a wallet that'll just manage channels in the background and not expose those details to the users which just want to send and receive payments, and we can start that now by de-emphasizing the importance of the peer selection. Regards, Christian ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Splicing Proposal: Feedback please!
> I would suggest more to consider the simpler method, despite its larger > onchain footprint (which is galling), The on-chain footprint is a shame, and also it gets worse if we start to allow multiple pending splices. Also the lack of a non-blocking splice in is a big draw back IMO. > but mostly because I do not see splicing as being as important as AMP or > watchtowers (and payment decorrelation seems to affect how AMP can be > implemented, so its priority also goes up). Most of what you mention here have _very_ different deployment timelines and synchronization requirements across clients. For example, splicing is a link level change and can start to be rolled out immediately. Decorrelation on the other hand, is a _network_ level change, and would take a considerable amount of time to reach widespread deployment as it essentially splits the rouble paths in the network until all/most are upgraded. 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. 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. -- Laolu On Thu, Oct 11, 2018 at 11:14 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Rusty, > > > > > > It may be good to start brainstorming possible failure modes during > splice, and how to recover, and also to indicate the expected behavior in > the proposal, as I believe these will be the points where splicing must be > designed most precisely. What happens when a splice is ongoing and the > communication gets disconnected? What happens when some channel failure > occurs during splicing and we are forced to drop onchain? And so on. > > > > Agreed, but we're now debating two fairly different methods for > > splicing. Once we've decided on that, we can try to design the > > proposals themselves. > > I would suggest more to consider the simpler method, despite its larger > onchain footprint (which is galling), but mostly because I do not see > splicing as being as important as AMP or watchtowers (and payment > decorrelation seems to affect how AMP can be implemented, so its priority > also goes up). So I think getting *some* splicing design out would be > better even if imperfect. Others may disagree on priority. > > Regards, > ZmnSCPxj > ___ > 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!
ZmnSCPxj writes: > Good morning Rusty, > > In BOLT #2 we currently impose a 2^24 satoshi limit on total channel > capacity. Is splicing intended to allow violation of this limit? I do not > see it mentioned in the proposal. Can I splice 21 million bitcoins on a > 1-satoshi channel? Good question! I think that's the kind of thing we should consider carefully at the Summit. > It may be good to start brainstorming possible failure modes during splice, > and how to recover, and also to indicate the expected behavior in the > proposal, as I believe these will be the points where splicing must be > designed most precisely. What happens when a splice is ongoing and the > communication gets disconnected? What happens when some channel failure > occurs during splicing and we are forced to drop onchain? And so on. Agreed, but we're now debating two fairly different methods for splicing. Once we've decided on that, we can try to design the proposals themselves. Thanks, 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!
Christian Decker writes: > On Thu, Oct 11, 2018 at 3:40 AM Rusty Russell wrote: > >> > * Once we have enough confirmations we merge the channels (either >> > automatically or with the next channel update). A new commitment tx is >> > being created which now spends each output of each of the two funding tx >> > and assigns the channel balance to the channel partners accordingly to >> the >> > two independent channels. The old commitment txs are being invalidated. >> > * The disadvantage is that while splicing is not completed and if the >> > funder of the splicing tx is trying to publish an old commitment tx the >> > node will only be punished by sending all the funds of the first funding >> tx >> > to the partner as the special commitment tx of the 2nd output has no >> newer >> > state yet. >> >> Yes, this is the alternative method; produce a parallel funding tx >> (which only needs to support a single revocation, or could even be done >> by a long timeout) and then join them when it reaches the agreed depth. >> >> It has some elegance; particularly because one side doesn't have to do >> any validation or store anything until it's about to splice in. You get >> asked for a key and signature, you produce a new one, and sign whatever >> tx they want. They hand you back the tx and the key you used once it's >> buried far enough, and you check the tx is indeed buried and the output >> is the script you're expecting, then you flip the commitment tx. >> >> But I chose chose not to do this because every transaction commitment >> forever will require 2 signatures, and doesn't allow us to forget old >> revocation information. >> >> And it has some strange side-effects: onchain this looks like two >> channels; do we gossip about both? We have to figure the limit on >> splice-in to make sure the commitment tx stays under 400kSipa. >> > > This is a lot closer to my original proposal for splicing, and I > still like it a lot more since the transition from old to new > channel is bascially atomic (not having to update state on both > pre-splice and post-splice version). The new funds will remain > unavailable for the same time, and since we allow only one > concurrent splice in your proposal we don't even lose any > additional time regarding the splice-outs. > > So pulling the splice_add_input and splice_add_output up to > signal the intent of adding funds to a splice. Splice_all_added > is then used to start moving the funds to a pre-allocated 2-of-2 > output where the funds can mature. Once the funds are > matured (e.g., 6 confirmations) we can start the transition: both > parties claim the funding output, and the pre-allocated funds, to > create a new funding tx which is immediately broadcast, and we > flip over to the new channel state. No need to keep parallel > state and then disambiguating which one it was. 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. Similarly, splice-out: 1. type: 139 (`update_splice_out`) (`option_splice`) * [`32`:`channel_id`] * [`8`: `satoshis`] * [`2`: `scriptlen`] * [`scriptlen`: `outscript`] The recipient checks that the output script is standard, and the amount can be afforded by the other side. From then on, each commitment tx has a new output. Note this doesn't put the splice out on the blockchain! 1. type: 140 (`propose_reopen`) (`option_splice`) * [`32`:`channel_id`] * [`4`:`feerate_per_kw`] * [`33`:`funding_pubkey`] This is initiates a mutually-agreed broadcast of the current state: all inputs (original and spliced), all spliced outputs, and a funding-style 2x2 which has all the remaining funds. Call this a 'reopen tx'. This
Re: [Lightning-dev] Splicing Proposal: Feedback please!
Good morning Rusty and Christian and list, > This is one of the cases where a simpler solution (relatively > speaking ^^) is to be preferred imho, allowing for future > iterations. I would basically agree here, with the further proviso that I think splice is not quite as priority as AMP, decorrelation, or watchtowers. The simpler solution has the drawback of more transactions onchain, but massively reduces the complexity of maintaining parallel state updates. Parallel updates would increase greatly our need to test the feature in various conditions (and specify also in the formal spec what possible failure modes are and how they should be recovered, as a basic safety for users of Lightning). Of course, the same course of thought is what lead to onchain transaction bloat in the first place. Splicing features might be versioned, with the possibility of better splicing mechanisms being defined in later BOLT specs. This can allow us to iterate somewhat and start with the simpler-but-more-onchain-txes splicev1 feature, possibly getting replaced with a more thought-out-and-planned splicev2 feature with parallel updates (and careful analysis of possible failures in parallel updates and how we should recover from them). The drawback is that this is further complexity later on by having to possibly support multiple splicing mechanisms (but if we assign completely separate feature bits, it may be possible for pragmatic implementations to eventually stop signalling the ability to splice using older splicing feature versions in favor of newer splicing feature versions). Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Splicing Proposal: Feedback please!
On Thu, Oct 11, 2018 at 3:40 AM Rusty Russell wrote: > > * Once we have enough confirmations we merge the channels (either > > automatically or with the next channel update). A new commitment tx is > > being created which now spends each output of each of the two funding tx > > and assigns the channel balance to the channel partners accordingly to > the > > two independent channels. The old commitment txs are being invalidated. > > * The disadvantage is that while splicing is not completed and if the > > funder of the splicing tx is trying to publish an old commitment tx the > > node will only be punished by sending all the funds of the first funding > tx > > to the partner as the special commitment tx of the 2nd output has no > newer > > state yet. > > Yes, this is the alternative method; produce a parallel funding tx > (which only needs to support a single revocation, or could even be done > by a long timeout) and then join them when it reaches the agreed depth. > > It has some elegance; particularly because one side doesn't have to do > any validation or store anything until it's about to splice in. You get > asked for a key and signature, you produce a new one, and sign whatever > tx they want. They hand you back the tx and the key you used once it's > buried far enough, and you check the tx is indeed buried and the output > is the script you're expecting, then you flip the commitment tx. > > But I chose chose not to do this because every transaction commitment > forever will require 2 signatures, and doesn't allow us to forget old > revocation information. > > And it has some strange side-effects: onchain this looks like two > channels; do we gossip about both? We have to figure the limit on > splice-in to make sure the commitment tx stays under 400kSipa. > This is a lot closer to my original proposal for splicing, and I still like it a lot more since the transition from old to new channel is bascially atomic (not having to update state on both pre-splice and post-splice version). The new funds will remain unavailable for the same time, and since we allow only one concurrent splice in your proposal we don't even lose any additional time regarding the splice-outs. So pulling the splice_add_input and splice_add_output up to signal the intent of adding funds to a splice. Splice_all_added is then used to start moving the funds to a pre-allocated 2-of-2 output where the funds can mature. Once the funds are matured (e.g., 6 confirmations) we can start the transition: both parties claim the funding output, and the pre-allocated funds, to create a new funding tx which is immediately broadcast, and we flip over to the new channel state. No need to keep parallel state and then disambiguating which one it was. The downsides of this is that we now have 2 on-chain transactions (pre-allocation and re-open), and splice-outs are no longer immediate if we have a splice-in in the changeset as well. The latter can be remediatet with one more reanchor that just considers splice-ins that were proposed. > > > I believe splicing out is even safer: > > * One just creates a spent of the funding tx which has two outputs. One > > output goes to the recipient of the splice out operation and the second > > output acts as a new funding transaction for the newly spliced channel. > > Once signatures for the new commitment transaction are exchanged > (basically > > following the protocol to open a channel) the splicing operation can be > > broadcasted. > > > > * The old channel MUST NOT be used anymore but the new channel can be > > operational right away without blockchain confirmation. In case someone > > tries to publish an old state of the old channel it will be a double > spent > > of the splicing operation and in the worst case will be punished and the > > splicing was not successful. > > > > if one publishes an old state of the new > > channel everything will just work as normal even if the funding tx is not > > yet mined. It could only be replaced with an old state of the previous > > channel (which as we saw is not a larger risk than the usual operation > of a > > lightning node) > > Right, you're relying on CPFP pushing through the splice-out tx if it > gets stuck. This requires that we check carefully for standardness and > other constraints which might prevent this; for example, we can't allow > more than 20 (?) of these in a row without being sufficiently buried > since I think that's where CPFP calculations top out. > We shouldn't allow more than one pending splice operation anyway, as stated in your proposal initially. We are already critically reliant on our transaction being confirmed on-chain, so I don't see this as much of an added issue. > > As mentioned maybe you had this workflow already in your mind but I don't > > see why we need to send around all the messages twice with my workflow. > We > > only need to maintain double state but only until it is fair / safe to do > > so. I would also
Re: [Lightning-dev] Splicing Proposal: Feedback please!
Good morning Rusty, In BOLT #2 we currently impose a 2^24 satoshi limit on total channel capacity. Is splicing intended to allow violation of this limit? I do not see it mentioned in the proposal. Can I splice 21 million bitcoins on a 1-satoshi channel? It may be good to start brainstorming possible failure modes during splice, and how to recover, and also to indicate the expected behavior in the proposal, as I believe these will be the points where splicing must be designed most precisely. What happens when a splice is ongoing and the communication gets disconnected? What happens when some channel failure occurs during splicing and we are forced to drop onchain? And so on. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, October 10, 2018 11:45 AM, Rusty Russell wrote: > Hi all! > > We've had increasing numbers of c-lightning users get upset they > can't open multiple channels, so I guess we're most motivated to allow > splicing of existing channels. Hence this rough proposal. > > For simplicity, I've chosen to only allow a single splice at a time. > It's still complex :( > > Feedback welcome! > > -- > > Splice Negotiation: > > 1. type: 40 (`splice_add_input`) (`option_splice`) > 2. data: > - [`32`:`channel_id`] > - [`8`: `satoshis`] > - [`32`: `prevtxid`] > - [`4`: `prevtxoutnum`] > - [`2`: `scriptlen`] > - [`scriptlen`: `scriptpubkey`] > 3. type: 41 (`splice_add_output`) (`option_splice`) > 4. data: > - [`32`:`channel_id`] > - [`8`: `satoshis`] > - [`2`: `scriptlen`] > - [`scriptlen`: `outscript`] > 5. type: 42 (`splice_all_added`) (`option_splice`) > 6. data: > - [`32`:`channel_id`] > - [`4`:`feerate_per_kw`] > - [`4`:`minimum_depth`] > > Each side sends 0 or more `splice_add_input` and 0 or more > `splice_add_output` followed by `spice_all_added` to complete the > splice > proposal. This is done either to initiate a splice, or to respond to a > `splice_*` from the other party. > > `splice_add_input` is checked for the following: > > > - must not be during a current splice > > - scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> EQUAL' > > - `satoshis` doesn't wrap on addition. > > - MAY check that it matches outpoint specified (sig will simply be > invalid if so), and that outpoint is segwit. > > `splice_add_output` is checked for the following: > > - must not be during a current splice > > - `satoshis` is less than or equal to amount owing to proposer, minus > current reserve, and greater than or equal to `dust_limit_satoshis` we > sent in our open_channel/accept_channel ,sg. > > - script is one of the approved forms as it is for `shutdown`. > > FIXME: Do we disallow splice-out if they specified > option_upfront_shutdown_script? > > `splice_all_added` is checked for the following: > > - average of `feerate_per_kw` by both sides (round down) is sufficient. > > - average of `feerate_per_kw` by both sides not grossly excessive, if we're > paying some of the fees (see below!) > > - both sides can afford the fees from their post-splice funds (see > Verification Changes below) > > - maximum of the two `minimum_depth` is not grossly excessive. > > - There is at least one splice_add_input or splice_add_output. > > Splice negotiation, like closing negotiation, does not have persistent > state. Reconnecting forgets previous negotiation. > > Splice Signing > > > Once`splice_all_added` is both sent and received, we need to create and > sign both the splice tx itself, and the first commitment transaction > which spends it (but not in that order!). > > 1. One input spends the current funding tx output. > 2. There is one additional input for each splice_add_input. > 3. One output creates the new funding tx. > 4. There is one additional output for each splice_add_output. > 5. The entire transaction is sorted into BIP69 order. > 6. The feerate is the sum of the two `feerate_per_kw` divided by 2, > rounded down. > > 7. type: 43 (`splice_commitment_signature`) (`option_splice`) > 8. data: > - [`32`:`channel_id`] > - [`64`:`commitment_signature`] > - [`2`:`num_htlcs`] > - [`num_htlcs*64`:`htlc_signature`] > 9. type: 44 (`splice_signature`) (`option_splice`) > 10. data: > - [`32`:`channel_id`] > - [`64`:`splice_signature`] > 11. type: 45 (`splice_witness`) (`option_splice`) > 12. data: > - [`32`:`channel_id`] > - [`2`: `num_witness_elements` > - [`2`:`len`] > -
