Re: [Lightning-dev] Trustless Watchtowers
Quick correction: > Thus, the cost to perform the attack would be many orders of > magnitude greater than the cost to back up one channel. This was written assuming the attacker was trying to upload multiple encrypted blobs for the same txid, which seems like an unlikely attack vector if the tower inherently defends against it. If instead they are just trying to fill up the tower, the cost is linear in the amount of blobs they send. --Conner On Tue, Nov 13, 2018 at 4:12 PM Conner Fromknecht wrote: > > Hi ZmnSCPxj, > > I haven't yet gotten around to writing up everything documenting in the > working > watchtower design. However, I think we are nearing that phase where things > seem > mostly solidified and would welcome feedback before attempting to formalize > it. > Expect some follow up posts on the ML :) > > > From my bare knowledge of go, it seems data structures and messages so far, > > without actual logic, but please inform me if I am incorrect. > > Much of the server side has been implemented, which accepts encrypted blobs > from > watchtower clients and stores them. The functionality related to scanning > blocks > and publishing justice txns has also been implemented, but has not been merged > yet. The big remaining task is to integrate the client such that it properly > backs up states after receiving revocations from the remote peer. > > > Note however that watchtowers would require to keep all encrypted blobs that > > are keyed to the same partial txid. I.e. watchtowers need to store the pair > > in a set with the set looking at the entire txid+blob as the identity of the > > object. Otherwise it would be possible, if your watchtower is identified by > > your counterparty, for the counterparty to give the commitment transaction's > > txid with a randomly-generated blob to your watchtower before it gives the > > revocation key to you. > > > > I have described the above problem before here: > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html > > with an unsatisfactory solution. > > Indeed, this was great observation! The tower can't be sure which client is > uploading the "real" blob either. In light of that, the chosen design uses a > two level bucketing structure that maps: > >-> client_pubkey1 : encrypted_blob1 > -> client_pubkey2 : encrypted_blob2 > > ensuring that different client's can't overwrite each other. Further, the > tower > will only store one blob for a given txid per client. Upon decryption, the > tower > would learn that only one of this a valid update (and possibly delete state > for > the offender). > > > However, this remains your counterparty best avenue of attack, is to simply > > spam your watchtower until it runs out of resources and crashes. > > The client pubkeys described above are tied to what we've been referring to > as a > session. In order for a client to facilitate the attack described above, they > would have to pay the tower for multiple sessions tied to different ephemeral > session keys. > > A session grants the client the ability to store up to N blobs, where N would > be > several thousand. Thus, the cost to perform the attack would be many orders of > magnitude greater than the cost to back up one channel. In the private tower > case, there isn't necessarily payment, though it's more or less assumed that > one > wouldn't DOS their own tower. > > In practice, the tower should only ever accept sessions if it can be certain > it > has the appropriate disk-space to facilitate them, so I don't think > there is much > risk in the node crashing due to this. Someone could still pay to fill > up my tower, > but the tower would be compensated appropriately. The tower could also raise > it's price point if it detects such behavior. > > > And if the watchtower identifies the user, then this leaks the privacy of > > the > > user to the watchtower, and what would then be the point of encrypted blob? > > I believe the same session-based, encrypted-blob approach would work eltoo > towers as well, if the concern is primarily about the channel partner > presuming > the valid blob. The general design should be readily able to serve > eltoo clients, > with some slight modifications to breach detection and justice txn > construction. > > My greater concern with the update-and-replace model is that it leaks timing > information about a particular channel to the tower, since the tower must know > which prior state needs replacing. So even though it is possible to make eltoo > towers constant-space per channel, IMO we're better off storing all prior > encrypted blobs to maintain adequate privacy. On private towers, perhaps this > privacy/space tradeoff may acceptable, but not sure if the tradeoff makes > sense > on public towers. > > Cheers, > Conner > > On Mon, Nov 12, 2018 at 1:18 AM ZmnSCPxj via Lightning-dev > wrote: > > > > Good morning list, > > > > We were not able to discuss this topic much at
Re: [Lightning-dev] Trustless Watchtowers
Hi ZmnSCPxj, I haven't yet gotten around to writing up everything documenting in the working watchtower design. However, I think we are nearing that phase where things seem mostly solidified and would welcome feedback before attempting to formalize it. Expect some follow up posts on the ML :) > From my bare knowledge of go, it seems data structures and messages so far, > without actual logic, but please inform me if I am incorrect. Much of the server side has been implemented, which accepts encrypted blobs from watchtower clients and stores them. The functionality related to scanning blocks and publishing justice txns has also been implemented, but has not been merged yet. The big remaining task is to integrate the client such that it properly backs up states after receiving revocations from the remote peer. > Note however that watchtowers would require to keep all encrypted blobs that > are keyed to the same partial txid. I.e. watchtowers need to store the pair > in a set with the set looking at the entire txid+blob as the identity of the > object. Otherwise it would be possible, if your watchtower is identified by > your counterparty, for the counterparty to give the commitment transaction's > txid with a randomly-generated blob to your watchtower before it gives the > revocation key to you. > > I have described the above problem before here: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html > with an unsatisfactory solution. Indeed, this was great observation! The tower can't be sure which client is uploading the "real" blob either. In light of that, the chosen design uses a two level bucketing structure that maps: -> client_pubkey1 : encrypted_blob1 -> client_pubkey2 : encrypted_blob2 ensuring that different client's can't overwrite each other. Further, the tower will only store one blob for a given txid per client. Upon decryption, the tower would learn that only one of this a valid update (and possibly delete state for the offender). > However, this remains your counterparty best avenue of attack, is to simply > spam your watchtower until it runs out of resources and crashes. The client pubkeys described above are tied to what we've been referring to as a session. In order for a client to facilitate the attack described above, they would have to pay the tower for multiple sessions tied to different ephemeral session keys. A session grants the client the ability to store up to N blobs, where N would be several thousand. Thus, the cost to perform the attack would be many orders of magnitude greater than the cost to back up one channel. In the private tower case, there isn't necessarily payment, though it's more or less assumed that one wouldn't DOS their own tower. In practice, the tower should only ever accept sessions if it can be certain it has the appropriate disk-space to facilitate them, so I don't think there is much risk in the node crashing due to this. Someone could still pay to fill up my tower, but the tower would be compensated appropriately. The tower could also raise it's price point if it detects such behavior. > And if the watchtower identifies the user, then this leaks the privacy of the > user to the watchtower, and what would then be the point of encrypted blob? I believe the same session-based, encrypted-blob approach would work eltoo towers as well, if the concern is primarily about the channel partner presuming the valid blob. The general design should be readily able to serve eltoo clients, with some slight modifications to breach detection and justice txn construction. My greater concern with the update-and-replace model is that it leaks timing information about a particular channel to the tower, since the tower must know which prior state needs replacing. So even though it is possible to make eltoo towers constant-space per channel, IMO we're better off storing all prior encrypted blobs to maintain adequate privacy. On private towers, perhaps this privacy/space tradeoff may acceptable, but not sure if the tradeoff makes sense on public towers. Cheers, Conner On Mon, Nov 12, 2018 at 1:18 AM ZmnSCPxj via Lightning-dev wrote: > > Good morning list, > > We were not able to discuss this topic much at recent summit, but I noticed > that lnd has some code related to watchtowers already. From my bare > knowledge of go, it seems data structures and messages so far, without actual > logic, but please inform me if I am incorrect. > > I assume much of the watchtowers code and design in lnd is by Conner, simply > because, he discussed this on this list earlier this year. > > I have seen recently, some paper about paying watchtowers by actually > simulating breaches. You would give a watchtower some txid+blob pair, then > send that txid and see if the watchtower claims it. If it does, then you > have evidence of liveness and correct behavior, and have also paid for and > incentivized the watchtower to
Re: [Lightning-dev] Approximate assignment of option names: please fix!
Pierre writes: > Hi Rusty, > >>The feature masks are split into local features (which only >>affect the protocol between these two nodes) and global features >>(which can affect HTLCs and are thus also advertised to other >>nodes). > > I don't think that definition makes a lot of sense. For example I > probably want to advertise the fact that my node supports > option_data_loss_protect, which is a local feature. OTOH why would I > *not* want to avertise a feature that I support? I struggle to see > what is the point of making the distinction between local/global > actually. The theory was that local features concern direct peers, global features concern others (thus *must* be advertized by gossip). I *expected* local features to become ubiquitous over time, so by the time an implementation decided "I don't even want to talk to nodes without feature X" then most nodes would support feature X, so you could simply connect and you're probably OK. So the question becomes: 1. Do people want to pre-filter by local features? 2. If so, only some local features, or all of them? If only some, then we make those ones global features. If all, then we remove the local/global distinction altogether? Thanks, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Wumbological local AND global features
ZmnSCPxj via Lightning-dev writes: > Thus, I propose: > > * The local feature bit `option_i_wumbo_you_wumbo`, which indicates that the > node is willing to wumbo with its counterparty in the connection. > * The global feature bit `option_anyone_can_wumbo`, which indicates that the > node is willing to wumbo with any node. I think we need to name `option_anyone_can_wumbo` to `option_wumborama`? Otherwise, this looks excellent. Thanks, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Recovering protocol with watchtowers
Good morning Margherita, > In case of a breach while node A is offline, can the Watchtowers do anything? > In my solution, the function of backup is not destinated to substitute the > first function of the watchtower, that is monitoring the status channel, but > instead, the backup option can be considered as a sort of additional feature. Watchtowers being designed currently are keyed to a txid, whose appearance onchain triggers the watchtower behavior. Your scheme is keyed on a node public key. There is an immediate incompatibility here. The reason why txid is used, is to protect privacy of the node. The watchtower has no identifying information, and cannot have identifying information. The txid is for a transaction that is not broadcast (except in a breach attempt), so the watchtower cannot identify the node using it at all. This can be important, since a hack of the watchtower might give the hackers the ability to find nodes that could be vulnerable and possibly targetable for attack. Distributed backup may be better implemented using standard techniques such as DHT. > How does this scheme protect the privacy of a node? > This scheme protects the privacy of the node because the payload contained > the information of status channel and nonce-time are encrypted on the public > key of A. So the watchtowers cannot decrypt the payload and modify it (e.g. > with a higher nonce value as you wrote) since just A has the own private key. > > If you refer that another node can personify A and send the payload to a > watchtower, this is not possible since the payload has to contain the > channel_id between A and the specific watchtower, and this information is not > known by the other node of the network. So, A can discover a malicious > activity because that channel_id is not correct. It is indeed possible, and the `channel_id` is immaterial. All an attacker has to do is corrupt the backup data, not replace it with data that is favorable to it. With corrupted backup data, the operation of A is doomed and irrecoverable, especially if private keys or even just derivation paths are part of the backed-up data. > Please note also, that you cannot make a single channel with multiple peers; > [...] > As regarding the channel, If A has three watchtowers, it has to have three > distinct payment channels. Every watchtower is independence from the others. Then why is the watchtower keyed to the node? Should it not be keyed to something that is distinct for each payment channel? Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Base AMP
Good morning Conner, > > MUST NOT forward (if an intermediate node) or claim (if the final node) > > unless > > it has received a total greater or equal to `intended_total_payment` in all > > incoming HTLCs for the same `payment_hash`. > > I was under the impression that this would not require changes on behalf of > the > intermediaries, and only need to be implemented by the sender and receiver? Strictly, it needs to be implemented by the sender and any merge points it wants. We have been thinking in terms of the receiver being the merge point, but it would be possible, with this scheme, for the merge point to be anywhere along the paths to the receiver. A-->B--->C--- \ \ ->D--->E--->F--- \ \ >G--->H--->I--->J In the above, the ultimate payee is J, which is a merge point. F is an intermediate node, but merges two paths together before forwarding. Other intermediate nodes, B, C, D, E, G, H, and I, are not merge points and do not need to understand this. Only F and J need to be given some merge point information in the new `per_hop_type`. B, C, D, E, G, H, and I, will be given `per_hop_type` of 0. This also means that AMP can be performed without the ultimate payee being AMP-capable, as the below: A-->B-->C--- \ \ ->D-->E--->F-->G Splitting the entire payment needs to be done at the ultimate source always, but merging can be done at any point along the way. So yes, it would be valuable to advertise the ability to merge payments as a global feature bit, not on the invoice. Regards, ZmnSCPxj > If not, then nodes would need to advertise that they support this so that the > sender can be sure to route through the subset of nodes that support it. > > Either way, it would seem that this constraint can only be accurately enforced > by the receiver. If any partial payments fail, then the > `intended_total_payment` > through an intermediary may never arise and the payment would be held. This > would also seem to exclude the possibility of iterative path finding, since > the > entire payment flow must be known up front during onion packet construction. > > Seems the proposal still works without the intermediaries needing to know > this? > > We may want to add that the receiver: > > - SHOULD fail the payment if `intended_total_payment` is less than the > invoice > amount > > > > I'm wondering, since these payments are no longer atomic, should we name it > > accordingly? > > Indeed this true. Perhaps NAMP or CPHR (Concurrent Payment Hash Re-use) are > more > accurate and may avoid confusion? > > Cheers, > Conner > On Tue, Nov 13, 2018 at 8:33 AM Johan Torås Halseth joha...@gmail.com wrote: > > > Good evening Z and list, > > I'm wondering, since these payments are no longer atomic, should we name it > > accordingly? > > Cheers, > > Johan > > On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev > > lightning-dev@lists.linuxfoundation.org wrote: > > > > > Good morning list, > > > I propose the below to support Base AMP. > > > The below would allow arbitrary merges of paths, but not arbitrary > > > splits. I am uncertain about the safety of arbitrary splits. > > > > > > ### The `multipath_merge_per_hop` type (`option_base_amp`) > > > > > > This indicates that payment has been split by the sender using Base AMP, > > > and that the receiver should wait for the total intended payment before > > > forwarding or claiming the payment. > > > In case the receiving node is not the last node in the path, then > > > succeeding hops MUST be the same across all splits. > > > > > > 1. type: 1 (`termination_per_hop`) > > > 2. data: > > > > > > - [`8` : `short_channel_id`] > > > - [`8` : `amt_to_forward`] > > > - [`4` : `outgoing_cltv_value`] > > > - [`8` : `intended_total_payment`] > > > - [`4` : `zeros`] > > > > > > The contents of this hop will be the same across all paths of the Base > > > AMP. > > > The `payment_hash` of the incoming HTLCs will also be the same across all > > > paths of the Base AMP. > > > `intended_total_payment` is the total amount of money that this node > > > should expect to receive in all incoming paths to the same `payment_hash`. > > > This may be the last hop of a payment onion, in which case the `HMAC` for > > > this hop will be `0` (the same rule as for `per_hop_type` 0). > > > The receiver: > > > > > > - MUST impose a reasonable timeout for waiting to receive all component > > > paths, and fail all incoming HTLC offers for the `payment_hash` if they > > > have not totalled equal to `intended_total_payment`. > > > - MUST NOT forward (if an intermediate node) or claim (if the final > > > node) unless it has received a total greater or equal to > > > `intended_total_payment` in all incoming HTLCs for the same > > > `payment_hash`. > > > > > > The sender: > > > > > > - MUST use the
Re: [Lightning-dev] Recovering protocol with watchtowers
Hello ZmnSCPxj, thanks for your e-mail and your feedback, I'll answer your questions in the following points. In case of a breach while node A is offline, can the Watchtowers do anything? In my solution, the function of backup is not destinated to substitute the first function of the watchtower, that is monitoring the status channel, but instead, the backup option can be considered as a sort of additional feature. I haven't merged the two functions yet, but the idea is to collaborate to have watchtowers which can have the function of monitor the channel, so defend A when it is offline, but also the function of backup when A loses the data of past commitments (e.g. software doesn't work properly). So, I'd like to highlight that the two functions are independent. The reason because I'm using a watchtower is just because I need a full node online 24h, that can guarantee the service. In my solution, the payment channels are created ad-hoc for the backup mechanism, and in the commitment transaction between the node A and the Watchtower has to be added a new field that contains the current nonce-time and payload. How does this scheme protect the privacy of a node? This scheme protects the privacy of the node because the payload contained the information of status channel and nonce-time are encrypted on the public key of A. So the watchtowers cannot decrypt the payload and modify it (e.g. with a higher nonce value as you wrote) since just A has the own private key. If you refer that another node can personify A and send the payload to a watchtower, this is not possible since the payload has to contain the channel_id between A and the specific watchtower, and this information is not known by the other node of the network. So, A can discover a malicious activity because that channel_id is not correct. As I've written in the previous point, my work is independence from the function of monitoring the channel when node A is offline, so my project doesn't use the blob data. I hope to get the question, otherwise, could you explain a little bit more the point, please? Please note also, that you cannot make a single channel with multiple peers; [...] As regarding the channel, If A has three watchtowers, it has to have three distinct payment channels. Every watchtower is independence from the others. If you have any opinions/feedback/suggestions, please do not hesitate to write to me. : -) Kind regards, Margherita Da: ZmnSCPxj Inviato: martedì 13 novembre 2018 00:33:41 A: Margherita Favaretto Cc: lightning-dev@lists.linuxfoundation.org Oggetto: Re: [Lightning-dev] Recovering protocol with watchtowers Good morning Margherita, How does this scheme protect privacy of node? I would at least suggest that the pubkey used be different from the node normal pubkey. If I find out the pubkey of A, can I spoof A and give a higher nonce value with a blob containing random data (which is indistinguishable from a properly-implemented ciphertext) to the watchtowers of A? Presumably part of the protocol will require that any updates be signed using the key of A, otherwise I can easily corrupt the data being backed up for A. In case of a breach while node A is offline, can the Watchtowers do anything? Please note, that main purpose of Watchtowers is to handle breaches while client is offline, not backup. It would be pointless for Watchtower to exist if it can only provide data while A is online. The best time to attack A is when A is unable to defend itself. Please refer to https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001196.html for information on what we consider the best design for watchtowers so far. Please note also, that you cannot make a single channel with multiple peers; you must make a channel for each peer. (well it is theoretically possible, with eltoo, to make multi-party channel. but it requires all members to be online at every update, such that if a single party is offline, the channel is unuseable; having multiple 2-party channels with each peer is far better since if one of your peers drops, you can use the channels with other peers) Regards, ZmnSCPxj �\�\�\�\�\�\�\ Original Message �\�\�\�\�\�\�\ On Tuesday, November 13, 2018 2:59 AM, Margherita Favaretto wrote: Hello, dev-lightning community, I’m writing to you to share an update of my Thesis project (previous object e-mail: Recovering protocol for Lightning network 11/01/2018). I warn you that this message is quite long, but I hope that could be interesting for you, and then it would be great receiving your opinions. :-) The problem that I'm focusing on is the recovering mechanism of false positive in the Lightning network, that it is possible to re-define as how it is possible to have a solution of backup in the network in case of false positive nodes, with a particular attention to privacy and security. First of all, compared to the solution
Re: [Lightning-dev] Link-level payment splitting via intermediary rendezvous nodes
Good morning all, Taking a step back—even if key switching can be done mathematically, it seems dubious that we would want to introduce re-routing or rendezvous routing in this manner. If the example provided _could_ be done, it would directly violate the wrap-resistance property of the ideal onion routing scheme defined in [1]. This property is proven for Sphinx in section 4.3 of [2]. Schemes like HORNET [3] support rendezvous routing and are formally proven in this model. Seems this would be the obvious path forward, given that we've already done a considerable amount of work towards implementing HORNET via Sphinx. Cheers, Conner [1] A Formal Treatment of Onion Routing: https://www.iacr.org/cryptodb/archive/2005/CRYPTO/1091/1091.pdf [2] Sphinx: https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf [3] HORNET: https://arxiv.org/pdf/1507.05724.pdf On Mon, Nov 12, 2018 at 8:47 PM ZmnSCPxj via Lightning-dev wrote: > > Good morning Christian, > > I am nowhere near a mathematician, thus, cannot countercheck your expertise > here (and cannot give a counterproposal thusly). > > But I want to point out the below scenarios: > > 1. C is the payer. He is in contact with an unknown payee (who in reality > is E). E provides the onion-wrapped route D->E with ephemeral key and other > data necessary, as well as informing C that D is the rendez-vous point. Then > C creates a route from itself to D (via channel C->D or via C->A->D). > > 2. B is the payer. He knows the entire route B->C->D->E and knows that > payee is C. Unfortunately the C<->D channel is low capacity or down or etc > etc. At C, B has provided the onion-wrapped route D->E with ephemeral key > and other data necessary, as well as informing to C that D is the next node. > Then C either pays via C->D or via C->A->D. > > Even if there is an off-by-one error in our thinking about rendez-vous nodes, > could it not be compensated also by an off-by-one in the link-level payment > splitting via intermediary rendez-vous node? > In short, D is the one that switches keys instead of A. > > The operation of processing a hop would be: > > 1. Unwrap the onion with current ephemeral key. > 2. Dispatch based on realm byte. > 2.1. If realm byte 0: > 2.1.1. Normal routing behavior, extract HMAC, etc etc > 2.2. If realm byte 2 "switch ephemeral keys": > 2.2.1. Set current ephemeral key to bytes 1 -> 32 of packet. > 2.2.2. Shift onion by one hop packet. > 2.2.3. Goto 1. > > Would that not work? > (I am being naive here, as I am not a mathist and I did not understand half > what you wrote, sorry) > > Then at C, we have the onion from D->E, we also know the next ephemeral key > to use (we can derive it since we would pass it to D anyway). > It rightshifts the onion by one, storing the next ephemeral key to the new > hop it just allocated. > Then it encrypts the onion using a new ephemeral key that it will use to > generate the D<-A<-C part of the onion. > > Regards, > ZmnSCPxj > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, November 13, 2018 11:45 AM, Christian Decker > wrote: > > > Great proposal ZmnSCPxj, but I think I need to raise a small issue with > > it. While writing up the proposal for rendez-vous I came across a > > problem with the mechanism I described during the spec meeting: the > > padding at the rendez-vous point would usually zero-padded and then > > encrypted in one go with the shared secret that was generated from the > > previous ephemeral key (i.e., the one before the switch). That ephemeral > > key is not known to the recipient (barring additional rounds of > > communication) so the recipient would be unable to compute the correct > > MACs. There are a number of solutions to this, basically setting the > > padding to something that the recipient could know when generating its > > half onion. > > > > My current favorite goes like this: > > > > 1. Rendez-vous RV receives an onion, performs ECDH like normal to get > > the shared secret, decrypts its payload, simultaneously encrypts > > the padding. > > > > 2. It extracts its per-hop payload and shifts the entire packet over > > (shift its payload out and the newly generated padding in) > > > > 3. It then notices that it should perform an ephemeral key switch, now > > deviating from the normal protocol (which would just be to generate > > the new ephemeral key, serialize and forward) > > 3.1. It zero-fills the padding that it just added (so we are in a > > state that the recipient knew when generating its partial onion > > 3.2 It performs ECDH with the switched in ephemeral key to get a new > > shared secret that which is then used to unwrap one additional > > layer of encryption, and most importantly encrypt the padding so > > the next hop doesn't see the zero-filled padding. > > 3.3 Only then will it generate the new ephemeral key for the next > > hop, based on the switched
Re: [Lightning-dev] Base AMP
Good morning all, > MUST NOT forward (if an intermediate node) or claim (if the final node) unless > it has received a total greater or equal to `intended_total_payment` in all > incoming HTLCs for the same `payment_hash`. I was under the impression that this would not require changes on behalf of the intermediaries, and only need to be implemented by the sender and receiver? If not, then nodes would need to advertise that they support this so that the sender can be sure to route through the subset of nodes that support it. Either way, it would seem that this constraint can only be accurately enforced by the receiver. If any partial payments fail, then the `intended_total_payment` through an intermediary may never arise and the payment would be held. This would also seem to exclude the possibility of iterative path finding, since the entire payment flow must be known up front during onion packet construction. Seems the proposal still works without the intermediaries needing to know this? We may want to add that the receiver: * SHOULD fail the payment if `intended_total_payment` is less than the invoice amount > I'm wondering, since these payments are no longer atomic, should we name it > accordingly? Indeed this true. Perhaps NAMP or CPHR (Concurrent Payment Hash Re-use) are more accurate and may avoid confusion? Cheers, Conner On Tue, Nov 13, 2018 at 8:33 AM Johan Torås Halseth wrote: > > Good evening Z and list, > > I'm wondering, since these payments are no longer atomic, should we name it > accordingly? > > Cheers, > Johan > > On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev > wrote: >> >> Good morning list, >> >> I propose the below to support Base AMP. >> >> The below would allow arbitrary merges of paths, but not arbitrary splits. >> I am uncertain about the safety of arbitrary splits. >> >> ### The `multipath_merge_per_hop` type (`option_base_amp`) >> >> This indicates that payment has been split by the sender using Base AMP, and >> that the receiver should wait for the total intended payment before >> forwarding or claiming the payment. >> In case the receiving node is not the last node in the path, then succeeding >> hops MUST be the same across all splits. >> >> 1. type: 1 (`termination_per_hop`) >> 2. data: >> * [`8` : `short_channel_id`] >> * [`8` : `amt_to_forward`] >> * [`4` : `outgoing_cltv_value`] >> * [`8` : `intended_total_payment`] >> * [`4` : `zeros`] >> >> The contents of this hop will be the same across all paths of the Base AMP. >> The `payment_hash` of the incoming HTLCs will also be the same across all >> paths of the Base AMP. >> >> `intended_total_payment` is the total amount of money that this node should >> expect to receive in all incoming paths to the same `payment_hash`. >> >> This may be the last hop of a payment onion, in which case the `HMAC` for >> this hop will be `0` (the same rule as for `per_hop_type` 0). >> >> The receiver: >> >> * MUST impose a reasonable timeout for waiting to receive all component >> paths, and fail all incoming HTLC offers for the `payment_hash` if they >> have not totalled equal to `intended_total_payment`. >> * MUST NOT forward (if an intermediate node) or claim (if the final node) >> unless it has received a total greater or equal to `intended_total_payment` >> in all incoming HTLCs for the same `payment_hash`. >> >> The sender: >> >> * MUST use the same `payment_hash` for all paths of a single multipath >> payment. >> >> Regards, >> ZmnSCPxj >> ___ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Base AMP
Good evening Z and list, I'm wondering, since these payments are no longer atomic, should we name it accordingly? Cheers, Johan On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning list, > > I propose the below to support Base AMP. > > The below would allow arbitrary merges of paths, but not arbitrary > splits. I am uncertain about the safety of arbitrary splits. > > ### The `multipath_merge_per_hop` type (`option_base_amp`) > > This indicates that payment has been split by the sender using Base AMP, > and that the receiver should wait for the total intended payment before > forwarding or claiming the payment. > In case the receiving node is not the last node in the path, then > succeeding hops MUST be the same across all splits. > > 1. type: 1 (`termination_per_hop`) > 2. data: > * [`8` : `short_channel_id`] > * [`8` : `amt_to_forward`] > * [`4` : `outgoing_cltv_value`] > * [`8` : `intended_total_payment`] > * [`4` : `zeros`] > > The contents of this hop will be the same across all paths of the Base AMP. > The `payment_hash` of the incoming HTLCs will also be the same across all > paths of the Base AMP. > > `intended_total_payment` is the total amount of money that this node > should expect to receive in all incoming paths to the same `payment_hash`. > > This may be the last hop of a payment onion, in which case the `HMAC` for > this hop will be `0` (the same rule as for `per_hop_type` 0). > > The receiver: > > * MUST impose a reasonable timeout for waiting to receive all component > paths, and fail all incoming HTLC offers for the `payment_hash` if they > have not totalled equal to `intended_total_payment`. > * MUST NOT forward (if an intermediate node) or claim (if the final node) > unless it has received a total greater or equal to `intended_total_payment` > in all incoming HTLCs for the same `payment_hash`. > > The sender: > > * MUST use the same `payment_hash` for all paths of a single multipath > payment. > > Regards, > ZmnSCPxj > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Offline Lightning-enabled Vending Machines
Good morning list, During the summit, it was asked about an actual application problem for vending machines without any secret keys (so that hackers of vending machines cannot steal money from the machine). It was quite very satisfactorily solved by one of us, and I thought it would best shared and recorded for posterity (as it was not recorded in the wiki). The problem: 1. There exists a vending machine which must be offline and not contain any secret keys, in order to prevent theft from the machine. As the machine is not under direct control of the owner of the machine, it is better if the attack surface is reduced. 2. The owner of the vending machine (who is selling the product) has a separate, probably singular, Lightning node to receive payments. The solution: 1. Each vending machine contains a fixed number of hashes, as well as invoice signatures (signed by the owner Lightning node) corresponding to each hash. The number of hashes must at least equal the number of product for sale. The description of the product as well as the invoice price is fixed (after all, Bitcoin must be our unit of account). (for vending machines supporting multiple product types, simply multiply this table by the number of different product types) 2. Each hash has a 1-bit flag, initially 0. This flag is set to 1 when the hash has been claimed. 3. When a customer requests to purchase a product, the machine searches for a hash whose flag is 0. It generates the invoice (concatenating the description and price, and filling in the payment hash and invoice signature) and gives to customer. 4. The customer pays as normal. The vending machine owner node receives this payment and releases the preimage as proof-of-payment. 5. The customer gives the preimage to the machine, via QR code or via short-range radio technology such as bluetooth or NFC. 6. The machine checks the preimage, computes it hash, and checks if it is in the list of hashes. If so, and the claim flag is not set, it sets the flag and releases the product. OPEN PROBLEM: If product release fails due to mechanical failure, there is no way to easily refund the payment. 7. When replenishing the supply of product to the vending machine, the supply of hashes can also be replenished by the owner of the vending machine also. Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Approximate assignment of option names: please fix!
Hi Rusty, >The feature masks are split into local features (which only >affect the protocol between these two nodes) and global features >(which can affect HTLCs and are thus also advertised to other >nodes). I don't think that definition makes a lot of sense. For example I probably want to advertise the fact that my node supports option_data_loss_protect, which is a local feature. OTOH why would I *not* want to avertise a feature that I support? I struggle to see what is the point of making the distinction between local/global actually. Also, as ZmnSCPxj pointed out in his Wumbo-related post, just because I support a feature doesn't mean that I want to apply it to any peer that connects to my node. Since we can't advertise our whitelist or whatever logic we use to enable a given feature for a particular node, we can only be sure that a feature will be enabled by connecting to the peer and seeing what's in the init message. So how about just getting rid of the global/local distinction (I think this can be done in a backward-compatible way), and use the following instead: - in the node_announcement message, have a node_features that describes features my node supports/requires - in the init message, have a connection_features that are set for this particular connection. Obviously node_features/connection_features are related and must "match", in the sense that node_features constrains connection_features, particularly if we use things like option_anyone_can_wumbo (again referring to ZmnSCPxj's post). Cheers, Pierre ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Base AMP
Good morning list, I propose the below to support Base AMP. The below would allow arbitrary merges of paths, but not arbitrary splits. I am uncertain about the safety of arbitrary splits. ### The `multipath_merge_per_hop` type (`option_base_amp`) This indicates that payment has been split by the sender using Base AMP, and that the receiver should wait for the total intended payment before forwarding or claiming the payment. In case the receiving node is not the last node in the path, then succeeding hops MUST be the same across all splits. 1. type: 1 (`termination_per_hop`) 2. data: * [`8` : `short_channel_id`] * [`8` : `amt_to_forward`] * [`4` : `outgoing_cltv_value`] * [`8` : `intended_total_payment`] * [`4` : `zeros`] The contents of this hop will be the same across all paths of the Base AMP. The `payment_hash` of the incoming HTLCs will also be the same across all paths of the Base AMP. `intended_total_payment` is the total amount of money that this node should expect to receive in all incoming paths to the same `payment_hash`. This may be the last hop of a payment onion, in which case the `HMAC` for this hop will be `0` (the same rule as for `per_hop_type` 0). The receiver: * MUST impose a reasonable timeout for waiting to receive all component paths, and fail all incoming HTLC offers for the `payment_hash` if they have not totalled equal to `intended_total_payment`. * MUST NOT forward (if an intermediate node) or claim (if the final node) unless it has received a total greater or equal to `intended_total_payment` in all incoming HTLCs for the same `payment_hash`. The sender: * MUST use the same `payment_hash` for all paths of a single multipath payment. Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Wumbological local AND global features
Good morning list, I would like to propose, to make both a wumbo local AND global feature bit. The interpretation is to be as follows: * The local wumbo feature specifically means "I am willing to wumbo with you." * The global wumbo feature means "I am willing to wumbo with anyone". The primary reasoning for limited channel sizes is the risk with new software. Although we are reasonably sure that our software will not lose money that often anymore (we hope...), given the new features for 1.1, we should consider also to allow some more limitation to wumbo. Thus, I suggest that practical software would allow making a whitelist of node pubkeys with which the node owner considers safe to accept making wumbo channels with. And more reckless users may also set another option in the software for being willing to wumbo with any node. Thus, I propose: * The local feature bit `option_i_wumbo_you_wumbo`, which indicates that the node is willing to wumbo with its counterparty in the connection. * The global feature bit `option_anyone_can_wumbo`, which indicates that the node is willing to wumbo with any node. A node: * MUST set the local feature bit `option_i_wumbo_you_wumbo` if it sets the global feature bit `option_anyone_can_wumbo` in its announcement. * MAY clear the global feature bit `option_anyone_can_wumbo` even if it sends a set `option_i_wumbo_you_wumbo` to its peer. * MAY report different values for `option_i_wumbo_you_wumbo` to different nodes. * if it did not set the `option_i_wumbo_you_wumbo` feature bit reported to its counterparty: * MUST respond with an `error` if it receives `open_channel` with `funding_satoshis` value beyond the indicated limit for the chain, Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
