Re: [Lightning-dev] complementing lightning with with a discreet physical delivery protocol?
Good morning VzxPLnHqr, > Dear ZmnSCPxj, > > Thank you for your reply. I see how the vending machine can be mapped into > the Courier role. There are some questions around how to extend this to a > multi-courier situation, but let us solve that problem later and further > discuss the nuances of hodl-invoices. One thing that seems currently > difficult to ascertain right now is how much "time preference liquidity" (for > lack of a better term) there exists in the network. > > For example, let's say the Merchant is an on-demand furniture maker, and it > takes 90 days for her to produce the item. The protocol we are considering, > in its current naive form as contemplated in this email thread, stacks up a > sequence of hodl invoices which, at least in theory, tries to align the > incentives of Merchant, Courier, Purchaser. It could, of course, go even > further up/down the entire supply chain too. > > However, since the payments themselves are routed through the lightning > network, and, in the example here, stuck in this hodling-pattern for up to 90 > days, then any routing nodes along the way may feel they are not being fairly > compensated for having their funds locked up for such time. > > Do I correctly understand that moving to payment points[1] instead of HTLCs > can help reduce concern here by allowing each node along the route to earn a > fee irrespective of whether the hodl invoice is settled or canceled? This does not need payment points. *However*, this hodl-payment-problem has multiple proposed solutions (none of which *require* payment points, but should still be compatible with them), none of which have gained much support, since all of them kind of suck in one way or another. Payment points do allow for certain escrows to be created in a low-trust way, but they still involve holding PTLCs for long periods of time, and locking up funds until the escrow conditions are satisfied. Note that one may consider the hodl-invoice as a sort of escrow, and thus the generalized escrow services that are proposed in that series of blog posts is a strict superset of that, but they still involve PTLCs being unclaimed for long periods of time. > > Outside of doing a large-scale test on mainnet (which could quickly become > expensive and cause some unsuspecting node operators displeasure), is there > any way right now for a node operator to determine the likelihood of, for > example, being able to even route (e.g. receive payment but not yet be able > to settle) a 90-day hodl invoice? 0, since I think most implementations impose a maximum limit on the timelocks HTLCs passing through them, which is far lower than 90 days. Though I should probably go check the code, haha. -- I think the issue here is the just-in-time nature of the Merchant in your example. Consider an ahead-of-time furniture maker instead. The furniture maker can, like the vending machine example, simply consign furniture to a Vendor. The Vendor simply releases the already-built furniture conditional on receiving the payment secret (i.e. proof-of-payment) of an invoice issued by the Merchant. The payment secret could then use the payment point homomorphism. The Vendor acts as a Retailer, buying furniture at reduced prices, in bulk, from the Merchant. Because it buys in bulk, the Retailer+Merchant can probably afford to use a hodl PTLC directly onchain, instead of over Lightning, since they makes fewer but larger transactions, buying in bulk. On the other hand, this reduces flexibility --- end consumers can only choose among pre-built furniture, and cannot customize. Buying the flexibility that just-in-time gives requires us to pay with some deep thinking over here in Lightning-land on how to implement this without sucking. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] complementing lightning with with a discreet physical delivery protocol?
Dear ZmnSCPxj, Thank you for your reply. I see how the vending machine can be mapped into the Courier role. There are some questions around how to extend this to a multi-courier situation, but let us solve that problem later and further discuss the nuances of hodl-invoices. One thing that seems currently difficult to ascertain right now is how much "time preference liquidity" (for lack of a better term) there exists in the network. For example, let's say the Merchant is an on-demand furniture maker, and it takes 90 days for her to produce the item. The protocol we are considering, in its current naive form as contemplated in this email thread, stacks up a sequence of hodl invoices which, at least in theory, tries to align the incentives of Merchant, Courier, Purchaser. It could, of course, go even further up/down the entire supply chain too. However, since the payments themselves are routed through the lightning network, and, in the example here, stuck in this hodling-pattern for up to 90 days, then any routing nodes along the way may feel they are not being fairly compensated for having their funds locked up for such time. Do I correctly understand that moving to payment points[1] instead of HTLCs can help reduce concern here by allowing each node along the route to earn a fee irrespective of whether the hodl invoice is settled or canceled? Outside of doing a large-scale test on mainnet (which could quickly become expensive and cause some unsuspecting node operators displeasure), is there any way right now for a node operator to determine the likelihood of, for example, being able to even route (e.g. receive payment but not yet be able to settle) a 90-day hodl invoice? Warm regards, -VzxPLnHqr [1] https://suredbits.com/payment-points-part-1/ Jun 27, 2021, 05:03 by zmnsc...@protonmail.com: > Good morning VzxPLnHqr, > > This certainly seems workable. > > I first encountered similar ideas when people were asking about how to > implement a vending machine with Lightning, with the vending machine being > offline and not having any keys. > > The idea was to have the vending machine record pregenerated invoices with > their hashes. > Then a separate online machine (disconnected from the vending machine) would > operate a LN node and receive the payment, releasing the preimage. > The payer would then enter the preimage into the vending machine, which would > validate it and release the item being vended. > > Under your framework, the vending machine operates as the Courier, except it > has a fixed geographical location and the Paul goes to the Courier (vending > machine) to get their item. > > Regards, > ZmnSCPxj > >> Dear Lightning-dev, >> >> I would like to share some initial research and ask for some feedback. >> https://github.com/VzxPLnHqr/discreet-physical-delivery-protocol is a >> repository to gather some thoughts around how it might be possible to >> utilize some of the current features (hodl invoices), and/or forthcoming >> features (payment points? dlcs?) of lightning to create a robust, reasonably >> private, and incentive-compatible network for physical delivery of items. >> >> There has been mention of using hodl invoices for atomic item delivery[1]. >> However, I seem to remember reading that, essentially, hodl invoices (e.g. >> invoices which may not settle for quite some time, if ever) are also the >> primary culprit for some attacks on the network? >> >> Does lightning in a post-taproot world solve any of these issues? >> >> There is some motivation given in the readme for why such a protocol may be >> desirable, but as quick refresher for those reading who may not be familiar >> with how lightning and hodl invoices can be used for atomic package delivery: >> >> 0. Merchant Mary operates an e-commerce website and Purchaser Paul would >> like to buy something and have it delivered. For initial simplicity, assume >> that both Paul and Mary have a relationship with Charlie, an independent >> Courier (e.g. neither Paul nor Mary is playing the role of Charlie, but >> Charlie knows the geographical locations of both). >> >> 1. During checkout, Paul generates preimage and sends hash of preimage to >> Mary >> Mary creates a hodl invoice invoice0 with hash. The amount of the invoice >> includes the cost of shipment as quoted to Mary by Courier Charlie. Paul >> pays invoice0, but Mary cannot yet settle it because preimage is still >> unknown to Mary. >> >> 2. Merchant Mary now sends hash to Charlie and Charlie creates another hodl >> invoice invoice1 (for the delivery costs). Mary pays it and gives the >> physical package to Charlie. >> >> 3. Charlie now has the package and delivers it to Paul. >> >> 4. Upon delivery, Paul gives preimage to Charlie who now can use it to >> settle his outstanding invoice (invoice1) with Mary, thereby revealing >> preimage to Mary who then settles her outstanding invoice0 with Paul. >> >> Taking the above, allowing
Re: [Lightning-dev] complementing lightning with with a discreet physical delivery protocol?
Good morning VzxPLnHqr, This certainly seems workable. I first encountered similar ideas when people were asking about how to implement a vending machine with Lightning, with the vending machine being offline and not having any keys. The idea was to have the vending machine record pregenerated invoices with their hashes. Then a separate online machine (disconnected from the vending machine) would operate a LN node and receive the payment, releasing the preimage. The payer would then enter the preimage into the vending machine, which would validate it and release the item being vended. Under your framework, the vending machine operates as the Courier, except it has a fixed geographical location and the Paul goes to the Courier (vending machine) to get their item. Regards, ZmnSCPxj > Dear Lightning-dev, > > I would like to share some initial research and ask for some feedback. > https://github.com/VzxPLnHqr/discreet-physical-delivery-protocol is a > repository to gather some thoughts around how it might be possible to utilize > some of the current features (hodl invoices), and/or forthcoming features > (payment points? dlcs?) of lightning to create a robust, reasonably private, > and incentive-compatible network for physical delivery of items. > > There has been mention of using hodl invoices for atomic item delivery[1]. > However, I seem to remember reading that, essentially, hodl invoices (e.g. > invoices which may not settle for quite some time, if ever) are also the > primary culprit for some attacks on the network? > > Does lightning in a post-taproot world solve any of these issues? > > There is some motivation given in the readme for why such a protocol may be > desirable, but as quick refresher for those reading who may not be familiar > with how lightning and hodl invoices can be used for atomic package delivery: > > 0. Merchant Mary operates an e-commerce website and Purchaser Paul would like > to buy something and have it delivered. For initial simplicity, assume that > both Paul and Mary have a relationship with Charlie, an independent Courier > (e.g. neither Paul nor Mary is playing the role of Charlie, but Charlie knows > the geographical locations of both). > > 1. During checkout, Paul generates preimage and sends hash of preimage to Mary > Mary creates a hodl invoice invoice0 with hash. The amount of the invoice > includes the cost of shipment as quoted to Mary by Courier Charlie. Paul pays > invoice0, but Mary cannot yet settle it because preimage is still unknown to > Mary. > > 2. Merchant Mary now sends hash to Charlie and Charlie creates another hodl > invoice invoice1 (for the delivery costs). Mary pays it and gives the > physical package to Charlie. > > 3. Charlie now has the package and delivers it to Paul. > > 4. Upon delivery, Paul gives preimage to Charlie who now can use it to settle > his outstanding invoice (invoice1) with Mary, thereby revealing preimage to > Mary who then settles her outstanding invoice0 with Paul. > > Taking the above, allowing it to be multi-hop (multiple Couriers) and > blinding the physical location from one hop to the next, is non-trivial but > seems doable. Some of you may have thought a lot more about these types of of > protocols (digital-meets-physical-world) already, so please chime in! > > Warm Regards, > -VzxPLnHqr > > [1] https://wiki.ion.radar.tech/tech/research/hodl-invoice (though, I think > first proposed by Joost?) > -- > Sent with Tutanota, the secure & ad-free mailbox: > https://tutanota.com ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] complementing lightning with with a discreet physical delivery protocol?
Sorry for the double mailing. My mail client may have messed up the link to the repo. It is here: https://github.com/VzxPLnHqr/discreet-physical-delivery-protocol Jun 25, 2021, 18:05 by vzxpln...@tutanota.com: > > Dear Lightning-dev, > > I would like to share some initial research and ask for some feedback. > > https://github.com/VzxPLnHqr/discreet-physical-delivery-protocol> is a > repository to gather some thoughts around how it might be possible to utilize > some of the current features (hodl invoices), and/or forthcoming features > (payment points? dlcs?) of lightning to create a robust, reasonably private, > and incentive-compatible network for physical delivery of items. > > There has been mention of using hodl invoices for atomic item delivery[1]. > However, I seem to remember reading that, essentially, hodl invoices (e.g. > invoices which may not settle for quite some time, if ever) are also the > primary culprit for some attacks on the network? > > Does lightning in a post-taproot world solve any of these issues? > > There is some motivation given in the readme for why such a protocol may be > desirable, but as quick refresher for those reading who may not be familiar > with how lightning and hodl invoices can be used for atomic package delivery: > > 0. Merchant Mary operates an e-commerce website and Purchaser Paul would like > to buy something and have it delivered. For initial simplicity, assume that > both Paul and Mary have a relationship with Charlie, an independent Courier > (e.g. neither Paul nor Mary is playing the role of Charlie, but Charlie knows > the geographical locations of both). > > 1. During checkout, Paul generates preimage and sends hash of preimage to Mary > Mary creates a hodl invoice invoice0 with hash. The amount of the invoice > includes the cost of shipment as quoted to Mary by Courier Charlie. Paul pays > invoice0, but Mary cannot yet settle it because preimage is still unknown to > Mary. > > 2. Merchant Mary now sends hash to Charlie and Charlie creates another hodl > invoice invoice1 (for the delivery costs). Mary pays it and gives the > physical package to Charlie. > > 3. Charlie now has the package and delivers it to Paul. > > 4. Upon delivery, Paul gives preimage to Charlie who now can use it to settle > his outstanding invoice (invoice1) with Mary, thereby revealing preimage to > Mary who then settles her outstanding invoice0 with Paul. > > Taking the above, allowing it to be multi-hop (multiple Couriers) and > blinding the physical location from one hop to the next, is non-trivial but > seems doable. Some of you may have thought a lot more about these types of of > protocols (digital-meets-physical-world) already, so please chime in! > > Warm Regards, > -VzxPLnHqr > > [1] > https://wiki.ion.radar.tech/tech/research/hodl-invoice> (though, I > think first proposed by Joost?) > -- > Sent with Tutanota, the secure & ad-free mailbox: > https://tutanota.com > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
