41

Bitcoin Cash (aka Bitcoin ABC aka UAHF) provides two methods of replay protection, both of which are opt in. If you do not create transactions which use these features, then your transactions are vulnerable to replay. The first method is a redefined sighashing algorithm which is basically the same as the one specified by BIP 143. This sighash algorithm is ...


12

As of what happens if someone send BTC from a BTC wallet to BCC wallet address, the transactions go through. But you can only see that transaction in the Bitcoin Blockchain rather than Bitcoin cash blockchain. I will explain with an example. Say there is an address named "abc" in BTC and another address named "def" in BCC. abc has 1 BTC (Bitcoin Network) ...


10

What is a transaction replay In the context of forks, transaction replay is when a transaction is valid on both sides of the fork. So a transaction can be played (i.e. broadcast) on both chains after the fork and be a valid transaction and confirm. This means that if you intend on sending coins on one fork, you could accidentally end up sending your coins ...


7

I don't believe any replay protection has yet been implemented, they still have an issue open for it on the BitcoinGold repository here: https://github.com/BTCGPU/BTCGPU/issues/51 I haven't dug into the code itself but I would imagine that they would have closed the issue if they had implemented something. The statement by Bittrex also claims that they ...


6

The answer is no, you can't, because the two chains don't share a common history. Internally, transactions don't spend "from" an address. Instead, they refer to a specific output created by an earlier transaction which they consume. In order for a replay attack to work, that same transaction whose outputs are being spent must exist on both chains. This is ...


6

One solution we brainstormed, was using some coins that were only valid on one chain (for example newly mined coins) and adding 1 satoshi of "taint" to all generated transactions. This would work but is not perfect. It so sounds like you have two problems: How to get some inputs that are only valid on one side of the chain. How to mix these inputs in with ...


6

There is nothing which distinguishes a BCC address from a BTC address; they are both the same format and refer the the same keys, thus a BCC address is a BTC address and vice versa. This means that if someone sends BTC to an address that you created with a BCC wallet, the person who owns that BCC wallet would receive BTC. It won't appear in his BCC wallet, ...


5

As long as both chains adhere to the same address format, which I believe they do for now, there is no such thing as a BTC or a BCC address -- both are valid on both chains. What enables you to split your coins is the replay protection BCC implemented. It makes a BCC transaction invalid under BTC rules and vice versa. BTW, Ethereum faced similar problems ...


5

He should listen to his engineer. I think that's just about it.


5

Can somebody take the transaction tx0 I signed and publish it in order to spend the new coins with the old transaction? No. Firstly, the transaction inputs are already known to have been used. Any node examining the block will know that the rerun transaction has invalid inputs. Secondly I expect (but haven't checked) the inputs to the signature include ...


4

Let's diagram an example hard fork block chain: A <-- B <-- C <-- D (current consensus rules chain, "original chain") ^---- C' <-- D' (new consensus rules chain, "new chain") If you received a transaction output in block A or B, you could spend it on both the original chain and the new chain[*]. How that would work out depends ...


4

This actually happened on Ethereum when they had a hard fork. If a transaction is valid on both chains (spends outputs from before the fork), and gets propagated to both chains, then yes, there is no reason it won't be added to blocks on both chains. However, there are still two chains. When the same transaction gets added to both chains, they are ...


4

First of all the sighashType field with (or without) any bit fields is used in source data while for signing. The signature does not sign itself, but it signs sighashType. So, changing sighashType invalidates signature. Second, the data for signature is created in different manner.


4

Since 2x has decided not to implement replay protection, transactions will be indeed compatible to both chains. If a transactions is simply broadcast to the other chain, it will enter the mempools there as well and may eventually get confirmed. This doesn't mean that one is completely helpless though. Here are some methods of making transactions valid only ...


4

The transaction ID and output index of the second 1 BTC that was sent to A's address will be different from the first 1 BTC that was sent there. Since transactions refer to inputs by their txid and output index, the signature used in the first transaction will not be valid for another tx trying to spend the second deposit. Additionally, depending on the ...


3

All transactions would be replayable on both chains even after one was confirmed in a block on one chain, because since both chains start with the same UTXO set, the transactions spending those UTXOs are valid on both chains. The only exception is coins mined on each chain after the fork, because those coins will not be valid on the other chain. So that is ...


3

segwit2x temporarily had an opt-in replay protection, but chose to remove it. it is intentional, as part of their strategy to make only one fork survive.


3

No. BIP 148 is a soft fork as the BIP 148 chain is valid to all non-BIP148 nodes and can wipe out the non-BIP 148 chain if it were to be longer than it. Because it is a soft fork, there cannot be any replay protection otherwise it would become a hard fork.


3

There are two ways to avoid transaction replay (besides something being built into the fork to begin with). You can taint your coins or double spend. Tainting your coins requires you to get access to coins created after the fork on at least one of the chains. If you create a transaction which includes an input from a coinbase transaction created on the BIP ...


3

A transaction contains a reference to the output that it is spending from. So all you would be doing is just rebroadcasting the same transaction over and over again. Since transactions are identified by the hash of the transaction, the transaction you are rebroadcasting is exactly the same thing as the one already broadcast, and all nodes will treat it as ...


3

Every full node keeps track of all unspent transaction outputs (UTXO). UTXO are identified via their outpoint txid:vout, where txid is the transaction identifier of the transaction that created it, and vout is the output position within this transaction. Transaction ids are generally unique, and thus each outpoint can only occur once as well.¹ To spend any ...


2

A) Currently, Unlimited retains the 100K MAX_STANDARD_TX_SIZE policy limit https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/release/src/policy/policy.h#L23 so it would be difficult to propagate a large transaction via P2P. However, a miner could mine a large 1MB TX if you got one directly to them, and then the UTXOs from the big TX could be used for ...


2

Here is the github ticket where we've been thinking about this problem for Zcash. Compared to Bitcoin, Zcash has the luxury of a smaller installed base and a longer runway before any probable blockchain split, so we don't have as many constraints on the design space as you have, but nonetheless some of these ideas might be helpful: https://github.com/zcash/...


2

When Alice creates a transaction of 1 BTC to Bob, she is giving him a specific bitcoin, by using an unspent transaction output that she has the key to. The blockchain tracks the flow of coins from transaction to transaction, it does not have 'balances'. So when Alice makes a new transaction, she provides an input to the transaction of at least 1 BTC, and ...


2

It's true that what you propose would effectively split the coins and prevent further replays, if it succeeded. However, it suffers the following problems: Every person who wants to split their coins has to create an additional transaction to do so (and pay a transaction fee). Presumably nobody really wants to be subject to replay attacks, so everyone is ...


2

The LegacyCoin network and NewCoin network are not distinctly separate from each other. Unless network magic and ports are changed, LegacyCoin nodes will be able to connect to NewCoin nodes and likely many will be connected to each other. So if you broadcast transaction A->B, on the LegacyCoin network, it will likely reach a NewCoin node which then causes ...


2

Yes, some people call this a 'Replay Attack'. But it's not literally an attack, but the desired outcome. If a fork don't want this to happen it can change the rules to prevent it. You can also avoid it but using inputs mined in BTC after the fork, if your wallet app allows this kind of selection.


2

Yes, there's OP_CHECKDATASIG in ABC's code and OP_MUL in SV's code. There's already a coin splitting tool.


1

Bitcoin is not an account based currency like Ethereum, which track the balance in addresses. Instead it is a UTXO based currency. In a UTXO-based currency, funds are tracked in portions called "Unspent Transaction Outputs", these are uniquely identified through their history, specifically through the transaction id that created them. Any new money moved to ...


1

Frauder then perform a segwit2x transaction through his segwit2x software to an exchange accepting segwit2x. The transaction being larger than 1Mb block size, it is rejected on the original blockchain and he keeps his balance on the original blockchain but not on the second. Note: just because a transaction on the 2x chain is in a block larger than 1MB, ...


Only top voted, non community-wiki answers of a minimum length are eligible