lisa neigut [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-10 📝 Original message: I'd like to propose that ...

📅 Original date posted:2020-02-10
📝 Original message:
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]. Venus-flytrap
because they sit in wait for victims; pouncing because the venus-flytrap
then attacks other nodes using the provided fly/utxo bait.

## The Attack
A malicious node sits and waits until another, honest, node initiates an
open with them. They wait until the honest initiator has sent them the
commitment and utxo proof. They then use the provided, non-blacklisted utxo
and commitment proof to attempt to open a channel with as many other nodes
as possible, simultaneously. They may either fail to respond or not fail
the original channel open. They fail every other open attempt,
simultaneously. Each of the nodes they've griefed will blacklist the
provided UTXO; the honest initiator has now had their utxo blacklisted.

## 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]

The global-point commitment is the one that is blacklisted; the node_id's
commitment prevents the other party from being able to re-use a commitment
in another channel, as they'll be unable to produce a valid commitment to
the point derived from the node_id of their victim (so the victim will know
the commitment has been re-used).

This has implications for 'multi-channel opens', in that any node
initiating an open MUST provide at least one utxo of their own. This seems
like an acceptable limitation, imo.

The protocol adjustments required for this are :

- Add a second commitment to the TLV of `open_channel2`; two H2's, one for
the 'global J' and one for the 'nodes J', with the global point commitment
always appearing first.
- The TLV type for the `tx_add_input` for the 'committed utxo' will now
include an array of two `proof of dle's`, in commitment hash order.

1. tlvs: `add_input_tlvs`
2. types:
1. type: 1 (`proof_of_dle_array`)
2. data:
*[`2*proof_of_dle`]

1. subtype (`proof_of_dle`)
*[`64*byte`:`s||e`]
*[`33*byte`:pubkey`]
*[`33*byte`:pubkey2`]

A node that provides a valid global point but an invalid 'local point'
commitment should be immediately errored on and potentially blacklisted.
A failure of this type should *not* result in a blacklist of the global
commitment.

[1] There's probably a better analogy here, but it's escaping me at the
moment.
[2] We reuse JoinMarket's NUMs point generation idea of appending a counter
to a hash until a valid positive-public key point is found, but without the
index.

On Mon, Feb 10, 2020 at 5:11 PM lisa neigut <niftynei at gmail.com> wrote:

> 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.)
> - 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' currently outstanding
> in the mempool, however, it should be possible to distinguish the two.
>
> ## Open Questions:
> - Should PoDLE be required for every collaborative transaction (opens,
> splices + closes), or only for opens? It seems reasonable to limit them
> just to opens, as for all others you'll already have a shared UTXO with the
> peer.
> - Is fixing the generator point too restrictive? JoinMarket allows for a
> range of acceptable NUMS (J) points (up to 256). The smaller the pool of
> eligible J's, the smaller the pool of potential blacklisted PoDLE's (up to
> no. NUMs * current utxo count). One upside to allowing a larger pool of J's
> means that the same UTXO can be retried on failure. One downside to
> allowing a pool of J's means that a single UTXO can be validly retried in a
> probe attack against a variety of peers.
>
> On Thu, Jan 30, 2020 at 5:32 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning darosior, ariard, niftynei, and list,
>>
>> > We could also consider PoDLE as used in JoinMarket, which solves a
>> similar problem.
>> >
>> https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-to-a-utxo-in-publicplaintext-at-the-start-of-the-handshake
>> > Basically, a PoDLE commits to a UTXO, without being trivially grindable
>> from the UTXO set and also including a proof that the creator of the PoDLE
>> knows the secret key behind it.
>> > It can later be opened to reveal which UTXO the opener allocated.
>> > If the opener aborts (i.e. does not provide its signatures to the
>> funding transaction) then the acceptor can gossip the UTXO and the revealed
>> PoDLE as well to the rest of Lightning, so that the opener at least cannot
>> reuse the same UTXO to probe other potential acceptors.
>> > (though, my understanding, there is no clear way to determine when we
>> can safely delete old PoDLEs: maybe each node can keep it around for a
>> month, which might be good enough to limit the practical ability of a snoop
>> to probe other nodes)
>> > I believe JoinMarket also has solved the issue of allowing a UTXO to be
>> used at most N times (for example due to "honest" failures, such as
>> connectivity interruptions which might cause an abort of the protocol); I
>> think it involves appending a single byte to something that is hashed, and
>> ensuring its value is less than N, so that it can only be used from 0 to N
>> - 1 (and thus allow a UTXO to be used at most N times).
>> >
>> > Getting into contact with waxwing / Adam Gibson for this might be
>> useful to fill out how PoDLE works and so on; basically, I believe this
>> issue is a practically solved problem already for JoinMarket, though
>> waxwing may be able to provide a more nuanced opinion.
>>
>> I communicated with waxwing, and he said:
>>
>> * See also: https://joinmarket.me/blog/blog/poodle \[sic\].
>> * The counter I mentioned is implemented using the second generator point.
>> * The PoDLE construction requires the standard base point `G`, and
>> another generator point `J`.
>> * To create the generator point `J`, JoinMarket appends the counter
>> byte (the one used to limit N number of uses of the same UTXO) to `G`,
>> hashes it, then uses a coerce-to-point.
>> * PoDLE is sometimes called DLEQ elsewhere.
>> * There is no concrete answer on "when to delete old PoDLE"; JoinMarket
>> never deletes (though they might if throughput increases).
>> * Watermarks like `nLockTime`, `nSequence`, `nVersion` are currently
>> fixed values; JoinMarket sees no reason to change this since equal-valued
>> CoinJoins are otherwise obvious to chain analysis anyway.
>> * But note: JoinMarket implements PayJoin, which is not otherwise
>> obvious onchain, and does indeed do anti-fee-sniping emulation for PayJoin.
>> * JoinMarket also strives to make similar feerates across users.
>>
>> In any case, for myself, my thoughts are:
>>
>> * I observe that our use-case is quite similar to a PayJoin:
>> * The opener proposes to make a payment (to a channel between the
>> opener and the acceptor, rather than outright giving control to the
>> acceptor as in PayJoin).
>> * The acceptor adds some UTXOs which will contribute to the payment
>> output (i.e. the channel).
>> * This probably does mean we want to later consider `nLockTime`
>> anti-fee-sniping as well in multi-funded channel opens.
>> * Speaking of multi-funded channel opens, it seems to me this interactive
>> tx construction mechanism as well can be later used for channel factories.
>> * Similarly, PoDLE techniques would be useful as well to multi-funded
>> channel factories.
>> * It would probably be a good idea to share PoDLE format with JoinMarket
>> so we can share PoDLE with them (there could be bridges that share PoDLE
>> between a JoinMarket maker and a Lightning node, and each network already
>> has its own gossip protocols, so LN just needs a gossip protocol for
>> sharing PoDLEs as well).
>> * Probably we can mandate in some BOLT spec to retain PoDLE for at least
>> a year or a month or two weeks or so, which should be enough to slow down
>> probe attempts.
>>
>> Regards,
>> ZmnSCPxj
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200210/f584936f/attachment-0001.html>;