4 mins ago |
By Jamie Redman – |
A Look at Bitcoin Replay Attacks and Self-Managed UTXO Protection
Over the past few weeks, bitcoin proponents have been quarreling online about the lack of replay attack protection for the pending Segwit2x fork scheduled for this November. As time draws closer, a lot of bitcoiners are planning on sitting tight to ride out the storm. However, there are also individuals searching for replay-protected exchanges, wallet providers, and alternative techniques to protect themselves.
Everyone Keeps Talking About This Thing Called Replay Protection
The decentralized cryptocurrency bitcoin and many other altcoins utilize a data storage concept called Unspent Transaction Outputs (UTXO). Someone who owns bitcoin in a non-custodial wallet has a list of “unspent” satoshis which primarily contains the user’s balance data. The sum of the bitcoin owner’s UTXOs is the individuals or organizations entire balance.
When a fork takes place on the network, there can be network confusion or replays when people are sending bitcoin transactions which could lead to financial losses. Because the split happens on the same chain, all transactions, addresses, and balances will be a direct reflection of the chain before the fork. This means UTXOs can be confirmed by miners on both chains and can theoretically be manipulated by malicious actors, or other types of transaction mistakes can happen. For example, if bitcoin is sent to an address on the Segwit2x chain it’s possible the UTXO can be replayed on both.
People Can Send Non-Replayable Transactions, But the Methods Are Not For the Light Hearted
There are some ways users and miners can send transactions and still keep a level of replay protection. The methods require specialized software and a reasonable level of technical knowledge. For instance, miners or people who know a mining pool can utilize sending bitcoins by a ‘Coinbase transaction’ which cannot be replayed after the fork. This is one method where an individual or group can send non-replayable transactions, but there’s a catch. Bitcoins in a Coinbase transaction cannot be spent until they’ve received 100 confirmations. But they will be only valid on the chain they were originally generated from, which assures there will be no replay for those UTXOs.
Another method which requires a bit of technical knowledge and software that can accomplish the process is called, ‘nLocktime.’ This procedure means when the two chains bifurcate, a transaction can be set for a specific time or block height. A user can use a full node client to set the nLocktime to a block height, but there are not that many wallets that offer this feature. By utilizing the nLocktime method, a user can essentially create a transaction that will confirm on the longest chain.
Two Transactions — Two Fee Settings
Bitcoin developer, David Harding, explains another process of using two different fees for transactions on both the high fee chain and the low fee chain. The statement from Harding is a response to a question from the CEO of Coinbase, Brian Armstrong, asking about replay prevention on the Bitcoin Stack Exchange Q&A website.
“It is possible miners on one side of the fork may be mining transactions with lower fees than on the other side, so you can broadcast a low-fee version of your transaction on the low-fee chain, wait for it to confirm, and then broadcast a higher-fee version on the high-fee chain,” explains Harding.
You may still have to wait a few blocks for fees to diverge by much, and since each miner has their own policy, you may need to try multiple times — Also, many wallets don’t let you choose arbitrary fees (they just give you a reasonable fee or let you choose from reasonable range of fees).
Protecting Digital Assets Requires Patience
Other methods of protection include simply waiting for a splitting tool created by an exchange or a wallet provider. Further, some wallets and exchanges will have also have built-in replay attack defense so using these services will allow you to transact without a replay outcome. For instance, Coinbase, and the wallet provider BTC.com, have already stated they will have their own replay protection. There will likely be many more businesses following suit.
Last but not least, probably the best method of all is waiting out the bitcoin fork until it’s 100 percent complete, and everyone is assured things are settled. If you don’t really need to transact with bitcoin, it’s probably better to wait until the fork is done, and do some research after the fork on the current state of each network before transacting. So to sum things up — Play it safe, be patient and investigate the results of the fork before proceeding to send, receive or really do anything on the bitcoin network.
What methods do you know of that will protect you from replay attacks? Are their bitcoin service providers that you know of that are providing their own replay protection? Let us know your thoughts in the comments below.