{"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:\nHere's some thoughts I had on PoDLE's and lightning. An enormous\ntip-of-the-hat is due to ZmnSCPxj for surfacing the work that JoinMarket\nhas done here already.\n\n- The initiating message (in the case of open channel, this would be\n`open_channel2`) is extended to include an 'H2' field in its TLV, a 32-byte\nhash commitment to the P2 key.\n- Only one H2 commitment is required.\n- The `tx_add_input` message, as specified previously, is extended to an\ninclude a TLV type. This must be present on the input addition that\ncorresponds with the UTXO used for the originally transmitted commitment\n- The non-initiator SHOULD wait to send any `tx_add_input` messages of\ntheir own until after receiving a `tx_add_input` message with a valid PoDLE\nTLV extension.\n\n1. tlvs: `add_input_tlvs`\n2. types:\n    1. type: 1 (`proof_of_dle`)\n    2. data:\n        *[`64*byte`:`s||e`]\n        *[`33*byte`:pubkey`]\n        *[`33*byte`:pubkey2`]\n\n- If the proof is incorrect, the non-initiator MAY fail the transaction\ncollaboration or respond with `tx_complete`. There is no need for them to\npublish the PoDLE.\n- If the proof is correct, the non-initiator verifies that the commitment\n(hash of pubkey2) has not been communicated to them via gossip.\n- If the proof is not in their gossip store, the transaction collaboration\ncontinues. It is considered 'safe' for the non-initiator to send\n`tx_add_input` to their peer.\n- If the proof IS in their gossip store, the transaction collaboration\nSHOULD reply with `tx_complete`. It is considered 'unsafe' for the\nnon-initiator to send `tx_add_input`. (This allows errored/erroring\ninitiators to use blacklisted utxos, however it prevents them from privy to\nany other nodes' UTXO set.)\n- The initiator MUST NOT remove the committed to UTXO from the\ncollaboration set.\n\n- If the transaction collaboration fails/is errored by the initiator,\n    - the non-initiator SHOULD broadcast the original PoDLE commitment to\nthe gossip network.\n    - the non-initiator MAY delay broadcast to allow the initiating node to\nre-attempt the open.\n\nThe gossip message for a PoDLE blacklist entry is as follows:\n\n1. type: 259 (`podle_blacklist`)\n2. data:\n    *[`signature`:`signature`]\n    *[`32*byte`:`H2`]\n    *[`point`:`node_id`]\n    *[`u32`:`timestamp`]\n\nNote that the `node_id` is the id of the node that signs (and broadcasts)\nthe blacklisted PoDLE. h/t to ZmnSCPxj for the gossip construction.\nThe timestamp is added as a convenience for peers to trim/discard blacklist\nparticipants as they wish depending on time/staleness.\n\n## Some Notes:\n- The JoinMarket protocol allows nodes to use any of a range of secondary\npoints for J. Since the lightning version of this allows blacklisted UTXOs\nto still open channels, albeit without participation from the peer, it\nseems unnecessary to allow for more than one valid J point. I'd propose\nfixing the J the same zero-index point used by JoinMarket. This reduces the\nnumber of valid H2's that are available for any given utxo set, while also\nkeeping blacklisted H2's compatible with the blacklist set generated by\nJoinMarket implementations.\n- The blacklist originates from the 'non-initiating' peer, and does not\nreveal the offending node's id.\n- Assuming that every node honestly participates in the blacklist, only\nverified H2's will be submitted to the blacklist\n- A malicious non-initiator can only prevent an honest initiator from using\nthe committed UTXO for collaborative transactions; they won't prevent them\nfrom successfully initiating a one-sided transaction with honest peers.\n- Only nodes that have at least one public channel will be able to\ncontribute to the public PoDLE blacklist. This means it's possible for a\nmalicious initiator to grief non-public nodes without much consequence,\nhowever this requires the ability to send inbound messages to private\nnodes, i.e. more likely for a close or splice interaction.\n- As ZmnSCPxj has pointed out elsewhere, a malicious peer could broadcast\njunk H2's; it is acceptable to rate-limit the number of PoDLE blacklists\ngenerated by a peer.peer\n- It is possible for a malicious peer to fail to relay their `H2` entries\nin the blacklisted gossip set.\n- Duplicate H2 gossip should replace older timestamped versions.\n- Elsewhere we've had a discussion/concern over floods of PoDLE blacklist\nmessages. It's possible for gossip message floods to originate from a\nmalicious peer; they also might signal an ongoing probe attempt. Given a\ntimestamp and a rough measure of the number of utxos' currently outstanding\nin the mempool, however, it should be possible to distinguish the two.\n\n## Open Questions:\n- Should PoDLE be required for every collaborative transaction (opens,\nsplices + closes), or only for opens? It seems reasonable to limit them\njust to opens, as for all others you'll already have a shared UTXO with the\npeer.\n- Is fixing the generator point too restrictive? JoinMarket allows for a\nrange of acceptable NUMS (J) points (up to 256). The smaller the pool of\neligible J's, the smaller the pool of potential blacklisted PoDLE's (up to\nno. NUMs * current utxo count). One upside to allowing a larger pool of J's\nmeans that the same UTXO can be retried on failure. One downside to\nallowing a pool of J's means that a single UTXO can be validly retried in a\nprobe attack against a variety of peers.\n\nOn Thu, Jan 30, 2020 at 5:32 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning darosior, ariard, niftynei, and list,\n\u003e\n\u003e \u003e We could also consider PoDLE as used in JoinMarket, which solves a\n\u003e similar problem.\n\u003e \u003e\n\u003e https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-to-a-utxo-in-publicplaintext-at-the-start-of-the-handshake\n\u003e \u003e Basically, a PoDLE commits to a UTXO, without being trivially grindable\n\u003e from the UTXO set and also including a proof that the creator of the PoDLE\n\u003e knows the secret key behind it.\n\u003e \u003e It can later be opened to reveal which UTXO the opener allocated.\n\u003e \u003e If the opener aborts (i.e. does not provide its signatures to the\n\u003e funding transaction) then the acceptor can gossip the UTXO and the revealed\n\u003e PoDLE as well to the rest of Lightning, so that the opener at least cannot\n\u003e reuse the same UTXO to probe other potential acceptors.\n\u003e \u003e (though, my understanding, there is no clear way to determine when we\n\u003e can safely delete old PoDLEs: maybe each node can keep it around for a\n\u003e month, which might be good enough to limit the practical ability of a snoop\n\u003e to probe other nodes)\n\u003e \u003e I believe JoinMarket also has solved the issue of allowing a UTXO to be\n\u003e used at most N times (for example due to \"honest\" failures, such as\n\u003e connectivity interruptions which might cause an abort of the protocol); I\n\u003e think it involves appending a single byte to something that is hashed, and\n\u003e ensuring its value is less than N, so that it can only be used from 0 to N\n\u003e - 1 (and thus allow a UTXO to be used at most N times).\n\u003e \u003e\n\u003e \u003e Getting into contact with waxwing / Adam Gibson for this might be useful\n\u003e to fill out how PoDLE works and so on; basically, I believe this issue is a\n\u003e practically solved problem already for JoinMarket, though waxwing may be\n\u003e able to provide a more nuanced opinion.\n\u003e\n\u003e I communicated with waxwing, and he said:\n\u003e\n\u003e * See also: https://joinmarket.me/blog/blog/poodle \\[sic\\].\n\u003e * The counter I mentioned is implemented using the second generator point.\n\u003e   * The PoDLE construction requires the standard base point `G`, and\n\u003e another generator point `J`.\n\u003e   * To create the generator point `J`, JoinMarket appends the counter byte\n\u003e (the one used to limit N number of uses of the same UTXO) to `G`, hashes\n\u003e it, then uses a coerce-to-point.\n\u003e * PoDLE is sometimes called DLEQ elsewhere.\n\u003e * There is no concrete answer on \"when to delete old PoDLE\"; JoinMarket\n\u003e never deletes (though they might if throughput increases).\n\u003e * Watermarks like `nLockTime`, `nSequence`, `nVersion` are currently fixed\n\u003e values; JoinMarket sees no reason to change this since equal-valued\n\u003e CoinJoins are otherwise obvious to chain analysis anyway.\n\u003e   * But note: JoinMarket implements PayJoin, which is not otherwise\n\u003e obvious onchain, and does indeed do anti-fee-sniping emulation for PayJoin.\n\u003e   * JoinMarket also strives to make similar feerates across users.\n\u003e\n\u003e In any case, for myself, my thoughts are:\n\u003e\n\u003e * I observe that our use-case is quite similar to a PayJoin:\n\u003e   * The opener proposes to make a payment (to a channel between the opener\n\u003e and the acceptor, rather than outright giving control to the acceptor as in\n\u003e PayJoin).\n\u003e   * The acceptor adds some UTXOs which will contribute to the payment\n\u003e output (i.e. the channel).\n\u003e   * This probably does mean we want to later consider `nLockTime`\n\u003e anti-fee-sniping as well in multi-funded channel opens.\n\u003e * Speaking of multi-funded channel opens, it seems to me this interactive\n\u003e tx construction mechanism as well can be later used for channel factories.\n\u003e   * Similarly, PoDLE techniques would be useful as well to multi-funded\n\u003e channel factories.\n\u003e * It would probably be a good idea to share PoDLE format with JoinMarket\n\u003e so we can share PoDLE with them (there could be bridges that share PoDLE\n\u003e between a JoinMarket maker and a Lightning node, and each network already\n\u003e has its own gossip protocols, so LN just needs a gossip protocol for\n\u003e sharing PoDLEs as well).\n\u003e * Probably we can mandate in some BOLT spec to retain PoDLE for at least a\n\u003e year or a month or two weeks or so, which should be enough to slow down\n\u003e probe attempts.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200210/047f7af7/attachment.html\u003e"}