Potential Privacy Issue With Dual Funded Channels
Dual funding and splicing mechanisms allow initial negotiations between node to
allow the node on the other end an opportunity to put funds at channel opening
time or after it. Finding liquidity is a problem that had solutions suggested
all the way back in November, the suggestion was, in summary, that a node will
advertise initial liquidity matching via their
node_announcement, this is meant
to help these nodes source inbound capacity from a market of advertised
liquidity rates as set by other nodes.
After a recent spec meeting, developer Rene Pickhardt noticed a potential privacy issue with this schema: a node can spam another probing for a lower bound for the amount of BTC available by this node, each time aborting the channel establishing before locking any of its own Bitcoin.
A few solutions popped up for this privacy issue, one is making this spamming more expensive by requiring the node to open a channel first then asking the other end to splice something in, this requires the “spamming” node to make an on-chain transaction.
Another is instead if the receiving node returning an error because of unavailable liquidity, it privately holds a randomization vector that returns an error with a probability P, making the attacker uncertain of the type of error received. Several other suggestions and protocol adjustments were discussed in the mailing list thread, you can read the discussion here.
Support us and the authors of this article by donating to the following address:3Q421j7XvneQA4yRFGxqSawt3ANRjcxUxd