Hi ZmnSCPxj, Using joinmarket's PoDLEs is a great idea, and it seems preferable to using a transaction chain with a distinguishable SIGHASH.
Just a naive question, what is described in https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-to-a-utxo-in-publicplaintext-at-the-start-of-the-handshake and https://joinmarket.me/blog/blog/poodle/ uses Schnorr signature. Can we use this protocol with ECDSA ? I'm now thinking about how this could be integrated into niftynei's work on the dual-funded channel proposal. The PoDLE broadcast protocol seems to be the bigger part. *Imagining the size of the monster PR if PoDLEs ever get integrated* Regards, Darosior ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Le vendredi, janvier 31, 2020 12:31 AM, ZmnSCPxj <zmnsc...@protonmail.com> a écrit : > 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
