Re: [Lightning-dev] Including a Protocol for splicing to BOLT
Now that you remind me of the wiki: I remember we discussed this before, so maybe I was just repeating myself (sorry). It is true the wiki should be more prominent. CJP Op 27-08-18 om 15:19 schreef Christian Decker: > Corné Plooy via Lightning-dev > writes: >>> Aside from that, spontaneous payments is amongst the most request feature >>> request I get from users and developers. >> A while ago I realized that spontaneous payments (without proof of >> payment, mostly for donations only) can be realized quite easily if the >> payer generates the preimage and hash, and includes the preimage in the >> sphinx message to the payee node. If the payee node recognizes the >> sphinx message format, it can use the preimage to claim the payment. >> >> CJP > You mean like we describe in the Brainstorming wiki [1]? We definitely > need to make the Wiki more prominent :-) > > [1] > https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#passing-a-transfer-secret-in-the-onion ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Including a Protocol for splicing to BOLT
Corné Plooy via Lightning-dev writes: >> Aside from that, spontaneous payments is amongst the most request feature >> request I get from users and developers. > > A while ago I realized that spontaneous payments (without proof of > payment, mostly for donations only) can be realized quite easily if the > payer generates the preimage and hash, and includes the preimage in the > sphinx message to the payee node. If the payee node recognizes the > sphinx message format, it can use the preimage to claim the payment. > > CJP You mean like we describe in the Brainstorming wiki [1]? We definitely need to make the Wiki more prominent :-) [1] https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#passing-a-transfer-secret-in-the-onion ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Including a Protocol for splicing to BOLT
> Aside from that, spontaneous payments is amongst the most request feature > request I get from users and developers. A while ago I realized that spontaneous payments (without proof of payment, mostly for donations only) can be realized quite easily if the payer generates the preimage and hash, and includes the preimage in the sphinx message to the payee node. If the payee node recognizes the sphinx message format, it can use the preimage to claim the payment. CJP ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Including a Protocol for splicing to BOLT
> #1 lets us leave out double-funded channels. #2 and #3 lets us leave out > splice. > For myself, I would rather leave out AMP and double-funding and splicing > than remove ZKCP. It isn't one or the other. ZKCPs are compatible with various flavors of AMP. All of these technologies can be rolled out, some with less coordination than others. Please stop presenting these upgrades as if they're opposing and fundamental constrains only allow a handful of them to be deployed. Dual funded channels allow for immediate bi-directional transfers between endpoints. Splicing allows channels to contract or grow, as well as: pay out to on chain addresses, fund new channel on the fly, close into old channels, consolidate change addresses, create fee inputs for eltoo, orchestrate closing/opening coin-joins, etc, etc. -- Laolu On Wed, Jul 4, 2018 at 10:36 PM ZmnSCPxj wrote: > Good morning all, > > > > What's the nasty compromise? > > > > > > Let's also not underestimate how big of an update switching to dlog > based > > > > > > HTLCs will be. > > > > Was referring to losing proof-of-payment; that's vital in a system > > > > without intermediaries. We have to decide what the lesser evil is. > > Without the inherent ZKCP, it becomes impossible to build a trustless > off-to-on/on-to-offchain bridge, since a trustless swap outside of > Lightning becomes impossible. To my mind, ZKCP is an important building > block in cryptocurrency: it is what we use in Lightning for routing. > Further, ZKCP can be composed together to form a larger ZKCP, which again > is what we use in Lightning for routing. > > The ZKCP here is what lets LN endpoint to interact with the chain and lets > off-to-on/on-to-offchain bridges to be trustless. > > off/onchain bridges are important as they provide: > > 1. Incoming channels: Get some onchain funds from cold storage (or > borrowed), create an outgoing channel (likely to the bridge for best chance > of working), then ask bridge for an invoice to send money to an address you > control onchain. The outgoing channel capacity becomes incoming capacity, > you get (most of) your money back (minus fees) onchain. > 2. Reloading spent channels. Give bridge an invoice and pay to the > bridge to trigger it reloading your channel. > 3. Unloading full channels. If you earn so much money (minus what you > spend on expenses, subcontractors, employees, suppliers, etc.) you can use > the bridge to send directly to your cold storage. > > #1 lets us leave out double-funded channels. #2 and #3 lets us leave out > splice. > > The interaction between bridge and Lightning is simply via BOLT11 > invoices. Those provide the ZKCP necessary to make the bridge trustless. > > AMP enhances such a Lightning+bridge network, since the importance of > maximum channel capacity is reduced if a ZKCP-providing AMP is available. > For myself, I would rather leave out AMP and double-funding and splicing > than remove ZKCP. > > One could imagine a semi-trusted ZKCP service for real-world items. Some > semi-trusted institution provides special safeboxes for rent that can be > unlocked either by seller private key after 1008 blocks, or by the > recipient key and a proof-of-payment preimage (and records the preimage in > some publicly-accessible website). To sell a real-world item, make a > BOLT11 invoice, bring item to a safebox, lock it with appropriate keys and > the invoice payment hash, give BOLT11 invoice to buyer. Buyer pays and > gets proof-of-payment preimage, goes to safebox and gets item. Multi-way > trades (A wants item from B, B wants item from C, C wants item from A) are > just compositions of ZKCP. > > > > > And yeah, I called it Schnorr-Eltoonicorn not only because it's so > > > > pretty, but because actually capturing it will be a saga. > > Bards shall sing about The Hunt for Schnorr-Eltoonicorn for ages, until > Satoshi himself is but a vague memory of a myth long forgotten. > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Including a Protocol for splicing to BOLT
> Was referring to losing proof-of-payment; that's vital in a system without > intermediaries. We have to decide what the lesser evil is. As is now, we don't have a proper proof of payment. We have a "proof that someone paid". A proper proof of payment would be: "proof that bob paid carol". Aside from that, spontaneous payments is amongst the most request feature request I get from users and developers. There're a few ways to achieve this with dlog based AMPs. As far hash based AMPs, with a bit more interaction, and something like zkboo, one can achieve stronger binding. However, we'd lose the nice "one shot" property that dlog based AMPs allow. > And yeah, I called it Schnorr-Eltoonicorn not only because it's so > pretty, but because actually capturing it will be a saga. eltoo won't be the end-all-be-all as it comes along with several tradeoffs, like everything else does. Also, everything we can do with Schnorr, we can also do with ECDSA, but today. -- Laolu On Wed, Jul 4, 2018 at 7:12 PM Rusty Russell wrote: > Olaoluwa Osuntokun writes: > > What's the nasty compromise? > > > > Let's also not underestimate how big of an update switching to dlog based > > HTLCs will be. > > Was referring to losing proof-of-payment; that's vital in a system > without intermediaries. We have to decide what the lesser evil is. > > And yeah, I called it Schnorr-Eltoonicorn not only because it's so > pretty, but because actually capturing it will be a saga. > > Cheers, > Rusty. > > > On Wed, Jul 4, 2018, 4:21 PM Rusty Russell > wrote: > > > >> Christian Decker writes: > >> > >> > ZmnSCPxj via Lightning-dev > >> writes: > >> >> For myself, I think splice is less priority than AMP. But I prefer an > >> >> AMP which retains proper ZKCP (i.e. receipt of preimage at payer > >> >> implies receipt of payment at payee, to facilitate trustless > >> >> on-to-offchain and off-to-onchain bridges). > >> > > >> > Agreed, multipath routing is a priority, but I think splicing is just > as > >> > much a key piece to a better UX, since it allows to ignore differences > >> > between on-chain and off-chain funds, showing just a single balance > for > >> > all use-cases. > >> > >> Agreed, we need both. Multi-channel was a hack because splicing doesn't > >> exist, and I'd rather not ever have to implement multi-channel :) > >> > >> AMP is important, but it's a nasty compromise with the current > >> limitations. I want to have my cake and eat it too, and I'm pretty sure > >> it's possible once the Scnorr-Eltoonicorn arrives. > >> > >> 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] Including a Protocol for splicing to BOLT
Good morning all, > > What's the nasty compromise? > > > > Let's also not underestimate how big of an update switching to dlog based > > > > HTLCs will be. > > Was referring to losing proof-of-payment; that's vital in a system > > without intermediaries. We have to decide what the lesser evil is. Without the inherent ZKCP, it becomes impossible to build a trustless off-to-on/on-to-offchain bridge, since a trustless swap outside of Lightning becomes impossible. To my mind, ZKCP is an important building block in cryptocurrency: it is what we use in Lightning for routing. Further, ZKCP can be composed together to form a larger ZKCP, which again is what we use in Lightning for routing. The ZKCP here is what lets LN endpoint to interact with the chain and lets off-to-on/on-to-offchain bridges to be trustless. off/onchain bridges are important as they provide: 1. Incoming channels: Get some onchain funds from cold storage (or borrowed), create an outgoing channel (likely to the bridge for best chance of working), then ask bridge for an invoice to send money to an address you control onchain. The outgoing channel capacity becomes incoming capacity, you get (most of) your money back (minus fees) onchain. 2. Reloading spent channels. Give bridge an invoice and pay to the bridge to trigger it reloading your channel. 3. Unloading full channels. If you earn so much money (minus what you spend on expenses, subcontractors, employees, suppliers, etc.) you can use the bridge to send directly to your cold storage. #1 lets us leave out double-funded channels. #2 and #3 lets us leave out splice. The interaction between bridge and Lightning is simply via BOLT11 invoices. Those provide the ZKCP necessary to make the bridge trustless. AMP enhances such a Lightning+bridge network, since the importance of maximum channel capacity is reduced if a ZKCP-providing AMP is available. For myself, I would rather leave out AMP and double-funding and splicing than remove ZKCP. One could imagine a semi-trusted ZKCP service for real-world items. Some semi-trusted institution provides special safeboxes for rent that can be unlocked either by seller private key after 1008 blocks, or by the recipient key and a proof-of-payment preimage (and records the preimage in some publicly-accessible website). To sell a real-world item, make a BOLT11 invoice, bring item to a safebox, lock it with appropriate keys and the invoice payment hash, give BOLT11 invoice to buyer. Buyer pays and gets proof-of-payment preimage, goes to safebox and gets item. Multi-way trades (A wants item from B, B wants item from C, C wants item from A) are just compositions of ZKCP. > > And yeah, I called it Schnorr-Eltoonicorn not only because it's so > > pretty, but because actually capturing it will be a saga. Bards shall sing about The Hunt for Schnorr-Eltoonicorn for ages, until Satoshi himself is but a vague memory of a myth long forgotten. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Including a Protocol for splicing to BOLT
Olaoluwa Osuntokun writes: > What's the nasty compromise? > > Let's also not underestimate how big of an update switching to dlog based > HTLCs will be. Was referring to losing proof-of-payment; that's vital in a system without intermediaries. We have to decide what the lesser evil is. And yeah, I called it Schnorr-Eltoonicorn not only because it's so pretty, but because actually capturing it will be a saga. Cheers, Rusty. > On Wed, Jul 4, 2018, 4:21 PM Rusty Russell wrote: > >> Christian Decker writes: >> >> > ZmnSCPxj via Lightning-dev >> writes: >> >> For myself, I think splice is less priority than AMP. But I prefer an >> >> AMP which retains proper ZKCP (i.e. receipt of preimage at payer >> >> implies receipt of payment at payee, to facilitate trustless >> >> on-to-offchain and off-to-onchain bridges). >> > >> > Agreed, multipath routing is a priority, but I think splicing is just as >> > much a key piece to a better UX, since it allows to ignore differences >> > between on-chain and off-chain funds, showing just a single balance for >> > all use-cases. >> >> Agreed, we need both. Multi-channel was a hack because splicing doesn't >> exist, and I'd rather not ever have to implement multi-channel :) >> >> AMP is important, but it's a nasty compromise with the current >> limitations. I want to have my cake and eat it too, and I'm pretty sure >> it's possible once the Scnorr-Eltoonicorn arrives. >> >> 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] Including a Protocol for splicing to BOLT
What's the nasty compromise? Let's also not underestimate how big of an update switching to dlog based HTLCs will be. On Wed, Jul 4, 2018, 4:21 PM Rusty Russell wrote: > Christian Decker writes: > > > ZmnSCPxj via Lightning-dev > writes: > >> For myself, I think splice is less priority than AMP. But I prefer an > >> AMP which retains proper ZKCP (i.e. receipt of preimage at payer > >> implies receipt of payment at payee, to facilitate trustless > >> on-to-offchain and off-to-onchain bridges). > > > > Agreed, multipath routing is a priority, but I think splicing is just as > > much a key piece to a better UX, since it allows to ignore differences > > between on-chain and off-chain funds, showing just a single balance for > > all use-cases. > > Agreed, we need both. Multi-channel was a hack because splicing doesn't > exist, and I'd rather not ever have to implement multi-channel :) > > AMP is important, but it's a nasty compromise with the current > limitations. I want to have my cake and eat it too, and I'm pretty sure > it's possible once the Scnorr-Eltoonicorn arrives. > > 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] Including a Protocol for splicing to BOLT
Christian Decker writes: > ZmnSCPxj via Lightning-dev writes: >> For myself, I think splice is less priority than AMP. But I prefer an >> AMP which retains proper ZKCP (i.e. receipt of preimage at payer >> implies receipt of payment at payee, to facilitate trustless >> on-to-offchain and off-to-onchain bridges). > > Agreed, multipath routing is a priority, but I think splicing is just as > much a key piece to a better UX, since it allows to ignore differences > between on-chain and off-chain funds, showing just a single balance for > all use-cases. Agreed, we need both. Multi-channel was a hack because splicing doesn't exist, and I'd rather not ever have to implement multi-channel :) AMP is important, but it's a nasty compromise with the current limitations. I want to have my cake and eat it too, and I'm pretty sure it's possible once the Scnorr-Eltoonicorn arrives. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Including a Protocol for splicing to BOLT
ZmnSCPxj via Lightning-dev writes: > For myself, I think, for old nodes, it should just appear as a > "normal" close followed by a "normal" open. That's exactly what they should look like, since the channel is being closed with the existing protocol and opened (possibly with a slightly different value). > So, instead, maybe a new `channel_announce_reopen` which informs > everyone that an old scid will eventually become a new scid, and that > the nodes involved will still consider routes via the old scid to be > valid regardless. I thought of it more as a new alias for the old channel, so that the update in the network view is just switching names after the announce depth is reached. > Then an ordinary `channel_announce` once the announce depth of the new > scid is reached. > > From point of view of old nodes, the channel is closed for some > blocks, but a new channel between the two nodes is then announced. > > From point of view of new nodes, the channel is referred to using the > previous scid, until an ordinary `channel_announce` is received, and > then the channel is referred to using the new scid. The message announcing the reopen or the alias should probably preceed the actual close, otherwise nodes may prune the channel from their view upon seeing the close. The message then simply has the effect of saying "ignore the close, let it linger for 6 more blocks before really removing from your network view". > For myself, I think splice is less priority than AMP. But I prefer an > AMP which retains proper ZKCP (i.e. receipt of preimage at payer > implies receipt of payment at payee, to facilitate trustless > on-to-offchain and off-to-onchain bridges). Agreed, multipath routing is a priority, but I think splicing is just as much a key piece to a better UX, since it allows to ignore differences between on-chain and off-chain funds, showing just a single balance for all use-cases. > With AMP, size of channels is less important, and many small channels > will work almost as well as a few large channels. Well, capacities are still very much important, and if there is a smaller min-cut separating source and destination than the total amount of the payment, then the payment will still fail. We now simply no longer require a single channel with sufficient capacity to exist. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Including a Protocol for splicing to BOLT
I'm delighted someone is fleshing this out! Splice-out is easy, splice-in is harder. Note that there are two ways: 1. Broadcast a spend which joins with one or more random outputs and then maintain both the old and new channels (ie. both sets of signatures) until it confirms deeply enough. This is the original plan, as detailed in [0]. 2. Pre-commit. You either set up what is basically another funding tx, then join the channels together once it's deep enough. The second is simpler, but requires two onchain txs, thus I prefer the original model despite the complexity. I think for 1.1 it's OK to limit this to one concurrent change at a time (ie. for the 6 blocks or whatever, you can't organize *another* splice in/out). The gossip extension is difficult: 1. If we extend channel_announce that won't propagate through old nodes until the new channel is 6 deep, and it's wasted space (sigs + old-chanid) once the splice is old news. 2. If we extend channel_update it won't propagate once the new spend is seen on the bitcoin network. 3. A new message type won't propagate at all through old nodes: maybe it could be made so that the "splice information" sigs + old-chanid is discardable though. Hmm... Rusty. ZmnSCPxj via Lightning-dev writes: > Good morning Laolu, > >>> but even though it seems technically straight forward t >> >> Well the full async implementation may be a bit involved, depending on the >> architecture of the implementation (see the second point below). >> >> In the abstract, I'd say a splicing proposal should include the following: >> >> * a generic message for both splice in/out >> * this allows both sides to schedule/queue up possible changes, >> opportunistically piggy-backing then on top of the other sides >> initiation >> * most of the channel params can also be re-negotiated as this point, >> another upside is this effectively allows garbage collecting old >> revocation state >> * fully async splice in/out >> * async is ideal as we don't need to block channel operation for >>confirmations, this greatly improves the UX of the process >> * async splice in should use a technique similar to what Conner has >>suggested in the past [0], otherwise it would need to block :( > > It increases complexity. I suppose it would be OK to limit splice-in so that > if a splice-in has not been buried deeply in the chain yet, you cannot > splice-in even more, to limit the number of parallel updates you need to keep > track of to only 2. > >> * a sort of pre-announcement gossip messages >> * purpose of this is to signal to other nodes "hey this channel is >>about to change outpoints, but you can keep routing through it" >> * otherwise, if this doesn't exist, then nodes would interpret the >>action as a close then open of a channel, rather than a re-allocation > > At first it seems benign to me -- after all, the channel is simply "reopened" > and what does it matter whether other nodes know if the new channel is the > same as the old channel? -- but then there will be a time of a few blocks > where other nodes consider the channel closed but the replacement channel is > not yet deep enough onchain to be reannounced. So I suppose it enables > routing across the channel during those few blocks. > > 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] Including a Protocol for splicing to BOLT
Good morning Laolu, >> but even though it seems technically straight forward t > > Well the full async implementation may be a bit involved, depending on the > architecture of the implementation (see the second point below). > > In the abstract, I'd say a splicing proposal should include the following: > > * a generic message for both splice in/out > * this allows both sides to schedule/queue up possible changes, > opportunistically piggy-backing then on top of the other sides > initiation > * most of the channel params can also be re-negotiated as this point, > another upside is this effectively allows garbage collecting old > revocation state > * fully async splice in/out > * async is ideal as we don't need to block channel operation for >confirmations, this greatly improves the UX of the process > * async splice in should use a technique similar to what Conner has >suggested in the past [0], otherwise it would need to block :( It increases complexity. I suppose it would be OK to limit splice-in so that if a splice-in has not been buried deeply in the chain yet, you cannot splice-in even more, to limit the number of parallel updates you need to keep track of to only 2. > * a sort of pre-announcement gossip messages > * purpose of this is to signal to other nodes "hey this channel is >about to change outpoints, but you can keep routing through it" > * otherwise, if this doesn't exist, then nodes would interpret the >action as a close then open of a channel, rather than a re-allocation At first it seems benign to me -- after all, the channel is simply "reopened" and what does it matter whether other nodes know if the new channel is the same as the old channel? -- but then there will be a time of a few blocks where other nodes consider the channel closed but the replacement channel is not yet deep enough onchain to be reannounced. So I suppose it enables routing across the channel during those few blocks. Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
