Bitcoin development has made new progress. Core developers propose to modify the logic of Bitcoin transaction replay to better transaction privacy.

Bitcoin Core developer Amiti Uttarwar is working on modifying Bitcoin's network replay logic to introduce more privacy in the transaction replay process.

Image credit: Pixabay

Uttarwar is a relatively new member of the Bitcoin Core team and was first hired as a Bitcoin Core developer for cryptocurrency startup Xapo in October 2019. Her main focus now is a proposal to change the replay logic of Bitcoin, which was previously highlighted by Bitcoin Core developer Pieter Wuille as one of many promising peer-to-peer implementation projects.

• The first "Blockchain Cloud Job Fair" is officially launched, looking for you in one millionth
• After Bitcoin plummeted 50%, do you feel the bottom is true?
• Bitfinex CTO: Bitcoin is the real currency on the Internet and will become the basic engine for future financial applications

As Uttarwar explained in his September 2019 presentation, when users initiate a Bitcoin transaction, they need to broadcast the transaction-which means they must send INV messages to other nodes and ensure that the transaction is in someone else's memory pool in.

However, the initial broadcast does not always succeed. For example, there may be problems with the relay process, or when other transactions have higher fees, the transaction may be withdrawn from the memory pool. If such a problem occurs, the user will have to send another INV message and rebroadcast it to other nodes.

In explaining the motivation for making this replay change, Uttarwar said, "The current replay logic is terrible for privacy."

How the change works

She said that under the current system, only the source wallet will rebroadcast transactions. As a result, if a spy node sees two INV messages for the same transaction from the same node, it can be inferred that the node is the source wallet, "at this time transaction privacy is a flaw".

"This leaves room for a vulnerability that is being attacked by dust," she said. When an attacker sends a small amount of BTC to many different addresses and observes the replay behavior of various wallets, a dust attack occurs that disrupts the network Privacy features.

The mechanism proposed by Uttarwar will migrate this vulnerability by having a more private replay behavior that does not leak the source wallet of the transaction. If the Bitcoin network implements this alternative design that she proposed, then all nodes will rebroadcast what they consider to be "should have been confirmed", not just the rebroadcast signal sent by the source wallet.

she says:

"I pulled the logic from the wallet into the node and used the block assembler so that we could identify the top of the memory pool in a similar way to how the node sees it. I updated the wallet logic to reinstate unconfirmed transactions Commit to the node instead of sending it directly to other nodes. I added a recent filter to the block creation logic so that we can ignore recent transactions. "

development route

This pull request (PR) first opened in August 2019, and Uttarwar told The Block that she has made considerable changes to the case since.

she says:

"One of the biggest changes is that I've been able to break down the functionality of a large PR into a separate change. So, I'm currently working on this transition. Once we merge it, I will return to this larger broadcast project . "

Another major change involves a mechanism that tracks the maximum time a person can rebroadcast the transition. Although Uttarwar had previously planned to use it as a follow-up to her replay proposal, she recently decided to build after the reviewers highlighted how to make it an attack vector after the lack of this change.

Uttarwar also noted that excessive bandwidth usage is one of the potential problems behind its design choices.

she says:

"I think bandwidth is an issue that we should carefully consider, and if done wrong, problems may arise."

In order to avoid extreme bandwidth peaks across the entire network, Uttarwar has adopted some precautionary mechanisms, including Poisson distributions of the replay timing of each node and filtering logic for replaying candidates.

The PR has been running for seven months, but she said she was not in a hurry to move the proposal through.

she says:

"I don't care much about the timeline, but more about the robustness of each step. I don't want anything to merge prematurely."

We will continue to update Blocking; if you have any questions or suggestions, please contact us!