Draft BUIP: Use Policy ID for Clean Forking

[praxeology]

Draft BUIP: Use Policy ID for Clean Forking

=== In Short ===

Create a "Policy ID" that nodes can use to identify desirable peers, blocks, and which transactions belong in a particular Bitcoin blocktree (blockchain-no-more) Branch.

=== Rational ===

Users want Bitcoin to be able to handle two different use cases. One (Core) is to be able to inexpensively operate a fully verifying node. The other (Unlimited) is to have more expensive operation, in order to support more usage.

Both of them should exist. Neither of the groups should compromise. The money capitalization of both systems would likely be greater in total if there was a fork rather than continuing together in a stalemate. See my analysis of competing money here: https://bitcointalk.org/index.php?topic=1873155.0

=== Details ===

1. Create a new kind of identifier... a "Policy ID". This ID is metadata used by a node and wallets to distinguish which Policy they are interested in, which Policy a Block conforms to, and which Branch a transaction is for. The transaction's target Policy may or may not have actually created a fork yet in the Bitcoin blockchain (or blocktree ).

2. The Policy ID need not be included in the Block header nor coinbase. It can be transmitted as metadata, and the node can verify for itself whether the Block conforms to the Policy ID.

3. The Policy ID should be used in a transaction in a virtual field that is visible to the signing script, but is not visible to the algorithm that generates the transaction's ID. The ID would need to be transmitted in the metadata when relaying an unconfirmed transaction, or when relaying a transaction included in a block... similar to how SegWit witness data is transmitted.

4. In Validation, a node will require that each transaction in a Block has the same Policy ID as the Policy ID of the Branch that the node is currently working on. There is a potential that a Node may maintain multiple Branches. The Policy ID doesn't need to be part of the Block Header, it can just be metadata that is transmitted with the Block ID and/or Block Header.

5. Policy ID should probably be a variable byte length non-negative integer when serialized with a transaction in the block and fed into the signature. I'm not sold on any particular technique for compressing the Policy ID for various purposes. Maybe when signing it and transmitting it with a transaction, its first 4 bits should encode the smallest byte length that can hold it, then the remaining bits be the actual Policy ID.

Discussion: Nodes can then find other nodes that are interested in the same Policy ID(s). Wallets can generate transactions that can only be spent on the user's desired Branch. Nodes and wallets could potentially maintain many different Branches.

======

If you guys don't want the "SegWit" merkle root in the coinbase, you could hard fork move it into the block header like this:

[Header tx root]
/ \
[tx merkle root] [extension root]

[extension root]
/ / \
[full witness+PolicyID tx merkle root], [merkle nonce], [other extensions...]

Sorry I'm not familiar with your Flexible Transactions alternative to SegWit. Not sure if it allows for the pruning of witness data like SegWit does. The above proposal makes the Policy ID prune-able too.

 

[AdrianX]

Users want Bitcoin to be able to handle two different use cases. One (Core) is to be able to inexpensively operate a fully verifying node.

I'm not sure this is the reason a hard fork is being blockaded is it?

The first problem I see is the network is more valuable as a single network, not a split network. Miners are incentivized to stay with the majority of hash power as that is where the majority of users get security, and they get the best return on investment.

I am not convinced a fork can actually happen before the majority of hash power was intending to abandon the existing transaction limit rule. Once it did, the minority of the hash power would be insecure and slow, they would follow the majority out of financial incentives to maximize return on investment.

That action would be prudent as the minority would be vulnerable to attack. So it appears to me that the default incentive is to keep the network as one.

I think there is some merit in the idea and don't want to dismiss it but what do you say to my observations above?

 

[praxeology]

AdrianX,

Yes, that is THE reason why Core does not want larger blocks. They are concerned that even with SegWit's effective 2MB block size increase, that the costs of network usage will go up too much and too many full nodes will drop out. This is especially the case for DSL users who have very limited upload bandwidth.

=== Miner incentives ===

Here is the equation that miners are interested in:

Energy Cost + Capital Rent + Labor ~= block bonus + transaction fees

Capital Rent: If the mining equipment, land, building, etc were rented out, cost/time
Labor: The operation workers want to get paid for their labor maintaining the equipment!

Miners put more and more capital, energy, and labor into building blocks for a coin, until the equation balances... then they are no longer motivated to increase their work. Changes in the coin's value or the reward impacts how much work is put towards mining the coin.

So as you can see, if the "block bonus" and the "transaction fees", the block reward... are worth something in the market... then miners will come and mine blocks for it. Miners don't really care about what coin has the most mining hash power. They just look for the coin where their equipment can make them the most money.

Litecoin and Etherium are still around, they are like Bitcoin forks that started with a different genesis block and policy. People still mine on them.

=== 51% attack ===

51% attack is nothing new. Its a costly one that can be investigated and result in bad PR. Its just a short term DoS annoyance for people who want their transactions confirmed... and doesn't really make sense for double spending. If it comes down to it, one would need to change the PoW algorithm.

Its probably only really worthwhile for something like the US Federal Government or The People's Republic Of China's Government to do a 51% attack. If they start attacking Bitcoin in such a way... its gong to be hard, maybe Bitcoin will end up only being a cyber punk money... until maybe in the future if government becomes less powerful.

I doubt that Unlimited people have to worry about Core miners doing such to them... probably more the other way around. I don't really understand the anger between the two groups. I guess its the fear of what could happen after a fork?

=== Motivation to Fork ===

If your money can offer a better money transfer efficiency for a use case, then people will use it. Build it and they will come. Forking Bitcoin is not a crime. The Bitcoin blockchain is in the public domain, anyone can use it for their own purpose.

The problem with keeping one branch is that either one, the other, or both group's goals must be compromised. But compromising isn't necessary, we can just fork.