rizzlarolla,
"Replay attack" prevention means that a user is able to choose which branch their transaction occurs on. The current BIP148 assumes that there would be no interest to transact on the branch that it orphans. In my opinion that is reckless. Below is my proposal on how to once and for all implement replay attack prevention. It should make forks cleanly separate money supplies. Whether people choose to use a branch is a completely different question.
Draft BIP: 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.
Neither of the groups want to 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. In the long term future, if there are multiple actively mined Bitcoin Branches, node and wallet software could potentially maintain many different Branches.
At first one might be concerned about spam consuming the Policy ID numberspace. But I'm pretty sure that a Policy ID can be reclaimed in the future if there is no active miner/branch using it... users won't be concerned if their transaction gets spent on an inactive branch.
Cheers,
Praxeology Guy
