Poll: encumbering tx replay between majority fork BU chain and old chain?

[freetrader]

Let's assume, hypothetically, that a BU majority fork has occurred and a >1MB block mined (i.e. chain has forked).
Let's also assume there is a 1MB small-blocker chain & network hanging around (don't know how realistic this is, but let's assume it).

The question is whether you would support a BUIP (set up prior to the above taking place, of course), which would allow you to:

1. create a transaction from pre-fork inputs on a BU client which a BU miner will not mine, but which would be accepted by miners on the small block chain (aka "sell your small block chain coins")

2. create a transaction from pre-fork inputs which the old chain nodes would reject as invalid, but which the BU nodes would accept as valid (aka "sell your big block chain coins")

By "encumbering tx replay between BU chain and 1MB chain" is meant that both of the above would only work as intended on the small block chain unless that chain takes deliberate action to render them ineffective.

I am primarily interested in what the BUIP members (or soon-to-be members) with voting powers about such a BUIP think about the idea.

Of course, any comments and discussion is welcome!

 

[adamstgbit]

The minority fork, is simply invalid, and should to be treated as such, by going out of our way to make it easy to interact with the lesser fork, we kinda give it validity...

IMO, its up to the lesser fork to do this kind of thing.

i think the most consideration the majority fork should give to this "replay attack" topic, is to make it impossible to replay a TX generated from old client-software.

 

[Zangelbert Bingledack]

@adamstgbit What if we are the minority fork?

@freetrader I thought about voting yes, but I'm not sure of all the considerations yet so it would just add noise. I also still feel like don't fully understand @Justus Ranvier's arguments about replay attacks.

 

[Norway]

BU follows Nakamoto consensus. It follows the most POW chain. That is the definition of bitcoin. If someone wants to keep a spinoff alive after an upgrade to BU (Core), they should manage replay attacs themselves.

 

[Zangelbert Bingledack]

It's still conceivable that the miners could get it wrong and the economic majority of nodes could revolt, in which case the hashpower majority's side would be in the economic minority, I think meaning that they would be the ones that need to worry about replay attacks.

 

[Norway]

@Zangelbert Bingledack
What do you mean by economic majority of nodes?

 

[Zangelbert Bingledack]

@Norway

Like if most of the exchanges, infrastructure businesses (Bitpay, Coinbase, Circle, 21.co), dark markets, nodes of major holders like Erik/Roger/etc., and so on are on the opposite side of the majority of miners. Of course this is a scenario miners will be doing everything in their power to avoid.

 

[adamstgbit]

@adamstgbit
What if we are the minority fork?

I believe BTCFork plans to make a minority fork using BU as its code base. ( if we fail )
they appear to have sorted out all the requirements that come with minority forks.
there's a pretty big list of nessary changes with minority fork.

It's still conceivable that the miners could get it wrong and the economic majority of nodes could revolt, in which case the hashpower majority's side would be in the economic minority, I think meaning that they would be the ones that need to worry about replay attacks.

I think this is an unlikely scenario, generally everyone has a preference, but when push comes to shove they will "go with the flow", most poeple recognize that both solutions are workable, altho they probably won't admit to that in the middle of debating...

it can only happen if the miners let it happen, they will see most fullnodes on the network have not upgraded and they will fork anyway... at which point this isn't a hardfork, its a 51% attack?

 

[Norway]

@Zangelbert Bingledack

Ok, I don't think nonmining nodes are that important regarding this power. The fact that Coinbase have a few nodes is not - in my eyes - relevant. Coinbase is important for different reasons. And I think real users of the currency are important, even though most of them don't run full nodes.

I might come off as a nitpicker, but I think people overestimate nonmining nodes in this complex power structure.

I'll show myself out

 

[dgenr8]

I think this would be very desirable, especially if @freetrader is offering to do it. There is no downside to it.

The old software can only author transactions valid on both chains. With this feature, BU could offer the ability to restrict transactions to one chain, if tx author desires. For example, when moving your old chain coins to an exchange to sell them, you don't want to move your BU coins there as well.

The default should still be to author a tx valid on both chains. And of course any tx spending chain-specific coins (post-fork coinbases, products of earlier chain-specific txes, or their children) will automatically be chain-specific.

Another analogy: this is a bit like Chrome offering to convert your IE favorites.

 

[freetrader]

@dgenr8, this is just a poll, I'm not yet offering to do it - just wanted to gauge whether there is sufficient interest to contemplate it further.

My opinion is that if BU becomes the majority, the 1MB chain would be too short-lived for this feature to pay off. I think it is more likely that such a feature would end up hardly being used, or even rendered partially useless by a suitably engineered minority fork of the small block chain (I see such a minority HF as inevitable if the small block chain wants to survive).

 

[redmarlen]

Its absolutely clear from my perspective. We must assume two chains will exist and we must take care to provide users the right tools to execute their wishes clearly and without ambiguity. Wallets move funds! around. NO USER wants ambiguity on which ledger their funds are moved. Options for Replaying are necessary and the defaults should be explicit for one chain.

 

[adamstgbit]

@redmarlen

sure, but.
simply making it so old software can only move funds on the old fork
and only by running the new software can you move funds on the new fork
makes it clear as day, 0 ambiguity.

my problem with making the new software generate old TX is:

1) its more complex for the user, "send BTC button" now has to settle the question " but which chain do you want to send it too???
2) it makes it seem as tho we think the minority fork is a valid fork, its not!
3) its very likely that once the fork happens 95% of hashing power and nodes will be on the new chain, and the 5% chain will be kinda broken... why bother supporting it?
[doublepost=1481812584][/doublepost]even if the old fork has 25% hashing power its not worth doing this.

user will either upgrade to the new software to TX on the new chain ( they will have done so beforehand, simply because it would be insane for miners to fork off majority of non-minning nodes )
or user will not upgrade and stick with the old fork.

why go any futher?

 

[dgenr8]

We must choose wisely because we have only one chance. If the hard fork doesn't introduce a way to keep transactions off the big-block fork, doing so in the future requires another hard fork upgrade that will never happen. If it doesn't introduce a way to keep transactions off the small-block chain, doing so in the future requires a soft-fork BIP9-style upgrade.

@adamstgbit What you describe is not the way BU will work currently. It will generate transactions that are valid on both forks, as will the old software. That's fine as a default, but it is extremely advisable to have a way to mark transactions as invalid on one fork or the other. There is no downside.

It doesn't need be part of the main UI (can be an advanced feature). Also it is not difficult to implement. Supporting an opt-out bit for the big block fork is only a couple lines of code. The other side is a bit more involved but @freetrader has worked on this more than anyone.

 

[painlord2k]

My suggestion is you don't implement this type of BUIP. Because it is a soft fork.

For users in the small block branch, it is pretty easy to make a transaction changing their balance in the large branch but not in the small branch.

They just need to make a transaction with a very small fee. It will never be mined in a small block because they will be already full. After it is mined in the big block branch they just make a normal transaction and pay a normal fee so this last tx will be included only in a small block (because it is now invalid for large blocks).

I'm also against preventing "replay attacks" because they are not attacks at all.

Miners/pools are sellers of secure space in the branch of the blockchain they mine. They get rewarded by the fees and new coins included in the blocks they mine. If Miner A mines branch A and Miner B mines branch B they get their rewards by their blocks. When they sell the coins they earned by mining the market demand decide what these coins are worth.

In a contentious fork about features of the blockchain and not about balances' history, developers of the fork should not discriminate between transactions.
[doublepost=1481821336,1481820657][/doublepost]A few side notes:

This is a soft fork of the consensus rules and it is not sure everyone will respect it anyway.

If the developers want to do a BUIP about transactions that will be created, sent but not mined by their software, why not just make it general and not fork specific?

It remembers me the idea I suggested about "tx only valid if the block is X" where X is less, equal or more of block height, block size, block version, etc.

 

[adamstgbit]

We must choose wisely because we have only one chance. If the hard fork doesn't introduce a way to keep transactions off the big-block fork, doing so in the future requires another hard fork upgrade that will never happen. If it doesn't introduce a way to keep transactions off the small-block chain, doing so in the future requires a soft-fork BIP9-style upgrade.

@adamstgbit What you describe is not the way BU will work currently. It will generate transactions that are valid on both forks, as will the old software. That's fine as a default, but it is extremely advisable to have a way to mark transactions as invalid on one fork or the other. There is no downside.

It doesn't need be part of the main UI (can be an advanced feature). Also it is not difficult to implement. Supporting an opt-out bit for the big block fork is only a couple lines of code. The other side is a bit more involved but @freetrader has worked on this more than anyone.

I figured, and honestly i think thats fine as is, i don't believe BU should give this problem any consideration whatsoever. At most, BU should just alter the TX format just enough so old nodes dont see the TX as valid. some +1 in the TXID calculation or somthing.
do you think core would do the same for us if we have a minority fork with BU?
IMO supporting an "altcoin" is not right...

downsides include but not limited too:
1) its more complex for the user, "send BTC button" now has to settle the question " which chain do you want to send it too?"
2) it makes it seem as tho we think the minority fork is a valid fork, its not!

with all that said, if its not part of the UI and only an adv cmd line function i'd be for it, but i still think its a bit of a waste of time, since old forks should be unusable anyway because of the high difficulty its left with.

 

[redmarlen]

The BU based btcfork chain client should only accept a new kind of transaction so that the old style txs will not be recognized. Therefore replay accidents are not possible.

The official BU client should add a new feature to accommodate the new style btcfork txs. Handling the new btcfork chain would be like becoming a multi-coin wallet. It could be that BU will have options to treat one side of the fork as a "lite" wallet while remaining a full node for the opposite chain. These are safety features in case a spinoff fork happens. So its a matter of security in the face of the community deciding to adapt.

In this sense the minority fork IS valid. A chain is always valid to the people using it. Its not the software that decides its the people. Giving the users safety options to switch chains, or handle spinoff forks is a great way to smooth out the lessons and adapt. The community can use the process to learn what features are best and what other people want.

Its likely payment processing for digital currency will treat all coins with large communities as if they were the one coin (e.g. payment process tunnel through shapeShift). So 'acceptance' will be the less competitive aspect and rather 'capacity','efficiency','privacy' & 'adaptivity' will be the qualities that distinguish the best coins.

 

[painlord2k]

@redmarlen
"The BU based btcfork chain client should only accept a new kind of transaction so that the old style txs will not be recognized. Therefore replay accidents are not possible. "

It is fine and dandy until you realize the 99% of the users is using software unable to create such transactions. And the coins mined in the fork are practically worthless because only a handful of people can actually use them.

 

[freetrader]

This thread was not intended to discuss the BTCfork (minority fork client) situation.
The hypothetical situation under discussion here is a majority BU fork.

I question whether it would be the case that 99% of the users would be unable to create such transactions, if e.g. the capability were built into the BU Qt client.
Bearing in mind that once the fork has occurred, many who run BU-incompatible software would become aware pretty fast that they are now on a minority chain and may have to undertake some decision whether to switch to some BU-compatible client or face being stuck on the 1MB chain.

Poor transactional performance on their chain would be one indicator, a possible HF announcement from their software provider would be another...

 

[painlord2k]

The majority fork developers should not introduce a different tx format to protect the minority and accommodate its needs. It is not their job or mission.

The minority has its own developers (and they claim to be the best of the best of the world) and their job and mission is to protect their own users and accommodate their needs.