{"type":"rich","version":"1.0","title":"lisa neigut [ARCHIVE] wrote","author_name":"lisa neigut [ARCHIVE] (npub1sp…s64t2)","author_url":"https://yabu.me/npub1sprhp66c693av0c0n9had046hcdcckp2th25fnmphwstc5e4wg9qxs64t2","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-02-10\n📝 Original message:\nI'd like to propose that we add a second commitment requirement to the\nPoDLE that JoinMarket uses, to limit the use of a commitment's validity to\nbe only between an initiator and a single peer. Otherwise you can enable\nsomething I'll call the \"pouncing venus-flytrap attack\"[1].  Venus-flytrap\nbecause they sit in wait for victims; pouncing because the venus-flytrap\nthen attacks other nodes using the provided fly/utxo bait.\n\n## The Attack\nA malicious node sits and waits until another, honest, node initiates an\nopen with them. They wait until the honest initiator has sent them the\ncommitment and utxo proof. They then use the provided, non-blacklisted utxo\nand commitment proof to attempt to open a channel with as many other nodes\nas possible, simultaneously. They may either fail to respond or not fail\nthe original channel open. They fail every other open attempt,\nsimultaneously. Each of the nodes they've griefed will blacklist the\nprovided UTXO; the honest initiator has now had their utxo blacklisted.\n\n## Mitigation\nHave each initiator provide two commitments: one to the shared/global J\npoint and one to a point that is found from the hash of the non-initiating\nnode's node_id.[2]\n\nThe global-point commitment is the one that is blacklisted; the node_id's\ncommitment prevents the other party from being able to re-use a commitment\nin another channel, as they'll be unable to produce a valid commitment to\nthe point derived from the node_id of their victim (so the victim will know\nthe commitment has been re-used).\n\nThis has implications for 'multi-channel opens', in that any node\ninitiating an open MUST provide at least one utxo of their own. This seems\nlike an acceptable limitation, imo.\n\nThe protocol adjustments required for this are :\n\n- Add a second commitment to the TLV of `open_channel2`; two H2's, one for\nthe 'global J' and one for the 'nodes J', with the global point commitment\nalways appearing first.\n- The TLV type for the `tx_add_input` for the 'committed utxo' will now\ninclude an array of two `proof of dle's`, in commitment hash order.\n\n1. tlvs: `add_input_tlvs`\n2. types:\n    1. type: 1 (`proof_of_dle_array`)\n    2. data:\n        *[`2*proof_of_dle`]\n\n1. subtype (`proof_of_dle`)\n        *[`64*byte`:`s||e`]\n        *[`33*byte`:pubkey`]\n        *[`33*byte`:pubkey2`]\n\nA node that provides a valid global point but an invalid 'local point'\ncommitment should be immediately errored on and potentially blacklisted.\nA failure of this type should *not* result in a blacklist of the global\ncommitment.\n\n[1] There's probably a better analogy here, but it's escaping me at the\nmoment.\n[2] We reuse JoinMarket's NUMs point generation idea of appending a counter\nto a hash until a valid positive-public key point is found, but without the\nindex.\n\nOn Mon, Feb 10, 2020 at 5:11 PM lisa neigut \u003cniftynei at gmail.com\u003e wrote:\n\n\u003e Here's some thoughts I had on PoDLE's and lightning. An enormous\n\u003e tip-of-the-hat is due to ZmnSCPxj for surfacing the work that JoinMarket\n\u003e has done here already.\n\u003e\n\u003e - The initiating message (in the case of open channel, this would be\n\u003e `open_channel2`) is extended to include an 'H2' field in its TLV, a 32-byte\n\u003e hash commitment to the P2 key.\n\u003e - Only one H2 commitment is required.\n\u003e - The `tx_add_input` message, as specified previously, is extended to an\n\u003e include a TLV type. This must be present on the input addition that\n\u003e corresponds with the UTXO used for the originally transmitted commitment\n\u003e - The non-initiator SHOULD wait to send any `tx_add_input` messages of\n\u003e their own until after receiving a `tx_add_input` message with a valid PoDLE\n\u003e TLV extension.\n\u003e\n\u003e 1. tlvs: `add_input_tlvs`\n\u003e 2. types:\n\u003e     1. type: 1 (`proof_of_dle`)\n\u003e     2. data:\n\u003e         *[`64*byte`:`s||e`]\n\u003e         *[`33*byte`:pubkey`]\n\u003e         *[`33*byte`:pubkey2`]\n\u003e\n\u003e - If the proof is incorrect, the non-initiator MAY fail the transaction\n\u003e collaboration or respond with `tx_complete`. There is no need for them to\n\u003e publish the PoDLE.\n\u003e - If the proof is correct, the non-initiator verifies that the commitment\n\u003e (hash of pubkey2) has not been communicated to them via gossip.\n\u003e - If the proof is not in their gossip store, the transaction collaboration\n\u003e continues. It is considered 'safe' for the non-initiator to send\n\u003e `tx_add_input` to their peer.\n\u003e - If the proof IS in their gossip store, the transaction collaboration\n\u003e SHOULD reply with `tx_complete`. It is considered 'unsafe' for the\n\u003e non-initiator to send `tx_add_input`. (This allows errored/erroring\n\u003e initiators to use blacklisted utxos, however it prevents them from privy to\n\u003e any other nodes' UTXO set.)\n\u003e - The initiator MUST NOT remove the committed to UTXO from the\n\u003e collaboration set.\n\u003e\n\u003e - If the transaction collaboration fails/is errored by the initiator,\n\u003e     - the non-initiator SHOULD broadcast the original PoDLE commitment to\n\u003e the gossip network.\n\u003e     - the non-initiator MAY delay broadcast to allow the initiating node\n\u003e to re-attempt the open.\n\u003e\n\u003e The gossip message for a PoDLE blacklist entry is as follows:\n\u003e\n\u003e 1. type: 259 (`podle_blacklist`)\n\u003e 2. data:\n\u003e     *[`signature`:`signature`]\n\u003e     *[`32*byte`:`H2`]\n\u003e     *[`point`:`node_id`]\n\u003e     *[`u32`:`timestamp`]\n\u003e\n\u003e Note that the `node_id` is the id of the node that signs (and broadcasts)\n\u003e the blacklisted PoDLE. h/t to ZmnSCPxj for the gossip construction.\n\u003e The timestamp is added as a convenience for peers to trim/discard\n\u003e blacklist participants as they wish depending on time/staleness.\n\u003e\n\u003e ## Some Notes:\n\u003e - The JoinMarket protocol allows nodes to use any of a range of secondary\n\u003e points for J. Since the lightning version of this allows blacklisted UTXOs\n\u003e to still open channels, albeit without participation from the peer, it\n\u003e seems unnecessary to allow for more than one valid J point. I'd propose\n\u003e fixing the J the same zero-index point used by JoinMarket. This reduces the\n\u003e number of valid H2's that are available for any given utxo set, while also\n\u003e keeping blacklisted H2's compatible with the blacklist set generated by\n\u003e JoinMarket implementations.\n\u003e - The blacklist originates from the 'non-initiating' peer, and does not\n\u003e reveal the offending node's id.\n\u003e - Assuming that every node honestly participates in the blacklist, only\n\u003e verified H2's will be submitted to the blacklist\n\u003e - A malicious non-initiator can only prevent an honest initiator from\n\u003e using the committed UTXO for collaborative transactions; they won't prevent\n\u003e them from successfully initiating a one-sided transaction with honest peers.\n\u003e - Only nodes that have at least one public channel will be able to\n\u003e contribute to the public PoDLE blacklist. This means it's possible for a\n\u003e malicious initiator to grief non-public nodes without much consequence,\n\u003e however this requires the ability to send inbound messages to private\n\u003e nodes, i.e. more likely for a close or splice interaction.\n\u003e - As ZmnSCPxj has pointed out elsewhere, a malicious peer could broadcast\n\u003e junk H2's; it is acceptable to rate-limit the number of PoDLE blacklists\n\u003e generated by a peer.peer\n\u003e - It is possible for a malicious peer to fail to relay their `H2` entries\n\u003e in the blacklisted gossip set.\n\u003e - Duplicate H2 gossip should replace older timestamped versions.\n\u003e - Elsewhere we've had a discussion/concern over floods of PoDLE blacklist\n\u003e messages. It's possible for gossip message floods to originate from a\n\u003e malicious peer; they also might signal an ongoing probe attempt. Given a\n\u003e timestamp and a rough measure of the number of utxos' currently outstanding\n\u003e in the mempool, however, it should be possible to distinguish the two.\n\u003e\n\u003e ## Open Questions:\n\u003e - Should PoDLE be required for every collaborative transaction (opens,\n\u003e splices + closes), or only for opens? It seems reasonable to limit them\n\u003e just to opens, as for all others you'll already have a shared UTXO with the\n\u003e peer.\n\u003e - Is fixing the generator point too restrictive? JoinMarket allows for a\n\u003e range of acceptable NUMS (J) points (up to 256). The smaller the pool of\n\u003e eligible J's, the smaller the pool of potential blacklisted PoDLE's (up to\n\u003e no. NUMs * current utxo count). One upside to allowing a larger pool of J's\n\u003e means that the same UTXO can be retried on failure. One downside to\n\u003e allowing a pool of J's means that a single UTXO can be validly retried in a\n\u003e probe attack against a variety of peers.\n\u003e\n\u003e On Thu, Jan 30, 2020 at 5:32 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003e\n\u003e\u003e Good morning darosior, ariard, niftynei, and list,\n\u003e\u003e\n\u003e\u003e \u003e We could also consider PoDLE as used in JoinMarket, which solves a\n\u003e\u003e similar problem.\n\u003e\u003e \u003e\n\u003e\u003e https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-to-a-utxo-in-publicplaintext-at-the-start-of-the-handshake\n\u003e\u003e \u003e Basically, a PoDLE commits to a UTXO, without being trivially grindable\n\u003e\u003e from the UTXO set and also including a proof that the creator of the PoDLE\n\u003e\u003e knows the secret key behind it.\n\u003e\u003e \u003e It can later be opened to reveal which UTXO the opener allocated.\n\u003e\u003e \u003e If the opener aborts (i.e. does not provide its signatures to the\n\u003e\u003e funding transaction) then the acceptor can gossip the UTXO and the revealed\n\u003e\u003e PoDLE as well to the rest of Lightning, so that the opener at least cannot\n\u003e\u003e reuse the same UTXO to probe other potential acceptors.\n\u003e\u003e \u003e (though, my understanding, there is no clear way to determine when we\n\u003e\u003e can safely delete old PoDLEs: maybe each node can keep it around for a\n\u003e\u003e month, which might be good enough to limit the practical ability of a snoop\n\u003e\u003e to probe other nodes)\n\u003e\u003e \u003e I believe JoinMarket also has solved the issue of allowing a UTXO to be\n\u003e\u003e used at most N times (for example due to \"honest\" failures, such as\n\u003e\u003e connectivity interruptions which might cause an abort of the protocol); I\n\u003e\u003e think it involves appending a single byte to something that is hashed, and\n\u003e\u003e ensuring its value is less than N, so that it can only be used from 0 to N\n\u003e\u003e - 1 (and thus allow a UTXO to be used at most N times).\n\u003e\u003e \u003e\n\u003e\u003e \u003e Getting into contact with waxwing / Adam Gibson for this might be\n\u003e\u003e useful to fill out how PoDLE works and so on; basically, I believe this\n\u003e\u003e issue is a practically solved problem already for JoinMarket, though\n\u003e\u003e waxwing may be able to provide a more nuanced opinion.\n\u003e\u003e\n\u003e\u003e I communicated with waxwing, and he said:\n\u003e\u003e\n\u003e\u003e * See also: https://joinmarket.me/blog/blog/poodle \\[sic\\].\n\u003e\u003e * The counter I mentioned is implemented using the second generator point.\n\u003e\u003e   * The PoDLE construction requires the standard base point `G`, and\n\u003e\u003e another generator point `J`.\n\u003e\u003e   * To create the generator point `J`, JoinMarket appends the counter\n\u003e\u003e byte (the one used to limit N number of uses of the same UTXO) to `G`,\n\u003e\u003e hashes it, then uses a coerce-to-point.\n\u003e\u003e * PoDLE is sometimes called DLEQ elsewhere.\n\u003e\u003e * There is no concrete answer on \"when to delete old PoDLE\"; JoinMarket\n\u003e\u003e never deletes (though they might if throughput increases).\n\u003e\u003e * Watermarks like `nLockTime`, `nSequence`, `nVersion` are currently\n\u003e\u003e fixed values; JoinMarket sees no reason to change this since equal-valued\n\u003e\u003e CoinJoins are otherwise obvious to chain analysis anyway.\n\u003e\u003e   * But note: JoinMarket implements PayJoin, which is not otherwise\n\u003e\u003e obvious onchain, and does indeed do anti-fee-sniping emulation for PayJoin.\n\u003e\u003e   * JoinMarket also strives to make similar feerates across users.\n\u003e\u003e\n\u003e\u003e In any case, for myself, my thoughts are:\n\u003e\u003e\n\u003e\u003e * I observe that our use-case is quite similar to a PayJoin:\n\u003e\u003e   * The opener proposes to make a payment (to a channel between the\n\u003e\u003e opener and the acceptor, rather than outright giving control to the\n\u003e\u003e acceptor as in PayJoin).\n\u003e\u003e   * The acceptor adds some UTXOs which will contribute to the payment\n\u003e\u003e output (i.e. the channel).\n\u003e\u003e   * This probably does mean we want to later consider `nLockTime`\n\u003e\u003e anti-fee-sniping as well in multi-funded channel opens.\n\u003e\u003e * Speaking of multi-funded channel opens, it seems to me this interactive\n\u003e\u003e tx construction mechanism as well can be later used for channel factories.\n\u003e\u003e   * Similarly, PoDLE techniques would be useful as well to multi-funded\n\u003e\u003e channel factories.\n\u003e\u003e * It would probably be a good idea to share PoDLE format with JoinMarket\n\u003e\u003e so we can share PoDLE with them (there could be bridges that share PoDLE\n\u003e\u003e between a JoinMarket maker and a Lightning node, and each network already\n\u003e\u003e has its own gossip protocols, so LN just needs a gossip protocol for\n\u003e\u003e sharing PoDLEs as well).\n\u003e\u003e * Probably we can mandate in some BOLT spec to retain PoDLE for at least\n\u003e\u003e a year or a month or two weeks or so, which should be enough to slow down\n\u003e\u003e probe attempts.\n\u003e\u003e\n\u003e\u003e Regards,\n\u003e\u003e ZmnSCPxj\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200210/f584936f/attachment-0001.html\u003e"}