darosior [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-11 📝 Original message: Hi niftynei and list, ...

📅 Original date posted:2020-02-11
📝 Original message:
Hi niftynei and list,

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le mardi, février 11, 2020 12:11 AM, lisa neigut <niftynei at gmail.com> a écrit :

> 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.)

We could agree on an acceptable number of reuse in case on a non-malicious failure from the initiator after a valid PoDLE exchange ? (credits ZmnSCPxj)

> - 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.

Ok, so knowing where PoDLE originate from mitigates the flood we talked about with ZmnSCPxj.
However I don't see how the number of utxos in the mempool is useful here, as you cannot distinguish which PoDLE is the real one out of the load you are receiving in case of a flood ?

> ## 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/20200211/32163fb0/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 477 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200211/32163fb0/attachment-0001.sig>;