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 reall
> On Jun 30, 2021, at 05:45, Zac Greenwood wrote:
>
>
> Eric,
>
> > A million nodes saying a transaction is invalid does nothing to enforce
> > that knowledge
>
> It does. Nodes disregard invalid transactions and invalid blocks as if they
> never existed. It is not possible for any party
Eric,
> A million nodes saying a transaction is invalid does nothing to enforce
that knowledge
It does. Nodes disregard invalid transactions and invalid blocks as if they
never existed. It is not possible for any party to transact bitcoin in a
way that violates the set of rules enforced by the ne
t; that’s all.
>
>
>
>
>
> > According to my understanding, miners follow the consensus rules enforced
> > by full nodes and get (subsidy + fees) for their work.
>
>
>
>
>
> Miners mine a chain, which ever one they want. There are many. They e
There are many. They earn
> the block reward.
>
>
>
> > Signaling is not voting although lot of people consider it voting
> including some mining pools and exchanges.
>
>
>
> What people consider it is inconsequential. It has clearly defined
> behavior.
>
&
A million nodes saying a transaction is invalid does nothing to enforce that
knowledge.
An economic node is a person who refuses to accept invalid money. A node only
informs this decision, it cannot enforce it. That’s up to people.
And clearly if one is not actually accepting bitcoin for anythi
> 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 co
"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 60%
What people consider it is inconsequential. It has clearly defined behavior.
e
From: Prayank
Sent: Sunday, June 27, 2021 5:01 AM
To: e...@voskuil.org
Cc: Bitcoin Dev
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork
Hello Eric,
I have few questions:
> Wi
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 spli
> 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
soft
@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 fo
> 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.
Any
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 wor
At least we are now acknowledging that splitting is what it’s about. That’s
progress.
e
> On Jun 29, 2021, at 01:32, Jorge Timón wrote:
>
>
> I think the option of "permanent failure because miners veto" should actually
> be abandoned.
> No, I don't think we should avoid splits when possib
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.
>
> Abs
@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 estimate
Hello Eric,
I have few questions:
> Without majority hash power support, activation simply means you are off on a
>chain split.
So majority hash power not following the consensus rules can result in chain
split? Why would majority of miners decide to mine a chain that nobody wants to
use? Wha
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 t
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 o
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 t
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 splitting
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 signa
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 releas
27 matches
Mail list logo
