Re: [Lightning-dev] A New Routing Paradigm:Ant Routing +`getroutequick` + Trampoline
Good morning again Cezary, > > That was really interesting to read this. > > Why you want to send Node ID inside pheromone? Why not to send random > > number, that would be then passed though invoice? > > To increase privacy, node could generate new random number every week and > > distribute pheromone gain. > > Our spam-limiting mechanism in current Lightning is tied to node IDs, and > node IDs are effectively anchored onchain by the channels they have (and > onchain is public anyway...). > I was hoping to reuse the same mechanism to give an upper bound on how much > spam you can ride on the Lightning pheromone network (the same bound applies > to the current Lightning gossip, you can only spam Lightning by spamming > Bitcoin, and spamming Bitcoin is costly). > > However, if you have other ideas about how to limit pheromone spam, I would > gladly like to hear it. For example, instead of considering distance-from-node, we could realize that it is the *channel* itself that is what limits the pheromone spam. So maybe the pheromone should count distance-from-*channel*. If I want to be a receiver, I just need to ensure that at least one of my open channels has been published as a pheromone (and I do not need to publish *all* my channels, just enough of them to have a good chance of being reachable). The pheromone would contain signatures of me and my counterparty. (In a post-Taproot world, it would contain a single signature, plus a proof that the UTXO involved is reserved *only* for Lightning network (for example, channel UTXOs could have a taprooted `OP_RETURN "Lightning Is Awesome!!"` branch which can never be used, but which can be revealed to show that it is for Lightning), and is not a locked UTXO that is *also* being used for another purpose, as that obviates the spam-limiting since multiple applications could now be spammed with a single onchain UTXO.) Crucially, the pubkeys used need not be our node IDs, and every channel will have different pubkeys, even if two channels are to the same two nodes. Now suppose I want to issue an invoice. I just check what channels I have that have been pheromone-broadcast. The invoice then contains the selected short-channel-id(s) rather than the actual node (though since invoices are signed, what pubkey do we use to sign it?). Then suppose I receive an incoming HTLC that is supposed to reach a short-channel-id of a channel I have. Either it is to me, or to my peer on that channel. If it is to me, then I should be able to recognize the payment hash / payment point on the HTLC/PTLC, and can claim it now. If I do not recognize it, it is probably to my counterparty, who can then check if it recognizes the payment hash / point and send back a definite `incorrect_or_unknown_payment_details`, signed by itself (which the payer can recognize as one of the signatories of the pheromone). Crucially, this lets me receive money via other, unpublished channels as well; the payment might be going in the direction of my channel, but I could also be on the shortest path between the payer and that specific channel. Now let us turn our attention to onion-routing a trampoline route when our pheromones are channel-based instead of node-based. Remember, onion-routing requires that we know a static public key of a node, with which we can make an asymmetric encryption. However, pheromones also show the two public keys involved in the channel, and our trampoline routing can use one or the other key arbitrarily (though budgets may need to add +1 hop in case it lands in the "wrong" direction). Then if I receive a trampoline-routed onion to a channel that I have, I can try to decrypt with my key, and if that succeeds, then I have unwrapped the onion and know the next trampoline (or I know that I am the final destination). If decryption fails (there is an HMAC again of the "rest" of the onion after all) then the onion is for my peer on that channel and I hand over the HTLC to it. Similarly, since payment point decorrelation will now be handled at the trampoline level, presumably the onion can now contain the tweak to be applied to the payment point. This gives a mild improvement in privacy: everyone else who is not involved in the channel has a 50/50 chance of guessing who is the real destination of the payment. Further, every channel I have has its own pubkey I own, which is not the same as the pubkey I own on another channel. I could use one channel as the destination when I am selling Ahura Mazda Holy Writings and Sanctified Commentary, and another channel as the destination when I am selling The Horned Man Depraved Sex Paraphernalia, even from the same Lightning node. With proper handling of UTXOs after closing (i.e. doing onchain mixing before spending onchain, or creating a new channel) then the single node I operate can sell both without anyone realizing I sell both kinds of products; I could claim that I was just an innocent
Re: [Lightning-dev] A New Routing Paradigm:Ant Routing +`getroutequick` + Trampoline
Good morning Cezary, > That was really interesting to read this. > Why you want to send Node ID inside pheromone? Why not to send random number, > that would be then passed though invoice? > To increase privacy, node could generate new random number every week and > distribute pheromone gain. Our spam-limiting mechanism in current Lightning is tied to node IDs, and node IDs are effectively anchored onchain by the channels they have (and onchain is public anyway...). I was hoping to reuse the same mechanism to give an upper bound on how much spam you can ride on the Lightning pheromone network (the same bound applies to the current Lightning gossip, you can only spam Lightning by spamming Bitcoin, and spamming Bitcoin is costly). However, if you have other ideas about how to limit pheromone spam, I would gladly like to hear it. Regards, ZmnSCPxj > Best regards, > Cezary Dziemian > > pon., 10 lut 2020 o 11:35 ZmnSCPxj via Lightning-dev > napisał(a): > > > Overview of Components > > == > > > > Ant Routing > > --- > > > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002505.html > > > > Ant Routing is a distributed pathfinding algorithm where nodes emit > > "pheromones", which are broadcasted over the entire network. > > When a node receives a pheromone (a UUID plus a distance counter) from a > > peer it has a channel with, it records that pheromone locally, then > > broadcasts it to other peers it has channels with, but with the distance > > counter increased by one. > > > > Subsequently, a payee can then provide the pheromone identifier to a payer, > > which can check if it has received that pheromone, and from which channel > > it received it from. > > It can the forward the payment via the channel. > > The next node can itself perform this operation, looking up the pheromone > > identifier and determining which channel it came from, and so on, until the > > payment reaches the destination. > > > > `getroutequick` > > --- > > > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-August/002095.html > > https://zmnscpxj.github.io/activity/2019-10-18/presentation.odp > > > > The overall `getroutequick` algorithm simply uses a Greedy Best First > > Search, which requires a heuristic that returns a distance to the target. > > The heuristic is generated from cached data: the cache itself is generated > > by first performing a Dijkstra on the entire routemap, recording the > > distance from our own node at each mapped node. > > The `getroutequick` algorithm then starts at one end of the route, and the > > other end must be our own node; this typically makes sense since both ends > > of the route are the payer and the payee, and have an interest in the > > payment succeeding by having a route available. > > > > The power of `getroutequick` lies in pre-caching the Dijkstra run; Dijkstra > > is heavy as it requires traversing the entire routemap, but its result can > > be cached and then used in Greedy Best First Search, which is likely to > > traverse only the shortest route. > > This moves the heavy lifting from the point in time in which a payment is > > initiated, improving payment experience by reducing the amount of time > > needed to find a route to a particular payee. > > > > Trampoline > > -- > > > > https://github.com/lightningnetwork/lightning-rfc/pull/654 > > > > Trampoline simply means doing onion routing at a level distinct from the > > individual channel level. > > An onion route of "trampoline" nodes is formed, without specifying the > > exact channels in the route between them. > > Currently, the idea is that there is an "outer" onion that describes a path > > to the next trampoline node, and an "inner" onion that describes the > > next-next trampoline node. > > > > Digression: On the Current Gossip System > > > > > > Currently, we use a gossip system where nodes and channels publicly show > > that particular outputs on the blockchain layer are actually funding > > transaction outputs that back channels. > > > > Whenever a new node joins the Lightning network, it anchors its existence > > to the blockchain by having a channel opened with it (either it funds, or > > is funded to). > > Then, on the basis of this anchored channel, it announces its existence. > > This implies that bandwidth usage for this gossip system is bounded by the > > bandwidth limits we have imposed in the blockchain layer. > > Thus, even though this gossip system requires the data to be broadcast > > globally to all nodes, the utilized resource is still bounded by the space > > limits of the Bitcoin blockchain layer. > > > > Further, the gossip system allows announcements to be refreshed > > periodically. > > However, ultimately the amount of bandwidth used for routing information > > broadcast via gossip is bounded by the amount of bandwidth we have
Re: [Lightning-dev] DRAFT: interactive tx construction protocol
Good morning niftynei, and waxwing, and list, > > s = k + H(kG || kJ || P || P2 || utxo || receiving-node) x > > > and as before transfer opening: (P, P2, u, s, e) with receiving-node > > implicitly reconstructed to do the verification of the Schnorr sig. It's > > basically a message in a signature. > > Oh that's *much* nicer than calculating a second commitment. Verification by > any node that's not the intended recipient will fail, as they'll use the > wrong node_id (their own). > > It seems unnecessary to me to commit to the utxo, since the pubkey pair > effectively does that. What's the motivation for including it? Probably so that address reuse is not dinged, i.e. I have two UTXOs with the same address and want to make two different channels with different peers. While address reuse Is Bad, you might not have much control over some wog who is supposed to pay you and decides to give you your money in two separate UTXOs to the same address. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] A New Routing Paradigm:Ant Routing +`getroutequick` + Trampoline
That was really interesting to read this. Why you want to send Node ID inside pheromone? Why not to send random number, that would be then passed though invoice? To increase privacy, node could generate new random number every week and distribute pheromone gain. Best regards, Cezary Dziemian pon., 10 lut 2020 o 11:35 ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> napisał(a): > Overview of Components > == > > Ant Routing > --- > > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002505.html > > Ant Routing is a distributed pathfinding algorithm where nodes emit > "pheromones", which are broadcasted over the entire network. > When a node receives a pheromone (a UUID plus a distance counter) from a > peer it has a channel with, it records that pheromone locally, then > broadcasts it to other peers it has channels with, but with the distance > counter increased by one. > > Subsequently, a payee can then provide the pheromone identifier to a > payer, which can check if it has received that pheromone, and from which > channel it received it from. > It can the forward the payment via the channel. > The next node can itself perform this operation, looking up the pheromone > identifier and determining which channel it came from, and so on, until the > payment reaches the destination. > > `getroutequick` > --- > > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-August/002095.html > https://zmnscpxj.github.io/activity/2019-10-18/presentation.odp > > The overall `getroutequick` algorithm simply uses a Greedy Best First > Search, which requires a heuristic that returns a distance to the target. > The heuristic is generated from cached data: the cache itself is generated > by first performing a Dijkstra on the entire routemap, recording the > distance from our own node at each mapped node. > The `getroutequick` algorithm then starts at one end of the route, and the > other end must be our own node; this typically makes sense since both ends > of the route are the payer and the payee, and have an interest in the > payment succeeding by having a route available. > > The power of `getroutequick` lies in pre-caching the Dijkstra run; > Dijkstra is heavy as it requires traversing the entire routemap, but its > result can be cached and then used in Greedy Best First Search, which is > likely to traverse only the shortest route. > This moves the heavy lifting from the point in time in which a payment is > initiated, improving payment experience by reducing the amount of time > needed to find a route to a particular payee. > > Trampoline > -- > > https://github.com/lightningnetwork/lightning-rfc/pull/654 > > Trampoline simply means doing onion routing at a level distinct from the > individual channel level. > An onion route of "trampoline" nodes is formed, without specifying the > exact channels in the route between them. > Currently, the idea is that there is an "outer" onion that describes a > path to the next trampoline node, and an "inner" onion that describes the > next-next trampoline node. > > Digression: On the Current Gossip System > > > Currently, we use a gossip system where nodes and channels publicly show > that particular outputs on the blockchain layer are actually funding > transaction outputs that back channels. > > Whenever a new node joins the Lightning network, it anchors its existence > to the blockchain by having a channel opened with it (either it funds, or > is funded to). > Then, on the basis of this anchored channel, it announces its existence. > This implies that bandwidth usage for this gossip system is bounded by the > bandwidth limits we have imposed in the blockchain layer. > Thus, even though this gossip system requires the data to be broadcast > globally to all nodes, the utilized resource is still bounded by the space > limits of the Bitcoin blockchain layer. > > Further, the gossip system allows announcements to be refreshed > periodically. > However, ultimately the amount of bandwidth used for routing information > broadcast via gossip is bounded by the amount of bandwidth we have allowed > the blockchain layer to use (i.e. the block size and block rate parameters > of the blockchain). > > Combined Proposal > = > > Combining Ant Routing and `getroutequick` > - > > Ant routing, we can observe, is equivalent to a distributed form of > Dijkstra algorithm. > Its major drawback is that every payment causes the emission of a > pheromone, which must be broadcasted to the entire network. > This implies using resources proportional to the total number of payments > globally, unlike the current Lightning network where each node only gets > data regarding payments it is involved in routing. > This reverses the advantage of Lightning network, making it as inefficient > (in terms of big-O,
Re: [Lightning-dev] DRAFT: interactive tx construction protocol
niftynei, ZmnSCPxj and list: Zmn** pinged me about this discussion and I thought I could add something directly: First, re: > I'd like to propose that we add a second commitment requirement to the PoDLE > that JoinMarket uses, to limit the use of a commitment's validity to be only > between an initiator and a single peer. Otherwise you can enable something > I'll call the "pouncing venus-flytrap attack"[1]. Here's some thoughts that may give context to this (excellent) observation: This issue didn't crop up (well, kinda! I do remember discussion about it) in our use case because takers always send out to 5-12 (typically) makers at once, and the HP2 only needs to get broadcast by one to stop any reuse. But whichever way you look at it, it's a very good point! And in LN case, seems like a very substantial attack (certainly no question it could be allowed for 2 party protocol). In case a brief summary of JM mechanism is helpful, I added some info on the the taker-maker conversation at the end of this mail [1]. Second, re: > ## Mitigation > Have each initiator provide two commitments: one to the shared/global J > point and one to a point that is found from the hash of the non-initiating > node's node_id.[2] I get the thinking here, and it makes a lot of sense, but I do think it can be done more compactly. If the commitment is H(P2), the opening of the commitment could be altered to include the receiving node: s = k + H(kG || kJ || P || P2 || utxo || receiving-node) x and as before transfer opening: (P, P2, u, s, e) with receiving-node implicitly reconstructed to do the verification of the Schnorr sig. It's basically a message in a signature. As you note, we wouldn't want to ban usage of a H(P2) value based on an incorrect opening; we just use that failure to decide to not hand over our utxo information (as receiver of the commitment). But unless I missed something, doing it the above way is the more logical/compact choice. Seems like there's a lot of fine nuance here. A malicious counterparty can always choose to blacklist. In Joinmarket we accept (because of our stringent no-identity policy) some roughness and assume some meaningful level of honest participation. A Taker issuing a request to 10 cps hopes that at least some number (min 4 by default) will actually respond to an honest request; if say 8 of 10 do so, he will do the coinjoin with those. That it is brittle or flaky is why we allow 3 tries for each qualifying utxo (qualified on age, size), and also allow custom insertion of additional utxos (although it's rarely if ever needed). It works fine in practice, for now, but it is not watertight; if you have overwhelmingly malicious counterparties you are kinda screwed from other angles, as well as this one. Meanwhile on the Maker side we're trying to create a kind of 'herd immunity'; as long as some few of them are honest, word will get out about used commitments which will stop free spam queries, at least (but it's not a super strong defence!). [1] Taker-Maker convo (excerpt); some notes re: commitments/PoDLE. === !fill amount, oid, commitment (HP2) -- this is where a taker sends to each maker an hp2 value. This is the step intended to enforce scarcity, and the assumption in JM was always that this would basically inevitably get shared. Because there are typically 5-12 makers involved, this seemed a reasonably safe assumption. If the commitment value is already used and thus not valid, it gets broadcast immediately. If it's not, it only gets shared as part of the !ioauth step below. !pubkey key -- this is just the maker giving an ephemeral key for the encryption !auth (s, e, u, P, P2) -- (encrypted) this is the taker opening the above commitment. It's rather weird at first sight, because he is opening immediately after committing, with apparently no step inbetween; but in fact the implicit intermediate step is the broadcast (exactly what is being questioned with 'venus flytrap'). !ioauth maker-utxo-data -- notice the maker is only sending this utxo data (encrypted of course) after proof of ownership of the utxo above. It's only at this step that the hp2 commitment value is (a) added to the maker's local "used up" list, and (b)privmsged to 1 randomly chosen other bots in the trading pit, who then pubmsgs it to everyone (and that happens multiple times because multiple makers in tx), and they in turn record it as "used". The mechanism is both not very strong - we use 3 allowed attempts per utxo - and imperfect in its "justice"; such commitments can be "used up" by failures of one's counterparties. But it does serve to stop trivial global snooping, and doesn't cost anything in terms of identity or locked funds, so it has served a purpose (we did actually see such attacks before it, and not after it). I'd also note that in terms of the venus flytrap attack mentioned, there could be a small time window between one maker receiving !auth and
Re: [Lightning-dev] DRAFT: interactive tx construction protocol
Hi darosior, niftynei, and list, waxwing replied the below text, and asked to propagate as well to lightning-dev. He has just recently re-subscribed to lightning-dev, but may be waiting for the necessary subscription notices or whatnot. Regards, ZmnSCPxj --- Re: Venus Flytrap attack and JoinMarket This issue didn't crop up in our use case because takers always send out to 5-12 (typically) makers at once, and the HP2 only needs to get broadcast by one to stop any reuse. But whichever way you look at it, it's a very good point! And in LN case, seems like a very substantial attack (at least from what little I've read so far). In case a brief summary of JM mechanism is helpful, here's the taker-maker conversation: !fill amount, oid, commitment (HP2) -- this is where a taker sends to each maker an hp2 value. This is the step intended to enforce scarcity, and the assumption in JM was always that this would basically inevitably get shared. Because there are typically 5-12 makers involved, this seemed a reasonably safe assumption. If the commitment value is already used and thus not valid, it gets broadcast immediately. If it's not, it only gets shared as part of the !ioauth step below. !pubkey key -- this is just the maker giving an ephemeral key for the encryption !auth (s, e, u, P, P2) -- (encrypted) this is the taker opening the above commitment. It's rather weird at first sight, because he is opening immediately after committing, with apparently no step inbetween; but in fact the implicit intermediate step is the broadcast (exactly what is being questioned with 'venus flytrap'). !ioauth maker-utxo-data -- notice the maker is only sending this utxo data (encrypted of course) after proof of ownership of the utxo above. It's only at this step that the hp2 commitment value is (a) added to the maker's local "used up" list, and (b)privmsged to 1 randomly chosen other bots in the trading pit, who then pubmsgs it to everyone (and that happens multiple times because multiple makers in tx), and they in turn record it as "used". The mechanism is both not very strong - we use 3 allowed attempts per utxo - and imperfect in its "justice"; such commitments can be "used up" by failures of one's counterparties. But it does serve to stop trivial global snooping, and doesn't cost anything in terms of identity or locked funds, so it has served a purpose (we did actually see such attacks before it, and not after it). I'd also note that in terms of the venus flytrap attack mentioned, there could be a small time window between one maker receiving !auth and at least one other honest maker getting to broadcast step at !ioauth; while I don't think that's very practical in our use case, it is for sure a theoretical concern and removing it could be either slightly, or extremely, important in another use case. I'll have a look at this new idea related to node-id and get back to you on that. Thanks for this analysis and investigation, it's a very interesting area. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] DRAFT: interactive tx construction protocol
Good morning darosior, niftynei, and list, > > We could agree on an acceptable number of reuse in case on a non-malicious > failure from the initiator after a valid PoDLE exchange ? (credits ZmnSCPxj) The default of 3 for JoinMarket seems reasonable. > > Ok, so knowing where PoDLE originate from mitigates the flood we talked about > with ZmnSCPxj. > However I don't see how the number of utxos in the mempool is useful here, as > you cannot distinguish which PoDLE is the real one out of the load you are > receiving in case of a flood ? No idea either, but if we limit accepted `node_id`s to those that we have seen in a `node_announcement` before, then we ride on the fact that `node_announcement` is costly in the sense that somebody has to allocate at least some small amount of funds to a channel that is visible onchain, because `node_announcement` requires a `channel_announcement` with an anchored channel. Then if nodes on the network can just send PoDLE gossip that they did not sign themselves, but are signed by *some* node that was `node_announcement`ed before, we can identify those nodes that are spamming a lot of their own signed PoDLE gossip, and rate-limit those. It is likely that announced nodes are the ones who will have such attack attempts performed on them, so they are in the best position to inform others of such attempts and are the most likely to have such data. At some point we probably also need to have set reconciliation for these as well. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Decoy node_ids and short_channel_ids
Hi Rusty, Thanks for the answer, and good luck with c-lightning 0.8.1-rc1 ;) (I think we should probably ban forwarding to private channels, > too, for similar reasons). Can you detail why? I believe that forwarding through private channels can actually be pretty useful in the future for payee privacy (more on that later). Note that with any self-assigned SCID schemes, Alice has to respond to > unknown scids in update_add_htlc with some BADONION code (which makes > *Bob* give Carol an error response, since Alice can't without revealing > her identity). I believe the difference is that in your scheme, Bob would answer with `unknown_next_peer`. When instead Alice responds with a `BADONION`, the only thing it reveals is that Alice does use the decoy feature (which Mallory already knows because she has seen an invoice from Alice). As long as this behavior is consistent throughout the network, I think both options offer the same privacy (unless I'm missing something). I expect such payments to become > significant, and as long as paying to a temporary id and paying to a > private channel looks identical, it's too draconian to ban. True, that must become the default flow for receiving payments on mobile wallets. Granted, my solution would take longer to deploy because it needs to be added to sender wallets before receivers can require it. I've been thinking more about improving my scheme to not require any sender change, but I don't think that's possible at the moment. As with all Lightning tricks though, once we have Schnorr then it's really easy to do. Alice simply needs to use `s * d_a` as her "preimage" (and the payment point becomes the P_I Bob needs). That may depend on the exact multi-hop locks construction we end up using though, so I'm not 100% sure about that yet. But I did come up with what could be an interesting development. Nothing prevents the decoy scheme to be used for public channels too, and for multiple hops: that enables a cheap form of rendezvous that only costs a few hundred bytes in the invoice. Alice would select multiple hops to a rendezvous node, and would apply some blinding to those hops' `node_id` and `scid`. Alice would include these decoy hops in the invoice `routing_hints` (only costs 51 bytes per hop instead of a full onion). Mallory would only learn an upper bound on the distance between Alice and the rendezvous. I have a detailed version of the scheme in a gist [1] if people want to take a deeper look and break it (beer on me to the first one who breaks the scheme). [1] https://gist.github.com/t-bast/9972bfe9523bb18395bdedb8dc691faf Cheers, Bastien Le lun. 10 févr. 2020 à 04:40, Rusty Russell a écrit : > > Bastien TEINTURIER writes: > >> But Mallory can do the same attack, I think. Just include the P_I from > >> the wrong invoice for Bob. > > > > Good catch, that's true, thanks for keeping me honest there! In that case > > my proposal > > would need the same mitigation as yours, Bob will need to include the > > `scid` he received > > in `update_add_htlc` (this is in fact not that hard once we allow TLV > > extensions on every > > message). > > Yes, I've added this to the PR. Which gives a new validation path, I > think: > > ## Figuring out what nodeid to use to decode onion > > 1. Look up scid from HTLC; if it didn't include one, use default. > 2. Look up payment_hash; if no invoice is found, use default. > 3. If invoice specified this scid, get nodeid and use that. > 4. ... and refuse to forward the HTLC (it must terminate here). > > My plan is to add an argument to `invoice` which is an array of one or > more scids: we get a temporary scids for each peer and use them in the > routehints. We also assign a random temporary nodeid to that invoice. > > The above algo is designed to ensure we behave like any other node which > has no idea about this nodeid if Mallory: > > 1. tries to use a temporary node id on a normal channel to us. > 2. tries to pay another invoice using this temporary node id. > 3. tries to probe our outgoing channels using this routing hint >(I think we should probably ban forwarding to private channels, >too, for similar reasons). > > --- > > Note that with any self-assigned SCID schemes, Alice has to respond to > unknown scids in update_add_htlc with some BADONION code (which makes > *Bob* give Carol an error response, since Alice can't without revealing > her identity). > > With Bob-assigned SCIDs, Alice simply needs to make him unallocate > it before forgetting the invoice, so she will simply never see old > invoices. > > (All these schemes give limited privacy, of course: Bob knows who Alice > is, and fingerprinting and liveness attacks are always possible). > > > I'm extremely nervous about custodial lightning services restricting > >> what they will pay to. This is not theoretical: they will come under > >> immense KYC pressure in the near future, which means they cannot pay > >> arbitrary invoices. > 1>> > > > > That's
Re: [Lightning-dev] DRAFT: interactive tx construction protocol
Hi niftynei and list, ‐‐‐ Original Message ‐‐‐ Le mardi, février 11, 2020 12:11 AM, lisa neigut a écrit : > Here's some thoughts I had on PoDLE's and lightning. An enormous > tip-of-the-hat is due to ZmnSCPxj for surfacing the work that JoinMarket has > done here already. > > - The initiating message (in the case of open channel, this would be > `open_channel2`) is extended to include an 'H2' field in its TLV, a 32-byte > hash commitment to the P2 key. > - Only one H2 commitment is required. > - The `tx_add_input` message, as specified previously, is extended to an > include a TLV type. This must be present on the input addition that > corresponds with the UTXO used for the originally transmitted commitment > - The non-initiator SHOULD wait to send any `tx_add_input` messages of their > own until after receiving a `tx_add_input` message with a valid PoDLE TLV > extension. > > 1. tlvs: `add_input_tlvs` > 2. types: > 1. type: 1 (`proof_of_dle`) > 2. data: > *[`64*byte`:`s||e`] > *[`33*byte`:pubkey`] > *[`33*byte`:pubkey2`] > > - If the proof is incorrect, the non-initiator MAY fail the transaction > collaboration or respond with `tx_complete`. There is no need for them to > publish the PoDLE. > - If the proof is correct, the non-initiator verifies that the commitment > (hash of pubkey2) has not been communicated to them via gossip. > - If the proof is not in their gossip store, the transaction collaboration > continues. It is considered 'safe' for the non-initiator to send > `tx_add_input` to their peer. > - If the proof IS in their gossip store, the transaction collaboration SHOULD > reply with `tx_complete`. It is considered 'unsafe' for the non-initiator to > send `tx_add_input`. (This allows errored/erroring initiators to use > blacklisted utxos, however it prevents them from privy to any other nodes' > UTXO set.) We could agree on an acceptable number of reuse in case on a non-malicious failure from the initiator after a valid PoDLE exchange ? (credits ZmnSCPxj) > - The initiator MUST NOT remove the committed to UTXO from the collaboration > set. > > - If the transaction collaboration fails/is errored by the initiator, > - the non-initiator SHOULD broadcast the original PoDLE commitment to the > gossip network. > - the non-initiator MAY delay broadcast to allow the initiating node to > re-attempt the open. > > The gossip message for a PoDLE blacklist entry is as follows: > > 1. type: 259 (`podle_blacklist`) > 2. data: > *[`signature`:`signature`] > *[`32*byte`:`H2`] > *[`point`:`node_id`] > *[`u32`:`timestamp`] > > Note that the `node_id` is the id of the node that signs (and broadcasts) the > blacklisted PoDLE. h/t to ZmnSCPxj for the gossip construction. > The timestamp is added as a convenience for peers to trim/discard blacklist > participants as they wish depending on time/staleness. > > ## Some Notes: > - The JoinMarket protocol allows nodes to use any of a range of secondary > points for J. Since the lightning version of this allows blacklisted UTXOs to > still open channels, albeit without participation from the peer, it seems > unnecessary to allow for more than one valid J point. I'd propose fixing the > J the same zero-index point used by JoinMarket. This reduces the number of > valid H2's that are available for any given utxo set, while also keeping > blacklisted H2's compatible with the blacklist set generated by JoinMarket > implementations. > - The blacklist originates from the 'non-initiating' peer, and does not > reveal the offending node's id. > - Assuming that every node honestly participates in the blacklist, only > verified H2's will be submitted to the blacklist > - A malicious non-initiator can only prevent an honest initiator from using > the committed UTXO for collaborative transactions; they won't prevent them > from successfully initiating a one-sided transaction with honest peers. > - Only nodes that have at least one public channel will be able to contribute > to the public PoDLE blacklist. This means it's possible for a malicious > initiator to grief non-public nodes without much consequence, however this > requires the ability to send inbound messages to private nodes, i.e. more > likely for a close or splice interaction. > - As ZmnSCPxj has pointed out elsewhere, a malicious peer could broadcast > junk H2's; it is acceptable to rate-limit the number of PoDLE blacklists > generated by a peer.peer > - It is possible for a malicious peer to fail to relay their `H2` entries in > the blacklisted gossip set. > - Duplicate H2 gossip should replace older timestamped versions. > - Elsewhere we've had a discussion/concern over floods of PoDLE blacklist > messages. It's possible for gossip message floods to originate from a > malicious peer; they also might signal an ongoing probe attempt. Given a > timestamp and a rough measure of the number of utxos'
