[Lightning-dev] Turbo channels spec?
Hi all! John Carvalo recently pointed out that not every implementation accepts zero-conf channels, but they are useful. Roasbeef also recently noted that they're not spec'd. How do you all do it? Here's a strawman proposal: 1. Assign a new feature bit "I accept zeroconf channels". 2. If both negotiate this, you can send update_add_htlc (etc) *before* funding_locked without the peer getting upset. 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel unless they have explicit reason to trust that node (they can still send *out* that channel, because that's not their problem!). It's a pretty simple change, TBH (this zeroconf feature would also create a new set of channel_types, altering that PR). I can draft something this week? Thanks! Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Interactive tx construction and UTXO privacy, some thoughts
Hey all, The dual-funding proposal has been up for a while now, and while we've had some really great reviews from a few people (@ariard + @rustyrussell thanks for your comments in particular). As a refresher, the PR is available here: https://github.com/lightningnetwork/lightning-rfc/pull/851. I wanted to make a quick summary of some of the biggest objections to the protocol. Most of these were made during the course of the 2018 spec meeting in Adelaide and while we've done a decent job of architecting around them, I wanted to make them explicit. If there's more to add, please do. ## Point One One: dual-funding (really the collaborative transaction protocol) requires you to share your UTXO set with the channel peer. This is true, in a 'limited' sense, where 'UTXO set' is actually constricted to 'UTXOs you're using for funding transactions'. On the face of it, this seems to be quite concerning to folks. Here's a few things that I think make this less concerning than it might appear at the outset. First, let's consider the current opening case. You (or your channel peer) constructs a transaction and shares the TXID and outpoint that the funding output can be found at. This transaction is published and mined, after the transaction is at sufficient depth a gossip announcement is broadcast to the entire network, explaining where the transaction can be found. Under the current protocol, it's reasonable\* to conclude that every UTXO in the funding transaction belongs to a single party, the opener. Assuming that all the UTXOs in your wallet will, at some point, end up in a lightning channel, all of your UTXOs will be *publicly* associated with your node at some point (in the current model). Your UTXO set is only private in the present, given a long enough time period (and channel opens) they will all be tied to your node. For this reason, it's probably not a great idea to fund wallets using a separate wallet that hasn't been coinjoined or otherwise obfuscated. In fact, I think you can make a fairly decent argument (under the existing UTXO model) for not mixing lightning funds with any funds you wish to remain truly private/unassociated to an 'entity'. Given that you're currently telling everyone what UTXOs your node owns (or at least has a 50/50 chance of owning..) let's consider the interactive transaction protocol. Assuming a 2-party dual-funded open, as an outside observer it's much more difficult to tell which UTXOs belong to who (though you can probably guess given input amounts and change outputs; maybe a good heuristic for opens is to use whole UTXOs). In this on-chain respect, the dual-funding protocol is no worse, and in the best case much better for on-chain coin-analysis heuristics than the current protocol. \* There are a few clear exceptions where other protocols (such as Pool, iiuc) have been developed that make this heuristic bunk as they *also* build a multi-party transaction, however afaik all of these other protocols (joinmmarket, pool) still require sharing your UTXOs with another (trusted) party, difference is you know in theory where "the Pool auctioneer" lives, whereas you don't really know much about "any random node that wants to open a channel". Seems like there might be some room in this space for better information about prospective channel peers... ## Point Two Two: an active prober can use the interactive transaction protocol to discover your wallet's entire UTXO set. Given the assumption that all of your node funds will, at some point, be used to open a lightning channel, a single attacker discovering a subset of your UTXOs is simply a 'fast-forward' of what will eventually become public information. That being said, much smarter minds (e.g. JoinMarket, which suffers from a very similar issue in what I would argue an even more privacy-conscious context) than mine have employed the PoDLE protocol to make the discovery of every UTXO more costly for a potential attacker. This is something we can add quite trivially to the protocol, at the cost of grossly increasing the gossip traffic. Worth noting that even without PoDLE you can much slow this type of attack by reusing the same UTXO across every open attempt, being choosy about which peers you do offer liquidity up to (do they have other established channels? what's their uptime?) etc. A dedicated attacker could probably figure out your UTXO set, but that's not much different from the current system; the only difference is the span of time it takes them to figure it out. ## Things We've Done to Counter This: I had the pleasure of finally meeting Nadav of SuredBits and DLC fame in Miami a few weeks ago. The DLC team has adopted a version of the interactive transaction protocol for their own purposes. Nadav pointed out that the protocol we landed on for lightning interactive construction transactions is *quite* interactive; the DLC version modified it to use batching to transmit the input/output sets (the
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] Lightning Mints
Good morning again CAsey, > > I believe a major failing of Chaumian mints is that they are, at their core, > inherently custodial. > The mint issues blinded minted coins in exchaange for people handing over > other resources to their custody. > While the mint itself cannot identify who owns how much, it can outright deny > all its clients access to their funds and then run off with the money to > places unknown. > > However, do note that both Wasabi and WabiSabi are extensions of Chaumian > mints. > These avoid the custodiality issue of Chaumian mints by operating the mint as > a temporary entity, whose output is then counterchecked by the users of the > Wasabi/WabiSabi scheme. > > ... > > In any case, you might also be interested in the "nodelets" I described some > years ago. > This link has a presentation where I introduce nodelets towards the end, > sorry but most of the beginning is about LN pathfinding (which is currently a > non-problem since nobody makes published channels anymore). > This allows multiple users to implement a single node without a central > custodian, and may allow for similar flexibility of liquidity if there are > enough users, but every action requires all users to have keys online. Thinking more, it helps to consider how Wasabi and WabiSabi are constructed. In Wasabi, there exists a coordinator, which is a server that works as a temporary Chaumian mint. Clients of the coordinator register some UTXOs of some common value to the mint (indicating any change outputs if the UTXO total value exceeds the fixed common value). Then the coordinator issues blind signatures, which serve as tokens in a Chaumian mint. Then users re-connect via a different pseudonym, unblind signatures and reclaim the funds, indicating a target output address. The coordinator then creates a single transaction that consumes the registered input UTXOs and the indicated outputs. As a *final* step, the clients then check that the produced transaction is correct. This final step prevents the coordinator from absconding with the funds. WabiSabi "simply" replaces blinded signatures with blinded credentials. Blinded signatures are fairly low-bandwidth either you have a blinded signature, or you do not. Credentials, however, also include a blinded homomorphic value. On issuing, the issuer can ensure that a particular value is encoded, then when the credential is blinded by the receiver, and the issuer can ensure that multiple credentials can be presented which sum up to a newly issued credential, with the value being correctly added. Thus, I think for a modern Chaumian mint, you should really consider the credentials scheme used by WabiSabi. -- Now, let us consider the "nodelets" idea as well. The "nodelets" system allows for a coordinator (which can be a separate entity, or, for the reduction of needed entities, any nodelet of the node). This coordinator in nodelets is simply a way to implement a broadcast medium among all the nodelets in a node. However, the same coordinator in a nodelets system can also serve as a coordinator in something very much like a WabiSabi system. So it seems to me that this can be implemented in a way that is non-custodial, as long as we can actually implement nodelets. (which "just" requires that we use a multiparticipant signing scheme for Schnorr signatures that is composable.) Basically, just as in the WabiSabi case, nodelets can connect to the coordinator, register some of the values they have in channels, then get back some equivalent credentials. Then the nodelets can "self-mix" their coins, then get back a new set of values, then request that some part of their value be sent over the network. Then, before signing off on the new state of any channel, the actual nodelets check the new state that the coordinator wants them to sign off on, thus preventing custodial risk in the same manner as Waasabi/WabiSabi does. Thus, each state update of the channel is created by a Chaumian mint (using credentials instead of blinded signatures), then the state update is "ratified" by the actual nodelets, preventing the Chaumian mint from stealing the funds; new states are simply not signed (and presumably one or more of the nodelets will drop the previous valid state onchain, which allows them to recover funds without loss) until all nodelets can confirm that the coordinator has not stolen anything. Nodelets can use pseudonyms in between states of channels, to reduce the ability of the coordinator, or the other nodelets, to guess who owns how much. An issue however is how to handle forwarding. Forwarding is an important privacy technique. If you are a forwarder, you can plausibly claim that an outgoing HTLC is not from your own funds, but instead was a forward. By supporting forwarding, the nodelets composing the node can reduce the ability of non-participants to determine the payments of the node. Handling forwarding in such a system
