Bitcoin unity

[chainm1rror]

This is an implementation of the BitcoinUnity idea.

[ThermosCoin]

Concept ACK. Will review code later and see about testing it. Legendary idea!

[jcansdale]

You've implemented two-way replay double-spend protection via a cross-chain consensus rule soft-fork?

[jcansdale]

This file would be easier to read if it was README.md.

[chainm1rror]

Agreed. Will do that after the likely code changes.

[Sjors]

This should also be in the Github issue description. I would also remove all the "philosophical" stuff.

[jcansdale]

Would this prevent any tx being created that could only appear on the 1x side? Counter intuitively, aren't even zero value outputs spendable? Maybe they should be zero value and sent to OP_FALSE (burned).

[chainm1rror]

You've implemented two-way replay double-spend protection via a cross-chain consensus rule soft-fork?

Yessir!

Would this prevent any tx being created that could only appear on the 1x side? Counter intuitively, aren't even zero value outputs spendable?

Yes, the zero outputs are valid according to current rules. However, they can not be spent according to the rules of the soft fork because any TXIDs involving them would not be whitelisted (or only if such a funny zero-output would exist on the 2x chain). So then that should be fine, I suppose?

[jcansdale]

I thought it would remove even the possibility of creating a tx that could only exist on the 1x chain. As you say, the cross-chain consensus rule would prevent any child of these coinbase outputs from being mined anyway.

It would maybe make more sense for these zero value outputs to point to an address that the miner owns. That way they could potentially be compensated by miners on the 2x side.

[chainm1rror]

To criticize myself here: Areas that need input and further development:

Restarting unity.py or the two watched bitcoinds in any order should always work. It might be a good idea to save transactions that are seen in the 2x chain to disk. Also, download the whitelist into 1x bitcoind as soon as it's online. Separate whitelisting from transaction injection using sendrawtransaction.

Transactions may be invalid on 1x: The fork logic is too stupid and will stay too stupid to understand why. Maybe doing sendrawtransaction with an exponential backoff and a possible dropping could make sense here? At the moment the code is too busy to send again and again.

I really like more input from other folks on all this. Thank you very much!

[jcansdale]

Transactions may be invalid on 1x: The fork logic is too stupid and will stay too stupid to understand why.

You mean if they've been replay protected using a 1M or coinbase tx on the 2x side? Could it receive its candidate tx from a node on the 1x side before checking against the whitelist and injecting them?

[hardforkmatters]

C'mon! Hurry up!) We can do it, coz of 25% of all Core Nodes ~ BTC1 Nodes count! Proof of hash (DONE), proof of nodes (almost DONE), proof of chain (in progress)=BTC is in our hands! CORE devs - Surrender now!!!

[Sjors]

From the README:

The core idea of BitcoinUnity is to put only those transactions into the 1x chain which also succeeded on the 2x chain, and therefore map a subset of the transactions in the 2x chain into the 1x chain. Preferably those who pay maximum transaction fees.

I see several major problems with this:

1. it requires a soft-fork on the 1x side on very short notice. Politics aside, a proposal like this would take months to discuss, review, implement and activate.
2. this subset will get smaller very quickly, as people (intentionally or otherwise) mix 2x coinbase transactions
3. if 2x blocks are full, 1x blocks would need to be mined twice as fast as 2x blocks in order to prevent an escalating backlog, although (2) would mitigate that effect.
4. it requires monitoring both chains, which is very complicated to implement and - more importantly - triples storage and bandwidth requirements (1x + 2x = 3x), although there's room for compression (good luck implementing that though...)
5. how would you handle reorgs? Does a reorg on 1x imply a reorg on 2x?

Native replay protection by either side is a far easier solution. That's unlikely to happen, and so a even more complicated solution like this is even is even less likely to happen.

This ensures that a division of the two chains and therefore the price and a dirty fight over supremacy of legacy against 2x Bitcoin is impossible!

For future non-contentious hard-forks I do think something like this would be useful, as an additional mitigation in case the fork does become contentious or has bugs. Maybe that would involve some sort of merged mining. There could be a one year transition to make a full reorg insanely expensive. If the hard fork involved a capacity increase, perhaps both chains could have identical transactions, the new chain coinbase transactions would be unspendable for two years. The first block of the new chain would have a > 1 MB transaction, but after that it wouldn't exceed 1 MB for the first year in order to prevent a backlog. In the second year blocks would be bigger, and the original chain would contain empty blocks. Something along those lines...

[chainm1rror]

You mean if they've been replay protected using a 1M or coinbase tx on the 2x side? Could it receive its candidate tx from a node on the 1x side before checking against the whitelist and injecting them?

@jcansdale :
Either that or a dependent transaction could not be included in the 1MB chain, or the transaction has been made with a locktime and the height of the 1x chain is not enough. There are potentially several reasons why a transaction can be rejected. Implementing a "smart" selection / injection of the right transactions at the right time seems to be difficult to do, so I suggest simply trying again while increasing the gaps exponentially between retries and letting the 1x chain repeatedly bark at and drop invalid transactions.

@Sjors :

it requires a soft-fork on the 1x side on very short notice. Politics aside, a proposal like this would take months to discuss, review, implement and activate.

Yes, I understand. Along those lines: Have any of you guys asked the bigger miners on this proposal or ideas like this? If not, could you do so?

this subset will get smaller very quickly, as people (intentionally or otherwise) mix 2x coinbase transactions

Agreed as well. The subset gets smaller, but the userbase of the legacy chain should get smaller as well. And being a die-hard supporter of the legacy chain seems doable as long as you pay the right fee for inclusion.

if 2x blocks are full, 1x blocks would need to be mined twice as fast as 2x blocks in order to prevent an escalating backlog, although (2) would mitigate that effect.

The assumption is that most users would eventually upgrade. In the meanwhile and with a scheme to either reimburse miners or spend coinbase transactions, high fees should allow inclusion in the 1x chain, should that be necessary.

it requires monitoring both chains, which is very complicated to implement and - more importantly - triples storage and bandwidth requirements (1x + 2x = 3x), although there's room for compression (good luck implementing that though...)

Yes. I assume that storage requirements of at most 1.5 times the expected value for btc1 are not a serious problem at current storage prices. The expected, unoptimized bandwidth is 1x + 2x so realistically also about 1.5x the 2x bandwidth, which seems reasonable. Note that the bandwidth usage of any current Bitcoin implementation is not limited anyway. As a fork, the additional resource requirements only concern miners who already have a large amount of hardware in operation.

how would you handle reorgs? Does a reorg on 1x imply a reorg on 2x?

The answer is not to care. As long as the 1x reorg complies with the additional rules of this soft fork, everything is fine. No additional requirement for the 2x chain. The current code expects a configurable number of confirmations before allowing transactions to be included in the 1x chain.

Native replay protection by either side is a far easier solution. That's unlikely to happen, and so a even more complicated solution like this is even is even less likely to happen.

I tend to disagree about complexity, because of the reality of this existing code. Have you tried it? Did someone else try it?

For everyone: Is it worth working on this? Is there a greater interest in continuing to work on this?

[chainm1rror]

Added persistence and a transaction injection priority queue with randomized exponential backoff.