Re: [Lightning-dev] A proposal for up-front payments.
Olaoluwa Osuntokun writes: > Hi Rusty, > > Agreed w.r.t the need for prepaid HTLCS, I've been mulling over other > alternatives for a few years now, and none of them seems to resolve the > series of routing related incentive issues that prepaid HTLCs would. > >> Since both Offers and Joost's WhatSat are looking at sending messages, >> it's time to float actual proposals. > > IMO both should just be done over HORNET, so we don't need introduce a new > set of internal protocol level messages whenever we have some new > control/signalling need. Instead, we'd have a control/signal channel (give > me > routes, invoices, sign this, etc), and a payment channel (HTLCs as used > today). I'm not so sure, as I don't think we're going to actually use each one more than once or twice? I mean, we could stream movies through LN, but I think that's an added service, which would be best done by HORNET. >> 2. Adding an HTLC causes a *push* of a number of msat on commitment_signed >> (new field), and a hash. > > The prepay amount should be signalled in the update add message instead. > This lets HTLCs carry a heterogeneous set of prepay amounts. In addition, we > need a new onion field as well to signal the incoming amount the node > _should_ have received (allows them to detect deviations in the sender's > intended route). Sorry, brain fart: it's a new field in the update_add_htlc of course. I just, um, added that to make sure you were all reading carefully! :_ >> 3. Failing/succeeding an HTLC returns some of those msat, and a count and >> preimage (new fields). > > Failing shouldn't return the prepay amount, otherwise extending long lived > HTLCs then cancelling them at the last minute is still costless. This > costlessness of _adding_ an HTLC to a _remote_ commitment is IMO, the > biggest incentive flaw that exists today in the greater routing network. No, that's type (liquidity) 3 spam, which needs a completely different solution. Definitely needs fixing, but up-front fees don't do it (except in the case where you might want to indicate you're *going* to have a long-held HTLC, where you'd pay additional up-front, but that's future work). >> You get to keep 50 msat[1] per preimage you present[2]. > > We should avoid introducing any new constants to the protocol, as they're > typically dreamed up independent of any empirical lessons learned from > deployment. OTOH, we should avoid creating more complex knobs for users, since the complexity of the protocol is becoming unmanagable. I think we did this too much with v1, so instead of getting empirical data we got defaults which in practice are unspecified specifications. I like a flat value to start, since it's easy to implement and deploy. > On the topic of the prepay cost, the channel update message should be > extended to allow nodes to signal prepay costs similar to the way we handle > regular payment success fees. In order to eliminate a number of costless > attacks possible today on the routing network, nodes should also be able to > signal a new coefficient used to _scale_ the prepay fee as a function of the > CLTV value of the incoming HTLC. ... and HTLC amount, surely? That becomes a pretty complex tuning parameter. I think we should directly target type 3 spam through a separate mechanism (as discussed previously). This is just to prevent quantity of messages. > With this addition, senders need to pay to > _add_ an HTLC to a remote commitment transaction (fixed base cost), then > also need to pay a variable rate that scales with the duration of the > proposed outgoing CLTV value (senders ofc don't prepay to themselves). Once > we introduce this, loop attacks and the like are no longer free to launch, > and nodes can dynamically respond to congestion in the network by raising > their prepay prices. I disagree; you should signal with normal fees, not prepay. Otherwise we're increasing fees at a time that success rates are lowering, which makes the incentive misalightment far more promiment :( Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Potential Minor Sphinx Privacy Leak and Patch
Hi y'all, A new paper analyzing the security of the Sphinx mix-net packet format [1] (and also HORNET) has recently caught my attention. The paper is rather long and very theory heavy, but the TL;DR is this: * The OG Sphinx paper proved various aspects of its security using a model for onion routing originally put forth by Camenisch and Lysyanskaya [2]. * This new paper discovered that certain security notions put forth in [2] weren't actually practically achievable by real-world onion routing implementations (in this case Onion-Correctnes), or weren't entirely correct or additive. New stronger security notions are put forth in response, along with extensions to the original Sphinx mix-net packet format that achieve these notions. * A flaw they discovered in the original Sphinx paper [3], can allow an exit node to deduce a lower bound of the length of the path used to reach it. The issue is that the original paper constructs the _starting packet_ (what the exit hop will receive) by adding extra padding zeroes after the destination and identifier (we've more or less revamped this with our new onion format, but it still stands). An adversarial exit node can then locate the first set bit after the identifier (our payload in this case), then use that to compute the lower bound. * One of the (?) reference Sphinx implementations recognizes that this was/is an issue in the paper and implements the mitigation [4]. * The fix on our end is easy: we need to replace those zero bytes with random bytes when constructing the starting packet. I've created a PR to lnd's lightning-onion PR implementing this mitigation [5]. As this changes the starting packet format, we also need to either update the test vectors or we can keep them as is, and note that we use zeroes so the test vectors are fully deterministic. My PR to the spec patching the privacy leak leaves the test vectors untouched as is [6]. With all that said, IMO we have larger existing privacy leaks just due to our unique application of the packet format. As an example, a receiver can use the CLTV of the final HTLC to deduce bounds on the path length as we have a restricted topology and CLTV values for public channels are all known. Another leak is our usage of the variable length onion payloads which a node can use to ascertain path length since they space they consume counts towards the max hop count of 20-something. In any case, we can patch this with just a few lines of code (fill out with random bytes) at _senders_, and don't need any intermediate nodes to update. The new and old packet construction algos are compatible as packet _processing_ isn't changing, instead just the starting set of bytes are. As always, please double-check by interpretation of the paper, as it's possible I'm missing something. If my interpretation stands, then it's a relatively minor privacy leak, and an easy low-hanging fruit that can be patched without wide-spread network coordination. -- Laolu [1]: https://arxiv.org/abs/1910.13772 [2]: https://www.iacr.org/cryptodb/archive/2005/CRYPTO/1091/1091.pdf [3]: https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf [4]: https://github.com/UCL-InfoSec/sphinx/blob/c05b7034eaffd8f98454e0619b0b1548a9fa0f42/SphinxClient.py#L67 [5]: https://github.com/lightningnetwork/lightning-onion/pull/40 [6]: https://github.com/lightningnetwork/lightning-rfc/pull/697 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] A proposal for up-front payments.
Anthony Towns writes: > On Tue, Nov 05, 2019 at 07:56:45PM +1030, Rusty Russell wrote: >> Sure: for simplicity I'm sending a 0-value HTLC. >> ZmnSCPxj has balance 1msat in channel with Rusty, who has 1000msat >> in the channel with YAIjbOJa. > > Alice, Bob and Carol sure seem simpler than Zmn YAI and Rusty... Agreed, I should not have directly answered the q. >> Rusty prepares a nonce, A and hashes it 25 times = Z. >> ZmnSCPxj prepares the onion, but adds extra fields (see below). > > It would have made more sense to me for Alice (Zmn) to generate > the nonce, hash it, and prepare the onion, so that the nonce is > revealed to Dave (Rusty) if/when the message ever actually reaches its > destination. Otherwise Rusty has to send A to Zmn already so that > Zmn can prepare the onion? The entire point is to pay *up-front*, though, to prevent spam. Bob/ZmnSCPxj doesn't prepare anything in the onion. They get handed the last hash directly: Alice is saying "I'll pay you 50msat for each preimage you can give me leading to this hash". >> He then >> sends the HTLC to Rusty, but also sends Z, and 25x50 msat (ie. those >> fields are in the update_add_htlc msg). His balance with Rusty is now >> 8750msat (ie. 25x50 to Rusty). >> >> Rusty decrypts the onion, reads the prepay field: it says 14, L. >> Rusty checks: the hash of the onion & block (or something) does indeed >> have the top 8 bits clear, so the cost is in fact 16 - 8/2 == 14. He >> then hashes L 14 times, and yes, it's Z as ZmnSCPxj said it >> should be. > > I'm not sure why lucky hashing should result in a discount? Because the PoW adds noise to the amounts, otherwise the path length is trivially exposed, esp in the failure case. It's weak protection though. > You're giving a linear discount for exponentially more luck in hashing > which also seems odd. Because you really want some actual payment, not just PoW. Botnets are really good at PoW, less good at sending msats. And the PoW is hard to calibrate (I guessed: real numbers will be necessary)/ > You've only got two nonce choices -- the initial and the depth > that you tell Bob and Carol to hash to as steps in the route; No, the sphinx construction allows for grinding, that was my intent here. The prepay hashes are independent. > I think you could just make the scheme be: > > Alice sends HTLC(k,v) + 1250 msat to Bob > Bob unwraps the onion and forwards HTLC(k,v) + 500 msat to Carol > Carol unwraps the onion and forwards HTLC(k,v) + 250 msat to Dave > Dave redeems the HTLC, claims an extra 300 msat and refunds 200 msat to > Carol > Carol redeems the HTLC and refunds 200 msat to Bob > Bob redeems the HTLC and refunds 200 msat to Alice > > If there's a failure, Alice loses the 1250 msat, and someone in the > path steals the funds. This example confuses me. So, you're charging 250msat per hop? Why is Bob taking 750? Does Carol now know Dave is the last hop? Does Alice lose everything on any routing failure? If so, that is strong incentive for Alice to reduce path-length privacy by keeping payments minimal, which I was really trying to avoid. > You could make the accountable by having Alice > also provide "Hash(, refund=200)" to everyone, encoding in the > onion to Dave, and then each hop reveals and refunds 200msat to > demonstrate their honesty. > > Does that miss anything that all the hashing achieves? It does nothing if Carol is the one who can't route. > I think the idea here is that you're paying tiny amounts for the > bandwidth, which when it's successful does in fact pay for the bandwidth; > and when it's unsuccessful results in a channel closure, which makes it > unprofitable to cheat the system, but doesn't change the economics of > lightning much overall because channel closures can happen anytime anyway. Not at all. You can still fail to route, and still get paid. You can't steal *more* money without channel closure though. > I think that approach makes sense. > > Cheers, > aj Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment
Joost Jager writes: >> >> > * Add `to_remote_delay OP_CHECKSEQUENCEVERIFY OP_DROP` to the `to_remote` >> > output. `to_remote_delay` is the csv delay that the remote party accepted >> > in the funding flow for their outputs. This not only ensures that the >> > carve-out works as intended, but also removes the incentive to game the >> > other party into force-closing. If desired, both parties can still agree >> = >> to >> > have different `to_self_delay` values. >> >> I think we should unify to_self_delay if we're doing this. Otherwise >> the game returns. > > The game returns, but both parties will be aware of the game they are > playing. They agreed to their peer's to_self_delay up front. (This is > different from the current situation where both peers are forced to accept > a remote_to_self_delay of 0.) With validation on the open/accept_channel > message, a node can still enforce both to_self_delays to be equal. We could > simplify this to a single to_self_delay that is proposed by the initiator, > but what was the original reason to allow distinct values? Because I didn't fight hard enough for simplicity :( There is no "negotiation" on opening; it's accept or error. That leads to a situation where every implementation MUST accept what every implementation offers. The unification proposal was to use the max of the two settings. That's fair; if you want me to suffer a 2 week delay, you should too. >> Agreed, this doesn't really work. We actually needed a bitcoin rule >> that allowed a single anyone-can-spend output. Seems like we didn't get >> that. > > With the mempool acceptance carve-out in bitcoind 0.19, we indeed won't be > able to safely produce a single OP_TRUE output for anyone to spend. An > attacker could attach low fee child transactions, reach the limits and > block further fee bumping. Indeed :( >> This is horribly spammy. At the moment we see ~ one unilateral close >> every 3 blocks. Hopefully that will reduce, but there'll always be >> some. > > It seems there isn't another way to do the anchor outputs given the mempool > limitations that exist? Each party needs to have their own anchor, > protected by a key. Otherwise it would open up these attack scenarios where > an attacker blocks the commitment tx confirmation until htlcs time out. > Even with the script OP_DEPTH OP_IF OP_CHECKSIG OP_ELSE 10 OP_CSV > OP_ENDIF, the "anyones" don't know the pubkey and still can't sweep after > 10 blocks. I think you're right, but I don't *like* it... >> * Within each version of the commitment transaction, both anchors always >> > have equal values and are paid for by the initiator. >> >> Who pays if they can't afford it? What if they push_msat everything to >> the other side? > > Similar to how it currently works. There should never be a commitment > transaction in which the initiator cannot pay the fee. Unfortunately, this is not correct (in theory). We can always get into a case where fees are insufficient (simultanous HTLC adds), but it's unusual. We used to specify that the non-funder would pay the remaining fee, but we dropped this in favor of allow unilateral close if this ever happened. > With anchor outputs > there should never be a commitment tx in which the initiator cannot pay the > fee and the anchors. There can be, but I think we can simply modify this so you have to pay the anchors *first* before fees. > Also currently you cannot push everything to the other > side with push_msat. The initiator still needs to have enough balance to > pay for the on-chain costs (miner fee and anchors). This is true; I forgot we fixed that, sorry. push_msat is a red herring. >> The value of the >> > anchors is the dust limit that was negotiated in the `open_channel` or >> > `accept_channel` message of the party that publishes the transaction. >> >> Now initiator has to care about the other side's dust limit, which is >> bad. And as accepter I now want this much higher, since I get those >> funds instantly. I don't think we gain anything by making this >> configurable at all; just pick a number and be done. >> >> Somewhere between 1000 and 10,000 sat is a good idea. >> > > Yes, it is free money. Therefore we need to validate the dust limit in the > funding flow. Check whether it is reasonable. That should also be done in > the current implementation. Otherwise your peer can set a really high dust > limit that lets your htlc disappear on-chain (although that is only free > money for the miner). True, and spec should note this BTW! I've added an issue. https://github.com/lightningnetwork/lightning-rfc/issues/696 > If we hard-code a constant, we won't be able to adapt to changes of > `dustRelayFee` in the bitcoin network. And we'd also need to deal with a > peer picking a value higher than that constant for its regular funding flow > dust limit parameter. Note that we can't adapt to dustRelayFee *today*, since we can't change it after funding (another thing we probably need to
Re: [Lightning-dev] A proposal for up-front payments.
Hi Rusty, Agreed w.r.t the need for prepaid HTLCS, I've been mulling over other alternatives for a few years now, and none of them seems to resolve the series of routing related incentive issues that prepaid HTLCs would. > Since both Offers and Joost's WhatSat are looking at sending messages, > it's time to float actual proposals. IMO both should just be done over HORNET, so we don't need introduce a new set of internal protocol level messages whenever we have some new control/signalling need. Instead, we'd have a control/signal channel (give me routes, invoices, sign this, etc), and a payment channel (HTLCs as used today). > 2. Adding an HTLC causes a *push* of a number of msat on commitment_signed > (new field), and a hash. The prepay amount should be signalled in the update add message instead. This lets HTLCs carry a heterogeneous set of prepay amounts. In addition, we need a new onion field as well to signal the incoming amount the node _should_ have received (allows them to detect deviations in the sender's intended route). > 3. Failing/succeeding an HTLC returns some of those msat, and a count and > preimage (new fields). Failing shouldn't return the prepay amount, otherwise extending long lived HTLCs then cancelling them at the last minute is still costless. This costlessness of _adding_ an HTLC to a _remote_ commitment is IMO, the biggest incentive flaw that exists today in the greater routing network. > You get to keep 50 msat[1] per preimage you present[2]. We should avoid introducing any new constants to the protocol, as they're typically dreamed up independent of any empirical lessons learned from deployment. On the topic of the prepay cost, the channel update message should be extended to allow nodes to signal prepay costs similar to the way we handle regular payment success fees. In order to eliminate a number of costless attacks possible today on the routing network, nodes should also be able to signal a new coefficient used to _scale_ the prepay fee as a function of the CLTV value of the incoming HTLC. With this addition, senders need to pay to _add_ an HTLC to a remote commitment transaction (fixed base cost), then also need to pay a variable rate that scales with the duration of the proposed outgoing CLTV value (senders ofc don't prepay to themselves). Once we introduce this, loop attacks and the like are no longer free to launch, and nodes can dynamically respond to congestion in the network by raising their prepay prices. -- Laolu On Mon, Nov 4, 2019 at 6:25 PM Rusty Russell wrote: > Hi all, > > It's been widely known that we're going to have to have up-front > payments for msgs eventually, to avoid Type 2 spam (I think of Type 1 > link-local, Type 2 though multiple nodes, and Type 3 liquidity-using > spam). > > Since both Offers and Joost's WhatSat are looking at sending > messages, it's time to float actual proposals. I've been trying to come > up with something for several years now, so thought I'd present the best > I've got in the hope that others can improve on it. > > 1. New feature bit, extended messages, etc. > 2. Adding an HTLC causes a *push* of a number of msat on >commitment_signed (new field), and a hash. > 3. Failing/succeeding an HTLC returns some of those msat, and a count >and preimage (new fields). > > How many msat can you take for forwarding? That depends on you > presenting a series of preimages (which chain into a final hash given in > the HTLC add), which you get by decoding the onion. You get to keep 50 > msat[1] per preimage you present[2]. > > So, how many preimages does the user have to give to have you forward > the payment? That depends. The base rate is 16 preimages, but subtract > one for each leading 4 zero bits of the SHA256(blockhash | hmac) of the > onion. The blockhash is the hash of the block specified in the onion: > reject if it's not in the last 3 blocks[3]. > > This simply adds some payment noise, while allowing a hashcash style > tradeoff of sats for work. > > The final node gets some variable number of preimages, which adds noise. > It should take all and subtract from the minimum required invoice amount > on success, or take some random number on failure. > > This leaks some forward information, and makes an explicit tradeoff for > the sender between amount spent and privacy, but it's the best I've been > able to come up with. > > Thoughts? > Rusty. > > [1] If we assume $1 per GB, $10k per BTC and 64k messages, we get about > 655msat per message. Flat pricing for simplicity; we're trying to > prevent spam, not create a spam market. > [2] Actually, a number and a single preimage; you can check this is > indeed the n'th preimage. > [3] This reduces incentive to grind the damn things in advance, though > maybe that's dumb? We can also use a shorter hash (siphash?), or > even truncated SHA256 (128 bits). > ___ > Lightning-dev mailing
Re: [Lightning-dev] Rendez-vous on a Trampoline
Hi t-bast, > She creates a Bolt 11 invoice containing that pre-encrypted onion. This seem insufficient, as if the prescribed route that Alice selects fails, then the sender has no further information to go off of (let's say Teddy is offline, but there're other pats). cdecker's rendezvous sketch using Sphinx you linked above also suffers from the same issue: you need some other bi-directional communication medium between the sender and receiver in order to account for payment failures. Beyond that, if any failures occur in the latter half of the route (the part that's opaque to the sender), then the sender isn't able to incorporate the failure information into their path finding. As a result, the payer would need to send the error back to the receiver for decrypting, possibly ping-ponging several times in a payment attempt. On the other hand, using HORNET for rendezvous routing as was originally intended gives the sender+receiver a communication channel they can use to exchange further payment information, and also a channel to use for decryption of the opaque errors. Amongst many other things, it would also give us a payment-level ACK [1], which may be a key component for payment splitting (otherwise you have no idea if _any_ shards have even arrived at the other side). [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001524.html -- Laolu On Tue, Oct 22, 2019 at 5:02 AM Bastien TEINTURIER wrote: > Good morning everyone, > > Since I'm a one-trick pony, I'd like to talk to you about...guess what? > Trampoline! > If you watched my talk at LNConf2019, I mentioned at the end that > Trampoline enables high AMP very easily. > Every Trampoline node in the route may aggregate an incoming multi-part > payment and then decide on how > to split the outgoing aggregated payment. It looks like this: > > . 1mBTC ..--- 2mBTC ---. > /\ / > \ > Alice - 3mBTC --> Ted -- 4mBTC > Terry - 6mBTC > > Bob >\ / > `--- 2mBTC --' > > In this example, Alice only has small-ish channels to Ted so she has to > split in 3 parts. Ted has good outgoing > capacity to Terry so he's able to split in only two parts. And Terry has a > big channel to Bob so he doesn't need > to split at all. > This is interesting because each intermediate Trampoline node has > knowledge of his local channels balances, > thus can make more informed decisions than Alice on how to efficiently > split to reach the next node. > > But it doesn't stop there. Trampoline also enables a better rendez-vous > routing than normal payments. > Christian has done most of the hard work to figure out how we could do > rendez-vous on top of Sphinx [1] > (thanks Christian!), so I won't detail that here (but I do plan on > submitting a detailed spec proposal with all > the crypto equations and nice diagrams someday, unless Christian does it > first). > > One of the issues with rendez-vous routing is that once Alice (the > recipient) has created her part of the onion, > she needs to communicate that to Bob (the sender). If we use a Bolt 11 > invoice for that, it means we need to > put 1366 additional bytes to the invoice (plus some additional information > for the ephemeral key switch). > If the amount Alice wants to receive is big and may require multi-part, > Alice has to decide upfront on how to split > and provide multiple pre-encrypted onions (so we need 1366 bytes *per > partial payment*, which kinda sucks). > > But guess what? Bitcoin Trampoline fixes that*™*. Instead of doing the > pre-encryption on a normal onion, Alice > would do the pre-encryption on a Trampoline onion (which is much smaller, > in my prototype it's 466 bytes). > And that allows rendez-vous routing to benefit from Trampoline's ability > to do multi-part at each hop. > Obviously since the onion is smaller, that limits the number of trampoline > hops that can be used, but don't > forget that there are additional "normal" hops between each Trampoline > node (and the final Trampoline spec > can choose the size of the Trampoline onion to enable a good enough > rendez-vous). > > Here is what it would look like. Alice chooses to rendez-vous at Terry. > Alice wants the payment to go through Terry > and Teddy so she pre-encrypts a Trampoline onion with that route: > > Alice <--- Teddy <--- Terry > > She creates a Bolt 11 invoice containing that pre-encrypted onion. Bob > picks up that invoice and can either reach > Terry directly (via a normal payment route) or via another Trampoline node > (Toad?). Bob finalizes the encryption of > the Trampoline onion and sends it onward. Bob can use multi-part and split > the payment however he wishes, > because every Trampoline node in the route will be free to aggregate and > re-split differently. > Terry is the only intermediate node to know that rendez-vous routing was > used. Terry
Re: [Lightning-dev] A proposal for up-front payments.
On Tue, Nov 05, 2019 at 07:56:45PM +1030, Rusty Russell wrote: > Sure: for simplicity I'm sending a 0-value HTLC. > ZmnSCPxj has balance 1msat in channel with Rusty, who has 1000msat > in the channel with YAIjbOJa. Alice, Bob and Carol sure seem simpler than Zmn YAI and Rusty... > Rusty prepares a nonce, A and hashes it 25 times = Z. > ZmnSCPxj prepares the onion, but adds extra fields (see below). It would have made more sense to me for Alice (Zmn) to generate the nonce, hash it, and prepare the onion, so that the nonce is revealed to Dave (Rusty) if/when the message ever actually reaches its destination. Otherwise Rusty has to send A to Zmn already so that Zmn can prepare the onion? > He then > sends the HTLC to Rusty, but also sends Z, and 25x50 msat (ie. those > fields are in the update_add_htlc msg). His balance with Rusty is now > 8750msat (ie. 25x50 to Rusty). > > Rusty decrypts the onion, reads the prepay field: it says 14, L. > Rusty checks: the hash of the onion & block (or something) does indeed > have the top 8 bits clear, so the cost is in fact 16 - 8/2 == 14. He > then hashes L 14 times, and yes, it's Z as ZmnSCPxj said it > should be. I'm not sure why lucky hashing should result in a discount? You're giving a linear discount for exponentially more luck in hashing which also seems odd. You've only got two nonce choices -- the initial and the depth that you tell Bob and Carol to hash to as steps in the route; so the incentive there seems to be to do a large depth, so you might hash 1000 times, and figure that you'll find a leading eight 0's once in the first 256 entries, then another by the time you get up to 512, and another by the time you get to 768, which gets you discounts on three intermediaries. But the cost there is that your intermediaries collectively have to do the same amount of hashing you did, so it's not proof-of-work, because it's as hard to verify as it is to generate. I think you could just make the scheme be: Alice sends HTLC(k,v) + 1250 msat to Bob Bob unwraps the onion and forwards HTLC(k,v) + 500 msat to Carol Carol unwraps the onion and forwards HTLC(k,v) + 250 msat to Dave Dave redeems the HTLC, claims an extra 300 msat and refunds 200 msat to Carol Carol redeems the HTLC and refunds 200 msat to Bob Bob redeems the HTLC and refunds 200 msat to Alice If there's a failure, Alice loses the 1250 msat, and someone in the path steals the funds. You could make the accountable by having Alice also provide "Hash(, refund=200)" to everyone, encoding in the onion to Dave, and then each hop reveals and refunds 200msat to demonstrate their honesty. Does that miss anything that all the hashing achieves? I think the idea here is that you're paying tiny amounts for the bandwidth, which when it's successful does in fact pay for the bandwidth; and when it's unsuccessful results in a channel closure, which makes it unprofitable to cheat the system, but doesn't change the economics of lightning much overall because channel closures can happen anytime anyway. I think that approach makes sense. Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers
Hi Rusty, It seems that there are two kind of TLV fields in your proposition: 1) LN specific fields like `num_paths` and `payment_preimage`. 2) "Business" fields like `address1` and `currency`. I understand the need to define and include the first category, but I don't think that we need or can define the second category. These fields already exists in software like crm, erp, etc.. and are well defined by standard body. My suggestion is to have a generic field containing well defined structured and standardized data. See for instance https://en.wikipedia.org/wiki/EDIFACT and/or https://en.wikipedia.org/wiki/Universal_Business_Language. What do you think? PS: Sorry for crossposting here and in https://github.com/lightningnetwork/lightning-rfc/pull/694 --yas On 05/11/2019 06:23, Rusty Russell wrote: Hi all, This took longer than I'd indicated; for that I'm sorry. However, this should give us all something to chew on. I've started with a draft "BOLT 12" (it might be BOLT 13 by the time it's finalized though!). I've also appended indications where we touch other BOLTs: 1. BOLT 7 gains a message/reply system, encoded like htlc onions and failure messages. 2. BOLT 11 gains a `q` field for quantity; this avoids changing the description when the user requests an invoice for more than one of something (since changing the description between offer and invoice requires user interaction: it's the *invoice* which you are committing to). There's definite handwaving in here; let's see if you can find it! Cheers, Rusty. # BOLT #12: Offer Protocols for Lightning Payments An higher-level, QR-code-ready protocol for dealing with invoices over Lightning. There are two simple flows supported: in one, a user gets an offer (`lno...`) and requests an invoice over the lightning network, obtaining one (or an error) in reply. In the other, a user gets an invoice request (`lni...`), and sends the invoice over the lightning network, retreiving an empty reply. # Table of Contents * [Offers](#offers) * [Encoding](#encoding) * [TLV Fields](#tlv-fields) * [Invrequests](#invrequests) * [Encoding](#encoding) * [TLV Fields](#tlv-fields) # Offers Offers supply a reader with enough information to request one or more invoices via the lightning network itself. ## Encoding The human-readable part of a Lightning offer is `lno`. The data part consists of three parts: 1. 0 or more [TLV](01-messaging.md#type-length-value-format) encoded fields. 2. A 32-byte nodeid[1] 3. 64-byte signature of SHA256(hrp-as-utf8 | tlv | nodeid). ## TLV Fields The TLV fields define how to get the invoice, and what it's for. Each offer has a unique `offer_idenfitier` so the offering node can distinguish different invoice requests. Offers can request recurring payments of various kinds, and specify what base currency they are calculated in (the actual amount will be in the invoice). `additional_data` is a bitfield which indicates what information the invoice requester should (odd) or must (even) supply: 1. Bits `0/1`: include `delivery_address` 2. Bits `2/3`: include `delivery_telephone_number` 3. Bits `4/5`: include `voucher_code` 4. Bits `6/7`: include `refund_proof` `refund_for` indicates an offer for a (whole or part) refund for a previous invoice, as indicated by the `payment_hash`. 1. tlvs: `offer` 2. types: 1. type: 1 (`paths`) 2. data: * [`u16`:`num_paths`] * [`num_paths*path`:`path`] 1. type: 2 (`description`) 2. data: * [`...*byte`:`description`] 1. type: 3 (`expiry`) 2. data: * [`tu64`:`seconds_from_epoch`] 1. type: 4 (`offer_identifier`) 2. data: * [`...*byte`:`id`] 1. type: 5 (`amount`) 2. data: * [`4*byte`:`currency`] * [`tu64`:`amount`] 1. type: 6 (`additional_data`) 2. data: * [`...*byte`:`rbits`] 1. type: 7 (`recurrance`) 2. data: * [`byte`:`time_unit`] * [`u32`:`period`] * [`tu32`:`number`] 1. type: 8 (`recurrance_base`) 2. data: * [`u32`:`basetime`] * [`tu32`:`paywindow`] 1. type: 9 (`quantity`) 2. data: * [`tu64`:`max`] 1. type: 10 (`refund_for`) 2. data: * [`32*byte`:`payment_hash`] 1. subtype: `path` 2. data: * [`u16`:`num_hops`] * [`num_hops*hop`:`hops`] 1. subtype: `hop` 2. data: * [`pubkey`:`nodeid`] * [`short_channel_id`:`short_channel_id`] * [`u16`:`flen`] * [`flen*byte`:`features`] ## Requirements For Offers And Invrequests A writer of an offer or an invrequest: - if it is connected only by private channels: - MUST include `paths` containing a path to the node. - otherwise: - MAY include `paths` containing a path to the node. - MUST describe the item(s) being offered or purpose of invoice in `description`. - MUST include `expiry` if the
