Bitcoin Core developer reworks the network's 'rebroadcast logic' to improve privacy

Quick Take

  • Bitcoin Core developer Amiti Uttarwar is working to revise Bitcoin transactions’ rebroadcast logic in order to strengthen the network’s privacy feature
  • The proposed change would also mitigate the risk of dusk attacks.

Bitcoin Core developer Amiti Uttarwar is working on revising the network’s rebroadcast logic to introduce more privacy into the transaction rebroadcasting process.

A relatively new addition to the Bitcoin Core team, Uttarwar was first employed as a Bitcoin Core developer at crypto startup Xapo in Oct. 2019. Her main focus right now concerns a proposed change to bitcoin's rebroadcast logic, which Pieter Wuille previously highlighted as one of a number of promising peer-to-peer implementation projects.

When users initiate a bitcoin transaction, as Uttarwar explained at a Sep. 2019 presentation, they need to broadcast the transaction – meaning they must send out an INV message to their peers and make sure that the transaction is in other people’s memory pool, or mempool.

However, the initial broadcast does not always go through. For example, there could be issues with relay or the transaction could get evicted from the mempool when other transactions have higher fee rates. If such issues arise, users would have to send out another INV message and rebroadcast it to their peers. 

“The current rebroadcast logic is terrible for privacy,” Uttarwar said, explaining her motivation for the proposed change

How it works

With the current system, she said, only the source wallet will rebroadcast transactions. As a result, if a spy node sees two INV messages for the same transaction coming from a node, it can infer that the node is the source wallet, “making privacy a dead giveaway.”

“This leaves room for a vulnerability called a dust attack,” she argued.  A dust attack happens when an attacker sends a tiny amount of BTC to a number of different addresses and observes various wallets’ rebroadcasting behaviors, thus undermining the network’s privacy feature. 

Uttarwar’s proposed mechanism would migrate this vulnerability by having a more private rebroadcast behavior that does not reveal a transaction's source wallet. If her alternative design gets implemented, instead of only the source wallet sending out the rebroadcast signal, all nodes will rebroadcast transitions that they believe “should have been confirmed.”

“I extract the logic from the wallet into the node and I use the block assembler so that we can identify the top of the mempool in a comparable way to how my node will be looking at it,” she said, going into some of the functionalities her proposal includes. “I update the wallet logic to resubmit unconfirmed transactions to the node instead of sending it directly to its peers. I add a recency filter in the block creation logic so that we can ignore the new recent transactions.”

Start your day with the most influential events and analysis happening across the digital asset ecosystem.

By signing-up you agree to our Terms of Service and Privacy Policy
By signing-up you agree to our Terms of Service and Privacy Policy

Development path

The pull request (PR) was first opened on Aug. 2019, and Uttarwar told The Block that she has made considerable changes to the proposal since then. 

“One of the big pieces of change is that I've been able to break out a piece of functionality from the large PR into a standalone change,” she said. “So I'm currently working on trying to see that change through. And once we get that merged, I'll return back to this larger rebroadcast project.”

Another significant change concerns a mechanism to keep track of the maximum amount of times one can rebroadcast a transition. While Uttarwar previously planned to include it as a followup to her rebroadcast proposal, she recently decided to build it out after a reviewer highlighted how the absence of this change could be an attack vector. 

Uttarwar also pointed to excessive bandwidth usage as one of her underlying concerns behind her design choices. 

“I think that bandwidth is something that we should be carefully considering and, if done wrong, could be problematic,” she said. To avoid extreme, network-wide bandwidth spikes, Uttarwar has incorporated a few preventive mechanisms, including poisson distribution of rebroadcast timings per node and filtering logic for rebroadcast candidates. 

While the PR has been in place for seven months, she said she’s in no rush to push the proposal through. 

“I'm less concerned about timeline and I'm more concerned about robustness every step along the way,” she said. “I wouldn't want anything to be merged prematurely.”

© 2023 The Block. All Rights Reserved. This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.

About Author

Yilun joined The Block in November 2019. She has a policy background and extensive experience in reporting and writing. She has worked on stories ranging from business to politics.