It feels like this discussion has gotten a bit off topic. The proposal is
intended to provide a best-of-both-worlds middleground between BIP8 and
BIP9. It would be nice if we could bring it back to a discussion of my
proposal in the context of other existing deployment plans (BIP8, BIP9,
taproot's
@Jorge
> I disagree... I would oppose such a change no matter what other users or
miners say.
I don't know why you think we disagree on that point. I agree that I would
oppose a change to 1GB blocks no matter what other users or miners say. You
must have misunderstood me there.
>> Are you
> From: Jorge Timón
>> "Soft forks aren’t compatible without miner enforcement"
> Compatible with what?
There is a good summary of what is meant by this term in BIP141:
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
"Backward compatibility
As a soft fork, older software will
"Softforks arentcompatible without miner enforcement"
Compatible with what?
"Softforks without miner support cause splits".
No, what causes splits are 3 things:
1) bugs
2) coordination mistakes
3) people wanting different rules.
Let me give an example. Let's say all users want change A.
Only
2021 7:03 PM
To: Eric Voskuil
Cc: Jorge Timón ; Luke Dashjr ; Bitcoin
Protocol Discussion
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
@Jorge
>I don't think we should avoid splits at all costs.
I absolutely agree that we shouldn't avoid splits
> Majority hash power does have the ability to determine what gets
confirmed.
Miners don’t have the ability to decide whether a block is valid.
Hash power is only recognized as such if it is used for creating a valid
block, i.e., a block that strictly follows all the rules as set by the node
@Jorge
>I don't think we should avoid splits at all costs.
I absolutely agree that we shouldn't avoid splits at all costs. There are
some costs too high to pay to avoid a split. If an economic majority
started wanting to increase bitcoin's blocksize to 1 GB next year, we
should absolutely hard
> On Jun 29, 2021, at 12:28, Jorge Timón wrote:
>
>
> "Confirmation" isn't needed for softforks.
All transactions require confirmation. Splitting does not change this.
Softforks are not compatible without miner enforcement. So soft forking without
it has essentially the same effect as hard
"Confirmation" isn't needed for softforks. Miners controlling confirmation
doesn't mean miners control the rules, they never did. Read section 11 of
the bitcoin paper "even with a majority of hashrate one cannot arbitrarily
change rules or forge signatures.
You may say users chosing the rules is
> On Jun 29, 2021, at 10:55, Luke Dashjr wrote:
>
> The only alternative to a split in the problematic scenarios are 1) concede
> centralised miner control over the network,
Miners control confirmation, entirely.
This is the nature of bitcoin. And merchants control validation, entirely.
The only alternative to a split in the problematic scenarios are 1) concede
centralised miner control over the network, and 2) have inconsistent
enforcement of rules by users who don't agree on what the correct rules are,
again leading to centralised miner control over the network.
In other
I think the option of "permanent failure because miners veto" should
actually be abandoned.
No, I don't think we should avoid splits when possible, I don't think we
should avoid splits at all costs.
On Sun, Jun 27, 2021, 19:12 Billy Tetrud wrote:
> @Luke
> > They can still slow it down.
>
>
@Luke
> They can still slow it down.
Absolutely. However I think that the option of permanent failure is
important. It certainly would be ideal to ensure that enough bitcoin users
support the upgrade *before* releasing it, however realistically this can
never be more than an estimate, and
I have not objected to anyone splitting. As I said, a split is always possible,
and of course has been done on a large scale. It is only the misleading
statements about inherent soft fork “compatibility” and the implication that
activation without hash power enforcement does not create a split
If different users want different incompatible things (enough on each
side), there's no way to avoid the split. We shouldn't try to avoid
such a split.
Users decide the rules, not miners nor developers.
On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
wrote:
>
> Ultimately there is
Ultimately there is only one answer to this question. Get majority hash power
support.
Soft fork enforcement is the same act as any other censorship enforcement, the
difference is only a question of what people want. Given that there is no
collective “we”, those wants differ. Bitcoin resolves
For some definitions of “block”.
Without majority hash power support, activation simply means you are off on a
chain split. Anyone can of course split off from a chain by changing a rule
(soft or otherwise) at any time, so this is a bit of an empty claim.
Nobody can stop a person from
BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They can
still slow it down.
It also already has the trinary state you seem to be describing (although
perhaps this could be better documented in the BIP): users who oppose the
softfork can and should treat the successful
Given the recent controversy over upgrade mechanisms for the
non-controversial taproot upgrade, I have been thinking about ways to solve
the problems that both sides brought up. In short, BIP8 LOT=true proponents
make the point that lazy miners failing to upgrade in a timely manner slow
down
19 matches
Mail list logo
