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`] > - [`
Re: [Lightning-dev] Splicing Proposal: Feedback please!
René Pickhardt writes: > So let us take the example of Splicing in: > * The situation before splicing is that we have one output in our funding > tx that is being spent with each commitment tx. (actually if the channel > was spliced before we have more inputs but that should not change anything) > * Splice in would create one additional output that can be spent in future > commitment tx. > * I propose while splicing in this output should be spent by a special > commitment tx which goes to the funder of the splicing operation. This > should happen before the actual funding takes place. The other commitment > tx spending the original output continues to operate (assuring non blocking > splice in operation). > * 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. > 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. > 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 believe that with my approach it should be possible (but > not really necessary) to have multiple splicing operations in parallel. The extra sigs are only needed in transition, though; once splicing is over the channel looks exactly like a newly created one, which is nice. > One other question: What happens to the short_channel_id of a channel to > which founds have been spliced in? In the parallel splice world, they look like two channels. In my proposal it looks like a new channel, with a channel_update to make sure modern nodes know that the transition is happening. 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!
Dear Rusty, thanks for the initiative. You suggested in your paragraph "messages changes during splicing" during splicing to duplicate each commitment transaction. One which spends the old funding tx and one which spends the spliced tx. I believe this can be simplified. Though I think my workflow pretty much resembles what you have written in "Splice Signing" from point 1. to 6. Maybe I might have misunderstood some parts of your suggestion. I will not write this down as formal as your proposal as I believe we are currently in the feedback and discussion phase. Maybe you already had "those details" that I am suggesting in mind. In that case sorry for my mail. So let us take the example of Splicing in: * The situation before splicing is that we have one output in our funding tx that is being spent with each commitment tx. (actually if the channel was spliced before we have more inputs but that should not change anything) * Splice in would create one additional output that can be spent in future commitment tx. * I propose while splicing in this output should be spent by a special commitment tx which goes to the funder of the splicing operation. This should happen before the actual funding takes place. The other commitment tx spending the original output continues to operate (assuring non blocking splice in operation). * 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. 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) 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 believe that with my approach it should be possible (but not really necessary) to have multiple splicing operations in parallel. One other question: What happens to the short_channel_id of a channel to which founds have been spliced in? best Rene On Wed, Oct 10, 2018 at 5:46 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`] > > 1. type: 41 (`splice_add_output`) (`option_splice`) > 2. data: >* [`32`:`channel_id`] >* [`8`: `satoshis`] >* [`2`: `scriptlen`] >* [`scriptlen`: `outscript`] > > 1. type: 42 (`splice_all_added`) (`option_splice`) > 2. 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 specifie
Re: [Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity
I agree the r-fields are useful to populate for public channels in many situations, but care must be taken to not _always_ try them first without accounting for potentially high fees on those channels. - Johan On Wed, Oct 10, 2018 at 5:46 AM Rusty Russell wrote: > Pierre writes: > >> But there's no reason to believe that the invoicer has more knowledge > about all but the last hop. > > > > I disagree: there is a good chance that the receiver is a 24/7 running > > merchant/website, with a full up-to-date view of the network, whereas > > the payer is most likely a mobile wallet with less > > accurate/partial/out of date information. > > > > At least this is what we are seeing on the current mainnet. Routing > > table sync is hard on mobile clients, and I think that it makes sense > > that receivers "help" senders, after all incentives are aligned. > > Good qualification; I agree. Certainly if the payer knows its > information is less reliable it should prefer the provided route. > > Cheers, > 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] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts
On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote: > eltoo is a drop-in replacement for the penalty based invalidation > mechanism that is used today in the Lightning specification. [...] Maybe this is obvious, but in case it's not, re: the locktime-based sequencing in eltoo: "any number above 0.500 billion is interpreted as a UNIX timestamp, and with a current timestamp of ~1.5 billion, that leaves about 1 billion numbers that are interpreted as being in the past" I think if you had a more than a 1B updates to your channel (50 updates per second for 4 months?) I think you could reset the locktime by rolling over to use new update keys. When unilaterally closing you'd need to use an extra transaction on-chain to do that roll-over, but you'd save a transaction if you did a cooperative close. ie, rather than: [funding] -> [coop close / re-fund] -> [update 23M] -> [HTLCs etc] or [funding] -> [coop close / re-fund] -> [coop close] you could have: [funding] -> [update 1B] -> [update 23,310,561 with key2] -> [HTLCs] or [funding] -> [coop close] You could repeat this when you get another 1B updates, making unilateral closes more painful, but keeping cooperative closes cheap. Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
