UASF by OP_RETURN flag

[mda]

As in the subject.

[1715688226]

1715688226

[1715688226]

1715688226

[1715688226]

1715688226

[1715688226]

1715688226

[1715688226]

1715688226

[1715688226]

1715688226

[achow101]

What is your question? Or are you proposing something? You need to provide more details than just a sentence fragment.

[mda]

I guess so. Make an announcement that 01 in OP_RETURN field is a vote for SegWit and 02 -  for Bitcoin Unlimited. Then aggregate fees for each option over a period of time.

[achow101]

I guess so. Make an announcement that 01 in OP_RETURN field is a vote for SegWit and 02 -  for Bitcoin Unlimited. Then aggregate fees for each option over a period of time.

And how is this any better than the current system? The current system with BIP 9 for signalling for segwit and the use of the coimbase for BU are clear enough signals for block support of a proposal. There is no need for yet another way to signal support for a proposal, especially one that takes up more space by needing another output in the coinbase.

Also, in what way is this a UASF? Users have no access to what goes into a block for signalling.

[mda]

And how is this any better than the current system?

Currently miners decide the future of bitcoin but they don't bring value in and don't have long term attachment to it, so the model is skewed.

especially one that takes up more space by needing another output in the coinbase.

You can't get something for nothing. 3 more bytes per transaction for a while seems a reasonable price to solve this deadlock.

Also, in what way is this a UASF?

I'll leave the decision if this is UASF to people versed in definitions better than me.

Users have no access to what goes into a block for signalling.

Yes but they have access to what goes into transaction. And one of the most important things are their fees.

[achow101]

This is why you need to actually provide details as to what you are proposing. It is not immediately clear to me (and probably other readers too) that you are talking about putting an OP_RETURN output in transactions that people make. Nowhere do you mention that, or any other details about your proposal. If you want to actually be taken seriously, you will need to follow the BIP process and actually detail out and specify the specifics of your proposal instead of making short few word or few sentence posts about what you want to do.

You need to provide more details. Is the OP_RETURN to signal for activation or to simply show support? Is it a vote? Does it require humans to actually intervene and enable a proposal?

Your idea can be easily gamed. It is fairly trivial for people to make transactions and to essentially spam up blocks full of transactions supporting one proposal over another. Each person can make more than one transaction, so this is not really a good indicator of what user support is.

[mda]

It is not immediately clear to me (and probably other readers too) that you are talking about putting an OP_RETURN output in transactions that people make.

I am sorry for that of course, however one can't put OP_RETURN anywhere else except in transactions.

Your idea can be easily gamed. It is fairly trivial for people to make transactions and to essentially spam up blocks full of transactions supporting one proposal over another. Each person can make more than one transaction, so this is not really a good indicator of what user support is.

Nope, if the period is long enough one can't game the whole world on fees amount.
You may disagree with me together with another bitcoin founder that this proposal will lead to 'mob rule'.
However in this case you will need to deal with your fear of the user base and not with the lack of technical solutions.

[achow101]

I am sorry for that of course, however one can't put OP_RETURN anywhere else except in transactions.

I had assumed you were talking about the coinbase transaction, not regular transactions.

Nope, if the period is long enough one can't game the whole world on fees amount.

How long of a period are you proposing? Currently transaction fees make up between 1 and 2 BTC per block. One transaction every couple blocks which pays a large transaction fee (like something bigger than say 0.5 BTC) would be able to make the aggregate fees for one proposal grow larger than the other. There are certainly people who make enough money and have enough Bitcoin in storage who can sustain doing that.

[mda]

How long of a period are you proposing?

The length doesn't really matter, there could be occasional misfires and re-votes. However long term it's impossible to gather enough money and media to outsmart the whole world.

[stdset]

Miners can create high fee transactions voting for their favourite proposal and mine them without broadcasting, thus voting for free.

[mda]

Miners can create high fee transactions voting for their favourite proposal and mine them without broadcasting, thus voting for free.

You mean they vote and then distribute the fees back between themselves? Then a mechanism to route fees to miners is needed, like encrypting parts of transaction with specific miners' public keys.

[stdset]

Miners can create high fee transactions voting for their favourite proposal and mine them without broadcasting, thus voting for free.

You mean they vote and then distribute the fees back between themselves? Then a mechanism to route fees to miners is needed, like encrypting parts of transaction with specific miners' public keys.

Not between. Miner A creates a high fee tx voting in favour of his preferred proposal, doesn't broadcast it, mines a block with this tx, takes the fee, thus paying to himself, thus voting for free, thus abusing this voting system.

[0xfff]

Miners can create high fee transactions voting for their favourite proposal and mine them without broadcasting, thus voting for free.

You mean they vote and then distribute the fees back between themselves? Then a mechanism to route fees to miners is needed, like encrypting parts of transaction with specific miners' public keys.

Not between. Miner A creates a high fee tx voting in favour of his preferred proposal, doesn't broadcast it, mines a block with this tx, takes the fee, thus paying to himself, thus voting for free, thus abusing this voting system.

Yes  I agree. This idea would not work. It would not end in a fair voting system.

[mda]

What about this, don't count any fees, just declare invalid any block in which OP_RETURN and BIP 9 (user's and miner's) flags are different?

[stdset]

What about this, don't count any fees, just declare invalid any block in which OP_RETURN and BIP 9 (user's and miner's) flags are different?

I don't see obvious holes/abuses with this approach.
However, it would only incentivize miners to change their BIP 9 flags when proportion of blocks signalling certain flag is significantly less than proportion of transactions demanding that flag. For example, miners would be incentivized to signal BIP_N if 70% of txes demand BIP_N, but only 30% of blocks signal it. Now if 90% of hashpower started to signal BIP_N, but 30% of txes demand BIP_M, miners will be incentivized to switch signalling to BIP_M, until more or less ratio BIP_N_blocks/BIP_M_blocks = BIP_N_txes/BIP_M_txes.
Also, this approach wouldn't work without majority of users actively expressing their preference through their transactions, despite sometimes having to pay higher fees and experiencing additional delays in confirmation times. I guess majority of users would continue generating transactions of default type, because they care more about fees and confirmation time than about something they have only vague idea about. So most of time we probably will be having like 90% default txes, 7% BIP_N txes, 3% BIP_M txes, what doesn't create any incentives to change signalling at all.
Nonetheless, in my opinion the idea is interesting.