{"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-11\n📝 Original message:\n\u003e s = k + H(kG || kJ || P || P2 || utxo || receiving-node) x\n\n\u003e and as before transfer opening: (P, P2, u, s, e) with receiving-node\nimplicitly reconstructed to do the verification of the Schnorr sig. It's\nbasically a message in a signature.\n\nOh that's *much* nicer than calculating a second commitment. Verification\nby any node that's not the intended recipient will fail, as they'll use the\nwrong node_id (their own).\n\nIt seems unnecessary to me to commit to the utxo, since the pubkey pair\neffectively does that. What's the motivation for including it? Though, now\nthat I think about it, it does seem imperative to verify that the pubkey\nprovided is in fact locked to by the utxo script, which we can do since the\nscript will have been provided in the `tx_add_input` message.\n\nSeems worth nothing that, given such a proof, you can grind to find out who\nthe intended node was. However, if the failure is indeed because of the\n\"venus flytrap\" attack I mentioned above, it'd pretty obviously be the node\nsending you the invalid signature (or a node that they spoofed/MITM'd),\nwhich isn't much of a leak.  Actually, this 'grindability' might be quite\nuseful for finding the originator of the attack, if needed. There's no\nreason for you to leak a PoDLE signature, but if you do you're\npotentially tying an H2 commitment offer to your node id. Seems very nice\nindeed!\n\nOne of the stated goals of implementing PoDLEs was to be \"compatible with\nJoinMarket\", but I believe this compatibility goal only extends as far as\nthe H2 construction (and not the proof), so we're ok there with this tweak.\n\nCheers!\nniftynei\n\nOn Tue, Feb 11, 2020 at 10:05 AM AdamISZ via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e niftynei, ZmnSCPxj and list:\n\u003e\n\u003e\n\u003e Zmn** pinged me about this discussion and I thought I could add something\n\u003e directly:\n\u003e\n\u003e\n\u003e First, re:\n\u003e \u003e I'd like to propose that we add a second commitment requirement to the\n\u003e PoDLE that JoinMarket uses, to limit the use of a commitment's validity to\n\u003e be only between an initiator and a single peer. Otherwise you can enable\n\u003e something I'll call the \"pouncing venus-flytrap attack\"[1].\n\u003e\n\u003e Here's some thoughts that may give context to this (excellent) observation:\n\u003e\n\u003e This issue didn't crop up (well, kinda! I do remember discussion about it)\n\u003e in our use case because takers always send out to 5-12 (typically) makers\n\u003e at once, and the HP2 only needs to get broadcast by one to stop any reuse.\n\u003e But whichever way you look at it, it's a very good point! And in LN case,\n\u003e seems like a very substantial attack (certainly no question it could be\n\u003e allowed for 2 party protocol).\n\u003e\n\u003e In case a brief summary of JM mechanism is helpful, I added some info on\n\u003e the the taker-maker conversation at the end of this mail [1].\n\u003e\n\u003e Second, re:\n\u003e \u003e ## Mitigation\n\u003e \u003e Have each initiator provide two commitments: one to the shared/global J\n\u003e \u003e point and one to a point that is found from the hash of the\n\u003e non-initiating\n\u003e \u003e node's node_id.[2]\n\u003e\n\u003e I get the thinking here, and it makes a lot of sense, but I do think it\n\u003e can be done more compactly.\n\u003e If the commitment is H(P2), the opening of the commitment could be altered\n\u003e to include the receiving node:\n\u003e\n\u003e s = k + H(kG || kJ || P || P2 || utxo || receiving-node) x\n\u003e\n\u003e and as before transfer opening: (P, P2, u, s, e) with receiving-node\n\u003e implicitly reconstructed to do the verification of the Schnorr sig. It's\n\u003e basically a message in a signature.\n\u003e\n\u003e As you note, we wouldn't want to ban usage of a H(P2) value based on an\n\u003e incorrect opening; we just use that failure to decide to not hand over our\n\u003e utxo information (as receiver of the commitment). But unless I missed\n\u003e something, doing it the above way is the more logical/compact choice.\n\u003e\n\u003e Seems like there's a lot of fine nuance here. A malicious counterparty can\n\u003e always choose to blacklist. In Joinmarket we accept (because of our\n\u003e stringent no-identity policy) some roughness and assume some meaningful\n\u003e level of honest participation. A Taker issuing a request to 10 cps hopes\n\u003e that at least some number (min 4 by default) will actually respond to an\n\u003e honest request; if say 8 of 10 do so, he will do the coinjoin with those.\n\u003e That it is brittle or flaky is why we allow 3 tries for each qualifying\n\u003e utxo (qualified on age, size), and also allow custom insertion of\n\u003e additional utxos (although it's rarely if ever needed). It works fine in\n\u003e practice, for now, but it is not watertight; if you have overwhelmingly\n\u003e malicious counterparties you are kinda screwed from other angles, as well\n\u003e as this one. Meanwhile on the Maker side we're trying to create a kind of\n\u003e 'herd immunity'; as long as some few of them are honest, word will get out\n\u003e about used commitments which will stop free spam queries,\n\u003e   at least (but it's not a super strong defence!).\n\u003e\n\u003e\n\u003e [1] Taker-Maker convo (excerpt); some notes re: commitments/PoDLE.\n\u003e ===\n\u003e !fill amount, oid, commitment (HP2)\n\u003e -- this is where a taker sends to each maker an hp2 value. This is the\n\u003e step intended to enforce scarcity, and the assumption in JM was always that\n\u003e this would basically inevitably get shared. Because there are typically\n\u003e 5-12 makers involved, this seemed a reasonably safe assumption.\n\u003e If the commitment value is already used and thus not valid, it gets\n\u003e broadcast immediately. If it's not, it only gets shared as part of the\n\u003e !ioauth step below.\n\u003e\n\u003e !pubkey key\n\u003e\n\u003e -- this is just the maker giving an ephemeral key for the encryption\n\u003e\n\u003e !auth (s, e, u, P, P2)\n\u003e -- (encrypted) this is the taker opening the above commitment. It's rather\n\u003e weird at first sight, because he is opening immediately after committing,\n\u003e with apparently no step inbetween; but in fact the implicit intermediate\n\u003e step is the broadcast (exactly what is being questioned with 'venus\n\u003e flytrap').\n\u003e\n\u003e !ioauth maker-utxo-data\n\u003e -- notice the maker is only sending this utxo data (encrypted of course)\n\u003e after proof of ownership of the utxo above.\n\u003e It's only at this step that the hp2 commitment value is (a) added to the\n\u003e maker's local \"used up\" list, and (b)privmsged to 1  randomly chosen other\n\u003e bots in the trading pit, who then pubmsgs it to everyone (and that happens\n\u003e multiple times because multiple makers in tx), and they in turn record it\n\u003e as \"used\".\n\u003e\n\u003e The mechanism is both not very strong - we use 3 allowed attempts per utxo\n\u003e - and imperfect in its \"justice\"; such commitments can be \"used up\" by\n\u003e failures of one's counterparties. But it does serve to stop trivial global\n\u003e snooping, and doesn't cost anything in terms of identity or locked funds,\n\u003e so it has served a purpose (we did actually see such attacks before it, and\n\u003e not after it).\n\u003e\n\u003e I'd also note that in terms of the venus flytrap attack mentioned, there\n\u003e could be a small time window between one maker receiving !auth and at least\n\u003e one other honest maker getting to broadcast step at !ioauth; while I don't\n\u003e think that's very practical in our use case, it is for sure a theoretical\n\u003e concern and removing it could be either slightly, or extremely, important\n\u003e in another use case.\n\u003e\n\u003e Thanks,\n\u003e Adam Gibson/waxwing/AdamISZ\n\u003e\n\u003e Sent with ProtonMail Secure Email.\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200211/d140fadd/attachment-0001.html\u003e"}