Lloyd Fournier [ARCHIVE] on Nostr: đź“… Original date posted:2021-01-04 đź“ť Original message: Happy New Year Lightning ...
đź“… Original date posted:2021-01-04
đź“ť Original message:
Happy New Year Lightning Developers,
I've recently been closely looking at the dual funding proposal [1] because
it uses a DLEQ proof (PoDLE) which we are also working on specifying as
part of DLC ECDSA adaptor signatures [2].
While reading it I had some queries and ideas that I thought were worth
sharing (even though they are very very late).
# Background
Lisa posted a draft proposal [1] which includes the PoDLE and explained it
in [3] along with a good list of its weaknesses.
The original discussion thread where the idea was conceived is [4] and
there is an excellent summary in the following optech [5] which I post
below:
> Another proposal was to use PoDLE, which was originally developed for
JoinMarket based on a suggestion by Gregory Maxwell. This protocol allows
an initiating user such as Mallory to commit to a UTXO in a way that
prevents anyone from identifying that UTXO. The participating user, such as
Bob, publishes the commitment across the network (e.g. the JoinMarket
network) so that nobody else will start a session with Mallory while she’s
using that particular UTXO. Then Bob asks Mallory to identify her UTXO and,
if it’s a valid UTXO that matches her commitment, Bob discloses his UTXO to
Mallory so that they can proceed with the protocol (e.g. a coinjoin). If
Mallory aborts the protocol before completion, the commitment previously
published across the network prevents her from being able to start a new
session with any other user and so learn their UTXO. Mallory’s only option
is to spend her coins from herself to herself in order to generate a new
UTXO—a process that costs her money and so limits her ability to spy on
users. (Note, though, that PoDLE as implemented in JoinMarket allows
Mallory up to three retries by default so honest users aren’t penalized for
occasional accidental failures, such as a loss of network connectivity.)
The idea is to adapt this protocol for LN in order to prevent attackers
from learning which available UTXOs are controlled by LN users.
Especially relevant to this post is the idea posted by Darosior here [6]
which was summarized as follows:
> One proposal to fix this would require the person proposing to open the
channel (e.g. Mallory) to provide their UTXO(s) in a ready-to-spend state
so that probing would cost money (e.g. transaction fees). A downside of
this approach is that the construction proposed would be easily
identifiable by block chain analysis, making it easy to determine when a
dual-funded channel was opened
The goals of this post is to (i) see if I understand the PoDLE idea
correctly, to (ii) refine Darosior's idea and to (iii) propose a minimal
alternative idea.
# Requirements
Informally, here are the desirable properties I came up with for a dual
funding protocol:
1. If a malicious initiator learns a peer UTXO, then the initiator should
have to spend their UTXOs before reusing them against the next peer (should
be forced to spend them to repeat attack -- *if attacking sequentially*).
2. A malicious initiator should not be able to use the same UTXOs in
parallel with multiple peers (to learn the UTXOs of multiple makers with a
single UTXO).
3. An honest initiator should not have to spend their UTXOs if they execute
with a malicious peer.
4. dual-funded opening transactions should not have any distinguishing
features (i.e. sighash flags).
5. An honest but intermittently failing initiator should not have their
UTXO details sent by an honest peer to other parties.
Note I am going to ignore property (2) because of proposals below can turn
their protection against sequential attacks (1) into protection against
parallel attacks (2) by having the peer choose a random time delay and see
if anything is gossiped to them that would indicate malicious behavior by
the initiator in some other channel.
# PoDLEs
To solve this problem in JoinMarket, Waxwing had the idea [8] of turning
knowledge of a secret key for a particular UTXO into a kind of unlinkable
credential.
Given a UTXO public key P1, the initiator projects their private key onto a
different generator J to produce P2.
P2 is unlinkable to P1 (without a proof) but is fully determined by P1.
This allows participants to maintain a blacklist of P2s without learning
the P1s.
Having the P1s in the blacklist would make the blacklist itself useful for
chain analysis because it contains a list of UTXOs that tried to open
channels (but perhaps accidentally failed).
The idea is like this:
1. Taker asks some maker's if they want to do a coinjoin and sends them all
SHA256(P2)
2. When they find the maker they want to proceed with they reveal P2 and
prove DLEQ((P1, G), (P2, J)) i.e. P1 and P2 have the same private key just
different base points.
3. If they haven't received SHA256(P2)from the gossip network (i.e. it's
not in the blacklist), the maker then sends their own UTXO data AND gossips
SHA256(P2)
4. They carry on the protocol.
The current lightning proposal [1] follows the same logic except that it
only gossips SHA256(P2) in case of malicious behavior (this seems sensible).
If I understood it correctly, then it achieves properties (1,4,5).
The main downside is that it introduces a new gossip message. The
difficulties associated with this are listed in [3].
Notably it is missing property (3) - protection against malicious peers who
gossip SHA256(P2) even when there was no wrongdoing.
A question I have is why is SHA256(P2) sent up front? I think that P2 can
just be sent along with the proof later on in the case of dual funding.
Waxwing gave an explanation of it in the case of joinmarket in [7] but I
didn't grasp it.
# Darosior's SIGHASH_SINGLE|SIGHASH_ANYONECANPAY
The proposal from Darosior [6] is to have the taker provide their inputs in
a ready to broadcast state using SIGHASH_SIGNLE|SIGHASH_ANYONECANPAY.
This way the peer never needs to send their inputs directly to the
initiator (the initiator will only find out about them when the transaction
is broadcast).
I encourage the reader to look at [6] which has nice diagrams and is very
short and to the point.
This achieves all properties except for (4 - distinguishable on-chain)
which is why it was dismissed.
I think it is possible to extend the idea to achieve (4) and therefore
obtain all desired properties.
Simply put peers can just use the SINGLE|ANYONECANPAY signature as back ups
in case of abort. Here's how it could work in my mind:
1. Initiator requests dual-funding and provides a TX_temp spending their
input set to a main output and a change output (does not sign it yet). They
also provide a sighash SIGNLE|ANYONECANPAY signature on the main output
spending into TX_backup-fund and a signature on the first commitment
transaction spending from TX_backup-fund (exactly as in [6]).
2. Peer responds with commitment TX signature for TX_backup-fund.
3. Initiator responds with the signatures for TX_temp.
*Peer now has a fully functional transaction chain with which to open the
channel -- now they can attempt to upgrade to a SIGHASH_ALL opening*.
4. Peer (if possible) checks there are no existing transactions in the
chain or mempool spending from the taker's inputs. If not it responds with
its inputs, change and commitment tx signature for a SIGHASH_ALL TX_fund.
5. Initiator responds with commitment TX signature and TX_fund input
signatures.
6. Peer broadcasts TX_fund.
*If at any point after step 3 Initiator does not respond for ~2 seconds
they broadcast TX_temp and TX_backup-funding*
We have (4) because the SINGLE|ANYONECANPAY signature only appears on-chain
in case of abort (i.e. TX_backup-funding makes it on-chain).
It appears to be pretty close to the ideal solution in terms of privacy and
security.
If the malicious initiator learns an output they will always have to spend
one of their inputs otherwise they will quickly get hit by the TX_temp +
TX_backup-funding.
Note that it is possible the node is just slow in which case even if step
TX_backup-funding makes it in both parties should just carry on with the
channel.
The downsides are that it involves six rounds of communication and cannot
use the "interactive tx building" protocol developed for the original
proposal
# Signaling Transactions
Finally I present a simple but unintuitive protocol that achieves roughly
the same properties as the PoDLE protocol but without lightning gossip
messages.
Whenever the initiator adds an input in the interactive tx building they
provide signatures on a "signaling" transaction spending that input (and
any inputs they have added so far).
The signaling transactions will typically spend the funds back to the
initiator's wallet.
Before revealing any of their inputs, the peer checks that none of the
inputs added by the initiator are in their mempool/chain.
If the initiator aborts the protocol after learning one of the peer's
inputs the peer broadcasts one of the signaling transactions.
Like the PoDLE proposal this doesn't achieve (3) since a malicious peer
could broadcast the signaling transaction making the honest initiator pay a
transaction fee before using the input in another session.
To mitigate this a bit, the transactions could be RBF and have a 1
sat-per-byte feerate to give the initiator a decent amount of time to use
their input productively before the tx confirms (and paying a low fee if it
ever does confirm).
The advantages of signaling transactions over PoDLE is that it doesn't
involve any wonky crypto or new gossip messages.
The advantage of the PoDLE proposal over this is that a malicious peer can
only blacklist the UTXO (not necessarily force you to spend it).
# Summary
The preference of protocol depends on how you weigh the importance of a
malicious non-initiating peer griefing the initiator.
To protect fully, the extended version of Darosior's protocol does not
allow griefing.
There is always a lot to be said for ruling out a class of attack even if
it costs you a few rounds of communication.
Is griefing a real concern though? Layer-2 is full of opportunities to
grief your counterparty and the ones presented here are hardly the worst.
If you're opening channels with someone who wants to grief you, you are
already in trouble.
PoDLEs have very weak griefing in the form of unfairly adding your UTXO to
the blacklist but comes at the cost of complexity and a few difficult to
answer questions.
I think the simplicity of signaling transactions may be worth the extra
griefing capabilities it offers a malicious peer given they are hardly as
bad as the griefing capabilities they will have if you open a channel to
them!
Cheers,
LL
[1] https://github.com/niftynei/lightning-rfc/pull/1
<https://github.com/lightningnetwork/lightning-rfc/pull/524>;
[2] https://github.com/discreetlogcontracts/dlcspecs/pull/114
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002516.html
[4]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002466.html
[5]
https://bitcoinops.org/en/newsletters/2020/02/05/#interactive-construction-of-ln-funding-transactions
[6]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002475.html
[7]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002522.html
[8] https://joinmarket.me/blog/blog/poodle/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210104/08adc787/attachment.html>;
đź“ť Original message:
Happy New Year Lightning Developers,
I've recently been closely looking at the dual funding proposal [1] because
it uses a DLEQ proof (PoDLE) which we are also working on specifying as
part of DLC ECDSA adaptor signatures [2].
While reading it I had some queries and ideas that I thought were worth
sharing (even though they are very very late).
# Background
Lisa posted a draft proposal [1] which includes the PoDLE and explained it
in [3] along with a good list of its weaknesses.
The original discussion thread where the idea was conceived is [4] and
there is an excellent summary in the following optech [5] which I post
below:
> Another proposal was to use PoDLE, which was originally developed for
JoinMarket based on a suggestion by Gregory Maxwell. This protocol allows
an initiating user such as Mallory to commit to a UTXO in a way that
prevents anyone from identifying that UTXO. The participating user, such as
Bob, publishes the commitment across the network (e.g. the JoinMarket
network) so that nobody else will start a session with Mallory while she’s
using that particular UTXO. Then Bob asks Mallory to identify her UTXO and,
if it’s a valid UTXO that matches her commitment, Bob discloses his UTXO to
Mallory so that they can proceed with the protocol (e.g. a coinjoin). If
Mallory aborts the protocol before completion, the commitment previously
published across the network prevents her from being able to start a new
session with any other user and so learn their UTXO. Mallory’s only option
is to spend her coins from herself to herself in order to generate a new
UTXO—a process that costs her money and so limits her ability to spy on
users. (Note, though, that PoDLE as implemented in JoinMarket allows
Mallory up to three retries by default so honest users aren’t penalized for
occasional accidental failures, such as a loss of network connectivity.)
The idea is to adapt this protocol for LN in order to prevent attackers
from learning which available UTXOs are controlled by LN users.
Especially relevant to this post is the idea posted by Darosior here [6]
which was summarized as follows:
> One proposal to fix this would require the person proposing to open the
channel (e.g. Mallory) to provide their UTXO(s) in a ready-to-spend state
so that probing would cost money (e.g. transaction fees). A downside of
this approach is that the construction proposed would be easily
identifiable by block chain analysis, making it easy to determine when a
dual-funded channel was opened
The goals of this post is to (i) see if I understand the PoDLE idea
correctly, to (ii) refine Darosior's idea and to (iii) propose a minimal
alternative idea.
# Requirements
Informally, here are the desirable properties I came up with for a dual
funding protocol:
1. If a malicious initiator learns a peer UTXO, then the initiator should
have to spend their UTXOs before reusing them against the next peer (should
be forced to spend them to repeat attack -- *if attacking sequentially*).
2. A malicious initiator should not be able to use the same UTXOs in
parallel with multiple peers (to learn the UTXOs of multiple makers with a
single UTXO).
3. An honest initiator should not have to spend their UTXOs if they execute
with a malicious peer.
4. dual-funded opening transactions should not have any distinguishing
features (i.e. sighash flags).
5. An honest but intermittently failing initiator should not have their
UTXO details sent by an honest peer to other parties.
Note I am going to ignore property (2) because of proposals below can turn
their protection against sequential attacks (1) into protection against
parallel attacks (2) by having the peer choose a random time delay and see
if anything is gossiped to them that would indicate malicious behavior by
the initiator in some other channel.
# PoDLEs
To solve this problem in JoinMarket, Waxwing had the idea [8] of turning
knowledge of a secret key for a particular UTXO into a kind of unlinkable
credential.
Given a UTXO public key P1, the initiator projects their private key onto a
different generator J to produce P2.
P2 is unlinkable to P1 (without a proof) but is fully determined by P1.
This allows participants to maintain a blacklist of P2s without learning
the P1s.
Having the P1s in the blacklist would make the blacklist itself useful for
chain analysis because it contains a list of UTXOs that tried to open
channels (but perhaps accidentally failed).
The idea is like this:
1. Taker asks some maker's if they want to do a coinjoin and sends them all
SHA256(P2)
2. When they find the maker they want to proceed with they reveal P2 and
prove DLEQ((P1, G), (P2, J)) i.e. P1 and P2 have the same private key just
different base points.
3. If they haven't received SHA256(P2)from the gossip network (i.e. it's
not in the blacklist), the maker then sends their own UTXO data AND gossips
SHA256(P2)
4. They carry on the protocol.
The current lightning proposal [1] follows the same logic except that it
only gossips SHA256(P2) in case of malicious behavior (this seems sensible).
If I understood it correctly, then it achieves properties (1,4,5).
The main downside is that it introduces a new gossip message. The
difficulties associated with this are listed in [3].
Notably it is missing property (3) - protection against malicious peers who
gossip SHA256(P2) even when there was no wrongdoing.
A question I have is why is SHA256(P2) sent up front? I think that P2 can
just be sent along with the proof later on in the case of dual funding.
Waxwing gave an explanation of it in the case of joinmarket in [7] but I
didn't grasp it.
# Darosior's SIGHASH_SINGLE|SIGHASH_ANYONECANPAY
The proposal from Darosior [6] is to have the taker provide their inputs in
a ready to broadcast state using SIGHASH_SIGNLE|SIGHASH_ANYONECANPAY.
This way the peer never needs to send their inputs directly to the
initiator (the initiator will only find out about them when the transaction
is broadcast).
I encourage the reader to look at [6] which has nice diagrams and is very
short and to the point.
This achieves all properties except for (4 - distinguishable on-chain)
which is why it was dismissed.
I think it is possible to extend the idea to achieve (4) and therefore
obtain all desired properties.
Simply put peers can just use the SINGLE|ANYONECANPAY signature as back ups
in case of abort. Here's how it could work in my mind:
1. Initiator requests dual-funding and provides a TX_temp spending their
input set to a main output and a change output (does not sign it yet). They
also provide a sighash SIGNLE|ANYONECANPAY signature on the main output
spending into TX_backup-fund and a signature on the first commitment
transaction spending from TX_backup-fund (exactly as in [6]).
2. Peer responds with commitment TX signature for TX_backup-fund.
3. Initiator responds with the signatures for TX_temp.
*Peer now has a fully functional transaction chain with which to open the
channel -- now they can attempt to upgrade to a SIGHASH_ALL opening*.
4. Peer (if possible) checks there are no existing transactions in the
chain or mempool spending from the taker's inputs. If not it responds with
its inputs, change and commitment tx signature for a SIGHASH_ALL TX_fund.
5. Initiator responds with commitment TX signature and TX_fund input
signatures.
6. Peer broadcasts TX_fund.
*If at any point after step 3 Initiator does not respond for ~2 seconds
they broadcast TX_temp and TX_backup-funding*
We have (4) because the SINGLE|ANYONECANPAY signature only appears on-chain
in case of abort (i.e. TX_backup-funding makes it on-chain).
It appears to be pretty close to the ideal solution in terms of privacy and
security.
If the malicious initiator learns an output they will always have to spend
one of their inputs otherwise they will quickly get hit by the TX_temp +
TX_backup-funding.
Note that it is possible the node is just slow in which case even if step
TX_backup-funding makes it in both parties should just carry on with the
channel.
The downsides are that it involves six rounds of communication and cannot
use the "interactive tx building" protocol developed for the original
proposal
# Signaling Transactions
Finally I present a simple but unintuitive protocol that achieves roughly
the same properties as the PoDLE protocol but without lightning gossip
messages.
Whenever the initiator adds an input in the interactive tx building they
provide signatures on a "signaling" transaction spending that input (and
any inputs they have added so far).
The signaling transactions will typically spend the funds back to the
initiator's wallet.
Before revealing any of their inputs, the peer checks that none of the
inputs added by the initiator are in their mempool/chain.
If the initiator aborts the protocol after learning one of the peer's
inputs the peer broadcasts one of the signaling transactions.
Like the PoDLE proposal this doesn't achieve (3) since a malicious peer
could broadcast the signaling transaction making the honest initiator pay a
transaction fee before using the input in another session.
To mitigate this a bit, the transactions could be RBF and have a 1
sat-per-byte feerate to give the initiator a decent amount of time to use
their input productively before the tx confirms (and paying a low fee if it
ever does confirm).
The advantages of signaling transactions over PoDLE is that it doesn't
involve any wonky crypto or new gossip messages.
The advantage of the PoDLE proposal over this is that a malicious peer can
only blacklist the UTXO (not necessarily force you to spend it).
# Summary
The preference of protocol depends on how you weigh the importance of a
malicious non-initiating peer griefing the initiator.
To protect fully, the extended version of Darosior's protocol does not
allow griefing.
There is always a lot to be said for ruling out a class of attack even if
it costs you a few rounds of communication.
Is griefing a real concern though? Layer-2 is full of opportunities to
grief your counterparty and the ones presented here are hardly the worst.
If you're opening channels with someone who wants to grief you, you are
already in trouble.
PoDLEs have very weak griefing in the form of unfairly adding your UTXO to
the blacklist but comes at the cost of complexity and a few difficult to
answer questions.
I think the simplicity of signaling transactions may be worth the extra
griefing capabilities it offers a malicious peer given they are hardly as
bad as the griefing capabilities they will have if you open a channel to
them!
Cheers,
LL
[1] https://github.com/niftynei/lightning-rfc/pull/1
<https://github.com/lightningnetwork/lightning-rfc/pull/524>;
[2] https://github.com/discreetlogcontracts/dlcspecs/pull/114
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002516.html
[4]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002466.html
[5]
https://bitcoinops.org/en/newsletters/2020/02/05/#interactive-construction-of-ln-funding-transactions
[6]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002475.html
[7]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002522.html
[8] https://joinmarket.me/blog/blog/poodle/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210104/08adc787/attachment.html>;