[Lightning-dev] Atomic Secrets Exchange
(Note to IAEA & others: this is not about nuclear technology. Feel free to read it though.) (Note 2: beware of awkward misspellings like atomic secret sexchange or the like. I have no idea how to fix this.) Hi, I admit I spend way too little time reading this mailing list, but in my recent futile attempt to get up-to-date, I got inspired by the recent elliptic curve based smart contracting discussions. I'd like to present my still somewhat half-baked solution to a problem I found in the discussion. I believe my solution, Atomic Secrets Exchange, is likely to have applications beyond this particular problem. In the description below, I am assuming some future Lightning where elliptic curve payment points are already used which allow EC arithmetic. # The use case The problem I'm trying to solve is in the proposed protocol for placing bets, as described by Nadav[1]. The idea is: * There is an oracle that promises to either publish p, or publish q, at a certain point in time, for instance, based on some real-world information. * Alice and Bob place bets on what the oracle will publish: Alice pays Bob if the oracle publishes p; Bob pays Alice if the oracle publishes q. * This can be realized by locking funds in two Lightning transactions: one from Alice to Bob, which can be redeemed by Bob with knowledge of p, and one from Bob to Alice, which can be redeemed by Alice with knowledge of q. The time-out of these transactions must be after the point of publication of the oracle. The problem is that one of the two transactions will always be created first; if, for instance, the tx from Alice to Bob is the first, then Bob no longer has an incentive to create his tx to Alice. Not creating the second tx results in a one-sided bet; this makes it risky to take part in the protocol (in this case, Alice is the victim). Nadav proposed a solution with a partially trusted escrow party. I will try to find a solution without an escrow party. #Solution outline In my approach, the payment from Alice to Bob requires Bob to know p *and* know a secret sa, which is initially only known by Alice. Similarly, the payment from Bob to Alice requires Alice to know q *and* a secret sb, which is initially only known to Bob. As long as they don't reveal these secrets to anyone, these are bound to time out (or voluntarily canceled), even after the oracle has spoken. This makes them safe to be locked in in any order. After locking in the transactions, Alice and Bob must reveal their secrets to each other, to make the locked-in transactions equivalent to an honest, two-sided bet. This changes the problem of atomically locking two transactions into atomically exchanging two secrets. Maybe the problem of atomically exchanging two secrets has already been solved in a more elegant way (ECDH, anyone?), but I came up with this method: * Alice locks in a Lightning tx to Bob that requires Bob to know sa and sb, and reveal at least sb to Alice. * Bob then locks in a Lightning tx, with a similar amount of funds, back to Alice that requires Alice to know sa and reveal sa to Bob. This must time out sooner than the first tx. * Alice redeems the second tx, revealing sa to Bob. * Bob redeems the first tx, revealing sb to Alice. Note that Bob can actually 'split the atom' by not redeeming the first tx, but he receives a penalty for this that roughly equals the tx amount. This amount can be made sufficiently large (in comparison to e.g. the bet) as required to move Bob's incentives towards honest behavior. #Some details In the application of paid bets, one detail is time-outs of the three transactions. I believe this is the correct order: * Locking in the bet txes * Locking in the secrets exchange txes * Time-out of the secrets exchange txes * Publication by the oracle * Time-out of the bet txes Another "detail" is how to do the elliptic curve magic. This is my beginners' attempt: P = p*G Q = q*G SA = sa*G SB = sb*G Bet txes: PP_b0 = P+SA, PP_b1 = Q+SB Secrets Exchange txes: PP_x0 = SA+SB, PP_x1 = SA Bob has to know SA to verify the value of PP_x0, and to generate PP_x1. I don't know if a subtract operation exists for elliptic curve points; in that case Bob could calculate SA = PP_b0 - P. Otherwise, Alice could just tell Bob SA, e.g. as meta-data included in the first bet tx. Similarly, Alice has to know SB to generate PP_x0; Alice could calculate SB = PP_b1 - Q, or Bob could tell Alice SB, e.g. as meta-data included in the second bet tx. CJP [1] idea 2 in https://lists.linuxfoundation.org/pipermail/lightning-dev /2019-October/002213.html ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
Regarding this subject, I believe I should disclose that my current employer, Bitonic, operates an evil, centralized, trusted exchange, and that the ideas discussed in this thread may be related to concepts that are actually being developed by my employer. So, am I biased? Who knows? Does it matter? Can you trust me? Maybe, but I guess you shouldn't anyway. In my view, words should be convincing or unconvincing regardless of who speaks them. CJP CJP schreef op vr 28-12-2018 om 09:27 [+0100]: > Hi ZmnSCPxj, > > I think we've already addressed this issue before: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/00 > 12 > 92.html > > and especially this proposal of me: > https://bitonic.nl/public/slowdown_prevention.pdf > > It's not completely trustless, but I tend to see trustlessness in a > very pragmatic sense anyway. Trust creates a risk, but if the > alternative trustless system is very impractical, and the risk is > small > enough, the benefits might simply be worth the risks. Note that this > is > a completely subjective trade-off, so it is only acceptable on an > individual, voluntary basis. > > CJP > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
ZmnSCPxj schreef op wo 02-01-2019 om 13:02 [+]: > I wonder however if this is a "small enough" hole that leaving it is > an acknowledged security vulnerability may be better than replacing > it with a trusted third party. > One may compare with the SSH "trust the first pubkey, verify the > second onwards" weakness, to SSL "trust the certificate authority to > say whose pubkey is whose". SSH's problem (non-authenticated initial key exchange) is small, because there is a very small time window for an attack, and an attacker has to place itself in the route *and* stay in the route to not be detected later. SSL's problem (trusted third parties for key authentication) is big, because each website only uses a single certificate issuer, so you need to trust every certificate issuer to be able to visit every website, even the more questionable certificate issuers; the combined security is as strong as the weakest certificate issuer. Route Makers (RM) (maybe I should change that name) are not a big problem, because, unlike websites, OMs and OTs are very fungible towards each other, especially on popular asset pairs: it's not a big deal if you lose, say, 10% of potential trading partners because you don't want to use a certain RM. Also, a single attack by a RM is not typically a big deal, and it is easily detectable. False positives are possible though (both accidental and deliberate), so you might want to suspend a RM after abuse detection for a while, and then give it another chance after some time. > The hop node just before the RM can provide proof that it offered an > HTLC and the RM allowed the HTLC offer to be made. > It can provide a commitment transaction signed by itself and the RM, > with that commitment transaction containing the HTLC in question. > This is proof that the RM *could* pull the HTLC, but did not do so > quickly enough. > > Since RM nodes are publicly known, perhaps we can make a different > routing from S to RM, one that reveals (to hop nodes) their distance > to RM, but not to S. > RM nodes provide a service to the network and we can argue that the > loss of their privacy here is acceptable, as long as the payee S is > still able to keep its privacy, as an acceptable cost to ensuring > that RM behaves honestly. > > If the just-before-last node (let us call this G or "guard" node) can > monitor the time that RM pulls the HTLC, then it can provide proof > that RM had the ability to pull the HTLC but did not do so. This, and the rest of your proposal, sounds like a lot of trouble, while it hardly solves anything. RM can have its node surrounded by other nodes also controlled by itself. So it is possible that RM controls all nodes that can possibly fulfill the 'G' role, and thereby stop any evidence being generated against the RM node. If you then want to build evidence against the G nodes, you end up recursively involving every single Lightning node in trying to solve your problem. Maybe it is possible, but I'd like not to do that. I like to see the exchange function as a higher layer (layer 3) on top of the Lightning layer, and have each layer solve its own problems in a clean and elegant way. I prefer that nodes that aren't involved in exchanging assets don't need to deal with its complexities either. CJP ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
> 1. It seems to me that there is still friction here. > RM, being a trusted third party, may very well charge as much as > the market will bear. https://nakamotoinstitute.org/trusted-third-par > ties/ > This seems to me to imply that OM (i.e. exchange nodes) will be > unable to extract any sizable fee, i.e. any fees that the market > would be willing to pay to exchange between assets will be taken by > RM as rent, and not by the OM who actually makes the market exist in > the first place. You may be right about the fees, but that doesn't necessarily make it an unattractive proposition for the OM party. When looking at different alternatives by sorting them in a better/worse fashion rather than a perfect/imperfect fashion, I see this: * No exchange: unattractive, because there is significant demand for this. * Regular Lightning-based or other HTLC-like atomic swap: unattractive, because of the exploitable "American Call Option" nature (as we both described). May only function with a very high spread, compensating for OM's risk. * Regular, centralized exchanges: current situation. Third party is trusted with holding funds and executing trade orders. * My proposal: third party is trusted with executing transactions properly (not performing the delay attack). * Trustless exchange: holy grail, but I don't know how to do that. So I don't claim my proposal is perfect, but I'd like to argue it is the best known system because it's an improvement over the current situation where most people use centralized exchanges, at least in terms of trust required(*). To compare the two: I'd like to compare the RM role in my proposal to that of a centralized exchange. Both need to be trusted to some degree, and since trust doesn't scale very well (you can't keep track of thousands of parties), both are probably a natural oligopoly market. As you wrote, these are the parties that are capable of extracting the majority of transaction fees. Still, as centralized exchanges show, people are prepared to trade this way, so apparently it's still an attractive market for both offer-makers and -takers. I think the market for RM services in my proposal is more competitive (and therefore has lower fees) than regular, centralized exchanges, because: * trust requirements are lower, so people are more likely to trust a small, unknown company offering RM services. People using smaller parties = more parties in the market = lower fees. * OMs can easily offer the same funds for use with different RM parties. This is not possible with regular exchanges(**): if you deposit funds on one exchange, you can't also deposit them on another exchange, so you have to commit your funds to a single exchange. Finally, I think the attack RMs can perform on trading parties is an order of magnitude smaller than the attack a regular exchange can perform by stealing deposited funds: a RM can only steal the *exchange rate change* of funds offered for trade, not the full value. Now, if an RM can be punished, it would be even better. I was thinking in the direction of collecting proof of misbehavior, which can then help make the RM lose its (lucrative!) business, but I doubt this is possible. CJP (*) not necessarily in latency: the low latency of centralized exchanges can be hard to match, even on Lightning. (**) as long as you can't go short ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
Hi ZmnSCPxj, I think we've already addressed this issue before: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/0012 92.html and especially this proposal of me: https://bitonic.nl/public/slowdown_prevention.pdf It's not completely trustless, but I tend to see trustlessness in a very pragmatic sense anyway. Trust creates a risk, but if the alternative trustless system is very impractical, and the risk is small enough, the benefits might simply be worth the risks. Note that this is a completely subjective trade-off, so it is only acceptable on an individual, voluntary basis. CJP ZmnSCPxj via Lightning-dev schreef op do 27-12-2018 om 05:43 [+]: > HTLCs as American Call Option, or, How Lightning Currently Cannot > Work Across Assets, or, An Argument For Single-Asset Lightning > Network > > Introduction > > > In theory, the Lightning Network could potentially perform "seamless" > currency conversions, allowing a payer to spend one currency to pay a > payee requesting for another currency. > However, a significant technical barrier prevents implementation of > such feature as of current designs (late 2018) for Lightning. > > The root cause of this significant technical barrier is the use of > hashlocked timelocked contracts to route payments. > HTLCs can be used across cryptocurrency systems to transfer value > between them. > From this point-of-view, every single Lightning Network channel is a > cryptocurrency system whose custodians are two entities, who are the > only entities who can use the system (the single Lightning Network > channel). > HTLCs allow cross-system trades to be performed, so that > participation on any single Lightning Network channel can be > leveraged to participation over the entire Lightning Network. > > However, HTLCs can also be used to construct American Call Options. > Further, due to UX concerns, on the Lightning Network, there is no > cost incurred in merely setting up HTLCs for routing. > By using the low-level HTLCs provided as primitives by Lightning > Network, one can set up American Call Options. > These on-Lightning American Call Options, however, can be "purchased" > for free (gratis), thus potentially earning money in a completely > risk-free manner. > Abusing this gratis ability means that any Lightning Network node > advertising cross-asset on-Lightning exchange will find large amounts > of its liquidity tied up in stalled forwarding payments (in reality, > American Call Options) with a risk of monetary loss in case of large > fluctuations in exchange rate. > > Hashlocked Timelocked Contracts as American Call Options > > > An American CallOption is a right (but not obligation) to purchase an > asset at a specific price, on or before an expiration date. > HTLCs allow building American Call Options. > > Suppose we have Bitcoin, and some other asset, and both are on > blockchains that support the same hash function and can define HTLCs. > It is unimportant if both are on the same blockchain, or on different > blockchains, since HTLCs can work across cryptocurrency systems. > > An American Call Option has these properties: > > 1. `P` = the price at which the asset can be purchased. > 2. `E` = the date at which the option expires. > > Suppose I, ZmnSCPxj, wanted to sell you an American Call Option for > 1 Widget (WJT) on the WJT blockchain. > We would then do the below ritual: > > 1. You provide me a hash of some secret preimage that only you know. > 2. You make an HTLC on the Bitcoin blockchain. > The value of this HTLC is `P`, the hash is the hash you gave > above, and the timelock is `E` + 1 day. > 3. I make an HTLC on the WJT blockchain. > The value of this HTLC is 1, the hash is the hash you gave, and > the timelock is `E`. > > On or before `E`, you can claim the WJT on the WJT blockchain by > providing a transaction that reveals the preimage. > Since the preimage is now revealed, I can then claim the Bitcoins of > price `P` on the Bitcoin blockchain. > Alternately, you can simply not exercise this right, and at time `E` > I would then reclaim my WJT, and at time `E` + 1 day you would > reclaim your bitcoins. > > Of course, I want to *sell* this contract to you, so you would have > to pay me some bitcoins before we set up the above. > A multi-stage construction of transactions that go through HTLC-like > constructs can be done on both blockchains to ensure that the above > contracts appear on both chains only if the payment for the actual > contract (i.e. the "premium") is done, and to enforce that both > contracts appear if the premium is paid, but that is beyond the scop
Re: [Lightning-dev] Proposal for updateable / revokable proofs of payment
I think it's true that most of my proposal can be achieved by writing such things in human-readable form in the description field. Mostly, the only thing my proposal does is to put things into a machine- readable form; this may aid in automated processing and maybe a better UI experience. Maybe the least trivial thing is the inclusion of a payer pubkey in the original invoice; this is the least trivial both in protocol complexity and in potential benefits. One benefit is that it turns a "proof-that- someone-paid" into a "proof-that-I-paid"; another benefit is that it becomes clear who is authorized to issue another invoice that says "this original invoice is nullified". Now that I think of it: my proposal has something important that yours doesn't: the requirement to have *two* signatures (both payer and payee) on each update. Without that requirement, there is one party who can nullify the old contract by making a unilaterally signed invoice and a self-generated payment preimage. Not even a need to do a payment to self to "fake" a sort of a refund payment or so. This may be OK as long as there is only one party who has obligations: then the other party may partially or completely nullify those obligations, optionally dependent on a payment. Requiring two signatures (and thereby consensus) on each update is more generic though: it allows for obligations on both parties. Even more generic could be to allow more than two parties. I'm sure there are complex business arrangements that have a need for this, but I think we can always develop that later. Let's first tackle this relatively simple case. CJP ZmnSCPxj schreef op ma 05-11-2018 om 01:20 [+]: > Good morning CJP, > > It seems to me, naively, that we can encode the description "the > obligation in the invoice whose hash is is nullified", whose > meaning then is promoted to "if payment happens, payee has an > obligation to ensure that the obligation in the invoice whose hash is > is nullified", then we have revokable payments already. Such a > payment may itself be revoked, ad infinitum. > > Regards, > ZmnSCPxj > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Monday, November 5, 2018 5:08 AM, CJP > wrote: > > > Right now, the only defined semantics of the description field in > > BOLT11 is that it SHOULD be "a complete description of the purpose > > of > > the payment". I think this is a bit vague; maybe this is > > deliberate? > > > > Anyway, you may also think of a BOLT11 payment request as an option > > contract. If the payment is performed (which can be proven by > > showing > > the preimage), then payee is bound to the terms and conditions in > > the > > description. So, then the meaning of a description "one cup of > > coffee" > > becomes "if payment happens, payee has an obligation to deliver one > > cup > > of coffee". > > > > A known issue is that payer is not identified in the contract, so > > it is > > not clear to who the payee has this obligation. As far as I can > > see, > > the only way to fix this is to have two-way communication, where > > first > > the payer sends some data to payee (e.g. public key), and then > > payee > > makes the payment request, including this data. With this > > established, > > we turn the preimage + payment request from a "proof that someone > > paid" > > into a "proof that I paid", and therefore also a "proof that payee > > has > > this obligation to me". > > > > I'm a bit afraid that such proofs are a bit too inflexible for > > real- > > life applications. I think in real-life there are many cases where > > you > > need to update / revoke agreements, even after payment. > > > > One example is a full refund: if goods/services cannot be delivered > > somehow, payer+payee might agree to a full refund instead of > > delivery > > of goods/services. The refund is another payment, with a payment > > request made by the original payer; its contract should state that > > the > > original payee is no longer bound by the obligations in the > > original > > contract. > > > > Another example is a partial refund, for instance if only a lower > > quantity or a lower quality of goods/services is delivered. This is > > another payment, but now the new contract replaces the old contract > > and > > specifies a new, lower set of obligations for the original payee. > > > > Another example is a change of conditions without change of > > payment, > > f
[Lightning-dev] Proposal for updateable / revokable proofs of payment
Right now, the only defined semantics of the description field in BOLT11 is that it SHOULD be "a complete description of the purpose of the payment". I think this is a bit vague; maybe this is deliberate? Anyway, you may also think of a BOLT11 payment request as an option contract. If the payment is performed (which can be proven by showing the preimage), then payee is bound to the terms and conditions in the description. So, then the meaning of a description "one cup of coffee" becomes "if payment happens, payee has an obligation to deliver one cup of coffee". A known issue is that payer is not identified in the contract, so it is not clear to who the payee has this obligation. As far as I can see, the only way to fix this is to have two-way communication, where first the payer sends some data to payee (e.g. public key), and then payee makes the payment request, including this data. With this established, we turn the preimage + payment request from a "proof that someone paid" into a "proof that I paid", and therefore also a "proof that payee has this obligation to me". I'm a bit afraid that such proofs are a bit too inflexible for real- life applications. I think in real-life there are many cases where you need to update / revoke agreements, even after payment. One example is a full refund: if goods/services cannot be delivered somehow, payer+payee might agree to a full refund instead of delivery of goods/services. The refund is another payment, with a payment request made by the original payer; its contract should state that the original payee is no longer bound by the obligations in the original contract. Another example is a partial refund, for instance if only a lower quantity or a lower quality of goods/services is delivered. This is another payment, but now the new contract replaces the old contract and specifies a new, lower set of obligations for the original payee. Another example is a change of conditions without change of payment, for instance when a white/gold dress was ordered, but turned out to be unavailable, and payer finds a black/blue dress acceptable as well, at equal price. Then you'd just want to replace white/gold in the contract by black/blue, without any payment. I think nearly all cases (including ones not mentioned here) are covered by a "contract update" format which includes: * the new obligations of the two parties to each other * a secure hash of the previous contract version that is replaced by this one * optionally, a payment hash * signatures from both parties The contract update is considered valid if and only if * the signatures correspond to the pubkeys in the original contract (the first in the chain) * the signatures are valid signatures on this contract * the previous contracts in the chain are all valid (except for being invalidated by contract updates) * there is no known valid contract that replaces this one * if a payment hash is included, a corresponding payment preimage is provided as well The original contract is different in that * It does not have a previous contract version (may be zeroed if you want to keep the same format) * A set of pubkeys is provided (one of payer, one of payee) * Only payee has obligations, so payee never needs to receive a signature from payer. Payer needs to receive payee's signature, and can trivially add his own signature whenever needed. Whenever one payee has obligations to another, the pubkey of the party with obligations has to be verified through some PKI. I consider this to be outside the scope of this concept. Especially in the case that one of the parties never has any obligations, that party may use a new, non-PKI-verified pubkey for the transaction, as a temporary pseudonym. There is some conceptual similarity between an updateable proof of payment and a payment channel. A potential issue is that, theoretically, the "contract update chain" can fork. The simple solution is "don't do that": either party can stop it from happening by not signing the forking update. CJP ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for rendez-vous routing
ZmnSCPxj schreef op zo 04-11-2018 om 14:34 [+]: > Good morning CJP, > > I believe this is a desirable feature, although... > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Sunday, November 4, 2018 2:26 PM, CJP > wrote: > > > Imagine a future where some powerful participant in the Lightning > > network starts enforcing KyC requirements on Lightning nodes. It > > requires its direct neighbors to reveal their identity or else > > closes > > channels to them. Next, it asks its direct neighbors to reveal the > > identity of their direct neighbors (or close their channels), with > > the > > threat of either channel closure, or (using the now-known identity) > > more extreme penalties. > > > > For this particular scenario, it seems to me that it would be better > for the rest of the network to punish this participant by closing any > channel to this KYC-requiring participant, and also to do retaliatory > preemptive closing of any channel to any participant publicly > connecting, directly or indirectly, to that participant. Or in > short, to let that participant enforce whatever it wants to > close. This will greatly lower its fee earnings as well as its > ability to monitor or control the network. If every Lightning node > refuses to reveal their identity (etc.) to this participant, then the > participant will close all its channels and it will no longer be a > powerful **participant** of Lightning, thus removing itself and its > influence from Lightning in the most satisfying way possible, i.e. > through shooting itself in the foot. I disagree: you may not be in a position to freely close such channels and remove your ability to transact with this party, similar to how you may not be in a position to refuse to pay taxes. Also, since it is hard to avoid (in the current situation) that some Lightning nodes have a known link to legal entities like companies or persons, there are ways outside the Lightning network to put pressure on node owners, especially non-pseudonymous high-profile ones. This is, however, a non- technical discussion; since we already agree on the desirability of the feature, I suggest to keep it at this and focus on the technical details. > Nonetheless, I believe this feature is desirable, not for the above > scenario, but simply so that a payee is not required to maintain even > a pseudonym on the Lightning Network (the payee will still have to be > somehow contactable so it can generate an invoice somehow, but at > least it will not even have an identifiable pseudonym on-Lightning; > perhaps it may have a pseudonym on some other network with better > privacy). If all its generated invoices use rendezvous routing, then > while it, obviously, must have a Lightning node somewhere, that node > is not easily identifiable among all Lightning nodes. I guess that for most use cases a payee pseudonym is needed, unless your use case is donating to random strangers. I only found one exception: where the thing you pay for is cryptographically linked to the Lightning payment (effectively, an atomic swap, like in a Lightning-based decentralized exchange). In that case, a truly anonymous (as opposed to pseudonymous) payee makes sense. However, for use cases where the payee needs a pseudonym, it might still be desirable to decouple that pseudonym from a location in the Lightning network. Rendezvous routing can do that. > Looking through BOLT 4, the text assumes inherently that source > routing is done, and even has a shared secret between hop and > source. However, it may be possible in rendezvous routing to simply > provide the blinding key (while hiding everything beyond the first > hop on the destination half of the route). Sounds like it makes sense; I need to look into it. > I also think that, as the destination is choosing the nodes on its > half of the route, that it should pay for fees, and thus the source > is only required to deliver the specified amount to the first hop > node of the destination half of the rendezvous route. Agreed. The price agreed between payer and payee is the incoming amount at the rendezvous point. In the "original" case that the payee-side route is 0 hops long, the payee is the rendezvous point, and we're equal to the original concept where the agreed-on price is the incoming amount at the payee. CJP ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Proposal for rendez-vous routing
Imagine a future where some powerful participant in the Lightning network starts enforcing KyC requirements on Lightning nodes. It requires its direct neighbors to reveal their identity or else closes channels to them. Next, it asks its direct neighbors to reveal the identity of their direct neighbors (or close their channels), with the threat of either channel closure, or (using the now-known identity) more extreme penalties. I guess this would lead to a split of the Lightning network into a compliant and a non-compliant part, with no ability to perform payments between the two. If we want to keep the Lightning network inclusive, anonymous and free of central authorities who can impose arbitrary rules, this is an undesirable scenario. The enabler of this scenario is the fact that, to allow source routing, we need a public channel map of the network. We have a sort-of-a counter measure called "private channels", which are channels that exist, but whose existence is not published. A private channel might bridge the gap between a compliant and a non- compliant part of the network, but it has a problem: in order to allow payments from one side to the other, the payer has to know about the private channel. If there are lots of payers who have to cross the gap and use the private channel, the existence of the private channel will leak out sooner or later. The node owner on the compliant side of the private channel, presumably having violated the rules by operating a private channel, risks penalties. Therefore, I think private channels are not a very suitable way to keep the network undivided and inclusive and to bridge the gap between different regulatory/non-regulatory domains. I propose another solution: rendez-vous routing. The idea is that the payee chooses one or more routes from certain third-party nodes in the network to himself and passes sphinx-encrypted blobs for those routes to the payer (for instance, as part of a payment request). The payer completes the route by finding routes from himself to those third-party nodes, and tries to perform the payment over these routes. Of course, payee has to tell payer how many hops payer may add to a route, somewhat revealing how much privacy payee wants for himself. I believe this approach has the following properties: * It is a superset of the regular approach to routing: the old approach is simply the special case where payee defines 0 of the 20 hops. * Payee may lead the route over private channels without revealing the existence of those private channels to payers. Of course the private channel still needs to be known to payee; it is probably most realistic that such private channels are operated by payee himself. * The payee node may still be a node inside the "compliant" section of the network; it's just that nobody (not even payer) can see which node it is. So, even when your node is linked to your identity, your activities (even as payee) are not linked to your identity. I guess we already discussed this before, but I just wanted to have a clear place to discuss this idea, and I couldn't find any clear past discussion about this in the mailing list. There might be alternative approaches, such as not routing between incompatible regulatory domains, but simply having nodes on each network if you need to, and simply move funds on-chain between your nodes whenever needed. That will require on-chain mixing though. CJP ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Why do we need fee estimation in the protocol?
Hi, Maybe this is a stupid question, and it is late so maybe I'm overlooking something, but I don't want to lose a potentially good idea, so here it goes: Right now, BOLT#3 imposes a certain algorithm for fee estimation. This algorithm is likely to be sub-optimal: fee estimation is a difficult subject, and may involve subjective situation-specific considerations of participants. I guess it's only there to achieve some kind of consensus between the peers. But why do we need consensus at all? There are two versions of each commitment transaction: one to be used for unilateral close by one peer (A), and one to be used by the other (B). Peer A has an interest in "commit transaction A", so I'd consider it fair to let peer A pay the transaction fee for that commit tx (subtracted from its part of the channel funds), and also to let peer A determine the amount of that fee. If A wants a different fee for whatever reason, it should simply be able to ask B for a signature on an updated "commit transaction A". B shouldn't care about that fee, as long as its own funds, HTLCs etc. are OK. I guess, when only changing the fee, you don't even need to use a new revocation secret. Your peer may have different versions which only differ in how much fees your peer pays, and you 'll never care which of them will be used by your peer. Not using a new revocation secret may or may not be a premature optimization though. If a peer doesn't have enough funds to pay a reasonably effective tx fee, normally that shouldn't be a problem, because then it doesn't have a significant financial interest in having a usable commit tx either. The only exception is if there are significant HTLCs. Is this where the idea breaks down? As far as I can see, this is an exceptional (but important) case, but during normal operation, peers should be free to choose the fee for their own commit tx. You'd have to deal with any follow-up transactions as well: changing a fee changes the txID, so you need to update follow-up transactions. regards, CJP ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning
Can you give a use case for this? Usually, especially in the common case that a payment is done in exchange for some non-cryptographic asset (e.g. physical goods), there already is some kind of trust between payer and payee. So, if a payment is split non-atomically into smaller transactions, and only a part succeeds, presumably they can cooperatively figure out some way to settle the situation. I spoke to people of the "interledger" project, and what they are planning to do is to non-atomically split *every* transaction into lots of micro-payments. In fact, they consider it unnecessary to enforce HTLCs with scripts, because their amounts are so small(*). If one micro-payment fails, that just makes them learn that a certain channel is unreliable, and they'll send further payments (and even the remaining part of the same payment) through a different route. CJP (*) not worth the extra on-blockchain fee due to the increased tx size. Olaoluwa Osuntokun schreef op di 06-02-2018 om 05:26 [+]: > Hi Y'all, > > > A common question I've seen concerning Lightning is: "I have five $2 > channels, is it possible for me to *atomically* send $6 to fulfill a > payment?". The answer to this question is "yes", provided that the > receiver > waits to pull all HTLC's until the sum matches their invoice. > Typically, one > assumes that the receiver will supply a payment hash, and the sender > will > re-use the payment hash for all streams. This has the downside of > payment > hash re-use across *multiple* payments (which can already easily be > correlated), and also has a failure mode where if the sender fails to > actually satisfy all the payment flows, then the receiver can still > just > pull the monies (and possibly not disperse a service, or w/e). > > > Conner Fromknecht and I have come up with a way to achieve this over > Lightning while (1) not re-using any payment hashes across all payment > flows, and (2) adding a *strong* guarantee that the receiver won't be > paid > until *all* partial payment flows are extended. We call this scheme > AMP > (Atomic Multi-path Payments). It can be experimented with on Lightning > *today* with the addition of a new feature bit to gate this new > feature. The beauty of the scheme is that it requires no fundamental > changes > to the protocol as is now, as the negotiation is strictly *end-to-end* > between sender and receiver. > > > TL;DR: we repurpose some unused space in the onion per-hop payload of > the > onion blob to signal our protocol (and deliver some protocol-specific > data), > then use additive secret sharing to ensure that the receiver can't > pull the > payment until they have enough shares to reconstruct the original > pre-image. > > > > > Protocol Goals > == > 1. Atomicity: The logical transaction should either succeed or fail in > entirety. Naturally, this implies that the receiver should not be > unable to > settle *any* of the partial payments, until all of them have arrived. > > > 2. Avoid Payment Hash Reuse: The payment preimages validated by the > consensus layer should be distinct for each partial payment. > Primarily, > this helps avoid correlation of the partial payments, and ensures that > malicious intermediaries straddling partial payments cannot steal > funds. > > > 3. Order Invariance: The protocol should be forgiving to the order in > which > partial payments arrive at the destination, adding robustness in the > face of > delays or routing failures. > > > 4. Non-interactive Setup: It should be possible for the sender to > perform an > AMP without directly coordinating with the receiving node. > Predominantly, > this means that the *sender* is able to determine the number of > partial > payments to use for a particular AMP, which makes sense since they > will be > the one fronting the fees for the cost of this parameter. Plus, we can > always turn a non-interactive protocol into an interactive one for the > purposes of invoicing. > > > > > Protocol Benefits > = > > > Sending pay payments predominantly over an AMP-like protocol has > several > clear benefits: > > > - Eliminates the constraint that a single path from sender to > receiver > with sufficient directional capacity. This reduces the pressure to > have > larger channels in order to support larger payment flows. As a > result, > the payment graph be very diffused, without sacrificing payment > utility > > > - Reduces strain from larger payments on individual paths, and > allows the > liquidity imbalances to be more diffuse. We expect this to have a > non-neglig
