darosior [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-31 📝 Original message: Hi ZmnSCPxj, Using ...
📅 Original date posted:2020-01-31
📝 Original message:
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 <ZmnSCPxj at 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
>
-------------- 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/20200131/4b9c0503/attachment.sig>;
📝 Original message:
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 <ZmnSCPxj at 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
>
-------------- 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/20200131/4b9c0503/attachment.sig>;