lisa neigut [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-11 📝 Original message: > s = k + H(kG || kJ || P ...
📅 Original date posted:2020-02-11
📝 Original message:
> 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? Though, now
that I think about it, it does seem imperative to verify that the pubkey
provided is in fact locked to by the utxo script, which we can do since the
script will have been provided in the `tx_add_input` message.
Seems worth nothing that, given such a proof, you can grind to find out who
the intended node was. However, if the failure is indeed because of the
"venus flytrap" attack I mentioned above, it'd pretty obviously be the node
sending you the invalid signature (or a node that they spoofed/MITM'd),
which isn't much of a leak. Actually, this 'grindability' might be quite
useful for finding the originator of the attack, if needed. There's no
reason for you to leak a PoDLE signature, but if you do you're
potentially tying an H2 commitment offer to your node id. Seems very nice
indeed!
One of the stated goals of implementing PoDLEs was to be "compatible with
JoinMarket", but I believe this compatibility goal only extends as far as
the H2 construction (and not the proof), so we're ok there with this tweak.
Cheers!
niftynei
On Tue, Feb 11, 2020 at 10:05 AM AdamISZ via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> 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 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.
>
> Thanks,
> Adam Gibson/waxwing/AdamISZ
>
> Sent with ProtonMail Secure Email.
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200211/d140fadd/attachment-0001.html>;
📝 Original message:
> 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? Though, now
that I think about it, it does seem imperative to verify that the pubkey
provided is in fact locked to by the utxo script, which we can do since the
script will have been provided in the `tx_add_input` message.
Seems worth nothing that, given such a proof, you can grind to find out who
the intended node was. However, if the failure is indeed because of the
"venus flytrap" attack I mentioned above, it'd pretty obviously be the node
sending you the invalid signature (or a node that they spoofed/MITM'd),
which isn't much of a leak. Actually, this 'grindability' might be quite
useful for finding the originator of the attack, if needed. There's no
reason for you to leak a PoDLE signature, but if you do you're
potentially tying an H2 commitment offer to your node id. Seems very nice
indeed!
One of the stated goals of implementing PoDLEs was to be "compatible with
JoinMarket", but I believe this compatibility goal only extends as far as
the H2 construction (and not the proof), so we're ok there with this tweak.
Cheers!
niftynei
On Tue, Feb 11, 2020 at 10:05 AM AdamISZ via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> 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 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.
>
> Thanks,
> Adam Gibson/waxwing/AdamISZ
>
> Sent with ProtonMail Secure Email.
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200211/d140fadd/attachment-0001.html>;