From jim.posen at gmail.com Thu Mar 1 14:45:16 2018 From: jim.posen at gmail.com (Jim Posen) Date: Thu, 1 Mar 2018 09:45:16 -0500 Subject: [Lightning-dev] Pinging a route for capacity Message-ID: My understanding is that the best strategy for choosing a route to send funds over is to determine all possible routes, rank them by estimated fees based on channel announcements and number of hops, then try them successively until one works. It seems inefficient to me to actually do a full HTLC commitment handshake on each hop just to find out that the last hop in the route didn't have sufficient remaining capacity in the first place. Depending on how many people are using the network, I could also forsee situations where this creates more payment failures because bandwidth is locked up in HTLCs that are about to fail anyway. One idea that would likely help is the ability to send a ping over an onion route asking "does every hop have capacity to send X msat?" Every hop would forward the onion request if the answer is yes, or immediately send the response back up the circuit if the answer is no. This should reveal no additional information about the channel capacities that the sender couldn't determine by sending a test payment to themself (assuming they could find a loop). Additionally, the hops could respond with the latest fee rate in case channel updates are slow to propagate. The main benefit is that this should make it quicker to send a successful payment because latency is lower than sending an actual payment and the sender could ping all possible routes in parallel, whereas they can't send multiple payments in parallel. The main downside I can think of is that, by the same token, it is faster and cheaper for someone to extract information about channel capacities on the network with a binary search. -jimpo -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.pickhardt at googlemail.com Thu Mar 1 15:26:22 2018 From: r.pickhardt at googlemail.com (=?UTF-8?Q?Ren=C3=A9_Pickhardt?=) Date: Thu, 1 Mar 2018 16:26:22 +0100 Subject: [Lightning-dev] Pinging a route for capacity In-Reply-To: References: Message-ID: Hey everyone, disclaimer I am new here and have not a full understanding of the complete specs yet - however since I decided to participate in lighting dev I will just be brave and try to add my ideas on the problem jimpo posed. So even in case by ideas are complete bs please just tell me in a friendly way and I know I need to read more code and specs in order to participate. Reading about the described problem techniques like IP-Fragmentation ( https://en.wikipedia.org/wiki/IP_fragmentation ) come to my mind. The setting is a little bit different but in from my current understanding it should still be applicable and also be the favorable solution in comparison to the proposed ping: 1.) IP setting: In IP-Fragmentation one would obviously just split the IP-package in order to utilize a link layer protocol that doesn't have enough bandwidth for a bigger size package. 2.) Lightning case: When the capacity of a channel during routing is not high enough - which means that the channel balance on that side is somewhere between 0 and the size of the payment - one would have to to send the second part of the fragmented package on a different route. This is obvious since the insufficient channel balance cannot come out of thin air (as in IP-Routing). My first intuition was that this would become a problem for onion routing since the router in question does not know the final destination but only knows the next hop which can't be utilized as the channel doesn't have enough funds. However I imagine one could just encapsulate the second part of the fragmented payment in a new onion routed package that goes on a detour (using different payment channels) to the original "next" hop und progresses from there as it was originally thought of. Not sure however how the impacts to the HTLC would be and if it would actually be possible to fragment a payment that is encapsulated within the onion routing. If possible the advantage in comparison to your proposed ping method is that fragmentation would be highly dynamic and still work if a channel runs out of funds while routing payment. In your ping scenario it could very well happen that you do a ping for a designated rout, everything looks great, you send a payment but while it is on its way a channel on that way could run dry. best Rene On Thu, Mar 1, 2018 at 3:45 PM, Jim Posen wrote: > My understanding is that the best strategy for choosing a route to send > funds over is to determine all possible routes, rank them by estimated fees > based on channel announcements and number of hops, then try them > successively until one works. > > It seems inefficient to me to actually do a full HTLC commitment handshake > on each hop just to find out that the last hop in the route didn't have > sufficient remaining capacity in the first place. Depending on how many > people are using the network, I could also forsee situations where this > creates more payment failures because bandwidth is locked up in HTLCs that > are about to fail anyway. > > One idea that would likely help is the ability to send a ping over an > onion route asking "does every hop have capacity to send X msat?" Every hop > would forward the onion request if the answer is yes, or immediately send > the response back up the circuit if the answer is no. This should reveal no > additional information about the channel capacities that the sender > couldn't determine by sending a test payment to themself (assuming they > could find a loop). Additionally, the hops could respond with the latest > fee rate in case channel updates are slow to propagate. > > The main benefit is that this should make it quicker to send a successful > payment because latency is lower than sending an actual payment and the > sender could ping all possible routes in parallel, whereas they can't send > multiple payments in parallel. The main downside I can think of is that, > by the same token, it is faster and cheaper for someone to extract > information about channel capacities on the network with a binary search. > > -jimpo > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > -- Skype: rene.pickhardt -------------- next part -------------- An HTML attachment was scrubbed... URL: From kiwigb at yahoo.com Thu Mar 1 21:16:02 2018 From: kiwigb at yahoo.com (gb) Date: Fri, 02 Mar 2018 10:16:02 +1300 Subject: [Lightning-dev] Pinging a route for capacity In-Reply-To: References: Message-ID: <1519938962.2842.0.camel@yahoo.com> .... and any thoughts on protections against flood pinging? On Thu, 2018-03-01 at 09:45 -0500, Jim Posen wrote: > The main benefit is that this should make it quicker to send a > successful payment because latency is lower than sending an actual > payment and the sender could ping all possible routes in parallel, > whereas they can't send multiple payments in parallel. The main > downside I can think of is that, by the same token, it is faster and > cheaper for someone to extract information about channel capacities on > the network with a binary search. > > > -jimpo > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev From info at AndySchroder.com Fri Mar 2 06:25:51 2018 From: info at AndySchroder.com (Andy Schroder) Date: Fri, 02 Mar 2018 01:25:51 -0500 Subject: [Lightning-dev] refunds -- was Re: BOLT 11, real time micro payments, and route redundancy In-Reply-To: <87shfooc3l.fsf@rustcorp.com.au> References: <59A6316A.2050809@AndySchroder.com> <874lsl93c2.fsf@rustcorp.com.au> <59AB9A0F.9040702@AndySchroder.com> <87o9qr7152.fsf@rustcorp.com.au> <59B62689.3020807@AndySchroder.com> <87shfooc3l.fsf@rustcorp.com.au> Message-ID: <5A98EE6F.3020509@AndySchroder.com> On 09/14/2017 11:49 PM, Rusty Russell wrote: >>>> I guess I'm confused how this is going to work safely. If you >>>> put a refund request in with your payment, isn't that revealing the >>>> public key of your node and then defeating the whole purpose of the >>>> onion routing of the payment in the first place (I'm, assuming the payee >>>> node re-uses the same public key?)? It seems like rather than putting a >>>> >>> flag in BOLT 11 to instruct a payer to include a refund payment request, >>>> >>> shouldn't the payer just know to do that if they think they will need >>>> >>> to? Or maybe they won't always? >>> >> Nobody along the route (B and C in our example above) can see it. And D >>> >> kind of has to, since it needs to send the refund. >> > >> > It seems to me like this is sort of a limitation in privacy with >> > lightening. With blockchain payments on my fuel pump, I could return a >> > refund back to the customer without always knowing who they are. With >> > lightning, it looks like the payer will reveal their identity to the >> > payee by offering a refund payment request. It's great that those along >> > the payment route don't know, but it's still bad to have the payer >> > revealed to the payee. Why does someone have to reveal their identity >> > just to get a refund? > Indeed, it's deeply suboptimal for privacy. > > There's a more complex scheme which is possible, using round-trip > payments (I think this was originally from Christian Decker?); I make a > payment via you and back to myself, it's just that I pay your node an > abnormally high "fee". But unfortunately for security reasons each > encrypted hop contains the amount it expects to be sent, which doesn't > work if I don't know how much you're going to refund. > > Technically, you can put a really small amount in there (each node only > insists that the amount sent is >= this amount), but this just allows > one of those return nodes to untracably steal the extra refund amount. > > So, we really need to be able to include a (smaller) return onion to > fix this properly. I've added that to: > > https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#refunds > > Thanks! > Rusty. If you are including a smaller return onion, you are including that with the payment? That return onion would be created by the payer since they know the routes from the payer to the payee? If so, how could this work if the route no longer has capacity (or goes down) by the time the payee decides it's going to send the refund back to the payer (which could be minutes, hours, or days later)? Also, even if all routes are still up, the payer may not necessarily know how much refund the payee will be giving them, so they may not necessarily be able to even know what the best route they should build an onion for? Andy Schroder From ZmnSCPxj at protonmail.com Fri Mar 2 07:53:46 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Fri, 02 Mar 2018 02:53:46 -0500 Subject: [Lightning-dev] Pinging a route for capacity In-Reply-To: References: Message-ID: Good morning Rene, Please consider the recent discussion about AMP, atomic multi-path. https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html Note that only the source (payer) can split the payment into multiple smaller payments; we cannot safely let intermediaries split the payment as the intermediaries may very well decide to send it to a ridiculously high-fee channel. So the payer will make multiple payments that can only be merged at the destination, each sub-payment has a single route and itself cannot be split unless the payer decides to split. > Not sure however how the impacts to the HTLC would be and if it would actually be possible to fragment a payment that is encapsulated within the onion routing. The timeouts in particular would be impossible to handle. At any point the payment should reach the payee within some N blocks and each hop reduces that margin by a small amount (14 blocks for c-lightning if I remember correctly). It is likely that there will not be enough time if it goes through a detour, unless the detour has equal or smaller reduction (delay) than the original hop with insufficient monetary capacity. Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ??????? Original Message ??????? On March 1, 2018 11:26 PM, Ren? Pickhardt via Lightning-dev wrote: > Hey everyone, > > disclaimer I am new here and have not a full understanding of the complete specs yet - however since I decided to participate in lighting dev I will just be brave and try to add my ideas on the problem jimpo posed. So even in case by ideas are complete bs please just tell me in a friendly way and I know I need to read more code and specs in order to participate. > > Reading about the described problem techniques like IP-Fragmentation ( https://en.wikipedia.org/wiki/IP_fragmentation ) come to my mind. The setting is a little bit different but in from my current understanding it should still be applicable and also be the favorable solution in comparison to the proposed ping: > > 1.) IP setting: In IP-Fragmentation one would obviously just split the IP-package in order to utilize a link layer protocol that doesn't have enough bandwidth for a bigger size package. > 2.) Lightning case: When the capacity of a channel during routing is not high enough - which means that the channel balance on that side is somewhere between 0 and the size of the payment - one would have to to send the second part of the fragmented package on a different route. This is obvious since the insufficient channel balance cannot come out of thin air (as in IP-Routing). > > My first intuition was that this would become a problem for onion routing since the router in question does not know the final destination but only knows the next hop which can't be utilized as the channel doesn't have enough funds. However I imagine one could just encapsulate the second part of the fragmented payment in a new onion routed package that goes on a detour (using different payment channels) to the original "next" hop und progresses from there as it was originally thought of. > > Not sure however how the impacts to the HTLC would be and if it would actually be possible to fragment a payment that is encapsulated within the onion routing. > > If possible the advantage in comparison to your proposed ping method is that fragmentation would be highly dynamic and still work if a channel runs out of funds while routing payment. In your ping scenario it could very well happen that you do a ping for a designated rout, everything looks great, you send a payment but while it is on its way a channel on that way could run dry. > > best Rene > > On Thu, Mar 1, 2018 at 3:45 PM, Jim Posen wrote: > >> My understanding is that the best strategy for choosing a route to send funds over is to determine all possible routes, rank them by estimated fees based on channel announcements and number of hops, then try them successively until one works. >> >> It seems inefficient to me to actually do a full HTLC commitment handshake on each hop just to find out that the last hop in the route didn't have sufficient remaining capacity in the first place. Depending on how many people are using the network, I could also forsee situations where this creates more payment failures because bandwidth is locked up in HTLCs that are about to fail anyway. >> >> One idea that would likely help is the ability to send a ping over an onion route asking "does every hop have capacity to send X msat?" Every hop would forward the onion request if the answer is yes, or immediately send the response back up the circuit if the answer is no. This should reveal no additional information about the channel capacities that the sender couldn't determine by sending a test payment to themself (assuming they could find a loop). Additionally, the hops could respond with the latest fee rate in case channel updates are slow to propagate. >> >> The main benefit is that this should make it quicker to send a successful payment because latency is lower than sending an actual payment and the sender could ping all possible routes in parallel, whereas they can't send multiple payments in parallel. The main downside I can think of is that, by the same token, it is faster and cheaper for someone to extract information about channel capacities on the network with a binary search. >> >> -jimpo >> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > -- > Skype: rene.pickhardt -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.posen at gmail.com Fri Mar 2 14:42:09 2018 From: jim.posen at gmail.com (Jim Posen) Date: Fri, 2 Mar 2018 09:42:09 -0500 Subject: [Lightning-dev] Pinging a route for capacity In-Reply-To: <1519938962.2842.0.camel@yahoo.com> References: <1519938962.2842.0.camel@yahoo.com> Message-ID: Regarding ping flooding, if it is problematic, the best solution is probably including a small proof-of-work with the ping, similar to BIP 154. However, the whole purpose of the ping in the first place is to be a cheaper way to collect routing information than attempting to send a payment, so I think adding a PoW starts to become counterproductive. Note that the sender needs to expend a certain amount of computation just creating the onion packet up front (on the order of a few ms, I believe), so perhaps that is sufficient. Also, if someone wanted to DoS the network, there are much better ways than using this proposed ping mechanism. For example, someone can send payments along any circuit with a randomly generated payment hash (for which the preimage is unknown), and force a payment failure at the end of the route. That is basically a way to ping that works now, but is more expensive for everyone. On Thu, Mar 1, 2018 at 4:16 PM, gb wrote: > .... and any thoughts on protections against flood pinging? > > On Thu, 2018-03-01 at 09:45 -0500, Jim Posen wrote: > > > > The main benefit is that this should make it quicker to send a > > successful payment because latency is lower than sending an actual > > payment and the sender could ping all possible routes in parallel, > > whereas they can't send multiple payments in parallel. The main > > downside I can think of is that, by the same token, it is faster and > > cheaper for someone to extract information about channel capacities on > > the network with a binary search. > > > > > > -jimpo > > _______________________________________________ > > Lightning-dev mailing list > > Lightning-dev at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurimoto at nayuta.co Sat Mar 3 12:52:03 2018 From: kurimoto at nayuta.co (=?UTF-8?B?5qCX5YWD5oay5LiA?=) Date: Sat, 3 Mar 2018 21:52:03 +0900 Subject: [Lightning-dev] Another Implementation Message-ID: I'm Kenichi Kurimoto from Japan. We are the team who have been seeking an application and architecture that combine cryptocurrency and IoT. (We are corporate team. Nayuta Inc.) We are implementing another Node software according to Lightning Network Specification(BOLT). https://github.com/nayutaco/ptarmigan The software is developping phase, but basic feature of BOLT works on small closed Testnet network with LND, c-lightning, and ?clair. We wrote how to use it on closed network. https://github.com/nayutaco/ ptarmigan/tree/development/docs When this node have valid path to starblocks, payment for starblocks can be done. We have not tested ip address broadcast mode. We have respect for the efforts of the people who made RFC document, and we would like to contribute further protocol development. -Kenichi Kurimoto -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.pickhardt at googlemail.com Sat Mar 3 23:30:23 2018 From: r.pickhardt at googlemail.com (=?UTF-8?Q?Ren=C3=A9_Pickhardt?=) Date: Sun, 4 Mar 2018 00:30:23 +0100 Subject: [Lightning-dev] Christian Deckers Duplex Micropayment Channels vs Lightning networks revocation key solution Message-ID: Hey everyone, as mentioned before I am quite new to lightning dev. Should the questions I'll ask be too basic please drop me a kind note and I will be more quite or ask my questions on other places. Today I studied Chrstian Deckers nice work about duplex micropayment channels ( http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf ) I am wondering what was the rational for the lightning spec ( https://github.com/lightningnetwork/lightning-rfc ) to go with the revocation key system instead of the solution by Christian Decker to the problem? I understand that the revocation system was already in the whitepaper and at the time of writing the whitepaper the work by Christian Decker wasn't out yet. But I guess this will not be the entire reason. To me the key revocation system seems pretty complex to handle. In particular as Rusty also mentioned on his article (c.f. https://medium.com/@rusty_lightning/lightning-watching-for-cheaters-93d365d0d02f ) that already in the white paper people knew that potentially a third party observing service to detect a cheater is needed. This seems to me like a big drawback. So what have been strong arguments to go with the revocation system? On a side note I would like to state my respect to you: The lightning network (in combination with bitcoin) is really the most beautiful piece of technology I came across since I learnt about TCP/IP. Great work everybody for creating such an amazing technology and bringing together all those beautiful ideas. I am very confident that this technology will become history. best Rene -- www.rene-pickhardt.de Skype: rene.pickhardt -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.pickhardt at googlemail.com Thu Mar 1 15:13:43 2018 From: r.pickhardt at googlemail.com (=?UTF-8?Q?Ren=C3=A9_Pickhardt?=) Date: Thu, 1 Mar 2018 16:13:43 +0100 Subject: [Lightning-dev] Pinging a route for capacity In-Reply-To: References: Message-ID: Hey everyone, disclaimer I am new here and have not a full understanding of the complete specs yet - however since I decided to participate in lighting dev I will just be brave and try to add my ideas on the problem jimpo posed. So even in case by ideas are complete bs please just tell me in a friendly way and I know I need to read more code and specs in order to participate. Reading about the described problem techniques like IP-Fragmentation ( https://en.wikipedia.org/wiki/IP_fragmentation ) come to my mind. The setting is a little bit different but in from my current understanding it should still be applicable and also be the favorable solution in comparison to the proposed ping: 1.) IP setting: In IP-Fragmentation one would obviously just split the IP-package in order to utilize a link layer protocol that doesn't have enough bandwidth for a bigger size package. 2.) Lightning case: When the capacity of a channel during routing is not high enough - which means that the channel balance on that side is somewhere between 0 and the size of the payment - one would have to to send the second part of the fragmented package on a different route. This is obvious since the insufficient channel balance cannot come out of thin air (as in IP-Routing). My first intuition was that this would become a problem for onion routing since the router in question does not know the final destination but only knows the next hop which can't be utilized as the channel doesn't have enough funds. However I imagine one could just encapsulate the second part of the fragmented payment in a new onion routed package that goes on a detour (using different payment channels) to the original "next" hop und progresses from there as it was originally thought of. Not sure however how the impacts to the HTLC would be and if it would actually be possible to fragment a payment that is encapsulated within the onion routing. If possible the advantage in comparison to your proposed ping method is that fragmentation would be highly dynamic and still work if a channel runs out of funds while routing payment. In your ping scenario it could very well happen that you do a ping for a designated rout, everything looks great, you send a payment but while it is on its way a channel on that way could run dry. best Rene On Thu, Mar 1, 2018 at 3:45 PM, Jim Posen wrote: > My understanding is that the best strategy for choosing a route to send > funds over is to determine all possible routes, rank them by estimated fees > based on channel announcements and number of hops, then try them > successively until one works. > > It seems inefficient to me to actually do a full HTLC commitment handshake > on each hop just to find out that the last hop in the route didn't have > sufficient remaining capacity in the first place. Depending on how many > people are using the network, I could also forsee situations where this > creates more payment failures because bandwidth is locked up in HTLCs that > are about to fail anyway. > > One idea that would likely help is the ability to send a ping over an > onion route asking "does every hop have capacity to send X msat?" Every hop > would forward the onion request if the answer is yes, or immediately send > the response back up the circuit if the answer is no. This should reveal no > additional information about the channel capacities that the sender > couldn't determine by sending a test payment to themself (assuming they > could find a loop). Additionally, the hops could respond with the latest > fee rate in case channel updates are slow to propagate. > > The main benefit is that this should make it quicker to send a successful > payment because latency is lower than sending an actual payment and the > sender could ping all possible routes in parallel, whereas they can't send > multiple payments in parallel. The main downside I can think of is that, > by the same token, it is faster and cheaper for someone to extract > information about channel capacities on the network with a binary search. > > -jimpo > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > -- www.rene-pickhardt.de Skype: rene.pickhardt mobile: +49 (0)176 5762 3618 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty at rustcorp.com.au Sun Mar 4 02:46:46 2018 From: rusty at rustcorp.com.au (Rusty Russell) Date: Sun, 04 Mar 2018 13:16:46 +1030 Subject: [Lightning-dev] Pinging a route for capacity In-Reply-To: References: Message-ID: <87tvtw8smh.fsf@rustcorp.com.au> Jim Posen writes: > My understanding is that the best strategy for choosing a route to send > funds over is to determine all possible routes, rank them by estimated fees > based on channel announcements and number of hops, then try them > successively until one works. > > It seems inefficient to me to actually do a full HTLC commitment handshake > on each hop just to find out that the last hop in the route didn't have > sufficient remaining capacity in the first place. Depending on how many > people are using the network, I could also forsee situations where this > creates more payment failures because bandwidth is locked up in HTLCs that > are about to fail anyway. If failure is common this would be true, but I think it's too early to design for it. This kind of signalling is what fees are for: when capacity gets low you increase fees, and when it gets high, you reduce them. But that may still prove insufficient. Two things come to mind: 1. `temporary_channel_failure` returns a `channel_update`. The implication is that this has the disabled flag, but we should probably make that true iff the request asks for < 2% of the channel capacity or some "minimal bar". If you can't even service this, you should disable the channel. 2. We can implement fast failure to reduce latency: https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming Note that there needs to be more analysis on reliable ways to mask the active capacity of a channel: using a static random threshold still leaks information that *something* has happened, so it may need to be more sophisticated. Cheers, Rusty. From decker.christian at gmail.com Sun Mar 4 22:18:56 2018 From: decker.christian at gmail.com (Christian Decker) Date: Sun, 04 Mar 2018 23:18:56 +0100 Subject: [Lightning-dev] Pinging a route for capacity In-Reply-To: <87tvtw8smh.fsf@rustcorp.com.au> References: <87tvtw8smh.fsf@rustcorp.com.au> Message-ID: <87zi3nxz5b.fsf@gmail.com> Rusty Russell writes: > Jim Posen writes: > If failure is common this would be true, but I think it's too early to > design for it. > > This kind of signalling is what fees are for: when capacity gets low you > increase fees, and when it gets high, you reduce them. But that may > still prove insufficient. > > Two things come to mind: > > 1. `temporary_channel_failure` returns a `channel_update`. The > implication is that this has the disabled flag, but we should > probably make that true iff the request asks for < 2% of the channel > capacity or some "minimal bar". If you can't even service this, you > should disable the channel. > > 2. We can implement fast failure to reduce latency: > https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming > > Note that there needs to be more analysis on reliable ways to mask the > active capacity of a channel: using a static random threshold still > leaks information that *something* has happened, so it may need to be > more sophisticated. I have to agree with Rusty here, pinging a channel for capacity sounds a lot like premature optimization. In addition it could lead to a rather large privacy leak, both for the sender as well as the individual channels. Giving any information about the current balance of a channel, could lead to tracing payments through the network. And users pinging channels before making a payment could result also in traced payments. The feedback mechanism we have by adding channel_updates in the failure message should allow senders to learn about changes in the channels that caused the failure, and it should be injected into the gossip so peers learn about it as well. Once we have exhausted what we can do with the simple gossip mechanism, only then should we be looking at other solutions. Cheers, Christian From ZmnSCPxj at protonmail.com Mon Mar 5 13:28:49 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Mon, 05 Mar 2018 08:28:49 -0500 Subject: [Lightning-dev] Christian Deckers Duplex Micropayment Channels vs Lightning networks revocation key solution In-Reply-To: References: Message-ID: Good morning Rene, The main issue I can think of offhand is the below issue for duplex channels: The maximum lockup period for your funds in the worst case is proportional to the number of updates the channel can have. Shorter worstcase lockup, fewer updates before the channel can only be closed. There is a technique to make O(log n) lockup time for n update limit rather than O(n) (at the cost of using O(log n) transactions in sequence), but the basic "more updates more worstcase lockup" exists. With Poon-Dryja (revocation) channels, there is no limit in the number of updates possible on a channel, especially when you use the "shachain" concept by Rusty Russell (which reduces storage for a sequence of revocation keys to just 64 bytes or so, I have not studied it deeply): in effect, you get O(1) lockup time and O(1) transactions for n update limit under Poon-Dryja rather than O(log n) lockup time and O(log n) transactions for Decker-Wattenhofer. Note in particular that every payment actually requires two updates: one to get payer funds to an HTLC, and the other to get the HTLC funds to the payee (or to revert the HTLC funds to the payer in case of routing failure). This is needed to get proof-of-payment and in particular to ensure that the final payee on a long route really did get the funds. So the cost incurred by Decker-Wattenhofer is higher by that factor, too. Decker-Wattenhofer does have the advantage that its construction can be extended to any number of participants per channel, while Poon-Dryja does not seem like it can be easily extended beyond two per channel. Hence the Burchert-Decker-Wattenhofer channel factories, where a Decker-Wattenhofer multiparticipant channel construction terminates into multiple two-participant Poon-Dryja channels. The Poon-Dryja channels can have any number of updates, and the Decker-Wattenhofer part only gets updated if all participants agree to redistribute their funds between terminating Poon-Dryja channels (which we expect to happen much more rarely than routing and sending/receiving funds, so that the O(log n) cost for maximum number of updates is less onerous for fund redistribution, while we still get to enjoy the potentially infinite number of possible channel updates for individual Poon-Dryja channels). Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ??????? Original Message ??????? On March 4, 2018 7:30 AM, Ren? Pickhardt via Lightning-dev wrote: > Hey everyone, > > as mentioned before I am quite new to lightning dev. Should the questions I'll ask be too basic please drop me a kind note and I will be more quite or ask my questions on other places. > > Today I studied Chrstian Deckers nice work about duplex micropayment channels ( [http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf](https://www.google.com/url?q=http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf&sa=D&source=hangouts&ust=1520200459037000&usg=AFQjCNG3ZwxZzV6e3VYlLpemzn0ZCUIv-A) ) > > I am wondering what was the rational for the lightning spec ( https://github.com/lightningnetwork/lightning-rfc ) to go with the revocation key system instead of the solution by Christian Decker to the problem? I understand that the revocation system was already in the whitepaper and at the time of writing the whitepaper the work by Christian Decker wasn't out yet. But I guess this will not be the entire reason. > > To me the key revocation system seems pretty complex to handle. In particular as Rusty also mentioned on his article (c.f. https://medium.com/@rusty_lightning/lightning-watching-for-cheaters-93d365d0d02f ) that already in the white paper people knew that potentially a third party observing service to detect a cheater is needed. This seems to me like a big drawback. > > So what have been strong arguments to go with the revocation system? > > On a side note I would like to state my respect to you: The lightning network (in combination with bitcoin) is really the most beautiful piece of technology I came across since I learnt about TCP/IP. Great work everybody for creating such an amazing technology and bringing together all those beautiful ideas. I am very confident that this technology will become history. > > best Rene > > -- > [www.rene-pickhardt.de](http://www.rene-pickhardt.de/)http://www.beijing-china-blog.com/ > > Skype: rene.pickhardt -------------- next part -------------- An HTML attachment was scrubbed... URL: From ZmnSCPxj at protonmail.com Mon Mar 5 13:50:10 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Mon, 05 Mar 2018 08:50:10 -0500 Subject: [Lightning-dev] Christian Deckers Duplex Micropayment Channels vs Lightning networks revocation key solution In-Reply-To: References: Message-ID: Good morning Rene, >To me the key revocation system seems pretty complex to handle. In particular as Rusty also mentioned on his article (c.f. https://medium.com/@rusty_lightning/lightning-watching-for-cheaters-93d365d0d02f ) that already in the white paper people knew that potentially a third party observing service to detect a cheater is needed. This seems to me like a big drawback. I believe this is also necessary under Decker-Wattenhofer? A potential thief trying to reuse old invalid state could make sure you will be offline for a few days, then broadcast (and hope it confirms) the kickoff transaction, wait for the old invalid state to be valid, and then broadcast the old invalid commitment transaction. You have to be online after the kickoff transaction gets confirmed to ensure you can broadcast the latest commitment transaction, too, or if you plan to be offline for long, you also need some watchtower-like service under Decker-Wattenhofer. And I believe that watchtowers under Poon-Dryja need only store the shachain and the funding txid, while watchtowers under Decker-Wattenhofer would have to store entire relative-timelocked transactions, leaking economic information at each update to a Decker-Wattenhofer watchtower, whereas Poon-Dryja watchtowers need to learn only about shachain updates, and can learn economic information only when channels get onchain (and honestly, when channels drop onchain everyone knows the economic information since the blockchain is publicly readable, so it is not a significant information at that point). Regards, ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty at rustcorp.com.au Tue Mar 6 03:55:25 2018 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 06 Mar 2018 14:25:25 +1030 Subject: [Lightning-dev] Lightning Protocol Summit September 10/11 2018? Message-ID: <87tvtt7t8y.fsf@rustcorp.com.au> Hi all, We had a kickoff summit for the Lightning Protocol in October 2016 in Milan. I think we're due for another one, so I'm proposing a date and location which works for me: September 10th and 11th Adelaide, Australia. This would be a meeting for development, update and optimization of the Lightning network protocol, with the aim to figure out what would be in the next version of the specification. I would love to host you all; we're a wine growing region, we have exotic animals, and spring is a great time to visit. Cheers, Rusty. PS. I'm confident we can find travel funds for developers who would otherwise be unable to attend. From rusty at rustcorp.com.au Tue Mar 6 03:42:46 2018 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 06 Mar 2018 14:12:46 +1030 Subject: [Lightning-dev] Another Implementation In-Reply-To: References: Message-ID: <877eqp98eh.fsf@rustcorp.com.au> ???? writes: > I'm Kenichi Kurimoto from Japan. Greetings Kenichi, I've been wondering what you've been doing, since we've seen so many of your intelligent questions on the lightning-rfc github! We have a Google Hangout every two weeks; you're welcome to join if you want to discuss the specification progress but it is very early for Japan (4:00am!). https://docs.google.com/document/d/1oU4wxzGsYd0T084rTXJbedb7Gvdtj4ax638nMkYUmco/edit I look forward to your contributions! Thankyou, Rusty. > We are the team who have been seeking an application and architecture that > combine cryptocurrency and IoT. (We are corporate team. Nayuta Inc.) > > We are implementing another Node software according to Lightning Network > Specification(BOLT). > https://github.com/nayutaco/ptarmigan > > The software is developping phase, but basic feature of BOLT works on small > closed Testnet network with LND, c-lightning, and ?clair. > We wrote how to use it on closed network. https://github.com/nayutaco/ > ptarmigan/tree/development/docs > When this node have valid path to starblocks, payment for starblocks can be > done. > We have not tested ip address broadcast mode. > > We have respect for the efforts of the people who made RFC document, and we > would like to contribute further protocol development. > > -Kenichi Kurimoto > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev From rusty at rustcorp.com.au Tue Mar 6 03:32:23 2018 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 06 Mar 2018 14:02:23 +1030 Subject: [Lightning-dev] refunds -- was Re: BOLT 11, real time micro payments, and route redundancy In-Reply-To: <5A98EE6F.3020509@AndySchroder.com> References: <59A6316A.2050809@AndySchroder.com> <874lsl93c2.fsf@rustcorp.com.au> <59AB9A0F.9040702@AndySchroder.com> <87o9qr7152.fsf@rustcorp.com.au> <59B62689.3020807@AndySchroder.com> <87shfooc3l.fsf@rustcorp.com.au> <5A98EE6F.3020509@AndySchroder.com> Message-ID: <87a7vl98vs.fsf@rustcorp.com.au> Andy Schroder writes: > On 09/14/2017 11:49 PM, Rusty Russell wrote: >> So, we really need to be able to include a (smaller) return onion to >> fix this properly. I've added that to: >> >> https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#refunds >> >> Thanks! >> Rusty. > > If you are including a smaller return onion, you are including that with > the payment? That return onion would be created by the payer since they > know the routes from the payer to the payee? If so, how could this work > if the route no longer has capacity (or goes down) by the time the payee > decides it's going to send the refund back to the payer (which could be > minutes, hours, or days later)? Also, even if all routes are still up, > the payer may not necessarily know how much refund the payee will be > giving them, so they may not necessarily be able to even know what the > best route they should build an onion for? You're right. While optimal routes aren't necessary, failures are possible and made worse by the inability to retry via a different route. I've noted this on the brainstorming phase. We don't currently return a reply message on success, but we could. It's best-effort of course (it won't appear if we drop to chain). I wonder if we could use that somehow. The general solution seems to require an ability to send payments to an anonymous destinations, which we don't have. Thanks! Rusty. From rusty at rustcorp.com.au Tue Mar 6 03:26:00 2018 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 06 Mar 2018 13:56:00 +1030 Subject: [Lightning-dev] Improving the initial gossip sync: DRAFT Message-ID: <87fu5d996f.fsf@rustcorp.com.au> https://github.com/lightningnetwork/lightning-rfc/pull/392 I'll append to this as suggestions come in. I'm trying to find some cycles to implement it too. Cheers, Rusty. From apoelstra at wpsoftware.net Tue Mar 6 20:58:51 2018 From: apoelstra at wpsoftware.net (Andrew Poelstra) Date: Tue, 6 Mar 2018 20:58:51 +0000 Subject: [Lightning-dev] Fwd: Post-Schnorr lightning txes In-Reply-To: References: <20180219225907.GA16444@erisian.com.au> Message-ID: <20180306205850.GK9082@boulet.lan> Hi Anthony, If you have adaptor/Bellare-Neven signatures you can actually do state updates in a much simpler way. Suppose we have two parties, Alice and Bob. The basic structure of a payment channel in state i is Funding tx --> Commit_i --> Close_i where Commit_i is a transaction with one output with the following script IF AB_i ELSE CSV AB'_i ENDIF CHECKSIG and Close_i is a transaction moving the coins to their final destination. (I'm using IF/ELSE, but for efficiency the CSV branch could be hidden behind a Taproot.) To create a new state i, A and B interact as follows. 0. Create tx_i, a 1-in-1-out tx which spends the funding tx output to the Commit_i output. 1. Both sign a closing transaction tx'_i which spends this output to the Close_i output. tx'_i will be valid blocks after the Commit transaction is posted to the blockchain. 2. A and B interactively sign tx_i twice. In the final step of this interaction, A gives s^1_{A,i} to B and B gives s^2_{B,i} to A. Now A can generate s^2_{A,i} to complete a signature and post tx_i, or B can generate s^1_{B,i} to the same effect. After creating a new state i, A and B revoke state i-1 as follows: 3. A sends an adaptor signature for s^2_{A,i-1} which reveals her half of AB_i if she publishes that signature. Similarly B sends an adaptor sig for s^1_{B,i-1} which reveals his half of AB_{i-1}. Now if either party completes tx_i and to post the (i-1)th state to the chain, the _other_ party will learn the secret key to AB_i and can take the coins. The partial signatures in step (2) can be adaptor signatures which link this state update to other state updates in other channel, giving complete paths. In fact you can link arbitrary sets of channels to get multipaths, so AMP comes for free in this scheme. As Anthony mentioned in his email, the payment receipt is now a discrete log (which can be reblinded so that participants in the hop who aren't the sender or recipient can't see it). This means that the sender can sign with this, getting a transferrable proof of payment that also works with AMP. The required state to store consists of these adaptor signatures, so it's linear in the number of state updates in each channel. I believe outsourcing will be quadratic :( but I haven't worked out those details. Though you can get a weak form of monitoring by giving the adaptor signatures to the monitor and having it contact the affected party with "wake up! somebody published an old state and revealed the key x, please use it to take your coins". I haven't worked out blind monitoring either, it seems like it should be doable because everything here is discrete-log based which is inherently friendly toward blinding. Andrew On Tue, Mar 06, 2018 at 08:18:31PM +0000, Christian Decker wrote: > ---------- Forwarded message --------- > From: Anthony Towns > Date: Mon, Feb 19, 2018 at 11:59 PM > Subject: [Lightning-dev] Post-Schnorr lightning txes > To: > > > Hi *, > > My understanding of lightning may be out of date, so please forgive > (or at least correct :) any errors on my behalf. > > I was thinking about whether Greg Maxwell's graftroot might solve the > channel monitoring problem (spoiler: not really) and ended up with maybe > an interesting take on Schnorr. I don't think I've seen any specific > writeup of what that might look like, so hopefully at least some of this > is novel! > > I'm assuming familiarity with current thinking on Schnorr sigs -- but all > you should need to know is the quick summary at footnote [0]. > > So I think there's four main scenarios for closing a lightning channel: > > - both parties are happy to close, do so cooperatively, and can > sign a new unconditional transaction that they agree on. already fine. > (should happen almost all of the time, call it 80%) > > - communications failure: one side has to close, but the other side > is happy to cooperate as far as they're able but can only do so via > the blockchain and maybe with some delay (maybe 15% of the time) > > - disappearance, uncooperative: one side effectively completely > disappears so the other side has to fully close the channel on their > own (5% of the time) > > - misbehaviour: one side tries publishing an old channel state due to > error or maliciousness, and the other collects the entire balance as > penalty (0% of the time) > > With "graftroot" in mind, I was thinking that optimising for the last > case might be interesting -- despite expecting it to be vanishingly > rare. That would have to look something like: > > (0) funding tx > (1) ...which is spent by a misbehaving commitment tx > (2) ...which is spent by a penalty tx > > You do need 3 txes for that case, but you really only need 1 output > for each: so (0) is 2-in-1-out, (1) is 1-in-1-out, (2) is 1-in-1-out; > which could all be relatively cheap. (And (2) could be batched with other > txes making it 1 input in a potentially large tx) > > For concreteness, I'm going to treat A as the one doing the penalising, > and B (Bad?) as the one that's misbehaving. > > If you treat each of those txes as a muSig Schnorr pay-to-pubkey, the > output addresses would be: > > (0) funding tx pays to [A,B] > (1) commitment tx pays to [A(i),Revocation(B,i)] > (2) pays to A > > (where i is a commitment id / counter for the channel state) > > If B misbehaves by posting the commitment tx after revealing the > revocation secret, A can calculate A(i) and Revocation(B,i) and claim > all the funds immediately. > > As far as the other cases go: > > - In a cooperative close, you don't publish any commitment txes, you > just spend the funding to each party's preferred destinations > directly; so this is already great. > > - Otherwise, you need to be able to actually commit to how the funds > get distributed. > > But committing to distributing funds is easy: just jointly sign > a transaction with [A(i),Revocation(B,i)]. Since B is the one we're > worrying about misbehaving, it needs to hold a transaction with the > appropriate outputs that is: > > - timelocked to `to_self_delay` blocks/seconds in advance via nSequence > - signed by A(i) > > That ensures A has `to_self_delay` blocks/seconds to penalise misehaviour, > and that when closing properly, B can complete the signature using the > current revocation secret. > > This means the "appropriate outputs" no longer need the OP_CSV step, which > should simplify the scripts a bit. > > Having B have a distribution transaction isn't enough -- B could vanish > between publishing the commitment transaction and the distribution > transaction, leaving A without access to any funds. So A needs a > corresponding distribution transaction. But because that transaction can > only be published if B signs and publishes the corresponding commitment > transaction, the fact that it's published indicates both A and B are > happy with the channel close -- so this is a semi-cooperative close and > no delay is needed. So A should hold a partially signed transaction with > the same outputs: > > - without any timelock > - signed by Revocation(B,i), waiting for signature by A(i) > > Thus, if B does a non-cooperative close, either: > > - A proves misbehaviour and claims all the funds immediately > - A agrees that the channel state is correct, signs and publishes > the un-timelocked distribution transaction, then claims A's outputs; > B can then immediately claim its outputs > - A does nothing, and B waits for the `to_self_delay` period, signs > and publishes its transaction, then claims B's outputs; A can eventually > claim its own outputs > > In that case all of the transactions except the in-flight HTLCs just look > like simple pay-to-pubkey transactions. > > Further, other than the historical secrets no old information needs > to be retained: misbehaviour can be dealt with (and can only be dealt > with) by creating a new transaction signed by your own secrets and the > revocation information. > > None of that actually relies on Schnorr-multisig, I think -- it could > be done today with normal 2-of-2 multisig as far as I can see. > > > > I'm not 100% sure how this approach works compared to the current one > for the CSV/CLTV overlap problem. I think any case you could solve by > obtaining a HTLC-Timeout or HTLC-Success transaction currently, you could > solve in the above scenario by just updating the channel state to remove > the HTLC. > > > So I believe the above lets you completely forget info about old HTLCs, > while still enforcing correct behavior, and also makes enforcing correct > behaviour cheaper because it's just two extremely simple transactions > to post. If I haven't missed any corner cases, it also seems to simplify > the scripts a fair bit. > > Does this make sense? It seems to to me... > > > So for completeness, it would make sense to do HTLCs via Schnorr -- > at least to make them reveal elliptic curve private keys, and ideally > to make them mostly indistinguishable from regular transactions as a > "scriptless script" [1] or "discreet log contract" [2]. (I think, at > least for HTLCs, these end up being the same?) > > The idea then is to have the HTLC payment hash be R=r*G, where r is the > secret/payment receipt. > > Supposing your current commitment has n HTLCs in-flight, some paying A > if the HTLC succeeds and "r" is revealed, others paying B. We'll focus > on one paying A. > > So you succeed by A completing a signature that reveals r to B, > and which simultaneously allows collection of the funds on chain. A > needs to be able to do this knowing nothing other than r (and their own > private keys). So agree to sign to muSig 2-of-2 multisig [A,B]. A and B > generate random values i and j respectively and reveal I=i*G and J=j*G, > and each calculates Q=I+J+R, and they generate partial signatures of a > transaction paying A: > > I, i + H(X,Q,m)*H(L,A)*a > J, j + H(X,Q,m)*H(L,B)*b > > where L = H(A,B) and X = H(L,A)*A + H(L,B)*B as usual. Once A knows r, > A can construct a full signature by adding R, r to the above values, > and B can then determine r by subtracting the above values from signature > A generated. > > To ensure B gets paid if the HTLC timesout, they should also sign a > timelocked transaction paying B directly, that B can hold onto until > the channel state gets updated. > > And once you're doing payment hashes via ECC, you can of course change > them at each hop to make it harder to correlate steps in a payment route. > > I think that when combined with the above method of handling CSV delays > and revocation, this covers all the needed cases with a straightforward > pay-to-pubkey(hash) output, no script info needed at all. It does mean > each HTLC needs a signature every time the channel state updates (B needs > to sign a tx allowing A to claim the output once A knows the secret, > A needs to sign a tx allowing B to claim the output on timeout). > > > For channel monitoring this is pretty good, I think. You need to > keep track of the revocation info and your secret keys -- but that's > essentially a constant amount of data. > > If you're happy to have the data grow by 64 bytes every time the channel > state updates, you can outsource channel monitoring: arrange a formula > for constructing a penalty tx based on the channel commitment tx -- > eg, 95% of the balance goes to me, 4% goes to the monitor's address, 1% > goes to fees, there's a relative locktime of to_self_delay/3 to allow me > to directly claim 100% of the funds if I happen to be paying attention; > then do a partial signature with A(i), and then allow the monitoring > service to catch fraudulent transactions, work out the appropriate > revocation secret, and finish the signature. > > If your channel updates 100 times a second for an entire year, that's > 200GB of data, which seems pretty feasible. (You can't just regenerate > that data though, unless you keep each commitment tx) And it's pretty > easy to work out which bit of data you need to access: the funding > tx that's being spent tells you which channel, and the channel state > index is encoded in the locktime and sequence, so you should only need > small/logarithmic overhead even for frequently updated channels rather > than any serious indexes. > > I don't think you can do better than that without serious changes to > bitcoin: if you let the monitoring agency sign on its own, you'd need some > sort of covenant opcode to ensure it sends any money to you; and with > segwit outputs, there's no way to provide a signature for a transaction > without committing to exactly which transaction you're signing. > > I was hoping covenants and graftroot would be enough, but I don't > think they are. The idea would be that since the transaction spends to > A(i)+Rev(B,i), you'd sign an output script with A that uses covenant > opcodes to ensure the transaction only pays the appropriate monitoring > reward, and the monitor could then work out A(i)-A and Rev(B,i) and finish > the signature. But the signature by "A" would need to know A(i)+Rev(B,i) > when calculating the hash, and that's different for every commitment > transaction, so as far as I can see, it just doesn't work. You can't > drop the muSig-style construction because you need to be protect yourself > against potential malicious choice of the revocation secret [3]. > > > Summary: > > - Funding txes as 2-of-2 multisig is still great. Convert to > Schnorr/muSig when available of course. > > - Generate 6+8*n transactions everytime the channel state is updated, > (n = number of HTLCs in-flight) > > 1. Channel state commitment tx, held by A, spends funding tx, > payable to Schnorr muSig address [A(i),Rev(B,i)], signed by B > 2. Channel fund distribution tx, held by A (CSV), spends (1), > signed by Rev(B,i) > 3. Channel fund distribution tx, held by B (no CSV), spends (1), > signed by A(i) > 4. Channel state commitment tx, held by B, spends funding tx > payable to Schnorr muSig address [B(i),Rev(A,i)], signed by A > 5. Channel fund distribution tx, held by B (CSV), spends (4), > signed by Rev(A,i) > 6. Channel fund distribution tx, held by A (no CSV), spends (4), > signed by B(i) > > The fund distribution txs all pay the same collection of addresses: > - channel balance for A directly to A's preferred address > - channel balance for B directly to B's preferred address > - HTLC balance to muSig address for [A,B] for each in-flight HTLC > paying A on success > - HTLC balance to muSig address for [B,A] for each in-flight HTLC > paying B on success > - (probably makes sense to bump the HTLC addresses by some random > value to make it harder for third parties to tell which addresses > were balances versus HTLCs) > > Both (1) and (4) include obscured channel state ids as per current > standard. > > For each HTLC that pays X on timeout and Y on success: > a. Timeout tx, held by X, signed by Y, spends from (2) > b. Timeout tx, held by X, signed by Y, spends from (3) > c. Timeout tx, held by X, signed by Y, spends from (5) > d. Timeout tx, held by X, signed by Y, spends from (6) > > e. Success tx, held by Y, signed by X, spends from (2) > f. Success tx, held by Y, signed by X, spends from (3) > g. Success tx, held by Y, signed by X, spends from (5) > h. Success tx, held by Y, signed by X, spends from (6) > > (these should all be able to be SIGHASH_SINGLE, ANYONECANPAY > to allow some level of aggregation) > > - Fund distribution tx outputs can all be pay2pubkey(hash): HTLCs work > by pre-signed timelocked transactions and scriptless > scripts/discreet-log contracts to reveal the secret; balances work > directly; CSV and revocations are already handled by that point > > - You can discard all old transaction info and HTLC parameters once > they're not relevant to the current channel state > > - Channel monitoring can be outsourced pretty efficiently -- as little as > a signature per state could be made to works as far as I can see, > which doesn't add up too fast. > > - There's still no plausible way of doing constant space outsourced > channel monitoring without some sort of SIGHASH_NOINPUT, at least > that I can see > > Thoughts? > > [4] > > Cheers, > aj, very sad that this didn't turn out to be a potential use case for > graftroot :( > > [0] In particular, I'm assuming that: > > - Schnorr sigs in bitcoin will look something like: > R, r + H(X,R,m)*x > > (where m is the message being signed by private key x, r is a > random per-sig nonce, R and X are public keys corresponding to r,x; > H is the secure hash function) > > - muSig is a secure way for untrusting parties to construct an n-of-n > combined signature; for public keys A and B, it produces a combined > public key: > X = H(L,A)*A + H(L,B)*B > with L = H(A,B) > > See > https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures.html > > [1] > https://scalingbitcoin.org/stanford2017/Day2/Using-the-Chain-for-what-Chains-are-Good-For.pdf > > http://diyhpl.us/wiki/transcripts/scalingbitcoin/stanford-2017/using-the-chain-for-what-chains-are-good-for/ > > [2] https://adiabat.github.io/dlc.pdf > https://diyhpl.us/wiki/transcripts/discreet-log-contracts/ > > [3] Well, maybe you could request a zero-knowledge proof to ensure a new > revocation hash conforms to the standard for generating revocation > secrets without revealing the secret, and have the public key be > a(i)*G + r(B,i)*G without using the muSig construct, but that would > probably be obnoxious to have to generate every time you update > the channel state. > > [4] As an aside -- this could make it feasible and interesting to penalise > disappearance as well as misbehaviour. If you add a transaction > the B pre-signs, spending the commitment tx A holds, giving all the > channel funds to A but only after a very large CSV timeout, perhaps > `to_self_delay`*50, then the scenarios are: > > If A is present: > > - B publishes an old commitment: A immediately steals all the > funds if active or outsourced misbehaviour monitoring. Whoops! > > - B publishes the current commitment: A publishes its distribution > transaction and collects its funds immediately, allowing B to > do likewise > > If A has disappeared: > > - B publises the current commitment and waits a modest amount > of time, publishes its distribution transaction claiming its > rightful funds, and allowing A to collect its funds if it ever > does reappear and still knows its secrets > > - B publishes the current commitment, waits a fair while, > A reappears and publishes its distribution transactions, both > parties get their rightful funds > > - B publishes the current commitment, waits an extended period > of time, and claims the entire channel's funds. If B is > particularly reputable, and A can prove its identity (but not > recover all its secrets) maybe B even refunds A some/all of its > rightful balance > > Perhaps that provides too much of an incentive to try blocking > someone from having access to the blockchain though. > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -- Andrew Poelstra Mathematics Department, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew "A goose alone, I suppose, can know the loneliness of geese who can never find their peace, whether north or south or west or east" --Joanna Newsom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: not available URL: From apoelstra at wpsoftware.net Tue Mar 6 21:06:25 2018 From: apoelstra at wpsoftware.net (Andrew Poelstra) Date: Tue, 6 Mar 2018 21:06:25 +0000 Subject: [Lightning-dev] Fwd: Post-Schnorr lightning txes In-Reply-To: <20180306205850.GK9082@boulet.lan> References: <20180219225907.GA16444@erisian.com.au> <20180306205850.GK9082@boulet.lan> Message-ID: <20180306210624.GM9082@boulet.lan> On Tue, Mar 06, 2018 at 08:58:51PM +0000, Andrew Poelstra wrote: > After creating a new state i, A and B revoke state i-1 as follows: > > 3. A sends an adaptor signature for s^2_{A,i-1} which reveals her half > of AB_i if she publishes that signature. Similarly B sends an > adaptor sig for s^1_{B,i-1} which reveals his half of AB_{i-1}. > > Now if either party completes tx_i and to post the (i-1)th state > to the chain, the _other_ party will learn the secret key to AB_i > and can take the coins. > Oof I messed up this paragraph. _i should be _{i-1} everywhere. Here is a correct version: > 3. A sends an adaptor signature for s^2_{A,i-1} which reveals her half > of AB_{i-1} if she publishes that signature. Similarly B sends an > adaptor sig for s^1_{B,i-1} which reveals his half of AB_{i-1}. > > Now if either party completes tx_{i-1} to post the (i-1)th state > to the chain, the _other_ party will learn the secret key to AB_{i-1} > and can take the coins. > -- Andrew Poelstra Mathematics Department, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew "A goose alone, I suppose, can know the loneliness of geese who can never find their peace, whether north or south or west or east" --Joanna Newsom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: not available URL: From corne at bitonic.nl Thu Mar 8 15:19:56 2018 From: corne at bitonic.nl (=?UTF-8?Q?Corn=c3=a9_Plooy?=) Date: Thu, 8 Mar 2018 16:19:56 +0100 Subject: [Lightning-dev] A protocol for requesting invoices Message-ID: Hi, I was thinking of how to use Lightning for various types of payments, and I think it's currently fine for customer/(web)shop type interactions, but it seems a bit inconvenient for other use cases, e.g. salary payments or direct pay-out of cryptocurrency bought on an exchange. I came up with an idea that addresses some of these issues and more (e.g. payee anonymity) by having a direct line of communication between payer and payee instead of BOLT11-style interaction. It's still a bit half-baked, with many details not worked out yet, but you can read it here, and see if you like where this is going: https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md In true permissionless fashion, I have been so bolD to register bolT #12 for my idea. Please let me know what you think. kind regards, CJP From ZmnSCPxj at protonmail.com Fri Mar 9 04:28:34 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Thu, 08 Mar 2018 23:28:34 -0500 Subject: [Lightning-dev] A protocol for requesting invoices In-Reply-To: References: Message-ID: Good morning Corne, You mention URLs in your draft. This made me remember about the Web Payments Working Group of W3C, https://www.w3.org/Payments/WG/ , of which Decker, Christian of Blockstream is a member: https://www.w3.org/2000/09/dbwg/details?group=83744&public=1 My understanding is that Christian aims to make Bitcoin payments (and possibly Lightning invoice payments?) payable over Web payment protocols that W3C group is working on. Possibly the Web Payments Working Group may provide better perspective on various other payment use cases as well as their subtleties, which can help inform your considerations in your proposed BOLT12. Regards, ZmnSCPxj ?Sent with ProtonMail Secure Email.? ??????? Original Message ??????? On March 8, 2018 11:19 PM, Corn? Plooy via Lightning-dev wrote: > Hi, > > I was thinking of how to use Lightning for various types of payments, > > and I think it's currently fine for customer/(web)shop type > > interactions, but it seems a bit inconvenient for other use cases, e.g. > > salary payments or direct pay-out of cryptocurrency bought on an > > exchange. I came up with an idea that addresses some of these issues and > > more (e.g. payee anonymity) by having a direct line of communication > > between payer and payee instead of BOLT11-style interaction. It's still > > a bit half-baked, with many details not worked out yet, but you can read > > it here, and see if you like where this is going: > > https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md > > In true permissionless fashion, I have been so bolD to register bolT #12 > > for my idea. > > Please let me know what you think. > > kind regards, > > CJP > > Lightning-dev mailing list > > Lightning-dev at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev From info at AndySchroder.com Sat Mar 10 05:16:14 2018 From: info at AndySchroder.com (Andy Schroder) Date: Sat, 10 Mar 2018 00:16:14 -0500 Subject: [Lightning-dev] A protocol for requesting invoices In-Reply-To: References: Message-ID: <5AA36A1E.5090909@AndySchroder.com> Hello Corn?, I'm glad to see that someone getting this kind of idea started. I'm still new to some of these topics, but I have a few comments. Hopefully I'm not wasting your time if they are too rudimentary! 1. You mention that the payee gives a URL where the payer can then connect to to request invoices. You mention that this can be a tor hidden service if the payee needs to remain private. You also suggest that the payee can remain private by "payee can send an invoice to payer which has a partial onion route as destination instead of a node ID". I was reading about tor hidden services (https://www.torproject.org/docs/onion-services.html.en), and they require an introduction point, and a rendezvous point. Do we not need this two step process for the payment route, because we already have communication initiated over the anonymous communication channel, and the beginning of the partial onion route is not publicly available information, and can change with every invoice? 2. What happens if the capacity of the partial onion route is no longer sufficient when the payer is ready to pay? Is there a way to provide a few routes just in case? Or, in the case where no amount is specified, how is the partial onion route possible if we don't even know how much capacity may be needed? 3. You say the refund should invalidate the proof of payment of the initial transaction. What about partial refunds? I think there are a lot of applications where there would be a partial refund. 4. You say "this BOLT specifies a protocol where payee gives a URL to one or more potential payers". How does the payer identify itself to the payee so that the payee knows what goods or services that they want an invoice for? Do they send this after making the connection, or is it part of the URL? Andy Schroder On 03/08/2018 10:19 AM, Corn? Plooy via Lightning-dev wrote: > Hi, > > I was thinking of how to use Lightning for various types of payments, > and I think it's currently fine for customer/(web)shop type > interactions, but it seems a bit inconvenient for other use cases, e.g. > salary payments or direct pay-out of cryptocurrency bought on an > exchange. I came up with an idea that addresses some of these issues and > more (e.g. payee anonymity) by having a direct line of communication > between payer and payee instead of BOLT11-style interaction. It's still > a bit half-baked, with many details not worked out yet, but you can read > it here, and see if you like where this is going: > > > https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md > > > In true permissionless fashion, I have been so bolD to register bolT #12 > for my idea. > > > Please let me know what you think. > > kind regards, > > CJP > > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.pickhardt at googlemail.com Tue Mar 13 13:30:21 2018 From: r.pickhardt at googlemail.com (=?UTF-8?Q?Ren=C3=A9_Pickhardt?=) Date: Tue, 13 Mar 2018 14:30:21 +0100 Subject: [Lightning-dev] New form of 51% attack via lightning's revocation system possible? Message-ID: Hey everyone, disclaimer: as mentioned in my other mail ( https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001065.html ) I am currently studying the revocation system of duplex micropayment channels in detail but I am also pretty new to the topic. So I hope the attack I am about to describe is not possible and it is just me overseeing some detail or rather my lack of understanding. That being said even after waiting one week upon discovery and double checking the assumptions I made I am still positive that the revocation system in its current form allows for a new form of a 51% attack. This attack seems to be way more harmful than a successful 51% attack on the bitcoin network. Afaik within the bitcoin network I could 'only double spend' my own funds with a successful 51% attack. In the lightning case it seems that an attacker could steal an arbitrary amount of funds as long as the attacker has enough payment channels with enough balance open. The attack itself follows exactly the philosophy of lightning: "If a tree falls in the forest and no one is around to hear it. Does it make a sound?" In the context of the attack this would translate to: "If a 51% attacker secretly mines enough blocks after fraudulently spending old commitment transactions and no one sees it during the the *to_self_delay* period, have the commitment transactions been spent? (How) Can they be revoked?" As for the technical details I quote from the spec of BOLT 3: "*To allow an opportunity for penalty transactions, in case of a revoked commitment transaction, all outputs that return funds to the owner of the commitment transaction (a.k.a. the "local node") must be delayed for * *to_self_delay** blocks. This delay is done in a second-stage HTLC transaction (HTLC-success for HTLCs accepted by the local node, HTLC-timeout for HTLCs offered by the local node)*" Assume an attacker has 51% of the hash power she could open several lightning channels and in particular accept any incoming payment channel (the more balance is in her channels the more lucrative the 51% attack). Since the attacker already has a lot of hash power it is reasonable (but not necessary) to assume that the attacker already has a lot of bitcoins and is well known to honest nodes in the network which makes it even more likely to have many open channels. The attacker keeps track of her (revocable) commitment transactions in which the balance is mostly on the attackers side. Once the attacker knows enough of these (old) commitment transactions the attack is being executed in the following way: 0.) The max value of to_self_delay is evaluated. Let us assume it is 72 blocks (or half a day). 1.) The attacker secretly starts mining on her own but does not broadcasts any successfully mined block. Since the attacker has 51% of the hash power she will most likely be faster than the network to mine the 72 blocks of the safety period in which fraudulent commitment transactions could be revoked. 2.) The attacker spends all the fraudulent (old) commitment transactions in the first block of her secrete mining endeavor. 3.) Meanwhile the attacker starts spending her own funds of her payment channels e.g on decentralized exchanges for any other (crypto)currency. 4.) As soon as the attacker has mined enough blocks that the commitment transactions cannot be revoked she broadcasts her secretly minded blockchain which will be accepted by the network as it is the longest chain. (In Particular she includes all the other bitcoin transactions that are also in the original public blockchain so that other people don't even realize something suspicious has happened.) Since according to the spec channels should never be balanced worse than 99% to 1% the attacker could steal up to 99% of all the bitcoins allocated in the sum of all payment channels the attacker was connected to. This amount could obviously be way higher than just double spending her own funds. This attack would be interesting in particular for the power nodes created by the Barabasi-Albert model of lnd's autopilot (c.f.: https://github.com/lightningnetwork/lnd/issues/677 ). I understand that with the growth of the bitcoin (mining) network a 51% attack becomes less and less likely. Also I am very happy to be proven false about the attack that I am describing. Another sad thing about this attack is that I currently do not see any (reasonable) way of preventing this form of a 51% attack (other than creating payment channels that don't offer the possibility of revocation) as it is abusing exactly the core idea of lightning to do something in secret without broadcasting it. Best regards Rene --- http://www.rene-pickhardt.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From decker.christian at gmail.com Tue Mar 13 14:55:10 2018 From: decker.christian at gmail.com (Christian Decker) Date: Tue, 13 Mar 2018 15:55:10 +0100 Subject: [Lightning-dev] New form of 51% attack via lightning's revocation system possible? In-Reply-To: References: Message-ID: <87efkoyqi9.fsf@gmail.com> Hi Ren?, very good question. I think the simple answer is that this is exactly the reason why not having a participant in the network that can 51% attack over a prolonged period is one of the base assumptions in Lightning. These attacks are deadly to all blockchains, and we are certainly no different in that regard. More interesting is the assertion that this may indeed be more dangerous than a classical 51% attack, in which an attacker can only doublespend funds that she had control over at some point during the attack (duration being defined as the period she can build a hidden fork of). I think the case for Lightning is not more dangerous since what they could do is enforce an old state in which they had a higher balance than in the final state, without incurring in a penalty. The key observation is that in this old state they actually had to have the balance they are stealing on the channel. So this maps directly to the classical scenario in which an attacker simply doublespends funds they had control over during the attack, making the attack pretty much the same. Another interesting observation is that with Lightning the state that the attacker is enforcing may predate the attack, e.g., an attacker could use a state that existed and was replaced before it started generating its fork. This is in contrast to the classical doublespend attack in which invalidated spends have to happen after the fork started, and the attacker just filters them from its fork. But as I said before, if we can't count on there not being a 51% attacker, then things are pretty much broken anyway :-) Cheers, Christian Ren? Pickhardt via Lightning-dev writes: > Hey everyone, > > disclaimer: as mentioned in my other mail ( > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001065.html > ) I am currently studying the revocation system of duplex micropayment > channels in detail but I am also pretty new to the topic. So I hope the > attack I am about to describe is not possible and it is just me overseeing > some detail or rather my lack of understanding. > That being said even after waiting one week upon discovery and double > checking the assumptions I made I am still positive that the revocation > system in its current form allows for a new form of a 51% attack. This > attack seems to be way more harmful than a successful 51% attack on the > bitcoin network. Afaik within the bitcoin network I could 'only double > spend' my own funds with a successful 51% attack. In the lightning case it > seems that an attacker could steal an arbitrary amount of funds as long as > the attacker has enough payment channels with enough balance open. > > The attack itself follows exactly the philosophy of lightning: "If a tree > falls in the forest and no one is around to hear it. Does it make a sound?" > In the context of the attack this would translate to: "If a 51% attacker > secretly mines enough blocks after fraudulently spending old commitment > transactions and no one sees it during the the *to_self_delay* period, > have the commitment transactions been spent? (How) Can they be revoked?" > > > As for the technical details I quote from the spec of BOLT 3: > "*To allow an opportunity for penalty transactions, in case of a revoked > commitment transaction, all outputs that return funds to the owner of the > commitment transaction (a.k.a. the "local node") must be delayed for * > *to_self_delay** blocks. This delay is done in a second-stage HTLC > transaction (HTLC-success for HTLCs accepted by the local node, > HTLC-timeout for HTLCs offered by the local node)*" > > Assume an attacker has 51% of the hash power she could open several > lightning channels and in particular accept any incoming payment channel > (the more balance is in her channels the more lucrative the 51% attack). > Since the attacker already has a lot of hash power it is reasonable (but > not necessary) to assume that the attacker already has a lot of bitcoins > and is well known to honest nodes in the network which makes it even more > likely to have many open channels. > > The attacker keeps track of her (revocable) commitment transactions in > which the balance is mostly on the attackers side. Once the attacker knows > enough of these (old) commitment transactions the attack is being executed > in the following way: > 0.) The max value of to_self_delay is evaluated. Let us assume it is 72 > blocks (or half a day). > 1.) The attacker secretly starts mining on her own but does not broadcasts > any successfully mined block. Since the attacker has 51% of the hash power > she will most likely be faster than the network to mine the 72 blocks of > the safety period in which fraudulent commitment transactions could be > revoked. > 2.) The attacker spends all the fraudulent (old) commitment transactions in > the first block of her secrete mining endeavor. > 3.) Meanwhile the attacker starts spending her own funds of her payment > channels e.g on decentralized exchanges for any other (crypto)currency. > 4.) As soon as the attacker has mined enough blocks that the commitment > transactions cannot be revoked she broadcasts her secretly minded > blockchain which will be accepted by the network as it is the longest > chain. (In Particular she includes all the other bitcoin transactions that > are also in the original public blockchain so that other people don't even > realize something suspicious has happened.) > > Since according to the spec channels should never be balanced worse than > 99% to 1% the attacker could steal up to 99% of all the bitcoins allocated > in the sum of all payment channels the attacker was connected to. This > amount could obviously be way higher than just double spending her own > funds. This attack would be interesting in particular for the power nodes > created by the Barabasi-Albert model of lnd's autopilot (c.f.: > https://github.com/lightningnetwork/lnd/issues/677 ). > > I understand that with the growth of the bitcoin (mining) network a 51% > attack becomes less and less likely. Also I am very happy to be proven > false about the attack that I am describing. > > Another sad thing about this attack is that I currently do not see any > (reasonable) way of preventing this form of a 51% attack (other than > creating payment channels that don't offer the possibility of revocation) > as it is abusing exactly the core idea of lightning to do something in > secret without broadcasting it. > > Best regards Rene > > --- > > http://www.rene-pickhardt.de > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev From r.pickhardt at googlemail.com Tue Mar 13 17:07:48 2018 From: r.pickhardt at googlemail.com (=?UTF-8?Q?Ren=C3=A9_Pickhardt?=) Date: Tue, 13 Mar 2018 18:07:48 +0100 Subject: [Lightning-dev] New form of 51% attack via lightning's revocation system possible? In-Reply-To: <87efkoyqi9.fsf@gmail.com> References: <87efkoyqi9.fsf@gmail.com> Message-ID: Hey Christian, I agree with you on almost anything you said. however I disagree that in the lightning case it produces just another double spending. I wish to to emphasize on my statement that the in the case with lightning such a 51% attack can steal way more BTC than double spending my own funds. The following example is a little extrem and constructed but it should help to make the point. Also for pure convenience reasons I neglected the fact that channels should never be worse distributed than 99% to 1%: Let us assume I am the attacker currently owning 1000 BTC. Now 1000 nodes called n_0,...n_{999} open a payment channel with me (all funded by the other side with 999 BTC in each channel (and 1 BTC from me)) resulting in the following channel balance sheet: c_0: me = 1 BTC and n_0 = 999 BTC c_1: me = 1 BTC and n_1 = 999 BTC c_2: me = 1 BTC and n_2 = 999 BTC ... c_{999}: me = 1 BTC and n_{999} = 999 BTC Now node n_0 sends 1 BTC to each node n_1,...,n_{999} (using me for routing the payment) so the channel balances read: c_0: me = 1000 BTC and n_0 = 0 BTC (save the corresponding commitment transaction!) c_1: me = 0 BTC and n_1 = 1000 BTC c_2: me = 0 BTC and n_2 = 1000 BTC ... c_{999}: me= 0 BTC and n_{999} = 1000 BTC next n_1 sends 1000 BTC to n_0: c_0: me = 0 BTC and n_0 = 1000 BTC c_1: me = 1000 BTC and n_1 = 0 BTC (save the corresponding commitment transaction!) c_2: me = 0 BTC and n_2 = 1000 BTC ... c_{999}: me= 0 BTC and n_{999} = 1000 BTC similarly n_2 sends 1000 BTC to n_1: c_0: me = 0 BTC and n_0 = 1000 BTC c_1: me = 0 BTC and n_1 = 1000 BTC c_2: me = 1000 BTC and n_2 = 0 BTC (save the corresponding commitment transaction!) ... c_{999}: me = 0 BTC nad n_{999} = 1000 BTC following this scheme n_3 --[1000 BTC]--> n_2, n_4 --[1000 BTC]--> n_3,... due to this (as mentioned highly constructed and artificial behavior) I will have old commitment transactions in *each* and every channel (which spends 1000 BTC to me) When starting my secret mining endeavor I spend those commitment transactions which gives in this particular case 1000 * 1000 BTC = 1M BTC to me. So while I agree that a 51% is a problem for any blockchain technology I think the consequences in the lightning scenario are way more problematic and makes such an attack also way more interesting for a dishonest fraudulent person / group. In particular I could run for a decade on stable payment channels storing old state and at some point realizing it would be a really big opportunity secretly cashing in all those old transactions which can't be revoked. I guess one way of resolving this kind of limitless but rare possibility for stealing could be to make sure no one can have more than 2 or three times the amount of BTC she owns in all the payment channels the person has open. As funding transactions are publicly visible on the blockchain one could at least use that measure to warn people before opening and funding another payment channel with a node that is heavily underfunded. Also in the sense of network topology such a measure would probably make sure that channels are somewhat equally funded. best Rene On Tue, Mar 13, 2018 at 3:55 PM, Christian Decker < decker.christian at gmail.com> wrote: > Hi Ren?, > > very good question. I think the simple answer is that this is exactly > the reason why not having a participant in the network that can 51% > attack over a prolonged period is one of the base assumptions in > Lightning. These attacks are deadly to all blockchains, and we are > certainly no different in that regard. > > More interesting is the assertion that this may indeed be more dangerous > than a classical 51% attack, in which an attacker can only doublespend > funds that she had control over at some point during the attack > (duration being defined as the period she can build a hidden fork of). I > think the case for Lightning is not more dangerous since what they could > do is enforce an old state in which they had a higher balance than in > the final state, without incurring in a penalty. The key observation is > that in this old state they actually had to have the balance they are > stealing on the channel. So this maps directly to the classical > scenario in which an attacker simply doublespends funds they had control > over during the attack, making the attack pretty much the same. > > Another interesting observation is that with Lightning the state that > the attacker is enforcing may predate the attack, e.g., an attacker > could use a state that existed and was replaced before it started > generating its fork. This is in contrast to the classical doublespend > attack in which invalidated spends have to happen after the fork > started, and the attacker just filters them from its fork. > > But as I said before, if we can't count on there not being a 51% > attacker, then things are pretty much broken anyway :-) > > Cheers, > Christian > > Ren? Pickhardt via Lightning-dev > writes: > > Hey everyone, > > > > disclaimer: as mentioned in my other mail ( > > https://lists.linuxfoundation.org/pipermail/lightning-dev/ > 2018-March/001065.html > > ) I am currently studying the revocation system of duplex micropayment > > channels in detail but I am also pretty new to the topic. So I hope the > > attack I am about to describe is not possible and it is just me > overseeing > > some detail or rather my lack of understanding. > > That being said even after waiting one week upon discovery and double > > checking the assumptions I made I am still positive that the revocation > > system in its current form allows for a new form of a 51% attack. This > > attack seems to be way more harmful than a successful 51% attack on the > > bitcoin network. Afaik within the bitcoin network I could 'only double > > spend' my own funds with a successful 51% attack. In the lightning case > it > > seems that an attacker could steal an arbitrary amount of funds as long > as > > the attacker has enough payment channels with enough balance open. > > > > The attack itself follows exactly the philosophy of lightning: "If a tree > > falls in the forest and no one is around to hear it. Does it make a > sound?" > > In the context of the attack this would translate to: "If a 51% attacker > > secretly mines enough blocks after fraudulently spending old commitment > > transactions and no one sees it during the the *to_self_delay* period, > > have the commitment transactions been spent? (How) Can they be revoked?" > > > > > > As for the technical details I quote from the spec of BOLT 3: > > "*To allow an opportunity for penalty transactions, in case of a revoked > > commitment transaction, all outputs that return funds to the owner of the > > commitment transaction (a.k.a. the "local node") must be delayed for * > > *to_self_delay** blocks. This delay is done in a second-stage HTLC > > transaction (HTLC-success for HTLCs accepted by the local node, > > HTLC-timeout for HTLCs offered by the local node)*" > > > > Assume an attacker has 51% of the hash power she could open several > > lightning channels and in particular accept any incoming payment channel > > (the more balance is in her channels the more lucrative the 51% attack). > > Since the attacker already has a lot of hash power it is reasonable (but > > not necessary) to assume that the attacker already has a lot of bitcoins > > and is well known to honest nodes in the network which makes it even more > > likely to have many open channels. > > > > The attacker keeps track of her (revocable) commitment transactions in > > which the balance is mostly on the attackers side. Once the attacker > knows > > enough of these (old) commitment transactions the attack is being > executed > > in the following way: > > 0.) The max value of to_self_delay is evaluated. Let us assume it is 72 > > blocks (or half a day). > > 1.) The attacker secretly starts mining on her own but does not > broadcasts > > any successfully mined block. Since the attacker has 51% of the hash > power > > she will most likely be faster than the network to mine the 72 blocks of > > the safety period in which fraudulent commitment transactions could be > > revoked. > > 2.) The attacker spends all the fraudulent (old) commitment transactions > in > > the first block of her secrete mining endeavor. > > 3.) Meanwhile the attacker starts spending her own funds of her payment > > channels e.g on decentralized exchanges for any other (crypto)currency. > > 4.) As soon as the attacker has mined enough blocks that the commitment > > transactions cannot be revoked she broadcasts her secretly minded > > blockchain which will be accepted by the network as it is the longest > > chain. (In Particular she includes all the other bitcoin transactions > that > > are also in the original public blockchain so that other people don't > even > > realize something suspicious has happened.) > > > > Since according to the spec channels should never be balanced worse than > > 99% to 1% the attacker could steal up to 99% of all the bitcoins > allocated > > in the sum of all payment channels the attacker was connected to. This > > amount could obviously be way higher than just double spending her own > > funds. This attack would be interesting in particular for the power nodes > > created by the Barabasi-Albert model of lnd's autopilot (c.f.: > > https://github.com/lightningnetwork/lnd/issues/677 ). > > > > I understand that with the growth of the bitcoin (mining) network a 51% > > attack becomes less and less likely. Also I am very happy to be proven > > false about the attack that I am describing. > > > > Another sad thing about this attack is that I currently do not see any > > (reasonable) way of preventing this form of a 51% attack (other than > > creating payment channels that don't offer the possibility of revocation) > > as it is abusing exactly the core idea of lightning to do something in > > secret without broadcasting it. > > > > Best regards Rene > > > > --- > > > > http://www.rene-pickhardt.de > > _______________________________________________ > > Lightning-dev mailing list > > Lightning-dev at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -- www.rene-pickhardt.de Skype: rene.pickhardt mobile: +49 (0)176 5762 3618 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aj at erisian.com.au Tue Mar 13 18:30:19 2018 From: aj at erisian.com.au (Anthony Towns) Date: Wed, 14 Mar 2018 04:30:19 +1000 Subject: [Lightning-dev] New form of 51% attack via lightning's revocation system possible? In-Reply-To: References: <87efkoyqi9.fsf@gmail.com> Message-ID: <20180313183019.GA23645@erisian.com.au> On Tue, Mar 13, 2018 at 06:07:48PM +0100, Ren? Pickhardt via Lightning-dev wrote: > Hey Christian, > I agree with you on almost anything you said. however I disagree that in the > lightning case it produces just another double spending. I wish to to emphasize > on my statement that the in the case with lightning such a 51% attack can steal > way more BTC than double spending my own funds. I think you can get a simpler example: * I setup a channel, funding it with 10 BTC (ie, balance is 100% on my side) * Someone else sets up a channel with me, funding it with 5 BTC (balance is 100% on their side) * I route 5 BTC to myself from the first channel through the second: aj -> X -> ... -> victim -> aj * I save the state that says I own all 5BTC in the victim <-> aj channel * I route 5 BTC to myself from the second channel throught the first: aj -> victim -> ... -> X -> aj * At this point I'm back to having 10 BTC (minus some small amont of lightning fees) in the first channel * I use 51% hashing power to mine a secret chain that uses the saved state to close the victim<->aj channel. Once that chain is long enough that I can claim the funds I do so. Once I have claimed the funds on my secret chain and the secret chain has more work than the public chain, I publish it, causing a reorg. * At this point I still have 10 BTC in the original channel, and I have the victim's 5 BTC. I can parallelise this attack as well: before doing any private mining or closing the victim's channel, I can do the same thing with another victim, allowing me to collect old states worth many multiples of up to 10 BTC, and mine them at once, leaving with my original 10BTC minus fees, plus n*10BTC stolen from victims. This becomes more threatening if you add in conspiracy theories about there already being a miner with >51% hashpower, who has financial interests in seeing lightning fail... The main limitation is that it still only allows a 51% miner to steal funds from channels they participate in, so creating channels with identifiable entities with whom you have an existing relationship (as opposed to picking random anonymous nodes) is a defense against this attack. Also, if 51% of hashpower is mining in secret for an extended period, that may be detectable, which may allow countermeasures to be taken? You could also look at this the other way around: at the point when lightning is widely deployed, this attack vector seems like it gives an immediate, personal, financial justification for large economic actors to ensure that hash rate is very decentralised. > In particular I could run for a decade on stable payment channels > storing old state and at some point realizing it would be a really big > opportunity secretly cashing in all those old transactions which can't be > revoked. (I'd find it surprising if many channels stayed open for a decade; if nothing else, I'd expect deflation over that time to cause people to want to close channels) Cheers, aj From decker.christian at gmail.com Tue Mar 13 19:23:10 2018 From: decker.christian at gmail.com (Christian Decker) Date: Tue, 13 Mar 2018 20:23:10 +0100 Subject: [Lightning-dev] New form of 51% attack via lightning's revocation system possible? In-Reply-To: References: <87efkoyqi9.fsf@gmail.com> Message-ID: <87bmfrzso1.fsf@gmail.com> Good example, even if rather hard to setup :-) What I meant with the attack being identical is that we can replay the entire attack on-chain, without needing Lightning in the first place, i.e., the attacker needed to own the funds he is going to steal at some time, whether that is as part of a channel settlement that is repalced or an output that has been spent. You are however right that Lightning with its multi-hop payments increases the potential exposure of a node, increasing the attackers payoff in case of a successful attack. Cheers, Christian Ren? Pickhardt writes: > Hey Christian, > > I agree with you on almost anything you said. however I disagree that in > the lightning case it produces just another double spending. I wish to to > emphasize on my statement that the in the case with lightning such a 51% > attack can steal way more BTC than double spending my own funds. The > following example is a little extrem and constructed but it should help to > make the point. Also for pure convenience reasons I neglected the fact that > channels should never be worse distributed than 99% to 1%: > > Let us assume I am the attacker currently owning 1000 BTC. Now 1000 nodes > called n_0,...n_{999} open a payment channel with me (all funded by the > other side with 999 BTC in each channel (and 1 BTC from me)) resulting in > the following channel balance sheet: > c_0: me = 1 BTC and n_0 = 999 BTC > c_1: me = 1 BTC and n_1 = 999 BTC > c_2: me = 1 BTC and n_2 = 999 BTC > ... > c_{999}: me = 1 BTC and n_{999} = 999 BTC > > Now node n_0 sends 1 BTC to each node n_1,...,n_{999} (using me for routing > the payment) so the channel balances read: > c_0: me = 1000 BTC and n_0 = 0 BTC (save the corresponding > commitment transaction!) > c_1: me = 0 BTC and n_1 = 1000 BTC > c_2: me = 0 BTC and n_2 = 1000 BTC > ... > c_{999}: me= 0 BTC and n_{999} = 1000 BTC > > next n_1 sends 1000 BTC to n_0: > c_0: me = 0 BTC and n_0 = 1000 BTC > c_1: me = 1000 BTC and n_1 = 0 BTC (save the corresponding > commitment transaction!) > c_2: me = 0 BTC and n_2 = 1000 BTC > ... > c_{999}: me= 0 BTC and n_{999} = 1000 BTC > > similarly n_2 sends 1000 BTC to n_1: > c_0: me = 0 BTC and n_0 = 1000 BTC > c_1: me = 0 BTC and n_1 = 1000 BTC > c_2: me = 1000 BTC and n_2 = 0 BTC (save the corresponding > commitment transaction!) > ... > c_{999}: me = 0 BTC nad n_{999} = 1000 BTC > > following this scheme n_3 --[1000 BTC]--> n_2, n_4 --[1000 BTC]--> n_3,... > > due to this (as mentioned highly constructed and artificial behavior) I > will have old commitment transactions in *each* and every channel (which > spends 1000 BTC to me) > > When starting my secret mining endeavor I spend those commitment > transactions which gives in this particular case 1000 * 1000 BTC = 1M BTC > to me. > > So while I agree that a 51% is a problem for any blockchain technology I > think the consequences in the lightning scenario are way more problematic > and makes such an attack also way more interesting for a dishonest > fraudulent person / group. In particular I could run for a decade on stable > payment channels storing old state and at some point realizing it would be > a really big opportunity secretly cashing in all those old transactions > which can't be revoked. > > I guess one way of resolving this kind of limitless but rare possibility > for stealing could be to make sure no one can have more than 2 or three > times the amount of BTC she owns in all the payment channels the person has > open. As funding transactions are publicly visible on the blockchain one > could at least use that measure to warn people before opening and funding > another payment channel with a node that is heavily underfunded. Also in > the sense of network topology such a measure would probably make sure that > channels are somewhat equally funded. > > best Rene > > > > > > On Tue, Mar 13, 2018 at 3:55 PM, Christian Decker < > decker.christian at gmail.com> wrote: > >> Hi Ren?, >> >> very good question. I think the simple answer is that this is exactly >> the reason why not having a participant in the network that can 51% >> attack over a prolonged period is one of the base assumptions in >> Lightning. These attacks are deadly to all blockchains, and we are >> certainly no different in that regard. >> >> More interesting is the assertion that this may indeed be more dangerous >> than a classical 51% attack, in which an attacker can only doublespend >> funds that she had control over at some point during the attack >> (duration being defined as the period she can build a hidden fork of). I >> think the case for Lightning is not more dangerous since what they could >> do is enforce an old state in which they had a higher balance than in >> the final state, without incurring in a penalty. The key observation is >> that in this old state they actually had to have the balance they are >> stealing on the channel. So this maps directly to the classical >> scenario in which an attacker simply doublespends funds they had control >> over during the attack, making the attack pretty much the same. >> >> Another interesting observation is that with Lightning the state that >> the attacker is enforcing may predate the attack, e.g., an attacker >> could use a state that existed and was replaced before it started >> generating its fork. This is in contrast to the classical doublespend >> attack in which invalidated spends have to happen after the fork >> started, and the attacker just filters them from its fork. >> >> But as I said before, if we can't count on there not being a 51% >> attacker, then things are pretty much broken anyway :-) >> >> Cheers, >> Christian >> >> Ren? Pickhardt via Lightning-dev >> writes: >> > Hey everyone, >> > >> > disclaimer: as mentioned in my other mail ( >> > https://lists.linuxfoundation.org/pipermail/lightning-dev/ >> 2018-March/001065.html >> > ) I am currently studying the revocation system of duplex micropayment >> > channels in detail but I am also pretty new to the topic. So I hope the >> > attack I am about to describe is not possible and it is just me >> overseeing >> > some detail or rather my lack of understanding. >> > That being said even after waiting one week upon discovery and double >> > checking the assumptions I made I am still positive that the revocation >> > system in its current form allows for a new form of a 51% attack. This >> > attack seems to be way more harmful than a successful 51% attack on the >> > bitcoin network. Afaik within the bitcoin network I could 'only double >> > spend' my own funds with a successful 51% attack. In the lightning case >> it >> > seems that an attacker could steal an arbitrary amount of funds as long >> as >> > the attacker has enough payment channels with enough balance open. >> > >> > The attack itself follows exactly the philosophy of lightning: "If a tree >> > falls in the forest and no one is around to hear it. Does it make a >> sound?" >> > In the context of the attack this would translate to: "If a 51% attacker >> > secretly mines enough blocks after fraudulently spending old commitment >> > transactions and no one sees it during the the *to_self_delay* period, >> > have the commitment transactions been spent? (How) Can they be revoked?" >> > >> > >> > As for the technical details I quote from the spec of BOLT 3: >> > "*To allow an opportunity for penalty transactions, in case of a revoked >> > commitment transaction, all outputs that return funds to the owner of the >> > commitment transaction (a.k.a. the "local node") must be delayed for * >> > *to_self_delay** blocks. This delay is done in a second-stage HTLC >> > transaction (HTLC-success for HTLCs accepted by the local node, >> > HTLC-timeout for HTLCs offered by the local node)*" >> > >> > Assume an attacker has 51% of the hash power she could open several >> > lightning channels and in particular accept any incoming payment channel >> > (the more balance is in her channels the more lucrative the 51% attack). >> > Since the attacker already has a lot of hash power it is reasonable (but >> > not necessary) to assume that the attacker already has a lot of bitcoins >> > and is well known to honest nodes in the network which makes it even more >> > likely to have many open channels. >> > >> > The attacker keeps track of her (revocable) commitment transactions in >> > which the balance is mostly on the attackers side. Once the attacker >> knows >> > enough of these (old) commitment transactions the attack is being >> executed >> > in the following way: >> > 0.) The max value of to_self_delay is evaluated. Let us assume it is 72 >> > blocks (or half a day). >> > 1.) The attacker secretly starts mining on her own but does not >> broadcasts >> > any successfully mined block. Since the attacker has 51% of the hash >> power >> > she will most likely be faster than the network to mine the 72 blocks of >> > the safety period in which fraudulent commitment transactions could be >> > revoked. >> > 2.) The attacker spends all the fraudulent (old) commitment transactions >> in >> > the first block of her secrete mining endeavor. >> > 3.) Meanwhile the attacker starts spending her own funds of her payment >> > channels e.g on decentralized exchanges for any other (crypto)currency. >> > 4.) As soon as the attacker has mined enough blocks that the commitment >> > transactions cannot be revoked she broadcasts her secretly minded >> > blockchain which will be accepted by the network as it is the longest >> > chain. (In Particular she includes all the other bitcoin transactions >> that >> > are also in the original public blockchain so that other people don't >> even >> > realize something suspicious has happened.) >> > >> > Since according to the spec channels should never be balanced worse than >> > 99% to 1% the attacker could steal up to 99% of all the bitcoins >> allocated >> > in the sum of all payment channels the attacker was connected to. This >> > amount could obviously be way higher than just double spending her own >> > funds. This attack would be interesting in particular for the power nodes >> > created by the Barabasi-Albert model of lnd's autopilot (c.f.: >> > https://github.com/lightningnetwork/lnd/issues/677 ). >> > >> > I understand that with the growth of the bitcoin (mining) network a 51% >> > attack becomes less and less likely. Also I am very happy to be proven >> > false about the attack that I am describing. >> > >> > Another sad thing about this attack is that I currently do not see any >> > (reasonable) way of preventing this form of a 51% attack (other than >> > creating payment channels that don't offer the possibility of revocation) >> > as it is abusing exactly the core idea of lightning to do something in >> > secret without broadcasting it. >> > >> > Best regards Rene >> > >> > --- >> > >> > http://www.rene-pickhardt.de >> > _______________________________________________ >> > Lightning-dev mailing list >> > Lightning-dev at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > > > > -- > www.rene-pickhardt.de > > > Skype: rene.pickhardt > > mobile: +49 (0)176 5762 3618 From ZmnSCPxj at protonmail.com Wed Mar 14 03:46:11 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Tue, 13 Mar 2018 23:46:11 -0400 Subject: [Lightning-dev] New form of 51% attack via lightning's revocation system possible? In-Reply-To: References: Message-ID: Good morning Rene, The attack is possible but requires the combination of the below: 1. A large 51% miner. 2. Many channels share-owned by the miner. 3. Large capacities in each channel share-owned by the miner. Individual nodes can protect against these as below: 1. Contributing hashpower to a decentralized mining aggregator (e.g. P2Pool). 2.1. Disallow more than n channels with a single node, with small n (ideally 1 as c-lightning does). 2.2. Insist on a blocksize limit. 3. Limit capacities per channel (e.g. 167.77215mBTC max capacity). Against protection #2.1 the attacker can run many nodes, but each node at least consumes some resource that could have been used for e.g. hashing. Against protection #3 the attacker can do nothing; if one side refuses to make larger than 167.77215 mBTC, the channel cannot be established. The blocksize limit is important since the number of channels that can be stolen in a single block is bounded by the blocksize. In combination with channel capacity limit, this increases the number of blocks needed to secretly mine to complete the attack. * If we impose a limit of 167.77216mBTC per channel, we need 6 channels to steal 1BTC. * To steal 1M BTC we need 6 million channels, which cannot fit in a block. * About 2000 transactions can fit in a block so that is 2000 channels closed per block. * To close 6 million channels you need to secretly mine 3000 blocks, which is about 20 days. Note that this only *closes* the channels: you also need to claim the commitment transactions, which is another 3000 blocks (an additional 20 or so days). Thus the block size limit and the channel capacity limit are vital protections against this attack. Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ??????? Original Message ??????? On March 13, 2018 9:30 PM, Ren? Pickhardt via Lightning-dev wrote: > Hey everyone, > > disclaimer: as mentioned in my other mail ( https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001065.html ) I am currently studying the revocation system of duplex micropayment channels in detail but I am also pretty new to the topic. So I hope the attack I am about to describe is not possible and it is just me overseeing some detail or rather my lack of understanding. > That being said even after waiting one week upon discovery and double checking the assumptions I made I am still positive that the revocation system in its current form allows for a new form of a 51% attack. This attack seems to be way more harmful than a successful 51% attack on the bitcoin network. Afaik within the bitcoin network I could 'only double spend' my own funds with a successful 51% attack. In the lightning case it seems that an attacker could steal an arbitrary amount of funds as long as the attacker has enough payment channels with enough balance open. > > The attack itself follows exactly the philosophy of lightning: "If a tree falls in the forest and no one is around to hear it. Does it make a sound?" > In the context of the attack this would translate to: "If a 51% attacker secretly mines enough blocks after fraudulently spending old commitment transactions and no one sees it during the the to_self_delay period, have the commitment transactions been spent? (How) Can they be revoked?" > > As for the technical details I quote from the spec of BOLT 3: > "To allow an opportunity for penalty transactions, in case of a revoked commitment transaction, all outputs that return funds to the owner of the commitment transaction (a.k.a. the "local node") must be delayed for to_self_delay blocks. This delay is done in a second-stage HTLC transaction (HTLC-success for HTLCs accepted by the local node, HTLC-timeout for HTLCs offered by the local node)" > > Assume an attacker has 51% of the hash power she could open several lightning channels and in particular accept any incoming payment channel (the more balance is in her channels the more lucrative the 51% attack). Since the attacker already has a lot of hash power it is reasonable (but not necessary) to assume that the attacker already has a lot of bitcoins and is well known to honest nodes in the network which makes it even more likely to have many open channels. > > The attacker keeps track of her (revocable) commitment transactions in which the balance is mostly on the attackers side. Once the attacker knows enough of these (old) commitment transactions the attack is being executed in the following way: > 0.) The max value of to_self_delay is evaluated. Let us assume it is 72 blocks (or half a day). > 1.) The attacker secretly starts mining on her own but does not broadcasts any successfully mined block. Since the attacker has 51% of the hash power she will most likely be faster than the network to mine the 72 blocks of the safety period in which fraudulent commitment transactions could be revoked. > 2.) The attacker spends all the fraudulent (old) commitment transactions in the first block of her secrete mining endeavor. > 3.) Meanwhile the attacker starts spending her own funds of her payment channels e.g on decentralized exchanges for any other (crypto)currency. > 4.) As soon as the attacker has mined enough blocks that the commitment transactions cannot be revoked she broadcasts her secretly minded blockchain which will be accepted by the network as it is the longest chain. (In Particular she includes all the other bitcoin transactions that are also in the original public blockchain so that other people don't even realize something suspicious has happened.) > > Since according to the spec channels should never be balanced worse than 99% to 1% the attacker could steal up to 99% of all the bitcoins allocated in the sum of all payment channels the attacker was connected to. This amount could obviously be way higher than just double spending her own funds. This attack would be interesting in particular for the power nodes created by the Barabasi-Albert model of lnd's autopilot (c.f.: https://github.com/lightningnetwork/lnd/issues/677 ). > > I understand that with the growth of the bitcoin (mining) network a 51% attack becomes less and less likely. Also I am very happy to be proven false about the attack that I am describing. > > Another sad thing about this attack is that I currently do not see any (reasonable) way of preventing this form of a 51% attack (other than creating payment channels that don't offer the possibility of revocation) as it is abusing exactly the core idea of lightning to do something in secret without broadcasting it. > > Best regards Rene > > --- > > http://www.rene-pickhardt.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From TSteenholdt at cascadetechnologypartners.com Wed Mar 14 17:45:07 2018 From: TSteenholdt at cascadetechnologypartners.com (Thomas Steenholdt) Date: Wed, 14 Mar 2018 17:45:07 +0000 Subject: [Lightning-dev] DNS Seed query semantics clarification Message-ID: Hi there, I'm trying to understand the DNS seeds described by BOLT10, but seem to be missing something regarding the query semantics. The BOLT states that the DNS seed must support a list of key-value pairs, but it's unclear to me how these pairs are used in a query. Are they encoded into the fqdn used in the query or something entirely different? Any pointers? /Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From corne at bitonic.nl Thu Mar 15 14:29:30 2018 From: corne at bitonic.nl (=?UTF-8?Q?Corn=c3=a9_Plooy?=) Date: Thu, 15 Mar 2018 15:29:30 +0100 Subject: [Lightning-dev] A protocol for requesting invoices In-Reply-To: References: Message-ID: <343b5029-476a-894a-571b-8d5b36fd284b@bitonic.nl> Hi? ZmnSCPxj, Thanks for the links. I've done a bit of reading, and this seems to be the clearest explanation of what the Web Payments Working Group wants to achieve: https://www.w3.org/TR/webpayments-overview/ But maybe Christian can give better / more up-to-date info. From what I can see, their concept is still very much focused on non-recurring purchases, and then especially on websites. In other words: the typical web shop use case. The site linked above does however contain the following text: "A concern has been raised over the structure of a payment request, notably that there are other forms of messages that may be initiated by a payer. There is currently a proposal to modify payment request to a more generalized "payment instruction" that would be capable of expressing other messages like subscriptions, preauthorizations, refunds, and other sorts of payment-related instructions." So it seems they're thinking about it, but there is no consensus or standardization yet. The important question: should we wait for this? How long is this going to take? How bad would it be to first push forward some simple version of BOLT 12? CJP PS. Quote of the day: "Some aspects of bitcoin are less useful, however. It is currently impossible to set up recurring payments with the currency, making it impractical for subscriptions that renew on a short term basis." Op 09-03-18 om 05:28 schreef ZmnSCPxj: > Good morning Corne, > > You mention URLs in your draft. This made me remember about the Web Payments Working Group of W3C, https://www.w3.org/Payments/WG/ , of which Decker, Christian of Blockstream is a member: https://www.w3.org/2000/09/dbwg/details?group=83744&public=1 > > My understanding is that Christian aims to make Bitcoin payments (and possibly Lightning invoice payments?) payable over Web payment protocols that W3C group is working on. > > Possibly the Web Payments Working Group may provide better perspective on various other payment use cases as well as their subtleties, which can help inform your considerations in your proposed BOLT12. > > Regards, > ZmnSCPxj > > > ?Sent with ProtonMail Secure Email.? > > ??????? Original Message ??????? > > On March 8, 2018 11:19 PM, Corn? Plooy via Lightning-dev wrote: > >> Hi, >> >> I was thinking of how to use Lightning for various types of payments, >> >> and I think it's currently fine for customer/(web)shop type >> >> interactions, but it seems a bit inconvenient for other use cases, e.g. >> >> salary payments or direct pay-out of cryptocurrency bought on an >> >> exchange. I came up with an idea that addresses some of these issues and >> >> more (e.g. payee anonymity) by having a direct line of communication >> >> between payer and payee instead of BOLT11-style interaction. It's still >> >> a bit half-baked, with many details not worked out yet, but you can read >> >> it here, and see if you like where this is going: >> >> https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md >> >> In true permissionless fashion, I have been so bolD to register bolT #12 >> >> for my idea. >> >> Please let me know what you think. >> >> kind regards, >> >> CJP >> >> Lightning-dev mailing list >> >> Lightning-dev at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > From corne at bitonic.nl Thu Mar 15 15:48:32 2018 From: corne at bitonic.nl (=?UTF-8?Q?Corn=c3=a9_Plooy?=) Date: Thu, 15 Mar 2018 16:48:32 +0100 Subject: [Lightning-dev] A protocol for requesting invoices In-Reply-To: <5AA36A1E.5090909@AndySchroder.com> References: <5AA36A1E.5090909@AndySchroder.com> Message-ID: Hi Andy, 1. Don't confuse TOR onion routing (used for anonymous/pseudonymous communication) with Lightning onion routing (used for anonymous payments). TOR's design is outside the scope of the discussion; as far as I can see, TOR is only relevant because it exists, it works(*) and it is useful to us. The "partial onion route" is about Lightning's onion routing. You could consider the start of the partial route as an "introduction point"; it is selected by the payee(**). I'm not sure if it is exactly equivalent to TOR's introduction points though. 2. Good thinking. I guess that, since either payer *or* payee will decide on the amount, there is no use case for omitting the amount in an invoice in BOLT 12; unlike BOLT 11, it should not be optional here. So that's not a problem for the partial onion route. Unknown capacity is an issue, and I guess it's worse than if the payer is completely free to choose a route, because the payer is no longer completely free to choose alternative routes. Giving a batch of alternative routes is one concept (TBD: can they have the same payment hash?); giving new alternatives interactively is another option. I think using the same "introduction point" for all routes is best for privacy: otherwise the payer could determine the neighborhood of the payee. 3. True. Right now I'm thinking in the opposite direction: simplifying BOLT 12 by removing the possibility of refunds. We can always add it back later (with a proper set of features for all kinds of refunds) as an optional feature. 4. This depends on the use case. The URL contains an optional invoice ID. A payee can request a payment for a specific, single transaction (for a single instance of delivery of goods/services) by handing over an URL, including an invoice ID, to a single payer. This provides similar functionality as BOLT 11, except that you now have a well-defined channel for transmitting larger invoice descriptions and for using partial onion routes. A payee can also hand over an URL without invoice ID; this can be used and re-used by one or more payers, whenever they want to perform payments to this payee. Thanks for the questions; I think I can improve my proposal based on your feedback. What should I do with BOLT 12? Have it pulled in lightningnetwork/lightning-rfc; maybe in a separate branch? Or first work it out in more detail? How does lightningnetwork/lightning-rfc distinguish between drafts, finished agreed-on specs and things we decided we don't want? Is there even a consensus forming mechanism? CJP (*) to some degree; there are limits to the privacy provided by TOR. (**) when extending the current BOLT 12 draft a bit, it might also optionally be selected by the payer. Op 10-03-18 om 06:16 schreef Andy Schroder: > Hello Corn?, > > I'm glad to see that someone getting this kind of idea started. > > I'm still new to some of these topics, but I have a few comments. > Hopefully I'm not wasting your time if they are too rudimentary! > > 1. You mention that the payee gives a URL where the payer can then > connect to to request invoices. You mention that this can be a tor > hidden service if the payee needs to remain private. You also > suggest that the payee can remain private by "payee can send an > invoice to payer which has a partial onion route as destination > instead of a node ID". I was reading about tor hidden services > (https://www.torproject.org/docs/onion-services.html.en), and they > require an introduction point, and a rendezvous point. Do we not > need this two step process for the payment route, because we > already have communication initiated over the anonymous > communication channel, and the beginning of the partial onion > route is not publicly available information, and can change with > every invoice? > 2. What happens if the capacity of the partial onion route is no > longer sufficient when the payer is ready to pay? Is there a way > to provide a few routes just in case? Or, in the case where no > amount is specified, how is the partial onion route possible if we > don't even know how much capacity may be needed? > 3. You say the refund should invalidate the proof of payment of the > initial transaction. What about partial refunds? I think there are > a lot of applications where there would be a partial refund. > 4. You say "this BOLT specifies a protocol where payee gives a URL to > one or more potential payers". How does the payer identify itself > to the payee so that the payee knows what goods or services that > they want an invoice for? Do they send this after making the > connection, or is it part of the URL? > > > > > Andy Schroder > On 03/08/2018 10:19 AM, Corn? Plooy via Lightning-dev wrote: >> Hi, >> >> I was thinking of how to use Lightning for various types of payments, >> and I think it's currently fine for customer/(web)shop type >> interactions, but it seems a bit inconvenient for other use cases, e.g. >> salary payments or direct pay-out of cryptocurrency bought on an >> exchange. I came up with an idea that addresses some of these issues and >> more (e.g. payee anonymity) by having a direct line of communication >> between payer and payee instead of BOLT11-style interaction. It's still >> a bit half-baked, with many details not worked out yet, but you can read >> it here, and see if you like where this is going: >> >> >> https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md >> >> >> In true permissionless fashion, I have been so bolD to register bolT #12 >> for my idea. >> >> >> Please let me know what you think. >> >> kind regards, >> >> CJP >> >> >> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > From ZmnSCPxj at protonmail.com Fri Mar 16 00:31:28 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Thu, 15 Mar 2018 20:31:28 -0400 Subject: [Lightning-dev] A protocol for requesting invoices In-Reply-To: References: <5AA36A1E.5090909@AndySchroder.com> Message-ID: Good morning Corne, > routing. You could consider the start of the partial route as an > > "introduction point"; it is selected by the payee(**). I'm not sure if > > it is exactly equivalent to TOR's introduction points though. It is almost equivalent I think. > > 2. Good thinking. I guess that, since either payer or payee will > > decide on the amount, there is no use case for omitting the amount in an > > invoice in BOLT 12; unlike BOLT 11, it should not be optional here. So > > that's not a problem for the partial onion route. Unknown capacity is an > > issue, and I guess it's worse than if the payer is completely free to > > choose a route, because the payer is no longer completely free to choose > > alternative routes. Giving a batch of alternative routes is one concept > > (TBD: can they have the same payment hash?); Yes. When we retry failing routes, we reuse the payment hash until we succeed to pay, or, give up paying. This is simply the same concept. > giving new alternatives > > interactively is another option. I think using the same "introduction > > point" for all routes is best for privacy: otherwise the payer could > > determine the neighborhood of the payee. I wonder. How does the payer contact the payee in the first place, without having located the neighborhood of the payee? If it is via some TOR hidden service, and the payee considers this enough protection, why cannot the same TOR hidden service be used as the address of the LN node of the payee (LN protocol spec allows this, current implementations not so much)? Freenet or I2P, I suppose? > > 3. True. Right now I'm thinking in the opposite direction: simplifying > > BOLT 12 by removing the possibility of refunds. We can always add it > > back later (with a proper set of features for all kinds of refunds) as > > an optional feature. > > 4. This depends on the use case. The URL contains an optional invoice > > ID. A payee can request a payment for a specific, single transaction > > (for a single instance of delivery of goods/services) by handing over an > > URL, including an invoice ID, to a single payer. This provides similar > > functionality as BOLT 11, except that you now have a well-defined > > channel for transmitting larger invoice descriptions and for using > > partial onion routes. A payee can also hand over an URL without invoice > > ID; this can be used and re-used by one or more payers, whenever they > > want to perform payments to this payee. How does the payer derive the payment hash? Or does the payer have to contact the payee again to get a fresh payment hash specifically for the payer? Regards, ZmnSCPxj From ZmnSCPxj at protonmail.com Fri Mar 16 01:53:28 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Thu, 15 Mar 2018 21:53:28 -0400 Subject: [Lightning-dev] Cyclic Superhubs Message-ID: Good morning list, For your amusement. https://zmnscpxj.github.io/offchain/cyclicsuperhubs.html Regards, ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at AndySchroder.com Fri Mar 16 04:11:31 2018 From: info at AndySchroder.com (Andy Schroder) Date: Fri, 16 Mar 2018 00:11:31 -0400 Subject: [Lightning-dev] A protocol for requesting invoices In-Reply-To: References: <5AA36A1E.5090909@AndySchroder.com> Message-ID: Andy Schroder On 03/15/2018 08:31 PM, ZmnSCPxj wrote: > Good morning Corne, > >> routing. You could consider the start of the partial route as an >> >> "introduction point"; it is selected by the payee(**). I'm not sure if >> >> it is exactly equivalent to TOR's introduction points though. > It is almost equivalent I think. I've been thinking, and start of the payment route has properties of both an introduction point and rendezvous point. The introduction point is chosen by the TOR hidden service, and in this case, the start point is chosen by the lightning payee (which is hidden if they are operating over TOR). The TOR rendezvous point is not known to the public (only the client and the hidden service), and in this case, the start point of the payment route is also not known by the public (only the payer and the payee if they are operating over TOR to communicate). > >> >> 2. Good thinking. I guess that, since either payer or payee will >> >> decide on the amount, there is no use case for omitting the amount in an >> >> invoice in BOLT 12; unlike BOLT 11, it should not be optional here. So >> >> that's not a problem for the partial onion route. Unknown capacity is an >> >> issue, and I guess it's worse than if the payer is completely free to >> >> choose a route, because the payer is no longer completely free to choose >> >> alternative routes. Giving a batch of alternative routes is one concept >> >> (TBD: can they have the same payment hash?); > Yes. When we retry failing routes, we reuse the payment hash until we succeed to pay, or, give up paying. This is simply the same concept. What about enforcing a maximum payment amount that can be refunded? Can this help make the amount not a requirement? This way the payment amount will still be open to the payer, but it will have a constraint. > >> giving new alternatives >> >> interactively is another option. I think using the same "introduction >> >> point" for all routes is best for privacy: otherwise the payer could >> >> determine the neighborhood of the payee. > I wonder. How does the payer contact the payee in the first place, without having located the neighborhood of the payee? If it is via some TOR hidden service, and the payee considers this enough protection, why cannot the same TOR hidden service be used as the address of the LN node of the payee (LN protocol spec allows this, current implementations not so much)? Freenet or I2P, I suppose? You're saying that a .onion address is really a public key, so their is no reason to include both a public key and a host name? > >> >> 3. True. Right now I'm thinking in the opposite direction: simplifying >> >> BOLT 12 by removing the possibility of refunds. We can always add it >> >> back later (with a proper set of features for all kinds of refunds) as >> >> an optional feature. I want my refund :-) ! http://andyschroder.com/BitcoinVendingDevices/ Rusty already suggested that a return onion be supplied for refunds, but I'm not sure if he was talking about a partial onion, or a complete onion, because that discussion was for the case where the original payment was sent directly to a non-anonymous payee. I think in this case though, were a partial onion route is supplied for the initial payment, the refund payment onion route would have to be a partial one. All return onions still have the same problem of capacity though. >> >> 4. This depends on the use case. The URL contains an optional invoice >> >> ID. A payee can request a payment for a specific, single transaction >> >> (for a single instance of delivery of goods/services) by handing over an >> >> URL, including an invoice ID, to a single payer. This provides similar >> >> functionality as BOLT 11, except that you now have a well-defined >> >> channel for transmitting larger invoice descriptions and for using >> >> partial onion routes. A payee can also hand over an URL without invoice >> >> ID; this can be used and re-used by one or more payers, whenever they >> >> want to perform payments to this payee. > How does the payer derive the payment hash? Or does the payer have to contact the payee again to get a fresh payment hash specifically for the payer? > > Regards, > ZmnSCPxj > From ZmnSCPxj at protonmail.com Fri Mar 16 10:56:36 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Fri, 16 Mar 2018 06:56:36 -0400 Subject: [Lightning-dev] A protocol for requesting invoices In-Reply-To: References: <5AA36A1E.5090909@AndySchroder.com> Message-ID: Good morning Andy, > > > giving new alternatives > > > > > > interactively is another option. I think using the same "introduction > > > > > > point" for all routes is best for privacy: otherwise the payer could > > > > > > determine the neighborhood of the payee. > > > > > > > I wonder. How does the payer contact the payee in the first place, without having located the neighborhood of the payee? If it is via some TOR hidden service, and the payee considers this enough protection, why cannot the same TOR hidden service be used as the address of the LN node of the payee (LN protocol spec allows this, current implementations not so much)? Freenet or I2P, I suppose? > > You're saying that a .onion address is really a public key, so their is > > no reason to include both a public key and a host name? It is a public key hash, yes. But what I refer to is that the payee-determined route section, which starts from an introduction point, protects the payee from being located by the payer, but how did the payer contact the payee in the first place anyway? If it was by IP or non-.onion hostname, then the payee has been already located and there is no point in hiding from the payer. If it was by .onion hostname, then the payee security is bounded by the security of TOR, so it is no more secure for the payee to simply run its LN node on the same .onion address (which LN spec supports) and provide the public key of its LN node. Note that onion routing on LN in general protects the payer and the payee from being known easily by intermediate hop nodes, and this is the sole intent of onion routing for now. Presumably the payer knows how to contact the payee (else how would it form a connection to the payee in order to make an interactive request for invoice?). Presumably if the payee is a merchant, it knows how to send its product to the payer (and thus would know details like the physical address of the payer). And so on. The payee-determined route that starts from the introduction point protects the payee from the payer, but does it indeed increase the security or is there some other way to locate the payee anyway? Regards, ZmnSCPxj From decker.christian at gmail.com Fri Mar 16 12:37:17 2018 From: decker.christian at gmail.com (Christian Decker) Date: Fri, 16 Mar 2018 13:37:17 +0100 Subject: [Lightning-dev] DNS Seed query semantics clarification In-Reply-To: References: Message-ID: <874llgyz5u.fsf@gmail.com> Hi Thomas, indeed the spec is a bit vague on the flags. The intent is to use them as subdomains. For example if you want to query for only realm IPv4 nodes then you'd use the following: dig a2.seed.bitcoinstats.com while IPv4 or IPv6 nodes, but only nodes with realm 0, should be returned to the following: dig r0.a6.seed.bitcoinstats.com Notice however that I haven't implemented the query filtering itself just yet. Cheers, Christian Thomas Steenholdt writes: > Hi there, > > > I'm trying to understand the DNS seeds described by BOLT10, but seem to be missing something regarding the query semantics. > > > The BOLT states that the DNS seed must support a list of key-value pairs, but it's unclear to me how these pairs are used in a query. Are they encoded into the fqdn used in the query or something entirely different? > > > Any pointers? > > > /Thomas From TSteenholdt at cascadetechnologypartners.com Fri Mar 16 13:06:28 2018 From: TSteenholdt at cascadetechnologypartners.com (Thomas Steenholdt) Date: Fri, 16 Mar 2018 13:06:28 +0000 Subject: [Lightning-dev] DNS Seed query semantics clarification In-Reply-To: <874llgyz5u.fsf@gmail.com> References: , <874llgyz5u.fsf@gmail.com> Message-ID: Hi Christian, Thanks for the explanation - This was exactly the the piece of the puzzle I was missing. ? I'd be happy to help clarify this in the BOLT10 specification, if that makes any type of sense? I can make a pull request for review? /Thomas ________________________________ From: Christian Decker Sent: Friday, March 16, 2018 9:37:17 AM To: Thomas Steenholdt Cc: lightning-dev at lists.linuxfoundation.org Subject: Re: DNS Seed query semantics clarification Hi Thomas, indeed the spec is a bit vague on the flags. The intent is to use them as subdomains. For example if you want to query for only realm IPv4 nodes then you'd use the following: dig a2.seed.bitcoinstats.com while IPv4 or IPv6 nodes, but only nodes with realm 0, should be returned to the following: dig r0.a6.seed.bitcoinstats.com Notice however that I haven't implemented the query filtering itself just yet. Cheers, Christian Thomas Steenholdt writes: > Hi there, > > > I'm trying to understand the DNS seeds described by BOLT10, but seem to be missing something regarding the query semantics. > > > The BOLT states that the DNS seed must support a list of key-value pairs, but it's unclear to me how these pairs are used in a query. Are they encoded into the fqdn used in the query or something entirely different? > > > Any pointers? > > > /Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ablacktshirt at gmail.com Sat Mar 17 09:02:39 2018 From: ablacktshirt at gmail.com (Yubin Ruan) Date: Sat, 17 Mar 2018 17:02:39 +0800 Subject: [Lightning-dev] Can I try Lightning without running a fully-fledged bitcoin block chain? Message-ID: <20180317090238.GC5074@HP> I just don't have so much space for a storing the whole blockchain on my laptop. Yubin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From aleksej at spidermail.tk Sat Mar 17 12:59:39 2018 From: aleksej at spidermail.tk (Aleksej) Date: Sat, 17 Mar 2018 13:59:39 +0100 Subject: [Lightning-dev] Can I try Lightning without running a fully-fledged bitcoin block chain? In-Reply-To: <20180317090238.GC5074@HP> References: <20180317090238.GC5074@HP> Message-ID: I don't see why running a pruning node wouldn't work. You might want to try that. Aleksej On Sat, 2018-03-17 at 17:02 +0800, Yubin Ruan wrote: > I just don't have so much space for a storing the whole blockchain on > my > laptop. > > Yubin > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev From ZmnSCPxj at protonmail.com Sun Mar 18 04:57:04 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Sun, 18 Mar 2018 00:57:04 -0400 Subject: [Lightning-dev] Can I try Lightning without running a fully-fledged bitcoin block chain? In-Reply-To: References: <20180317090238.GC5074@HP> Message-ID: Good morning Aleksej and Yubin, C-lightning is currently known to NOT work with a pruning bitcoind. lnd has a neutrino mode which is a SPV mode, but neutrino protocol to my knowledge is not in official bitcoind yet (but I have not checked, possibly I am wrong), so you will need to peer with neutrino-supporting bitcoin peer. Regards, ZmnSCPxj ?Sent with ProtonMail Secure Email.? ??????? Original Message ??????? On March 17, 2018 8:59 PM, Aleksej wrote: > I don't see why running a pruning node wouldn't work. > > You might want to try that. > > Aleksej > > On Sat, 2018-03-17 at 17:02 +0800, Yubin Ruan wrote: > > > I just don't have so much space for a storing the whole blockchain on > > > > my > > > > laptop. > > > > Yubin > > > > Lightning-dev mailing list > > > > Lightning-dev at lists.linuxfoundation.org > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > Lightning-dev mailing list > > Lightning-dev at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev From TSteenholdt at cascadetechnologypartners.com Sun Mar 18 22:24:07 2018 From: TSteenholdt at cascadetechnologypartners.com (Thomas Steenholdt) Date: Sun, 18 Mar 2018 22:24:07 +0000 Subject: [Lightning-dev] High level fee mechanics Message-ID: Hi, I've been trying to figure out the mechanics of Lightning fees, especially in the case of routed payments. Unfortunately, I haven't had any success in finding a high level description on the topic. I'm hoping somebody is able to point me in the right direction? Example: A multi-hop routed payment where A needs to pay D through B and C. Established channels are A -> B -> C -> D. What I'm looking for is a high level explanation of how fees are established, announced and ultimately claimed in a payment like this. Some of the questions that come to mind are: - Does A know ahead of time the fees on B and C, or only when trying to set up the payment? And how? - How does A know the amount of fees that need to be added to the payment to cover all fees? - Is D aware of the full amount including fees or is that somehow hidden? - How are the fees actually claimed (who ends up paying whom)? Thanks in advance. /Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ZmnSCPxj at protonmail.com Sun Mar 18 23:48:57 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Sun, 18 Mar 2018 19:48:57 -0400 Subject: [Lightning-dev] High level fee mechanics In-Reply-To: References: Message-ID: Good morning Thomas, Sent with [ProtonMail](https://protonmail.com) Secure Email. ??????? Original Message ??????? On March 19, 2018 6:24 AM, Thomas Steenholdt wrote: > Hi, > > I've been trying to figure out the mechanics of Lightning fees, especially in the case of routed payments. Unfortunately, I haven't had any success in finding a high level description on the topic. > > I'm hoping somebody is able to point me in the right direction? BOLT spec https://github.com/lightningnetwork/lightning-rfc contains everything, but is very detailed and contains the topic in multiple places. > Example: > > A multi-hop routed payment where A needs to pay D through B and C. Established channels are A -> B -> C -> D. > > What I'm looking for is a high level explanation of how fees are established, announced and ultimately claimed in a payment like this. Some of the questions that come to mind are: > > - Does A know ahead of time the fees on B and C, or only when trying to set up the payment? And how? Yes. Node gossip, the `channel_update` message in BOLT#7. This message, contains `fee_base_msat` and `fee_proportional_millionths`. For each channel, there are two `channel_update` messages, one from each direction. For example B<->C channel, B announces its fee for B->C transfers while C announnces its fee for C->B transfers. The A may have obsolete information about fees (e.g. B or C change their fee but their `channel_update` has not propagated to A yet). In this case, payment routing will fail, but the `channel_update` will also be sent as part of the error message returned by payment routing failure. > - How does A know the amount of fees that need to be added to the payment to cover all fees? It computes it. If D is to be given a payment with value `msatoshi` then it computes first the C->D fee, which is the C->D `fee_base_msat` + (C->D `fee_proportion_millionts` * `msatoshi` / 1,000,000). Add that to `msatoshi` and that is the payment that needs to reach C, so A computes the payment from B->C similarly, except the `msatoshi` is replaced with the payment that should reach C. Then A knows how much it has to give to B. > - Is D aware of the full amount including fees or is that somehow hidden? No. D is only aware of how much C offers it. > - How are the fees actually claimed (who ends up paying whom)? A offer B a value that is higher than what A instruct B to forward to C. The difference is the fee. Since the highest value is at the source A, A is the one, who ends up paying the entire fee. Regards, ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: From ZmnSCPxj at protonmail.com Mon Mar 19 00:25:13 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Sun, 18 Mar 2018 20:25:13 -0400 Subject: [Lightning-dev] AMP via HD, BN+SS, and TR Message-ID: Good morning list, I sketch here the idea, of making atomic multipath payment (AMP), with the properties: 1. Has a proof-of-payment. 2. Multipath decorrelation. Note: I am not a mathematician. Thus, it is likely, that there is a mistake here, and we cannot make this work. First, we look at BIP32 hierarchically derived (HD) keys by Wuille. Roughly, given a parent private key k_par, we can do derive k_i child keys for integer i by: k_i = H(i || k_par * G) + k_par where H(x) is a hash function and G is the generator point. (this it not quite how BIP32 does it, it uses HMAC, maybe that is safer for some reason that my non-mathematician self is unaware of...) The parent public key K_par = k_par * G. We can derive K_i public child keys for integer i by: K_i = H(i || K_par) * G + K_par (I think) Note that K_i = k_i * G still, as is usual for elliptic curve asymmetric cryptography: K_i = k_i * G = (H(i || k_par * G) + k_par) * G = H(i || k_par * G) * G + k_par * G = H(i || K_par) * G + K_par Of note is that if we know an i, a private child key k_i corresponding to that i, and the public parent key K_par, we can derive the private parent key k_par: k_i = H(i || K_par) + k_par k_par = k_i - H(i || K_par) Now all we need is to have a conditional payment, which can only be performed if the payee provides a private key which matches a public key, i.e. given x * G, the payee must provide x. Fortunately Poelstra has done this work beforehand in the Scriptless Script (SS) concept, where the payee provides a T = t * G, and the Scriptless Script construction requires that the payee reveal the t in order to claim the payment. I will not go into the math since there is a good chance I shall make a mistake; look up discussions by better mathematicians by me. Scriptless Script requires Bellare-Neven (BN) signatures to work. Note that Scriptless Script handles only the equivalent of hashlocking. We still need a timelock in case the payee refuses to reveal the proof-of-payment t. Fortunately, Maxwell has provided a construction, taproot (TR). This construction has two top-level branches: a Bellare-Neven n-of-n, or a Bitcoin Script. We know that Scriptless Script can make an equivalent to a hashlock from a Bellare-Neven n-of-n. The other branch of a taproot construction can now be a simple OP_CLTV+OP_CHECKSIG script, forming the timelock half of an HTLC. How would a multipath payment work? The invoice would contain the parent public key K_par. From this, the payer derives as many K_i, as it needs to split the payment to. It sets up conditional payments that require revelation of the private child key k_i for each K_i it derives. When the payee receives a partial payment, it is not incentivized to claim it immediately yet. This is because revelation of even one child key k_i will, in combination with the parent public key K_par, reveal the parent private key k_par, which serves as proof-of-payment. The payee will wait for the entire payment to reach it, and then claim all of them. This reveals all the private child keys k_i, any one of which will let the payer extract the parent private key k_par that serves as proof-of-payment. Each path has a different k_i, thus providing multipath decorrelation. (Please check my math --- I am not a mathematician and it is possible I have made a mistake somewhere) Regards, ZmnSCPXj -------------- next part -------------- An HTML attachment was scrubbed... URL: From TSteenholdt at cascadetechnologypartners.com Mon Mar 19 11:30:35 2018 From: TSteenholdt at cascadetechnologypartners.com (Thomas Steenholdt) Date: Mon, 19 Mar 2018 11:30:35 +0000 Subject: [Lightning-dev] High level fee mechanics In-Reply-To: References: , Message-ID: Hi ZmnSCPxj, Thank you so much - Exactly what I needed! ? /Thomas ________________________________ From: ZmnSCPxj Sent: Sunday, March 18, 2018 8:48:57 PM To: Thomas Steenholdt Cc: lightning-dev at lists.linuxfoundation.org Subject: Re: [Lightning-dev] High level fee mechanics Good morning Thomas, Sent with ProtonMail Secure Email. ??????? Original Message ??????? On March 19, 2018 6:24 AM, Thomas Steenholdt wrote: Hi, I've been trying to figure out the mechanics of Lightning fees, especially in the case of routed payments. Unfortunately, I haven't had any success in finding a high level description on the topic. I'm hoping somebody is able to point me in the right direction? BOLT spec https://github.com/lightningnetwork/lightning-rfc contains everything, but is very detailed and contains the topic in multiple places. Example: A multi-hop routed payment where A needs to pay D through B and C. Established channels are A -> B -> C -> D. What I'm looking for is a high level explanation of how fees are established, announced and ultimately claimed in a payment like this. Some of the questions that come to mind are: - Does A know ahead of time the fees on B and C, or only when trying to set up the payment? And how? Yes. Node gossip, the `channel_update` message in BOLT#7. This message, contains `fee_base_msat` and `fee_proportional_millionths`. For each channel, there are two `channel_update` messages, one from each direction. For example B<->C channel, B announces its fee for B->C transfers while C announnces its fee for C->B transfers. The A may have obsolete information about fees (e.g. B or C change their fee but their `channel_update` has not propagated to A yet). In this case, payment routing will fail, but the `channel_update` will also be sent as part of the error message returned by payment routing failure. - How does A know the amount of fees that need to be added to the payment to cover all fees? It computes it. If D is to be given a payment with value `msatoshi` then it computes first the C->D fee, which is the C->D `fee_base_msat` + (C->D `fee_proportion_millionts` * `msatoshi` / 1,000,000). Add that to `msatoshi` and that is the payment that needs to reach C, so A computes the payment from B->C similarly, except the `msatoshi` is replaced with the payment that should reach C. Then A knows how much it has to give to B. - Is D aware of the full amount including fees or is that somehow hidden? No. D is only aware of how much C offers it. - How are the fees actually claimed (who ends up paying whom)? A offer B a value that is higher than what A instruct B to forward to C. The difference is the fee. Since the highest value is at the source A, A is the one, who ends up paying the entire fee. Regards, ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: From corne at bitonic.nl Mon Mar 19 12:06:03 2018 From: corne at bitonic.nl (=?UTF-8?Q?Corn=c3=a9_Plooy?=) Date: Mon, 19 Mar 2018 13:06:03 +0100 Subject: [Lightning-dev] A protocol for requesting invoices In-Reply-To: References: <5AA36A1E.5090909@AndySchroder.com> Message-ID: > > What about enforcing a maximum payment amount that can be refunded? > Can this help make the amount not a requirement? This way the payment > amount will still be open to the payer, but it will have a constraint. I see no use case anymore for leaving out the amount in the invoice. For any type of transaction where the payer decides the amount, he can do so by specifying the amount in the invoice request. >>> ???? 3.? True. Right now I'm thinking in the opposite direction: >>> simplifying >>> ???? ???? BOLT 12 by removing the possibility of refunds. We can >>> always add it >>> ???? ???? back later (with a proper set of features for all kinds of >>> refunds) as >>> ???? ???? an optional feature. > > > I want my refund :-) ! I did some further thinking on refunds. Generally speaking, they are a solution for when Transactions Get Messy, right? You agreed to a transaction, the Lightning payment happened, but now you want to change something. That 'something' can be, for instance, a full refund (e.g. if goods cannot be delivered), a partial refund (e.g. if goods arrived later than agreed, or with inferior quality), an extra payment by the payer (e.g. cheaper model out of stock, decided to buy the more expensive one instead), or no payment at all (e.g. payer changes mind after the payment, and wants the black/blue model instead of the white/gold one, which has the same price). There is some similarity between a "BOLT 12" transaction that allows refunds and other updates, and a microtransaction channel. Specifically, I think you want the new state to be signed by whoever may possibly have a legitimate interest *against* the update, and you want the old state to be invalidated. In BOLT 12, to support this, a state should typically contain the description field, a field that invalidates the previous state, a field that specifies how this state can be invalidated, and optionally a payment hash(*), which indicates that this state update is valid only in combination with the corresponding preimage. A transaction starts in a "null" state (no obligations between participants), and ends specifying certain obligations that have been fulfilled. TBD: maybe returning to null state by signing off that all obligations have been fulfilled? E.g. payer signing off that ordered goods have been received. Note that this must be different from canceling the transaction, since you want the payer to keep some kind of proof of ownership. Anyway, I think returning to null state should not be required on BOLT12 protocol level: not everybody wants this. Some suppliers may want to require it though. Looking at the protocol for this (generalized) refund usage, it seems clear that, often, you don't want to have to keep the communication line open the entire time: it can take days, weeks or longer until the final settlement of a transaction. You should be able to reconnect (typically in the same direction as the initial connect) and say "hey, let's update the state of the transaction to this-or-that". So, on re-connecting, you also need to be able to specify *which* transaction to update. The format of the "description" field is unspecified for now; I think it's best to keep it that way. Machine-readable formats for this are a very complex subject, better solved at a higher level protocol. For now, assume it to be human-readable; maybe add a MIME type field so that its format is both unambiguous (technologically) and upgradeable. TBD: is there a use case for transactions between more than two parties? Or having smart contract (scriptless?) scripts? These would then typically be evaluated by a settlement service provider (e.g. the legal system) instead of a block chain. > All return onions still have the same problem of capacity though. A partial onion is a very generic solution. If capacity is your greatest concern as payee, you just supply a zero-hop partial onion. Minimum privacy, but maximum ability of the payer to construct a route over channels with sufficient capacity. The choice is yours. >>> ???? 4.? This depends on the use case. The URL contains an optional >>> invoice >>> ???? ???? ID. A payee can request a payment for a specific, single >>> transaction >>> ???? ???? (for a single instance of delivery of goods/services) by >>> handing over an >>> ???? ???? URL, including an invoice ID, to a single payer. This >>> provides similar >>> ???? ???? functionality as BOLT 11, except that you now have a >>> well-defined >>> ???? ???? channel for transmitting larger invoice descriptions and >>> for using >>> ???? ???? partial onion routes. A payee can also hand over an URL >>> without invoice >>> ???? ???? ID; this can be used and re-used by one or more payers, >>> whenever they >>> ???? ???? want to perform payments to this payee. >> How does the payer derive the payment hash? Or does the payer have to >> contact the payee again to get a fresh payment hash specifically for >> the payer? Contact the payee again. Or, more generally, one of them knows how to contact the other to propose updates to the agreement; if the payee of the update agrees, he will provide the payment hash. CJP (*) together with amount and timeout: these allow the payer to know under what conditions the payee is likely to release the preimage. From decker.christian at gmail.com Fri Mar 16 13:44:01 2018 From: decker.christian at gmail.com (Christian Decker) Date: Fri, 16 Mar 2018 14:44:01 +0100 Subject: [Lightning-dev] DNS Seed query semantics clarification In-Reply-To: References: <874llgyz5u.fsf@gmail.com> Message-ID: <87vadwxhi6.fsf@gmail.com> Thomas Steenholdt writes: > Thanks for the explanation - This was exactly the the piece of the > puzzle I was missing. ? > > I'd be happy to help clarify this in the BOLT10 specification, if that > makes any type of sense? I can make a pull request for revie Absolutely, improvements are always welcome :-) From corne at bitonic.nl Mon Mar 19 13:59:11 2018 From: corne at bitonic.nl (=?UTF-8?Q?Corn=c3=a9_Plooy?=) Date: Mon, 19 Mar 2018 14:59:11 +0100 Subject: [Lightning-dev] A protocol for requesting invoices In-Reply-To: References: <5AA36A1E.5090909@AndySchroder.com> Message-ID: <444483c3-c7da-4b95-4150-e7c3de307650@bitonic.nl> > It is a public key hash, yes. But what I refer to is that the payee-determined route section, which starts from an introduction point, protects the payee from being located by the payer, but how did the payer contact the payee in the first place anyway? If it was by IP or non-.onion hostname, then the payee has been already located and there is no point in hiding from the payer. If it was by .onion hostname, then the payee security is bounded by the security of TOR, so it is no more secure for the payee to simply run its LN node on the same .onion address (which LN spec supports) and provide the public key of its LN node. > > Note that onion routing on LN in general protects the payer and the payee from being known easily by intermediate hop nodes, and this is the sole intent of onion routing for now. Presumably the payer knows how to contact the payee (else how would it form a connection to the payee in order to make an interactive request for invoice?). Presumably if the payee is a merchant, it knows how to send its product to the payer (and thus would know details like the physical address of the payer). And so on. The payee-determined route that starts from the introduction point protects the payee from the payer, but does it indeed increase the security or is there some other way to locate the payee anyway? If that payee has a LN node that is 100% a TOR hidden service, and you don't use a (partially) payee-determined route, the payee has to reveal its node ID to the payer. This is not the same as revealing the physical identity of the payee, and having a hidden service may help to keep the two identities separated, but a LN node is a relatively long-lived entity. Over time, the risk increases that knowledge about the node ID (e.g. what kinds of transactions are linked to this ID) leaks out and gets combined, revealing things you don't want to be revealed. It may, for instance, be that some of your incoming transactions are inherently linked to your physical identity (e.g. salary), and some other you don't want linked to yourself. If you have to reveal your node ID to all payers, you risk those transactions being linked to you, either now or in the future. Running a node as a TOR hidden service is not sufficient. However, if you manage to hide your node ID from payers, this becomes much more difficult; you really gain some privacy. In fact, using a TOR hidden service may not always be necessary. In some cases, you could alternatively set up payer/payee communication over a more-or-less anonymous physical medium; maybe using a burner phone, WiFi with a randomized MAC address, NFC, or some other kind of radio communication. The alternative approach to partially payee-determined routes would be to run different nodes for different identities and to regularly shut down nodes and set up new ones. This requires expensive on-chain actions though (more expensive than setting up a new TOR hidden service), and I don't think it's good for the rest of the network either if channels are regularly shut down. I prefer if people can have lots of privacy, even when running only a single node. You could roughly say that TOR is necessary because your IP address can often be linked to you, and partially payee-determined routes are necessary because your node ID can often be linked to you. CJP From ZmnSCPxj at protonmail.com Mon Mar 19 14:27:00 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Mon, 19 Mar 2018 10:27:00 -0400 Subject: [Lightning-dev] A protocol for requesting invoices In-Reply-To: <444483c3-c7da-4b95-4150-e7c3de307650@bitonic.nl> References: <5AA36A1E.5090909@AndySchroder.com> <444483c3-c7da-4b95-4150-e7c3de307650@bitonic.nl> Message-ID: Good morning Corne, > > It is a public key hash, yes. But what I refer to is that the payee-determined route section, which starts from an introduction point, protects the payee from being located by the payer, but how did the payer contact the payee in the first place anyway? If it was by IP or non-.onion hostname, then the payee has been already located and there is no point in hiding from the payer. If it was by .onion hostname, then the payee security is bounded by the security of TOR, so it is no more secure for the payee to simply run its LN node on the same .onion address (which LN spec supports) and provide the public key of its LN node. > > > > Note that onion routing on LN in general protects the payer and the payee from being known easily by intermediate hop nodes, and this is the sole intent of onion routing for now. Presumably the payer knows how to contact the payee (else how would it form a connection to the payee in order to make an interactive request for invoice?). Presumably if the payee is a merchant, it knows how to send its product to the payer (and thus would know details like the physical address of the payer). And so on. The payee-determined route that starts from the introduction point protects the payee from the payer, but does it indeed increase the security or is there some other way to locate the payee anyway? > > If that payee has a LN node that is 100% a TOR hidden service, and you > > don't use a (partially) payee-determined route, the payee has to reveal > > its node ID to the payer. This is not the same as revealing the physical > > identity of the payee, and having a hidden service may help to keep the > > two identities separated, but a LN node is a relatively long-lived > > entity. The LN node is long-lived, but the TOR address it uses is not long-lived? LN nodes need to communicate with counterparties, and if the connection breaks, you need to get in contact again, else the channel is unuseable. Admittedly an LN node may change its TOR address by re-gossiping a new TOR address, though, so I suppose that is a possibility. But that still links LN pubkeys with TOR addresses anyway. I suppose the use-case here is that the payee uses many TOR addresses with only one LN node. Regards, ZmnSCPxj From apoelstra at wpsoftware.net Mon Mar 19 14:57:57 2018 From: apoelstra at wpsoftware.net (Andrew Poelstra) Date: Mon, 19 Mar 2018 14:57:57 +0000 Subject: [Lightning-dev] AMP via HD, BN+SS, and TR In-Reply-To: References: Message-ID: <20180319145757.GZ9082@boulet.lan> Hi ZmnSCPxj, Yep, I'm pretty sure this works the way you describe -- essentially replace the hash challenges with adaptor signatures which are reblinded at each layer. Because adaptor signatures can make arbitrary sets of signatures atomic (and don't require any precommitments in the blockchain) it's easy to do multipath stuff this way. And using discrete logs as challenges makes reblinding and transferrable proof-of-payment easy. It's also true that you can use BIP32 hardened keys for the challenges. You might as well use HMAC rather than a hash for the sake of standardness, but I don't think there's any particular reason to do this for key derivation. Then Taproot can hide the non-cooperative cases as you mention. I've been working on understanding Lightning and figuring out best way to use the full power of scriptless scripts. I think we can do better than just dropping TR+SS into the existing architecture. (Some of AJ's recent emails to the list have been one-sided commentary on ideas I floated to him in person recently, but I haven't had time to get everything straight enough in my mind to reply.) For example, with adaptor signatures + Graftroot [1], one party can make their commit-tx signature atomic with a delegation to a timelock script; the other party does the same but for a different timelock script. Then maybe both parties can share the same commit tx rather than doing the symmetric thing, which would save space and simplify the protocol a bit. And more generally, this "output has different spend conditions depending on who publishes to the chain" primitive seems like a really powerful thing, and AFAIK nobody has noticed this feature of Graftroot until very recently. Cheers Andrew [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html On Sun, Mar 18, 2018 at 08:25:13PM -0400, ZmnSCPxj via Lightning-dev wrote: > Good morning list, > > I sketch here the idea, of making atomic multipath payment (AMP), with the properties: > > 1. Has a proof-of-payment. > 2. Multipath decorrelation. > > Note: I am not a mathematician. Thus, it is likely, that there is a mistake here, and we cannot make this work. > > First, we look at BIP32 hierarchically derived (HD) keys by Wuille. Roughly, given a parent private key k_par, we can do derive k_i child keys for integer i by: > > k_i = H(i || k_par * G) + k_par > > where H(x) is a hash function and G is the generator point. (this it not quite how BIP32 does it, it uses HMAC, maybe that is safer for some reason that my non-mathematician self is unaware of...) > > The parent public key K_par = k_par * G. We can derive K_i public child keys for integer i by: > > K_i = H(i || K_par) * G + K_par > > (I think) > > Note that K_i = k_i * G still, as is usual for elliptic curve asymmetric cryptography: > > K_i = k_i * G = (H(i || k_par * G) + k_par) * G = H(i || k_par * G) * G + k_par * G = H(i || K_par) * G + K_par > > Of note is that if we know an i, a private child key k_i corresponding to that i, and the public parent key K_par, we can derive the private parent key k_par: > > k_i = H(i || K_par) + k_par > > k_par = k_i - H(i || K_par) > > Now all we need is to have a conditional payment, which can only be performed if the payee provides a private key which matches a public key, i.e. given x * G, the payee must provide x. > > Fortunately Poelstra has done this work beforehand in the Scriptless Script (SS) concept, where the payee provides a T = t * G, and the Scriptless Script construction requires that the payee reveal the t in order to claim the payment. I will not go into the math since there is a good chance I shall make a mistake; look up discussions by better mathematicians by me. Scriptless Script requires Bellare-Neven (BN) signatures to work. > > Note that Scriptless Script handles only the equivalent of hashlocking. We still need a timelock in case the payee refuses to reveal the proof-of-payment t. > > Fortunately, Maxwell has provided a construction, taproot (TR). This construction has two top-level branches: a Bellare-Neven n-of-n, or a Bitcoin Script. We know that Scriptless Script can make an equivalent to a hashlock from a Bellare-Neven n-of-n. The other branch of a taproot construction can now be a simple OP_CLTV+OP_CHECKSIG script, forming the timelock half of an HTLC. > > How would a multipath payment work? The invoice would contain the parent public key K_par. From this, the payer derives as many K_i, as it needs to split the payment to. It sets up conditional payments that require revelation of the private child key k_i for each K_i it derives. > > When the payee receives a partial payment, it is not incentivized to claim it immediately yet. This is because revelation of even one child key k_i will, in combination with the parent public key K_par, reveal the parent private key k_par, which serves as proof-of-payment. The payee will wait for the entire payment to reach it, and then claim all of them. This reveals all the private child keys k_i, any one of which will let the payer extract the parent private key k_par that serves as proof-of-payment. > > Each path has a different k_i, thus providing multipath decorrelation. > > (Please check my math --- I am not a mathematician and it is possible I have made a mistake somewhere) > > Regards, > ZmnSCPXj > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -- Andrew Poelstra Mathematics Department, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew "A goose alone, I suppose, can know the loneliness of geese who can never find their peace, whether north or south or west or east" --Joanna Newsom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: not available URL: From ZmnSCPxj at protonmail.com Tue Mar 20 02:32:16 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Mon, 19 Mar 2018 22:32:16 -0400 Subject: [Lightning-dev] AMP via HD, BN+SS, and TR In-Reply-To: <20180319145757.GZ9082@boulet.lan> References: <20180319145757.GZ9082@boulet.lan> Message-ID: Good morning Andrew, > Hi ZmnSCPxj, > > Yep, I'm pretty sure this works the way you describe -- essentially replace > > the hash challenges with adaptor signatures which are reblinded at each layer. Thank you very much your confirmation. > For example, with adaptor signatures + Graftroot \[1\], one party can make their > > commit-tx signature atomic with a delegation to a timelock script; the other > > party does the same but for a different timelock script. Then maybe both parties > > can share the same commit tx rather than doing the symmetric thing, which would > > save space and simplify the protocol a bit. Possibly not? On each pair of symmetric commitments, an output that is timelocked on one commitment transaction is not timelocked on the other commitment transaction, and that output is signable by the same party. E.g. in the simple case with a single output controlled by a single party A, A has a commitment transaction whose output is timelocked and unlockable by A, B has a commitment transaction whose output is only unlockable by A (and in particular not timelocked). Each side still needs its own commitment transaction I think. (unless Graftroot is even more magical than how I understand it: my skills already strain trying to understand Scriptless Script and Taproot, so possibly I just do not understand Graftroot well enough) Symmetry in commitment transactions is not particularly space-heavy. Well-behaved nodes will never bother storing old commitments and can delete those from disk, and you only need to store your own commitment --- the other commitment is the responsibility of the counterparty to store. > And more generally, this "output > > has different spend conditions depending on who publishes to the chain" primitive > > seems like a really powerful thing, and AFAIK nobody has noticed this feature of > > Graftroot until very recently. Ah, this is indeed very interesting! Regards, ZmnSCPxj From ZmnSCPxj at protonmail.com Tue Mar 20 03:19:02 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Mon, 19 Mar 2018 23:19:02 -0400 Subject: [Lightning-dev] Towards a gridlike Lightning Network Message-ID: Good morning list, As my award-winning and supremely notable and talked-about-by-the-man-on-the-street article "Cyclic Superhubs as Solution Towards Reasonable Lightning Network Topography" points out, cycles are a good way to organize the LN in order to allow easier accessibility to the network for all participants of all kinds. An issue here is the need for coordination in order to set up cyclic superhubs. A node acting by itself cannot form cyclic superhubs. However, one can consider that coordination is needed only to identify peers with which one forms superhubs. But we already have a system that identifies peers: the node gossip. So let us assume: All nodes have similar-enough views of the publicly-visible peers on the node graph, as built by node gossip. I now present an algorithm, which given a set of nodes extracted from node gossip, returns a peer to try connecting and funding a channel to. -- First, start with a 32-bit number i = 0. For each node, get hash = H(i || pubkey), where H is some standard hash algorithm, and pubkey is the public key of the node. Also get our_hash = H(i || our_pubkey) Perform successive filtering. While the set is larger than 2 nodes, successively compare high bits. If the highest bit of hash does not match the highest bit of our_hash, remove it from the set. If the resulting set is still larger than 2, match the next bit. When the set is now 2 or 1 node, back off by one bit and add back the most recently removed nodes. This yields a set that is at least 3 or more nodes. Sort the nodes according to hash. Identify where our node is in the sorted list. Then our candidate is the next node in the list, or if we are the last node, then the first node in the list. If the candidate already has a channel with us, or has no address info and cannot be found by DNS seed or so on, or cannot be contacted, or refuses incoming channels or some other error, then increment i and try finding again. --- Even if nodes have some divergence in their own local maps of the network, there is the chance that the difference will be filtered away and the nodes that are "destined" to form a superhub can still find each other in the same superhub. Assuming all nodes have the same routemap, then all nodes will form their own, non-overlapping superhubs for each i. However if some nodes get to increment i, hopefully because it already has a channel with its destined candidate peer at one value of i, it can then potentially form superhubs with other nodes that have also reached higher i. Regards, ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: From ZmnSCPxj at protonmail.com Tue Mar 20 06:25:20 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Tue, 20 Mar 2018 02:25:20 -0400 Subject: [Lightning-dev] AMP via HD, BN+SS, and TR In-Reply-To: References: Message-ID: <9bzyrqrp4G1uWo0c3NC6_1Zk3VV8dNQCWukcGZzXAzj3x-u2kXcU2bKli3clv9H0X9nsHqbmT3XZRn6YZ4St1P-6uV4rwcWMVU_R0Ou2M80=@protonmail.com> Good morning list, It is possible to mean atomic in multiple meanings: 1. The payee is completely unable to claim any partial payments until all partial payments arrive at the payee. 2. The payee is not incentivized to claim partial payments until all partial payments arrive at the payee. My proposal uses "atomic" in the sense of #2. As soon as a single partial payment reveals a child key k_i, then with the know public parent key K_par it is possible to compute parent secret key k_par. This is sufficient if k_par is valuable, for example if it is also the encryption key for valuable digital data such as some megabytes of a streamed movie, game downloadable content, ransomed files, etc. i.e. for ZKCP. The payee is incentivized to claim payments only if all partial payments reach it, since once it claims any sub-payment, it will also release the valuable secret k_par. However, it is possible to upgrade from #2 to #1 by adding a secret from the payer to the payee that is sent "in pieces" for each sub-payment. We add this payer secret p and modify our derivation as follows: K_i = H(i || p || K_par) * G + K_par k_i = H(i || p || k_par * G) + k_par k_par can be derived if we know any i, k_i, p, and K_par: k_par = k_i - H(i || p || K_par) When splitting a single payment into two payments, the payer generates a hiding random number x_1. When sending an onion payment, the onion payload contains pieces of the payer secret p. For example, in the 2-subpayment case: sub-payment 1: p ^ x_1 sub-payment 2: x_1 This can be extended to any number of subpayments n: sub-payment 1: p ^ x_1 ^ ... ^ x_n-1 sub-payment 2: x_1 ... sub-payment n: x_n-1 In this case, the payee truly cannot claim any sub-payment unless all sub-payments have reached it. When all sub-payments have reached it, it XORs all the pieces of the payer secret together to compute p. The payee cannot derive k_i unless it knows i, p, and the secret k_par. Once at least one sub-payment is claimed, then the payer can derive the secret k_par. Since offers on LN are HTLCs, there is a timelock involved. As long as the payee does not claim too close to the timelock, it has time to claim all sub-payments, even if only claiming one sub-payment is enough for the payer to derive the (potentially valuable) secret k_par. Thus this scheme achieves atomicity in the sense "the payee cannot claim partial payments", not just "the payee is disincentivized to claim partial payments". Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ??????? Original Message ??????? On March 19, 2018 8:25 AM, ZmnSCPxj via Lightning-dev wrote: > Good morning list, > > I sketch here the idea, of making atomic multipath payment (AMP), with the properties: > > 1. Has a proof-of-payment. > 2. Multipath decorrelation. > > Note: I am not a mathematician. Thus, it is likely, that there is a mistake here, and we cannot make this work. > > First, we look at BIP32 hierarchically derived (HD) keys by Wuille. Roughly, given a parent private key k_par, we can do derive k_i child keys for integer i by: > > k_i = H(i || k_par * G) + k_par > > where H(x) is a hash function and G is the generator point. (this it not quite how BIP32 does it, it uses HMAC, maybe that is safer for some reason that my non-mathematician self is unaware of...) > > The parent public key K_par = k_par * G. We can derive K_i public child keys for integer i by: > > K_i = H(i || K_par) * G + K_par > > (I think) > > Note that K_i = k_i * G still, as is usual for elliptic curve asymmetric cryptography: > > K_i = k_i * G = (H(i || k_par * G) + k_par) * G = H(i || k_par * G) * G + k_par * G = H(i || K_par) * G + K_par > > Of note is that if we know an i, a private child key k_i corresponding to that i, and the public parent key K_par, we can derive the private parent key k_par: > > k_i = H(i || K_par) + k_par > > k_par = k_i - H(i || K_par) > > Now all we need is to have a conditional payment, which can only be performed if the payee provides a private key which matches a public key, i.e. given x * G, the payee must provide x. > > Fortunately Poelstra has done this work beforehand in the Scriptless Script (SS) concept, where the payee provides a T = t * G, and the Scriptless Script construction requires that the payee reveal the t in order to claim the payment. I will not go into the math since there is a good chance I shall make a mistake; look up discussions by better mathematicians by me. Scriptless Script requires Bellare-Neven (BN) signatures to work. > > Note that Scriptless Script handles only the equivalent of hashlocking. We still need a timelock in case the payee refuses to reveal the proof-of-payment t. > > Fortunately, Maxwell has provided a construction, taproot (TR). This construction has two top-level branches: a Bellare-Neven n-of-n, or a Bitcoin Script. We know that Scriptless Script can make an equivalent to a hashlock from a Bellare-Neven n-of-n. The other branch of a taproot construction can now be a simple OP_CLTV+OP_CHECKSIG script, forming the timelock half of an HTLC. > > How would a multipath payment work? The invoice would contain the parent public key K_par. From this, the payer derives as many K_i, as it needs to split the payment to. It sets up conditional payments that require revelation of the private child key k_i for each K_i it derives. > > When the payee receives a partial payment, it is not incentivized to claim it immediately yet. This is because revelation of even one child key k_i will, in combination with the parent public key K_par, reveal the parent private key k_par, which serves as proof-of-payment. The payee will wait for the entire payment to reach it, and then claim all of them. This reveals all the private child keys k_i, any one of which will let the payer extract the parent private key k_par that serves as proof-of-payment. > > Each path has a different k_i, thus providing multipath decorrelation. > > (Please check my math --- I am not a mathematician and it is possible I have made a mistake somewhere) > > Regards, > ZmnSCPXj -------------- next part -------------- An HTML attachment was scrubbed... URL: From TSteenholdt at cascadetechnologypartners.com Tue Mar 20 11:26:58 2018 From: TSteenholdt at cascadetechnologypartners.com (Thomas Steenholdt) Date: Tue, 20 Mar 2018 11:26:58 +0000 Subject: [Lightning-dev] DNS Seed query semantics clarification In-Reply-To: <87vadwxhi6.fsf@gmail.com> References: <874llgyz5u.fsf@gmail.com> , <87vadwxhi6.fsf@gmail.com> Message-ID: Cool, Since we're trying to clarify some of the things that may not be entirely clear, there are a few other things it may be relevant to address or define at the same time: 1. What's the intended direction of interpreting the conditions? 2. What's the result of the conflict if a condition is specified multiple times? So using the thought-up case of r0.a2.n5.a4.n10.seed.example.com: 1. Should the DNS seed process the conditions from the seed root and "up the tree" or in the opposite direction? For the sake of argument, I'm going to assume we want to take a (DNS-wise) logical approach, i.e. interpreting from the seed root and "up the tree", so in the order: n10, a4, n5, a2, r0. 1. What happens to a2 when we meet a4? Should a4 replace any current a condition or simply be ignored (or in the case of a perhaps even merged through a bitwise or)? Same question for n5when we meet n10. Personally I think it would make sense to always replace currently set conditions, when we hit new conditions with the same key. This would allow us to easily add a condition to a query programmatically, without having to interpret any conditions that may be set already. Prepending a current query string with a6. would then guarantee that an earlier condition does not limit my results to either IPv4 or IPv6 nodes. As long as the length of the query string does not exceed a total of 253 chars (standard DNS limitation, not counting the root .). Any thoughts on this? /Thomas ________________________________ From: Christian Decker Sent: Friday, March 16, 2018 10:44:01 AM To: Thomas Steenholdt Cc: lightning-dev at lists.linuxfoundation.org Subject: Re: DNS Seed query semantics clarification Thomas Steenholdt writes: > Thanks for the explanation - This was exactly the the piece of the > puzzle I was missing. ? > > I'd be happy to help clarify this in the BOLT10 specification, if that > makes any type of sense? I can make a pull request for revie Absolutely, improvements are always welcome :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From corne at bitonic.nl Tue Mar 20 12:59:28 2018 From: corne at bitonic.nl (=?UTF-8?Q?Corn=c3=a9_Plooy?=) Date: Tue, 20 Mar 2018 13:59:28 +0100 Subject: [Lightning-dev] A protocol for requesting invoices In-Reply-To: References: <5AA36A1E.5090909@AndySchroder.com> <444483c3-c7da-4b95-4150-e7c3de307650@bitonic.nl> Message-ID: <582f7c8e-3c86-89fb-21ac-74e02611e3a4@bitonic.nl> > I suppose the use-case here is that the payee uses many TOR addresses with only one LN node. Yes. Use different TOR addresses for things you want to keep separated. Any TOR address you advertise for channel connections is so widely shared through gossiping that you can in practice consider such an address to be the same identity as your peer ID. For the payer/payee communication (BOLT 12, and other interfaces such as a website) you should *not* use the same TOR address if you want that activity to remain unlinked from your node ID. You could use another TOR address, or any other pseudonymous communication method. Depending on the transport layer you use (TOR or something else) you end up with a different type of URL. I think for now it's good enough to support TCP and TOR. Another use case could be to use partial onion routes for payments in the opposite direction. This is, for instance, to refund a payer who wishes to remain anonymous. The original payee has an URL (can be TOR hidden service, or even regular TCP), and the original payer connects to this (using TOR or another anonymizing medium). The original payer can then remain anonymous by sending an invoice for the refund that uses a partial onion route on LN. In this use case, the purpose is to keep the original payer anonymous (not reveal the node ID), not to keep the original payee anonymous. CJP From melvincarvalho at gmail.com Tue Mar 20 13:11:16 2018 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Tue, 20 Mar 2018 14:11:16 +0100 Subject: [Lightning-dev] A protocol for requesting invoices In-Reply-To: References: Message-ID: On 9 March 2018 at 05:28, ZmnSCPxj via Lightning-dev < lightning-dev at lists.linuxfoundation.org> wrote: > Good morning Corne, > > You mention URLs in your draft. This made me remember about the Web > Payments Working Group of W3C, https://www.w3.org/Payments/WG/ , of which > Decker, Christian of Blockstream is a member: https://www.w3.org/2000/09/ > dbwg/details?group=83744&public=1 > > My understanding is that Christian aims to make Bitcoin payments (and > possibly Lightning invoice payments?) payable over Web payment protocols > that W3C group is working on. > > Possibly the Web Payments Working Group may provide better perspective on > various other payment use cases as well as their subtleties, which can help > inform your considerations in your proposed BOLT12. > I'm interested in this effort too. There's various levels of web payments incubation. Working Group is for wide deployment in browsers. Interest Group is for ideas that are aimed at standards track. Community group is aimed at new ideas and specs which can have stable references, but may be more on the bleeding edge. I do quite a bit of work with the W3C, so am happy to look over things, as I'd like to include something similar in my apps. I was thinking I'd have to make my own ontology, but if it's possible to reuse, that's even better! > > Regards, > ZmnSCPxj > > > ?Sent with ProtonMail Secure Email.? > > ??????? Original Message ??????? > > On March 8, 2018 11:19 PM, Corn? Plooy via Lightning-dev < > lightning-dev at lists.linuxfoundation.org> wrote: > > > Hi, > > > > I was thinking of how to use Lightning for various types of payments, > > > > and I think it's currently fine for customer/(web)shop type > > > > interactions, but it seems a bit inconvenient for other use cases, e.g. > > > > salary payments or direct pay-out of cryptocurrency bought on an > > > > exchange. I came up with an idea that addresses some of these issues and > > > > more (e.g. payee anonymity) by having a direct line of communication > > > > between payer and payee instead of BOLT11-style interaction. It's still > > > > a bit half-baked, with many details not worked out yet, but you can read > > > > it here, and see if you like where this is going: > > > > https://github.com/bitonic-cjp/lightning-rfc/blob/ > payment-protocol/12-payment-protocol.md > > > > In true permissionless fashion, I have been so bolD to register bolT #12 > > > > for my idea. > > > > Please let me know what you think. > > > > kind regards, > > > > CJP > > > > Lightning-dev mailing list > > > > Lightning-dev at lists.linuxfoundation.org > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ZmnSCPxj at protonmail.com Wed Mar 21 04:02:39 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Wed, 21 Mar 2018 00:02:39 -0400 Subject: [Lightning-dev] A protocol for requesting invoices In-Reply-To: <582f7c8e-3c86-89fb-21ac-74e02611e3a4@bitonic.nl> References: <5AA36A1E.5090909@AndySchroder.com> <444483c3-c7da-4b95-4150-e7c3de307650@bitonic.nl> <582f7c8e-3c86-89fb-21ac-74e02611e3a4@bitonic.nl> Message-ID: Good morning Corne, > > I suppose the use-case here is that the payee uses many TOR addresses with only one LN node. > > Yes. Use different TOR addresses for things you want to keep separated. > > Any TOR address you advertise for channel connections is so widely > > shared through gossiping that you can in practice consider such an > > address to be the same identity as your peer ID. For the payer/payee > > communication (BOLT 12, and other interfaces such as a website) you > > should not use the same TOR address if you want that activity to > > remain unlinked from your node ID. You could use another TOR address, or > > any other pseudonymous communication method. I understand. I want to bring up another possible privacy break. Channels can be brought onchain anytime, and any HTLCs pending through that channel will also be brought onchain and will be visible. This will also publish the `payment_hash`. A payer observing the chain knows the `payment_hash` it was paying to, can see the HTLC getting claimed and exposing the `payment_hash`, and from the channel signatures knows which nodes were using that channel (if it was a public channel then it has signatures attesting who the nodes participating in it are, from node gossip!). It can guess that it is likelier than usual that one of the nodes on that channel is the payee, and definitely knows that the channel was part of the payee-provided route. (using non-public channels helps here in that the payer would have to observe every possible HTLC claim, not just those that it knows are from the public channels on the network, and would be hoping that such an event occurred during its payment: so it would have to devote more bandwidth and processing power searching through all transactions for an HTLC claim that matches its `payment_hash`. But I think there is no such thing as a truly private channel: each channel has two participants and two can keep a secret only if one of them is dead) This is not such a big concern; this is expected to be a rare case and if your node accepts received HTLCs very quickly and has very good uptime it is unlikely to occur in practice. In addition, once we switch to Scriptless Script (which requires Bellare-Neven signatures to be implemented in some form on the base Bitcoin blockchain layer) this privacy leak disappears (I think... or maybe greatly reduces at least), as even onchain the equivalent to a hashlock is indistinguishable from an ordinary Bellare-Neven m-of-n signature. Regards, ZmnSCPxj From info at AndySchroder.com Wed Mar 21 05:45:44 2018 From: info at AndySchroder.com (Andy Schroder) Date: Wed, 21 Mar 2018 01:45:44 -0400 Subject: [Lightning-dev] A protocol for requesting invoices In-Reply-To: References: <5AA36A1E.5090909@AndySchroder.com> Message-ID: Andy Schroder On 03/19/2018 08:06 AM, Corn? Plooy wrote: >> What about enforcing a maximum payment amount that can be refunded? >> Can this help make the amount not a requirement? This way the payment >> amount will still be open to the payer, but it will have a constraint. > I see no use case anymore for leaving out the amount in the invoice. For > any type of transaction where the payer decides the amount, he can do so > by specifying the amount in the invoice request. Maybe you are right. > >>>> ???? 3.? True. Right now I'm thinking in the opposite direction: >>>> simplifying >>>> ???? ???? BOLT 12 by removing the possibility of refunds. We can >>>> always add it >>>> ???? ???? back later (with a proper set of features for all kinds of >>>> refunds) as >>>> ???? ???? an optional feature. >> >> I want my refund :-) ! > I did some further thinking on refunds. Generally speaking, they are a > solution for when Transactions Get Messy, right? You agreed to a > transaction, the Lightning payment happened, but now you want to change > something. That 'something' can be, for instance, a full refund (e.g. if > goods cannot be delivered), a partial refund (e.g. if goods arrived > later than agreed, or with inferior quality), an extra payment by the > payer (e.g. cheaper model out of stock, decided to buy the more > expensive one instead), or no payment at all (e.g. payer changes mind > after the payment, and wants the black/blue model instead of the > white/gold one, which has the same price). Did you take a look a the application in my link? It demonstrates paying for fuel for an automobile with bitcoin using blockchain payments. There is first a payment and then the pump powers on. After the person finishes dispensing fuel into their vehicle, it immediately places a refund transaction using the refund address received using the BIP70 payment protocol. It even uses NFC and bluetooth instead of QR codes and http. Most automobile owners have to go through this payment process every 5-15 days if they buy fuel with cash. It's not really a messy transaction and their is no any way to know with much accuracy how much fuel they actually need since fuel level gauges in automobiles aren't very inaccurate. And, you can always be filling up some cans of unknown size to take back and refill your tractor, generator, boat, or whatever. This is a situation where you shouldn't need to divulge your identity to make a trivial purchase of a commodity. Other common examples include making a deposit for a hotel. Normally you need to put something up far beyond the cost of the room rental in order to cover any damages you could make to the room. Same goes for renting anything really. There are many other little cases where you may need to place a deposit greater than the cost of the good/service you are receiving. > > There is some similarity between a "BOLT 12" transaction that allows > refunds and other updates, and a microtransaction channel. Specifically, > I think you want the new state to be signed by whoever may possibly have > a legitimate interest *against* the update, and you want the old state > to be invalidated. In BOLT 12, to support this, a state should typically > contain the description field, a field that invalidates the previous > state, a field that specifies how this state can be invalidated, and > optionally a payment hash(*), which indicates that this state update is > valid only in combination with the corresponding preimage. A transaction > starts in a "null" state (no obligations between participants), and ends > specifying certain obligations that have been fulfilled. TBD: maybe > returning to null state by signing off that all obligations have been > fulfilled? E.g. payer signing off that ordered goods have been received. > Note that this must be different from canceling the transaction, since > you want the payer to keep some kind of proof of ownership. Anyway, I > think returning to null state should not be required on BOLT12 protocol > level: not everybody wants this. Some suppliers may want to require it > though. > > Looking at the protocol for this (generalized) refund usage, it seems > clear that, often, you don't want to have to keep the communication line > open the entire time: it can take days, weeks or longer until the final > settlement of a transaction. You should be able to reconnect (typically > in the same direction as the initial connect) and say "hey, let's update > the state of the transaction to this-or-that". So, on re-connecting, you > also need to be able to specify *which* transaction to update. Makes sense. > > The format of the "description" field is unspecified for now; I think > it's best to keep it that way. Machine-readable formats for this are a > very complex subject, better solved at a higher level protocol. For now, > assume it to be human-readable; maybe add a MIME type field so that its > format is both unambiguous (technologically) and upgradeable. > > TBD: is there a use case for transactions between more than two parties? > Or having smart contract (scriptless?) scripts? These would then > typically be evaluated by a settlement service provider (e.g. the legal > system) instead of a block chain. Interesting thought. > >> All return onions still have the same problem of capacity though. > A partial onion is a very generic solution. If capacity is your greatest > concern as payee, you just supply a zero-hop partial onion. Minimum > privacy, but maximum ability of the payer to construct a route over > channels with sufficient capacity. The choice is yours. > >>>> ???? 4.? This depends on the use case. The URL contains an optional >>>> invoice >>>> ???? ???? ID. A payee can request a payment for a specific, single >>>> transaction >>>> ???? ???? (for a single instance of delivery of goods/services) by >>>> handing over an >>>> ???? ???? URL, including an invoice ID, to a single payer. This >>>> provides similar >>>> ???? ???? functionality as BOLT 11, except that you now have a >>>> well-defined >>>> ???? ???? channel for transmitting larger invoice descriptions and >>>> for using >>>> ???? ???? partial onion routes. A payee can also hand over an URL >>>> without invoice >>>> ???? ???? ID; this can be used and re-used by one or more payers, >>>> whenever they >>>> ???? ???? want to perform payments to this payee. >>> How does the payer derive the payment hash? Or does the payer have to >>> contact the payee again to get a fresh payment hash specifically for >>> the payer? > Contact the payee again. Or, more generally, one of them knows how to > contact the other to propose updates to the agreement; if the payee of > the update agrees, he will provide the payment hash. > > CJP > > (*) together with amount and timeout: these allow the payer to know > under what conditions the payee is likely to release the preimage. > > > From info at AndySchroder.com Wed Mar 21 05:50:43 2018 From: info at AndySchroder.com (Andy Schroder) Date: Wed, 21 Mar 2018 01:50:43 -0400 Subject: [Lightning-dev] A protocol for requesting invoices In-Reply-To: <444483c3-c7da-4b95-4150-e7c3de307650@bitonic.nl> References: <5AA36A1E.5090909@AndySchroder.com> <444483c3-c7da-4b95-4150-e7c3de307650@bitonic.nl> Message-ID: <63bd4590-238b-f84c-ed29-ce4b9cc59b4e@AndySchroder.com> Andy Schroder On 03/19/2018 09:59 AM, Corn? Plooy wrote: >> It is a public key hash, yes. But what I refer to is that the payee-determined route section, which starts from an introduction point, protects the payee from being located by the payer, but how did the payer contact the payee in the first place anyway? If it was by IP or non-.onion hostname, then the payee has been already located and there is no point in hiding from the payer. If it was by .onion hostname, then the payee security is bounded by the security of TOR, so it is no more secure for the payee to simply run its LN node on the same .onion address (which LN spec supports) and provide the public key of its LN node. >> >> Note that onion routing on LN in general protects the payer and the payee from being known easily by intermediate hop nodes, and this is the sole intent of onion routing for now. Presumably the payer knows how to contact the payee (else how would it form a connection to the payee in order to make an interactive request for invoice?). Presumably if the payee is a merchant, it knows how to send its product to the payer (and thus would know details like the physical address of the payer). And so on. The payee-determined route that starts from the introduction point protects the payee from the payer, but does it indeed increase the security or is there some other way to locate the payee anyway? > If that payee has a LN node that is 100% a TOR hidden service, and you > don't use a (partially) payee-determined route, the payee has to reveal > its node ID to the payer. This is not the same as revealing the physical > identity of the payee, and having a hidden service may help to keep the > two identities separated, but a LN node is a relatively long-lived > entity. Over time, the risk increases that knowledge about the node ID > (e.g. what kinds of transactions are linked to this ID) leaks out and > gets combined, revealing things you don't want to be revealed. > > It may, for instance, be that some of your incoming transactions are > inherently linked to your physical identity (e.g. salary), and some > other you don't want linked to yourself. If you have to reveal your node > ID to all payers, you risk those transactions being linked to you, > either now or in the future. Running a node as a TOR hidden service is > not sufficient. However, if you manage to hide your node ID from payers, > this becomes much more difficult; you really gain some privacy. > > In fact, using a TOR hidden service may not always be necessary. In some > cases, you could alternatively set up payer/payee communication over a > more-or-less anonymous physical medium; maybe using a burner phone, WiFi > with a randomized MAC address, NFC, or some other kind of radio > communication. Regarding NFC and radio communication, I think this would be important to bake into the original spec. I'm going to encourage bluetooth over wifi with a randomized MAC address. Bluetooth is likely a little better because you can make a lot of simultaneous bluetooth connections and they don't require you to do any changes to your internet connection, which you still need in order to interact with the bitcoin and lightning networks. Bluetooth also makes it simpler for the payee as far as limiting what the payee can use the connection for. I'm guessing you can randomize the bluetooth MAC address. One thing for example that makes BIP70 complicated in that regard is that you need to be able to supply a few URLs in order to give the payer an option on how they may want to connect to fetch a payment request (locally via bluetooth, or over the internet using http). Some hacks were made to BIP70 to make it work with bluetooth, but I'm not sure if the design was the best. * Demo using my fuel pump and Bitcoin Wallet o http://andyschroder.com/BitcoinFluidDispenser/2.3/ + Watch the first video on this page. + I don't think totally offline payments are possible with lightning, so that part of the workflow isn't comparable. * Details about how Bitcoin Wallet is designed and different ways to communicate with the payee. o https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki o https://github.com/bitcoin-wallet/bitcoin-wallet/wiki/Payment-Requests o Note, the bluetooth communication protocol used here still needs to be encrypted. That extension was never developed. Obviously we aren't going to use BIP70 here for lightning, but my point is that there are some lessons that can be learned from the work flow. > > The alternative approach to partially payee-determined routes would be > to run different nodes for different identities and to regularly shut > down nodes and set up new ones. This requires expensive on-chain actions > though (more expensive than setting up a new TOR hidden service), and I > don't think it's good for the rest of the network either if channels are > regularly shut down. Definitely. > I prefer if people can have lots of privacy, even > when running only a single node. > > You could roughly say that TOR is necessary because your IP address can > often be linked to you, and partially payee-determined routes are > necessary because your node ID can often be linked to you. > > CJP > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From TSteenholdt at cascadetechnologypartners.com Fri Mar 23 13:06:47 2018 From: TSteenholdt at cascadetechnologypartners.com (Thomas Steenholdt) Date: Fri, 23 Mar 2018 13:06:47 +0000 Subject: [Lightning-dev] DNS Seed query semantics clarification In-Reply-To: References: <874llgyz5u.fsf@gmail.com> , <87vadwxhi6.fsf@gmail.com>, Message-ID: Hi guys, I have proposed an update to BOLT #10 in pull request #396, in an attempt to address these things. Any feedback is welcome. /Thomas ________________________________ From: lightning-dev-bounces at lists.linuxfoundation.org on behalf of Thomas Steenholdt Sent: Tuesday, March 20, 2018 8:26:58 AM To: Christian Decker Cc: lightning-dev at lists.linuxfoundation.org Subject: Re: [Lightning-dev] DNS Seed query semantics clarification Cool, Since we're trying to clarify some of the things that may not be entirely clear, there are a few other things it may be relevant to address or define at the same time: 1. What's the intended direction of interpreting the conditions? 2. What's the result of the conflict if a condition is specified multiple times? So using the thought-up case of r0.a2.n5.a4.n10.seed.example.com: 1. Should the DNS seed process the conditions from the seed root and "up the tree" or in the opposite direction? For the sake of argument, I'm going to assume we want to take a (DNS-wise) logical approach, i.e. interpreting from the seed root and "up the tree", so in the order: n10, a4, n5, a2, r0. 1. What happens to a2 when we meet a4? Should a4 replace any current a condition or simply be ignored (or in the case of a perhaps even merged through a bitwise or)? Same question for n5when we meet n10. Personally I think it would make sense to always replace currently set conditions, when we hit new conditions with the same key. This would allow us to easily add a condition to a query programmatically, without having to interpret any conditions that may be set already. Prepending a current query string with a6. would then guarantee that an earlier condition does not limit my results to either IPv4 or IPv6 nodes. As long as the length of the query string does not exceed a total of 253 chars (standard DNS limitation, not counting the root .). Any thoughts on this? /Thomas ________________________________ From: Christian Decker Sent: Friday, March 16, 2018 10:44:01 AM To: Thomas Steenholdt Cc: lightning-dev at lists.linuxfoundation.org Subject: Re: DNS Seed query semantics clarification Thomas Steenholdt writes: > Thanks for the explanation - This was exactly the the piece of the > puzzle I was missing. ? > > I'd be happy to help clarify this in the BOLT10 specification, if that > makes any type of sense? I can make a pull request for revie Absolutely, improvements are always welcome :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ZmnSCPxj at protonmail.com Fri Mar 23 15:29:19 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Fri, 23 Mar 2018 11:29:19 -0400 Subject: [Lightning-dev] Towards a gridlike Lightning Network In-Reply-To: References: Message-ID: Good morning list, Igor Cota has started implementing my idea: https://github.com/icota/presto/commit/3311785e660d840f0ac8f2e333d0f0097aec980e This forced me to actually start thinking more deeply about the algorithm I gave. 1. We should use a well-used hash algorithm, such as RIPEMD160(SHA256(x)) 2. We should specify the size of `i` - 32-bits, 4 bytes - and indicate its endianness. Let us use big-endian, as is typical for the rest of Lightning and for network order. 3. My original algorithm had a significant probability of diverging. So I respecify the termination condition later. 4. Our own node should be part of the original working set. 5. In the decimation loop, start with the highest bit. This is the 7-index bit (1 << 7) of the first byte in the 20-byte hash (we treat the hash as a big-endian 160-bit number). The modified termination condition for the decimation loop is below: * If the working set is 7 nodes or more, decimate (i.e. match the next bit in the hashes and remove those that do not match our own hash in that bit.). * If the working set is 3 to 6 nodes, stop, that is now the members of the superhub and we then sort them by hash and decide our position in the superhub (who will channel to us and who we will channel to). * If the working set is 1 or 2 nodes, fail to form a superhub. Increment `i` and restart. Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ??????? Original Message ??????? On March 20, 2018 11:19 AM, ZmnSCPxj via Lightning-dev wrote: > Good morning list, > > As my award-winning and supremely notable and talked-about-by-the-man-on-the-street article "Cyclic Superhubs as Solution Towards Reasonable Lightning Network Topography" points out, cycles are a good way to organize the LN in order to allow easier accessibility to the network for all participants of all kinds. > > An issue here is the need for coordination in order to set up cyclic superhubs. A node acting by itself cannot form cyclic superhubs. > > However, one can consider that coordination is needed only to identify peers with which one forms superhubs. But we already have a system that identifies peers: the node gossip. > > So let us assume: All nodes have similar-enough views of the publicly-visible peers on the node graph, as built by node gossip. > > I now present an algorithm, which given a set of nodes extracted from node gossip, returns a peer to try connecting and funding a channel to. > > -- > > First, start with a 32-bit number i = 0. > > For each node, get hash = H(i || pubkey), where H is some standard hash algorithm, and pubkey is the public key of the node. Also get our_hash = H(i || our_pubkey) > > Perform successive filtering. While the set is larger than 2 nodes, successively compare high bits. If the highest bit of hash does not match the highest bit of our_hash, remove it from the set. If the resulting set is still larger than 2, match the next bit. When the set is now 2 or 1 node, back off by one bit and add back the most recently removed nodes. This yields a set that is at least 3 or more nodes. > > Sort the nodes according to hash. > > Identify where our node is in the sorted list. Then our candidate is the next node in the list, or if we are the last node, then the first node in the list. > > If the candidate already has a channel with us, or has no address info and cannot be found by DNS seed or so on, or cannot be contacted, or refuses incoming channels or some other error, then increment i and try finding again. > > --- > > Even if nodes have some divergence in their own local maps of the network, there is the chance that the difference will be filtered away and the nodes that are "destined" to form a superhub can still find each other in the same superhub. > > Assuming all nodes have the same routemap, then all nodes will form their own, non-overlapping superhubs for each i. However if some nodes get to increment i, hopefully because it already has a channel with its destined candidate peer at one value of i, it can then potentially form superhubs with other nodes that have also reached higher i. > > Regards, > ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: From ZmnSCPxj at protonmail.com Sat Mar 24 12:07:52 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Sat, 24 Mar 2018 08:07:52 -0400 Subject: [Lightning-dev] Towards a gridlike Lightning Network In-Reply-To: References: Message-ID: Good morning list, I have decided on a better termination condition for searching for a cyclic superhub. I re-describe below the algorithm: Start with `i` = 0 and a set of known nodes, including our own node. Iterate over `i`: - Compute hash = H(i || pubkey) for each node. H = RIPEMD160 . SHA256, serialize `i` as a big-endian 32-bit number. Also compute our_hash = H(i || our_pubkey) for our self. Put this in a working set. - Iterate over bits (start with the 7th bit (128) of the first byte): - - Split the working set into two sets, the matching set and the non-matching set, where the bit in the hash matches the bit in our_hash. - - If the non-matching set is empty, skip to the next bit. - - If the matching set is 1 or 2 members, or the non-matching set is 1 or 2 members, merge the two sets together into the working set and exit this loop: we have found a cyclic superhub. - - else set the working set to the matching set. - Sort the set according to the hash (treat the hash as a 160-bit big-endian number). - We should open a channel to the node after us in the sorted list; if we are the last, wrap around to the first node in the list. Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ??????? Original Message ??????? On March 23, 2018 11:29 PM, ZmnSCPxj wrote: > Good morning list, > > Igor Cota has started implementing my idea: https://github.com/icota/presto/commit/3311785e660d840f0ac8f2e333d0f0097aec980e > > This forced me to actually start thinking more deeply about the algorithm I gave. > > 1. We should use a well-used hash algorithm, such as RIPEMD160(SHA256(x)) > 2. We should specify the size of `i` - 32-bits, 4 bytes - and indicate its endianness. Let us use big-endian, as is typical for the rest of Lightning and for network order. > 3. My original algorithm had a significant probability of diverging. So I respecify the termination condition later. > 4. Our own node should be part of the original working set. > 5. In the decimation loop, start with the highest bit. This is the 7-index bit (1 << 7) of the first byte in the 20-byte hash (we treat the hash as a big-endian 160-bit number). > > The modified termination condition for the decimation loop is below: > > * If the working set is 7 nodes or more, decimate (i.e. match the next bit in the hashes and remove those that do not match our own hash in that bit.). > * If the working set is 3 to 6 nodes, stop, that is now the members of the superhub and we then sort them by hash and decide our position in the superhub (who will channel to us and who we will channel to). > * If the working set is 1 or 2 nodes, fail to form a superhub. Increment `i` and restart. > > Regards, > ZmnSCPxj > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > > ??????? Original Message ??????? > On March 20, 2018 11:19 AM, ZmnSCPxj via Lightning-dev wrote: > >> Good morning list, >> >> As my award-winning and supremely notable and talked-about-by-the-man-on-the-street article "Cyclic Superhubs as Solution Towards Reasonable Lightning Network Topography" points out, cycles are a good way to organize the LN in order to allow easier accessibility to the network for all participants of all kinds. >> >> An issue here is the need for coordination in order to set up cyclic superhubs. A node acting by itself cannot form cyclic superhubs. >> >> However, one can consider that coordination is needed only to identify peers with which one forms superhubs. But we already have a system that identifies peers: the node gossip. >> >> So let us assume: All nodes have similar-enough views of the publicly-visible peers on the node graph, as built by node gossip. >> >> I now present an algorithm, which given a set of nodes extracted from node gossip, returns a peer to try connecting and funding a channel to. >> >> -- >> >> First, start with a 32-bit number i = 0. >> >> For each node, get hash = H(i || pubkey), where H is some standard hash algorithm, and pubkey is the public key of the node. Also get our_hash = H(i || our_pubkey) >> >> Perform successive filtering. While the set is larger than 2 nodes, successively compare high bits. If the highest bit of hash does not match the highest bit of our_hash, remove it from the set. If the resulting set is still larger than 2, match the next bit. When the set is now 2 or 1 node, back off by one bit and add back the most recently removed nodes. This yields a set that is at least 3 or more nodes. >> >> Sort the nodes according to hash. >> >> Identify where our node is in the sorted list. Then our candidate is the next node in the list, or if we are the last node, then the first node in the list. >> >> If the candidate already has a channel with us, or has no address info and cannot be found by DNS seed or so on, or cannot be contacted, or refuses incoming channels or some other error, then increment i and try finding again. >> >> --- >> >> Even if nodes have some divergence in their own local maps of the network, there is the chance that the difference will be filtered away and the nodes that are "destined" to form a superhub can still find each other in the same superhub. >> >> Assuming all nodes have the same routemap, then all nodes will form their own, non-overlapping superhubs for each i. However if some nodes get to increment i, hopefully because it already has a channel with its destined candidate peer at one value of i, it can then potentially form superhubs with other nodes that have also reached higher i. >> >> Regards, >> ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: From federicotenga at gmail.com Sat Mar 17 10:56:05 2018 From: federicotenga at gmail.com (Federico Tenga) Date: Sat, 17 Mar 2018 11:56:05 +0100 Subject: [Lightning-dev] Can I try Lightning without running a fully-fledged bitcoin block chain? In-Reply-To: <20180317090238.GC5074@HP> References: <20180317090238.GC5074@HP> Message-ID: You can try pruning, you will still have to validate the whole chain so it takes time, but you won't need to store all the blockchain on your disk. On 17 March 2018 at 10:02, Yubin Ruan wrote: > I just don't have so much space for a storing the whole blockchain on my > laptop. > > Yubin > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh at digiledge.com Tue Mar 27 01:12:08 2018 From: mahesh at digiledge.com (Mahesh Govind) Date: Tue, 27 Mar 2018 06:42:08 +0530 Subject: [Lightning-dev] Lightning network implementation with ethereum Message-ID: Dear Experts, Could you please let me know the implementation I could use with ethereum . With thanks and regards mahesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From 012mistery at frankentrikes.com Tue Mar 27 03:26:53 2018 From: 012mistery at frankentrikes.com (Segue) Date: Mon, 26 Mar 2018 20:26:53 -0700 Subject: [Lightning-dev] Can I try Lightning without running a fully-fledged bitcoin block chain? In-Reply-To: <7eaf1653-dc82-693b-b41d-1b2ef53cc995@frankentrikes.com> References: <7eaf1653-dc82-693b-b41d-1b2ef53cc995@frankentrikes.com> Message-ID: Developers, On THIS note and slightly off-topic but relevant, why can't chunks of blockchain peel off the backend periodically and be archived, say on minimum of 150 computers across 7 continents? It seems crazy to continue adding on to an increasingly long chain to infinity if the old chapters (i.e. more than, say, 2 years old) could be stored in an evenly distributed manner across the planet.? The same 150 computers would not need to store every chapter either, just the index would need to be widely distributed in order to reconnect with a chapter if needed. Then maybe it is no longer a limitation in the future for people like Yubin. Segue On 3/26/18 6:12 PM, lightning-dev-request at lists.linuxfoundation.org wrote: > Message: 2 > Date: Sat, 17 Mar 2018 11:56:05 +0100 > From: Federico Tenga > To: Yubin Ruan > Cc:lightning-dev at lists.linuxfoundation.org > Subject: Re: [Lightning-dev] Can I try Lightning without running a > fully-fledged bitcoin block chain? > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > You can try pruning, you will still have to validate the whole chain so it > takes time, but you won't need to store all the blockchain on your disk. > > On 17 March 2018 at 10:02, Yubin Ruan wrote: > >> I just don't have so much space for a storing the whole blockchain on my >> laptop. >> >> Yubin >> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From karanverma at alumni.stanford.edu Tue Mar 27 03:57:57 2018 From: karanverma at alumni.stanford.edu (Karan Verma) Date: Tue, 27 Mar 2018 03:57:57 +0000 Subject: [Lightning-dev] Opening channels with neighbors for cost/connectivity benefit Message-ID: Hello, The sender node doesn?t always have a route to the receiving node accepting lightning payments and since opening new channels is costly - I was wondering if there was a smarter way to open channels such that it increases the connectedness of the sender node with other nodes in the network and also possibly save money?in the intended transaction. To clarify, if Bob wants to send money to Alice but doesn?t have a route to her. He would need to open a?new channel with Alice and send the money. This is costly for Bob if that was the only transaction he ever wanted to do with Alice. However, if Alice was connected to Charlie and Dave (Unidirectional: Charlie -> Alice & Dave -> Alice due to the amount being sent). He could instead connect with Charlie/Dave or nodes connected with them which have a route to Alice through Charlie/Dave such that it minimizes the transaction cost to reaching Alice (some routes might have negative fee)?and maximizes the number of nodes Bob can now reach through this channel. Lets say if Bob chose Charlie's neighbor, then he can now reach at-least three nodes - Charlie's neighbor, Charlie and Alice and end up paying less. Essentially we're sorting choice of the nodes to open a channel with by transaction fee and connectedness it brings to the origin node. This would benefit Bob in the long term and also maybe lightning network as a whole. I'm new to lightning and would appreciate feedback on this idea. Thanks. -Karan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ZmnSCPxj at protonmail.com Wed Mar 28 05:00:49 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Wed, 28 Mar 2018 01:00:49 -0400 Subject: [Lightning-dev] Can I try Lightning without running a fully-fledged bitcoin block chain? In-Reply-To: References: <7eaf1653-dc82-693b-b41d-1b2ef53cc995@frankentrikes.com> Message-ID: <7syNdTVtsBVRm29yVjQzY1P6Ytm-u8c3RjWxJGk2Zk8gR1L7wQRAQfJDSKe2klmk3PDHY9VjnP_v6hOIsgLeAAMIvjmt4hAE8ch_VSkctEY=@protonmail.com> Good morning Segue, Please consider creating an implementation of this idea for bitcoind and share it on bitcoin-dev. Then please make a pull request on github.com/bitcoin/bitcoin for this. Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ??????? Original Message ??????? On March 27, 2018 11:26 AM, Segue <012mistery at frankentrikes.com> wrote: > Developers, > > On THIS note and slightly off-topic but relevant, why can't chunks of blockchain peel off the backend periodically and be archived, say on minimum of 150 computers across 7 continents? > > It seems crazy to continue adding on to an increasingly long chain to infinity if the old chapters (i.e. more than, say, 2 years old) could be stored in an evenly distributed manner across the planet. The same 150 computers would not need to store every chapter either, just the index would need to be widely distributed in order to reconnect with a chapter if needed. > > Then maybe it is no longer a limitation in the future for people like Yubin. > > Segue > > On 3/26/18 6:12 PM, lightning-dev-request at lists.linuxfoundation.org wrote: > >> Message: 2 >> Date: Sat, 17 Mar 2018 11:56:05 +0100 >> From: Federico Tenga >> [](mailto:federicotenga at gmail.com) >> To: Yubin Ruan >> [](mailto:ablacktshirt at gmail.com) >> Cc: >> lightning-dev at lists.linuxfoundation.org >> Subject: Re: [Lightning-dev] Can I try Lightning without running a >> fully-fledged bitcoin block chain? >> Message-ID: >> [](mailto:CAP=-fx4APtKw-x08kQ_+y7bEh-EbGfPmSCGQDBrZn0Fh-NNjAQ at mail.gmail.com) >> Content-Type: text/plain; charset="utf-8" >> >> You can try pruning, you will still have to validate the whole chain so it >> takes time, but you won't need to store all the blockchain on your disk. >> >> On 17 March 2018 at 10:02, Yubin Ruan >> [](mailto:ablacktshirt at gmail.com) >> wrote: >> >>> I just don't have so much space for a storing the whole blockchain on my >>> laptop. >>> >>> Yubin >>> >>> _______________________________________________ >>> Lightning-dev mailing list >>> Lightning-dev at lists.linuxfoundation.org >>> >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ZmnSCPxj at protonmail.com Wed Mar 28 05:41:10 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Wed, 28 Mar 2018 01:41:10 -0400 Subject: [Lightning-dev] Opening channels with neighbors for cost/connectivity benefit In-Reply-To: References: Message-ID: Good morning Karan, Channel direction cannot be determined publicly, as sharing that information would be equivalent to broadcasting how much you own on a channel to everyone, and updating everyone about each transaction made on that channel. This hurts privacy. I believe lnd implements the Barabasi-Albert model which tries to look for hub nodes and preferentially attaches to those, but I worry that this would cause effective centralization of the network, which will hurt privacy and possibly network availability. See also my recent pointless rants about cyclic superhubs. These encourage a gridlike network with good alternative routes, but is not implemented by anyone at all yet, making it pointless to implement in the first place, since they would work only if everybody strongly prefers them. It also does not handle very well when a good number of nodes are shut down regularly, or are buggy, and you would strongly want to have atomic multipath payments in order to be able to spread out your counterparty risk to more nodes. Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ??????? Original Message ??????? On March 27, 2018 11:57 AM, Karan Verma wrote: > Hello, > > The sender node doesn?t always have a route to the receiving node accepting lightning payments and since opening new channels is costly - I was wondering if there was a smarter way to open channels such that it increases the connectedness of the sender node with other nodes in the network and also possibly save money in the intended transaction. > > To clarify, if Bob wants to send money to Alice but doesn?t have a route to her. He would need to open a new channel with Alice and send the money. This is costly for Bob if that was the only transaction he ever wanted to do with Alice. However, if Alice was connected to Charlie and Dave (Unidirectional: Charlie -> Alice & Dave -> Alice due to the amount being sent). He could instead connect with Charlie/Dave or nodes connected with them which have a route to Alice through Charlie/Dave such that it minimizes the transaction cost to reaching Alice (some routes might have negative fee) and maximizes the number of nodes Bob can now reach through this channel. Lets say if Bob chose Charlie's neighbor, then he can now reach at-least three nodes - Charlie's neighbor, Charlie and Alice and end up paying less. > > Essentially we're sorting choice of the nodes to open a channel with by transaction fee and connectedness it brings to the origin node. This would benefit Bob in the long term and also maybe lightning network as a whole. I'm new to lightning and would appreciate feedback on this idea. Thanks. > > -Karan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh at digiledge.com Wed Mar 28 08:21:34 2018 From: mahesh at digiledge.com (Mahesh Govind) Date: Wed, 28 Mar 2018 13:51:34 +0530 Subject: [Lightning-dev] Can I try Lightning without running a fully-fledged bitcoin block chain? In-Reply-To: <7syNdTVtsBVRm29yVjQzY1P6Ytm-u8c3RjWxJGk2Zk8gR1L7wQRAQfJDSKe2klmk3PDHY9VjnP_v6hOIsgLeAAMIvjmt4hAE8ch_VSkctEY=@protonmail.com> References: <7eaf1653-dc82-693b-b41d-1b2ef53cc995@frankentrikes.com> <7syNdTVtsBVRm29yVjQzY1P6Ytm-u8c3RjWxJGk2Zk8gR1L7wQRAQfJDSKe2klmk3PDHY9VjnP_v6hOIsgLeAAMIvjmt4hAE8ch_VSkctEY=@protonmail.com> Message-ID: Could we use similar technique used in hyperledger to prune the chain . Pruning based on consensus ? -mahesh On Wed, Mar 28, 2018 at 10:30 AM, ZmnSCPxj via Lightning-dev < lightning-dev at lists.linuxfoundation.org> wrote: > Good morning Segue, > > Please consider creating an implementation of this idea for bitcoind and > share it on bitcoin-dev. Then please make a pull request on > github.com/bitcoin/bitcoin for this. > > Regards, > ZmnSCPxj > > > Sent with ProtonMail Secure Email. > > ??????? Original Message ??????? > On March 27, 2018 11:26 AM, Segue <012mistery at frankentrikes.com> wrote: > > Developers, > > > On THIS note and slightly off-topic but relevant, why can't chunks of > blockchain peel off the backend periodically and be archived, say on > minimum of 150 computers across 7 continents? > > It seems crazy to continue adding on to an increasingly long chain to > infinity if the old chapters (i.e. more than, say, 2 years old) could be > stored in an evenly distributed manner across the planet. The same 150 > computers would not need to store every chapter either, just the index > would need to be widely distributed in order to reconnect with a chapter if > needed. > > Then maybe it is no longer a limitation in the future for people like > Yubin. > > Segue > > > > On 3/26/18 6:12 PM, lightning-dev-request at lists.linuxfoundation.org wrote: > > Message: 2 > Date: Sat, 17 Mar 2018 11:56:05 +0100 > From: Federico Tenga > To: Yubin Ruan > Cc: lightning-dev at lists.linuxfoundation.org > Subject: Re: [Lightning-dev] Can I try Lightning without running a > fully-fledged bitcoin block chain? > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > You can try pruning, you will still have to validate the whole chain so it > takes time, but you won't need to store all the blockchain on your disk. > > On 17 March 2018 at 10:02, Yubin Ruan wrote: > > > I just don't have so much space for a storing the whole blockchain on my > laptop. > > Yubin > > _______________________________________________ > Lightning-dev mailing listLightning-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.pickhardt at googlemail.com Wed Mar 28 08:57:20 2018 From: r.pickhardt at googlemail.com (=?UTF-8?Q?Ren=C3=A9_Pickhardt?=) Date: Wed, 28 Mar 2018 08:57:20 +0000 Subject: [Lightning-dev] Fwd: Opening channels with neighbors for cost/connectivity benefit In-Reply-To: References: Message-ID: Sorry I sent this mail by accident only to Karan. ---------- Forwarded message --------- From: Ren? Pickhardt Date: Di., 27. M?rz 2018 11:10 Subject: Re: [Lightning-dev] Opening channels with neighbors for cost/connectivity benefit To: Karan Verma Dear karan, There is a feature called autopilot in the lnd implementation that tries to achieve something similar to what you describe. However the problem is much harder than just using some plausible heuristic. I have an open issue on github discussing these problems: https://github.com/lightningnetwork/lnd/issues/677 >From there I also linked a draft of a whitepaper that I am working on in which I plan to discuss ways of automatically create a well connected network topology fitting the specific needs of the peers in the lightning network. Your help and ideas would be appreciated. Also you could just implement your idea in the lnd autopilot interface Best regards Rene Pickhardt Karan Verma schrieb am Di., 27. M?rz 2018 05:58: > Hello, > > The sender node doesn?t always have a route to the receiving node > accepting lightning payments and since opening new channels is costly - I > was wondering if there was a smarter way to open channels such that it > increases the connectedness of the sender node with other nodes in the > network and also possibly save money in the intended transaction. > > To clarify, if Bob wants to send money to Alice but doesn?t have a route > to her. He would need to open a new channel with Alice and send the money. > This is costly for Bob if that was the only transaction he ever wanted to > do with Alice. However, if Alice was connected to Charlie and Dave > (Unidirectional: Charlie -> Alice & Dave -> Alice due to the amount being > sent). He could instead connect with Charlie/Dave or nodes connected with > them which have a route to Alice through Charlie/Dave such that it > minimizes the transaction cost to reaching Alice (some routes might have > negative fee) and maximizes the number of nodes Bob can now reach through > this channel. Lets say if Bob chose Charlie's neighbor, then he can now > reach at-least three nodes - Charlie's neighbor, Charlie and Alice and end > up paying less. > > Essentially we're sorting choice of the nodes to open a channel with by > transaction fee and connectedness it brings to the origin node. This would > benefit Bob in the long term and also maybe lightning network as a whole. > I'm new to lightning and would appreciate feedback on this idea. Thanks. > > -Karan > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From decker.christian at gmail.com Fri Mar 30 14:04:20 2018 From: decker.christian at gmail.com (Christian Decker) Date: Fri, 30 Mar 2018 16:04:20 +0200 Subject: [Lightning-dev] Lightning network implementation with ethereum In-Reply-To: References: Message-ID: <87vaddd5i3.fsf@gmail.com> Dear Mahesh, that's a very interesting question, to be best of my knowledge there is no working implementation for Ethereum and I don't think anybody is working on one currently. There is the Raiden network attempt at porting a Lightning-like network to Ethereum, but I'm not sure what the current status of that project is. A direct port is probably not possible due to the differences in the underlying blockchain, but a Lightning-like network is definitely possible. Cheers, Christian Mahesh Govind writes: > Dear Experts, > > Could you please let me know the implementation I could use with ethereum . > > With thanks and regards > mahesh > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev From decker.christian at gmail.com Fri Mar 30 14:06:27 2018 From: decker.christian at gmail.com (Christian Decker) Date: Fri, 30 Mar 2018 16:06:27 +0200 Subject: [Lightning-dev] Can I try Lightning without running a fully-fledged bitcoin block chain? In-Reply-To: References: <7eaf1653-dc82-693b-b41d-1b2ef53cc995@frankentrikes.com> <7syNdTVtsBVRm29yVjQzY1P6Ytm-u8c3RjWxJGk2Zk8gR1L7wQRAQfJDSKe2klmk3PDHY9VjnP_v6hOIsgLeAAMIvjmt4hAE8ch_VSkctEY=@protonmail.com> Message-ID: <87sh8hd5ek.fsf@gmail.com> Dear Mahesh, as interesting as the discussion of alternative blockchain storage it, it is probably off-topic for the Lightning mailing list. So I'd suggest taking this discussion to either the bitcoin-dev or bitcoin-core-dev mailing lists. Cheers, Christian Mahesh Govind writes: > Could we use similar technique used in hyperledger to prune the chain . > Pruning based on consensus ? > -mahesh > > On Wed, Mar 28, 2018 at 10:30 AM, ZmnSCPxj via Lightning-dev < > lightning-dev at lists.linuxfoundation.org> wrote: > >> Good morning Segue, >> >> Please consider creating an implementation of this idea for bitcoind and >> share it on bitcoin-dev. Then please make a pull request on >> github.com/bitcoin/bitcoin for this. >> >> Regards, >> ZmnSCPxj >> >> >> Sent with ProtonMail Secure Email. >> >> ??????? Original Message ??????? >> On March 27, 2018 11:26 AM, Segue <012mistery at frankentrikes.com> wrote: >> >> Developers, >> >> >> On THIS note and slightly off-topic but relevant, why can't chunks of >> blockchain peel off the backend periodically and be archived, say on >> minimum of 150 computers across 7 continents? >> >> It seems crazy to continue adding on to an increasingly long chain to >> infinity if the old chapters (i.e. more than, say, 2 years old) could be >> stored in an evenly distributed manner across the planet. The same 150 >> computers would not need to store every chapter either, just the index >> would need to be widely distributed in order to reconnect with a chapter if >> needed. >> >> Then maybe it is no longer a limitation in the future for people like >> Yubin. >> >> Segue >> >> >> >> On 3/26/18 6:12 PM, lightning-dev-request at lists.linuxfoundation.org wrote: >> >> Message: 2 >> Date: Sat, 17 Mar 2018 11:56:05 +0100 >> From: Federico Tenga >> To: Yubin Ruan >> Cc: lightning-dev at lists.linuxfoundation.org >> Subject: Re: [Lightning-dev] Can I try Lightning without running a >> fully-fledged bitcoin block chain? >> Message-ID: >> >> Content-Type: text/plain; charset="utf-8" >> >> You can try pruning, you will still have to validate the whole chain so it >> takes time, but you won't need to store all the blockchain on your disk. >> >> On 17 March 2018 at 10:02, Yubin Ruan wrote: >> >> >> I just don't have so much space for a storing the whole blockchain on my >> laptop. >> >> Yubin >> >> _______________________________________________ >> Lightning-dev mailing listLightning-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >> >> >> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev From a.ranchalpedrosa at gmail.com Thu Mar 29 15:10:37 2018 From: a.ranchalpedrosa at gmail.com (Alejandro Ranchal Pedrosa) Date: Thu, 29 Mar 2018 17:10:37 +0200 Subject: [Lightning-dev] An Idea to Improve Connectivity of the Graph Message-ID: Hello all, Christian Decker pointed the following out (source:https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000991.html): >I'd also like to point out that the way we do state invalidations in >Lightning is not really suited for multi-party negotiations beyond 2 >parties. The number of potential reactions to a party cheating grows >exponentially in the number of parties in the contract, which is the >reason the Channel Factories paper relies on the Duplex Micropayment >Channel construction instead of the retaliation construction in LN. Can somebody ellaborate on this assumption? Best, Alejandro. -------------- next part -------------- An HTML attachment was scrubbed... URL: