Topic: [bitcoin-dev] I do not support the BIP 148 UASF (Read 3533 times)

Gregory Maxwell,

Sorry for my outburst.  I read between the lines, interpreting your message in the most negative light.  Then I implied you meant something that you didn't say.

I do appreciate your patience, wisdom, and insights.  I can be a hot head sometimes, wanting to make changes happen before everything is ready.

Sincerely,
Praxeology Guy

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://bitcointalksearch.org/topic/fundamentalist-long-positioned-money-investment-1873155

=== 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

Good points, where?

All it say's to me,
"I do not care what the majority wants. "
"I want SegWit."
"I just want replay attack prevention."
(to protect his minority hash chain from ruin!)

This is a well written response that makes some good points.

All of your arguments are in the context of segwit = majority.  Because non segwit minority build on top of the longest chain, there is no longer an issue of different spent/unspent TXO.
But if segwit is the minority and non-segwit is the majority, it is different, hence my original point in this thread.

Yes, I agree. What are you trying to argue?

Non segwit minority miners must still build on top of the longest chain that the rest of the network considers valid.   Do you agree or disagree?

Their blocks only get rejected if and only if they include a segwit transaction, but they also consider segwit transactions to be non-standard so they won't include such transactions thus their blocks won't be rejected.

You're not making sense.  If blocks are rejected (per bitcoincore.org) then either they get orphaned, or there's a split.

No, unmodified non-segwit miners will be producing valid blocks and their blocks will still be accepted. Segwit transactions are considered by non-segwit nodes as being non-standard. An unmodified non-segwit miner means that they have not changed any of the local node policy rules, which include the standardness rules. As long as they are following the standardness rules, they will not be mining segwit transactions and thus their blocks will not be invalid. These miners will not have their blocks orphaned unless they mine a segwit transaction, but that will only happen if they modify their standardness rules.

I am aware that are no actual balances.  I was abstracting this out of the conversation just like a wallet
can calculate a balance to display to the user. The point is still valid:  Non-segwit chain vs segwit chain
can show different "balances" on an address, or spent/unspent outputs if you want to be more precise.


Yes, because "blocks that you consider to be valid but which every segwit-enforcing node rejects"
will be orphaned as the longest chain prevails. 



You chopped the part of my quote where I said "to avoid a network split".  I understand the distinction you make, but many non technical people may not.  If all the 'economic users' loved Segwit but a majority group of miners refused to go along with them, there would be a split.

I was under the impression that the concept of standard vs non-standard transaction was a matter of local policy, to - among other things - simplify softfork upgrades.

Every miner is still free to accept any non-standard transactions, and can safely accept and include them as a service for example to collect higher fees.

Do I understand that you consider rejecting non-standard transactions a requirement for compliance?

Tomas
Bitcrust

This is a profound misunderstanding of how Bitcoin works, there are no 'balances' in the system.

And unmodified non-segwit miners will not initiate a split under any condition.

No, that is one sufficient condition, it can instead include basically all of the users (in particular, economically significant users). Either are sufficient alone.  The users define what are the miners and if the user define mining to include segwit, it does... from their perspective it is impossible to violate the rules, and any miner that tries just stops existing-- just as litecoin miners do not exist as far as Bitcoin users (and their nodes) are concerned today.

jonald_fyookball,


I don't know how you can go and call me "misinformed" when you fail to read my post.  bitcoincore.org is not divine truth.  I came up with a solution that they didn't consider.

Sorry for my frustration with you.  Have a nice day.

cryptoanarchist,

Each Bitcoin Node has a Policy chosen by its operator.  Anybody can produce block candidates that conform to a node's policy.  A node will look for the chain of blocks with the greatest PoW THAT MEETS ITS POLICY.  Differences in node policy can result in chain splits.  There is nothing stopping long lasting chain splits, where each is its own separate money supply/ledger.

In fact, alt coins can be considered Bitcoin nodes that adopted a different Policy, who forked at or before the Bitcoin genesis block.

Miners are motivated to increase their mining work on a coin until the following equation equalizes:

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

So as long as a branch's coins are worth something to somebody... they will be mined.

Cheers,
Praxeology Guy

You are misinformed.

Even with majority hashpower behind segwit, a non segwit miner cannot verify segwit blocks.

From bitcoincore.org:


The implicit assumption here is that the minority non-segwit miner will rejoin the main chain and not split off.  If the segwit chain is the minority hashpower chain, they will either have to abandon segwit, or split off.

Segwit transaction types are meant to be backwards compatible, so the first block will validate, but later on, the outputs and inputs will be different.  As soon as a transaction is sent from an address with an insufficient balance, that's when the split will occur.

People clamoring for UASF don't understand how PoW works.

jonald_fyookball,

Above in my reply I propose a way that non-upgrading miners could continue to mine non-segwit blocks while still verifying SegWit blocks, which would avoid a chain split.  You claimed that such was not possible, I showed how it was possible.

=============

The One,

Policy: Rules that a node performs on block candidates in order to decide whether a block should be accepted into their block "tree", and then more rules that decide which branch tip describes the current ledger.

Soft Fork: A change to policy that is more constraining.

The purpose of BIP9 is to activate a Soft Fork that almost every miner wants without risk of a chain split (fork).  If a significant portion of miners (maybe 5% or more) do not want the policy change, then BIP9 fails.  Then we decide if we want to propose something new, or if we should cause a fork (via user activated policy change).

The next step is to User Activated Soft Fork.  I'm not too particular on which method is used to get SegWit activated.  Whatever (reasonable) option BitFury goes with, I'm in.

Cheers,
Praxeology Guy

Then what?

Sorry I don't follow you.  Filtering the blocks doesn't prevent the fork at all if other miners support Segwit.

jonald_fyookball,

Potentially the non-SegWit supporting miners could filter their blocks with a SegWit node... if they actually wanted to avoid a fork.  Its really hard to say what Bitcoin Unlimited signalling miners would do after SegWit validation rules were activated.