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.

References:

Support us and the authors of this article by donating to the following address:

3Q421j7XvneQA4yRFGxqSawt3ANRjcxUxd

Comments powered by Talkyard.