Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Billy Tetrud via bitcoin-dev]

@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 fork away from that mess with a minority chain.

>  I don't think we should avoid splits when possible,

I want to see why exactly we disagree about avoiding chain splits "when
possible". Are you really saying that we should just hard fork every time
instead of soft fork? Should we even bother to get widespread buy in at
all, or should we just release the software, hardfork away, and let anyone
that wants to follow us follow us later? Are you not at all worried about
the costs associated with an increased orphan rate and reorg rate? Are you
not worried that an update might happen too fast and that a significant
fraction of people that could have come along with us to the new update
might be left behind because they didn't have time to evaluate the
changed rules?

Do you agree that, in a conversation about rule changes, some people want
it their way no matter what and will hardfork to get the rules they want,
and some people want it their way, but only if enough other people agree to
follow those rules too? Some people might want a rule change, but aren't
willing to follow, say, a 20% minority fork. Perhaps their personal cut-off
is 40% or 50% or 75% or 90%. Do you agree those people exist?

If you do, then I don't understand why you disagree that we should avoid
chain splits even "when possible". Maybe you could elaborate as to what you
mean there.

@Luke

Are you in agreement with Jorge here that we should not even attempt to
avoid chain splits?

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

There is not simply a binary "do or do not". There is also timing.
Non-contentious changes can happen fast. Contentious changes need more time
for discussion, preparation, or coordination, even if the eventual outcome
is the same. Do you disagree that timing issues can be
important, that delays can be useful and help to avoid chain splits? Do you
agree that miners have a (large) incentive to follow the economic majority?
Is the goal here to do what the economic majority wants, or some other
group? If so, do you think we have an accurate way of measuring what the
economic majority wants? Will that mechanism continue to be accurate into
the future?

I'm asking these questions to try and figure out why we disagree here.

On Tue, Jun 29, 2021 at 12:44 PM Eric Voskuil  wrote:

>
> 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 forking, the chain
> splits.
>
> Miners controlling confirmation doesn't mean miners control the rules,
> they never did.
>
>
> Please define “control” because these statements hinge on that word.
> Nobody “controls” the rules of others, nor did anyone claim that to be the
> case. Majority hash power does have the ability to determine what gets
> confirmed. That is the central design principle of proof of work. It takes
> that decision out of the hands of politicians and places it at the feet of
> the market.
>
> Read section 11 of the bitcoin paper "even with a majority of hashrate one
> cannot arbitrarily change rules or forge signatures.
>
>
> Never claimed that was the case. One can run any rules that one desires.
>
> You may say users chosing the rules is "politicial". Isn't miners deciding
> them for users more political?
>
>
> No, it’s economic. The largest investment in mining (including highest
> fees paid to incentivize it) determines censorship resistance.
>
> Whatever you call it, it is still how free software works: users decide
> what to run.
>
>
> A *person* can run whatever software they want. Money requires that others
> agree (same rules), and to be money bitcoin requires confirmation.
>
> It is extremely disappointing to see how few developers seem to ubderstand
> this, or even care about users deciding or miners not deciding the rules.
>
>
> It’s poorly understood because there are so many who should know better
> making very misleading statements.
>
> How can we expect users to understand bitcoin when most developers don't
> seem to understand it?
>
>
> Clearly we cannot.
>
> It is really sad.
>
> On Tue, Jun 29, 2021, 19:17 Eric Voskuil  wrote:
>
>>
>> > On Jun 29, 2021, at 10:55, Luke Dashjr  wrote:
>> >
>> > The only alternative to a split in the problematic scenarios are 1)
>> concede
>> > centra

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Zac Greenwood via bitcoin-dev]

> 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
software that transacting users choose to run.

If suddenly 70% of all hash power decided to start mining blocks that are
invalid according to the rules set in the users’ software, then these
invalid blocks will be disregarded. From a user perspective, 70% of all
hash power will seem to have disappeared.

In short, users define what is Bitcoin, not miners. This is fundamental to
being decentralized.



On Tue, 29 Jun 2021 at 23:17, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> 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 forking, the chain
> splits.
>
> Miners controlling confirmation doesn't mean miners control the rules,
> they never did.
>
>
> Please define “control” because these statements hinge on that word.
> Nobody “controls” the rules of others, nor did anyone claim that to be the
> case. Majority hash power does have the ability to determine what gets
> confirmed. That is the central design principle of proof of work. It takes
> that decision out of the hands of politicians and places it at the feet of
> the market.
>
> Read section 11 of the bitcoin paper "even with a majority of hashrate one
> cannot arbitrarily change rules or forge signatures.
>
>
> Never claimed that was the case. One can run any rules that one desires.
>
> You may say users chosing the rules is "politicial". Isn't miners deciding
> them for users more political?
>
>
> No, it’s economic. The largest investment in mining (including highest
> fees paid to incentivize it) determines censorship resistance.
>
> Whatever you call it, it is still how free software works: users decide
> what to run.
>
>
> A *person* can run whatever software they want. Money requires that others
> agree (same rules), and to be money bitcoin requires confirmation.
>
> It is extremely disappointing to see how few developers seem to ubderstand
> this, or even care about users deciding or miners not deciding the rules.
>
>
> It’s poorly understood because there are so many who should know better
> making very misleading statements.
>
> How can we expect users to understand bitcoin when most developers don't
> seem to understand it?
>
>
> Clearly we cannot.
>
> It is really sad.
>
> On Tue, Jun 29, 2021, 19:17 Eric Voskuil  wrote:
>
>>
>> > 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. Anyone can be a miner or a merchant. Neither is inherently
>> “better” than the other. The largest merchants are likely a handful of
>> exchanges, likely at least as centralized as miners are pooled.
>>
>> Splitting does not change this.
>>
>> > and 2) have inconsistent
>> > enforcement of rules by users who don't agree on what the correct rules
>> are,
>>
>> There are no “correct” rules. Whatever rules one enforces determine what
>> network he chooses to participate in.
>>
>> > again leading to centralised miner control over the network.
>>
>> Leading to? Miners control confirmation, always. Whether that is
>> centralized, just as with merchanting, is up to individuals.
>>
>> > In other words, in this context, accepting a split between disagreeing
>> users
>> > is the ONLY way Bitcoin can possibly continue as a decentralised
>> currency.
>>
>> No, it is not. You are proposing splitting as the method of censorship
>> resistance inherent to Bitcoin. Coordinating this split requires
>> coordinated action. The whole point of bitcoin is coordinate that action
>> based on mining (proof of work). Replacing that with a political process is
>> just a reversion to political money.
>>
>> > Making that split as clean and well-defined as possible not only
>> ensures the
>> > best opportunity for both sides of the disagreement,
>>
>> Trivially accomplished, just change a rule. This isn’t about that. It’s
>> about how one gets others to go along with the new coin, or stay with the
>> old. An entirely political process, which is clearly evident from the
>> campaigns around such attempts.
>>
>> > but also minimises the
>> > risk that the split occurs at all (since the "losing" side needs to
>> concede,
>> > rather than passively continue the disagreement ongoing after the
>> attempted
>> > protocol change).
>>
>> Nobody “needs to” concede once a 

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

All good questions.

 

> Is the goal here to do what the economic majority wants, or some other group? 
> If so, do you think we have an accurate way of measuring what the economic 
> majority wants?

 

It’s important that people understand that “economic” does not refer to people 
interested in, HODLing, coding, or selling Bitcoin. It is only those who are 
*presently accepting* it. We refer to these as “economic nodes”. Those are the 
people with the economic power to reject coin that they consider invalid. Only 
their validation is of any economic consequence in the event of a split. I see 
no reason to assume that the economy is any less centralized than mining is 
pooled. Today the support of the economy would be best measured by meeting with 
exchange operators. If they did not go along, any unenforced soft fork (split) 
would isolate everyone who thought they could continue to trade their coin on 
exchanges.

 

I’d also question the use of the term “majority”. It applies to hash power, by 
design, but not to the economy. A split of any size is possible, requiring no 
majority. All it requires is other people to trade with.

 

Exchanges are highly regulated and compliant institutions. Mining operations 
are heavily pooled. Neither of these is inherently better than the other. 
Everyone can have a say by being a miner or being a merchant. Subeconomies can 
split, majority hash power can censor (which is the exact mechanism of soft 
fork enforcement). These ideas are straightforward and hardly worthy of debate. 
The interesting question is how one gets others to go along with his new coin. 
Make no mistake, any rule change (soft or hard) is a new coin. If hash power 
doesn’t enforce the new rules of a soft fork, the chain is split just as if it 
was a hard fork.

 

I’m sure people will continue to try and devise ways to figure out who wants to 
come along, to try and convince people (including exchanges and miners) to do 
so, to reassure them that everyone else will “have to”, and to mislead them 
about the actual behavior and risks. We’ve seen permanent splits, and we’ve 
seen hash power enforced soft forks. We’re likely to see more of both. But as 
core devs we have a responsibility to inform people, honestly, and let them 
decide. My only beef with this whole process has been that a widespread belief 
had formed, supported by far too many core devs (and even embedded in the text 
of deployed BIPs), that soft forks are inherently “backward compatible”. This 
is unequivocally not true. The only such compatibility is majority hash power 
enforcement of a soft fork. This is not a matter of opinion, it’s the core 
innovation of Bitcoin. Proof of Work settles the question of who has authority 
to order transactions. Majority hash power has that authority. Merchants can 
split again and again, but their miners will still have that authority. If one 
wants a say, one can mine.

 

e

 

From: Billy Tetrud  
Sent: Tuesday, June 29, 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 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 
fork away from that mess with a minority chain. 

 

>  I don't think we should avoid splits when possible, 

 

I want to see why exactly we disagree about avoiding chain splits "when 
possible". Are you really saying that we should just hard fork every time 
instead of soft fork? Should we even bother to get widespread buy in at all, or 
should we just release the software, hardfork away, and let anyone that wants 
to follow us follow us later? Are you not at all worried about the costs 
associated with an increased orphan rate and reorg rate? Are you not worried 
that an update might happen too fast and that a significant fraction of people 
that could have come along with us to the new update might be left behind 
because they didn't have time to evaluate the changed rules?

 

Do you agree that, in a conversation about rule changes, some people want it 
their way no matter what and will hardfork to get the rules they want, and some 
people want it their way, but only if enough other people agree to follow those 
rules too? Some people might want a rule change, but aren't willing to follow, 
say, a 20% minority fork. Perhaps their personal cut-off is 40% or 50% or 75% 
or 90%. Do you agree those people exist? 

 

If you do, then I don't understand why you disagree that we should avoid chain 
splits even "when possible". Maybe you could elaborate as to what you mean 
there. 

 

@Luke

 

Are you in agreement with Jorge here that we should not even attempt to avoid 
chain splits? 

 

> The only alterna

Re: [bitcoin-dev] Trinary Version Signaling for softfork

[Eric Voskuil via bitcoin-dev]

Hi Prayank,

 

> So majority hash power not following the consensus rules can result in chain 
> split?

 

Any two people on different rules implies a chain split. That’s presumably why 
rule changes are called forks. There is no actual concept of “the rules” just 
one set of rules or another.

 

> Why would majority of miners decide to mine a chain that nobody wants to use?

 

I don’t presume to know why people prefer one thing over another, or what 
people want to use, nor does economics.

 

> What are different things possible in this case based on game theory?

 

I’ve seen no actual demonstration of the relevance of game theory to Bitcoin. 
People throw the words around quite a bit, but I can’t give you an answer 
because I have found no evidence of a valid game theoretic model applicable to 
Bitcoin. It’s not a game, it’s a market.

 

> Do miners and mining pools participate in discussions before signaling for a 
> soft fork begins?

 

Who knows, I don’t get invited to round table meetings.

 

> Can they still mine something else post activation even if signaling 
> readiness for soft fork? 

 

A person can mine whatever they want. Signaling does not compel a miner to 
enforce. Each block mined is anonymous. But each miner seeing the signals of 
others, unless they are coordinating, would presumably assume that others will 
enforce.

 

> Who enforces consensus rules technically in Bitcoin? Full nodes or Miners?

 

A node (software) doesn’t enforce anything. Merchants enforce consensus rules 
when they reject trading for something that they don’t consider money. Every 
time two people trade both party validates what they receive (not what they 
trade away). Those receiving Bitcoin are economically relevant and their power 
is a function of how much they are doing so.

 

Miners censor, which is inconsequential unless enforced. Majority miners can 
enforce censorship by simply not building on any non-censoring blocks. This is 
what soft fork enforcement is.

 

> Is soft fork signaling same as voting?

 

I don’t see that it needs a label apart from signaling. There are many kinds of 
voting. It would be hard to equate signaling with any of them. It’s a public 
signal that the miner who mined a given block miner intends to censor, 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 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.

 

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:

 

> 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? What are different things possible in this case based on game theory? 

 

> And activation without majority hash power certainly does not “ensure” this.

 

Do miners and mining pools participate in discussions before signaling for a 
soft fork begins? Can they still mine something else post activation even if 
signaling readiness for soft fork? 

 

> If one wants to enforce a soft fork (or otherwise censor) this is 
> accomplished by mining (or paying others to do so). Anyone can mine, so 
> everyone gets a say. Mining is trading capital now for more later. If enough 
> people want to do that, they can enforce a soft fork. It’s time Bitcoiners 
> stop thinking of miners as other people. Anyone can mine, and that’s your 
> vote.

 

Who enforces consensus rules technically in Bitcoin? Full nodes or Miners?

 

Is soft fork signaling same as voting?

 

According to my understanding, miners follow the consensus rules enforced by 
full nodes and get (subsidy + fees) for their work. Signaling is not voting 
although lot of people consider it voting including some mining pools and 
exchanges.

 

 

-- 

Prayank

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Jorge Timón via bitcoin-dev]

"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% miners want it.
When it activates with LOT=true, will this cause a split?

Well, not necessarily. Since all users will be on the chain with change A,
all miners will quickly abandon that useless chain and start building on
the one that actually pays them.

Do you agree that's what would happen in this example given the assumptions?


On Tue, Jun 29, 2021, 20:44 Eric Voskuil  wrote:

>
> 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 forking, the chain
> splits.
>
> Miners controlling confirmation doesn't mean miners control the rules,
> they never did.
>
>
> Please define “control” because these statements hinge on that word.
> Nobody “controls” the rules of others, nor did anyone claim that to be the
> case. Majority hash power does have the ability to determine what gets
> confirmed. That is the central design principle of proof of work. It takes
> that decision out of the hands of politicians and places it at the feet of
> the market.
>
> Read section 11 of the bitcoin paper "even with a majority of hashrate one
> cannot arbitrarily change rules or forge signatures.
>
>
> Never claimed that was the case. One can run any rules that one desires.
>
> You may say users chosing the rules is "politicial". Isn't miners deciding
> them for users more political?
>
>
> No, it’s economic. The largest investment in mining (including highest
> fees paid to incentivize it) determines censorship resistance.
>
> Whatever you call it, it is still how free software works: users decide
> what to run.
>
>
> A *person* can run whatever software they want. Money requires that others
> agree (same rules), and to be money bitcoin requires confirmation.
>
> It is extremely disappointing to see how few developers seem to ubderstand
> this, or even care about users deciding or miners not deciding the rules.
>
>
> It’s poorly understood because there are so many who should know better
> making very misleading statements.
>
> How can we expect users to understand bitcoin when most developers don't
> seem to understand it?
>
>
> Clearly we cannot.
>
> It is really sad.
>
> On Tue, Jun 29, 2021, 19:17 Eric Voskuil  wrote:
>
>>
>> > 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. Anyone can be a miner or a merchant. Neither is inherently
>> “better” than the other. The largest merchants are likely a handful of
>> exchanges, likely at least as centralized as miners are pooled.
>>
>> Splitting does not change this.
>>
>> > and 2) have inconsistent
>> > enforcement of rules by users who don't agree on what the correct rules
>> are,
>>
>> There are no “correct” rules. Whatever rules one enforces determine what
>> network he chooses to participate in.
>>
>> > again leading to centralised miner control over the network.
>>
>> Leading to? Miners control confirmation, always. Whether that is
>> centralized, just as with merchanting, is up to individuals.
>>
>> > In other words, in this context, accepting a split between disagreeing
>> users
>> > is the ONLY way Bitcoin can possibly continue as a decentralised
>> currency.
>>
>> No, it is not. You are proposing splitting as the method of censorship
>> resistance inherent to Bitcoin. Coordinating this split requires
>> coordinated action. The whole point of bitcoin is coordinate that action
>> based on mining (proof of work). Replacing that with a political process is
>> just a reversion to political money.
>>
>> > Making that split as clean and well-defined as possible not only
>> ensures the
>> > best opportunity for both sides of the disagreement,
>>
>> Trivially accomplished, just change a rule. This isn’t about that. It’s
>> about how one gets others to go along with the new coin, or stay with the
>> old. An entirely political process, which is clearly evident from the
>> campaigns around such attempts.
>>
>> > but also minimises the
>> > risk that the split occurs at all (since the "losing" side needs to
>> concede,
>> > rather than passively continue the disagreement ongoing after the
>> attempted
>> > protocol change).
>>
>> Nobody “needs to” concede once a split has occurred, which is evident in
>> existing splits.
>>
>> e
>>
>> > Luke
>> >
>> >
>> >> On Tuesday 29 June 2021 08

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Eric Voskuil via bitcoin-dev]

> 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 continue to operate without modification. 
Non-upgraded nodes, however, will not see nor validate the witness data and 
will consider all witness programs as anyone-can-spend scripts (except a few 
edge cases where the witness programs are equal to 0, which the script must 
fail). Wallets should always be wary of anyone-can-spend scripts and treat them 
with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order 
to take advantage of the new features."

The explanation is however incomplete. If majority hash power does not enforce 
the new rules, the above is incorrect. Granted the word "operate" is vague, but 
clearly what is intended is that "non-upgraded" nodes will not be on a 
different coin. But in fact they would be. The underlying presumption is that 
BIP141 is not only signaled, but enforced by majority hash power.

>> "Soft forks without miner support cause splits".
> No, what causes splits are 3 things:
>
> 1) bugs
> 2) coordination mistakes
> 3) people wanting different rules.

#3 (and possibly #4) is what we're talking about, so it's not at all clear why 
you said "no".

People change their rules, because #3. If majority hash power does not enforce 
this (soft) change, it's a chain split.

> Let me give an example. Let's say all users want change A.
>
> Only 60% miners want it.
> When it activates with LOT=true, will this cause a split?

No, regardless of percentage adoption. You've proposed that it' is majority 
hash power enforced.

Furthermore, the term compatibility (see above) implies that not everyone (your 
impossible presumption of 100%) is aligned.

This is not a debatable subject as far as I'm concerned, but it's worth 
discussion for those who aren't familiar.

e

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Derivation Paths for Single Key Taproot Scripts

[Pavol Rusnak via bitcoin-dev]

+1 from the author of BIP43, BIP44 and BIP84. The proposed BIP follows this
pattern nicely.

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
Co-founder and CTO, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork

[Eric Voskuil via bitcoin-dev]

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 anything at the time, 
he is not enforcing anything.

The idea of a non-economic node is well established, nothing new here.

e

> On Jun 30, 2021, at 04:33, Zac Greenwood  wrote:
> 
> 
> Hi Eric,
> 
> > A node (software) doesn’t enforce anything. Merchants enforce consensus 
> > rules
> 
> … by running a node which they believe to enforce the rules of Bitcoin.
> 
> A node definitely enforces consensus rules and defines what is Bitcoin. I am 
> quite disturbed that this is even being debated here.
> 
> Zac
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork

[Zac Greenwood via bitcoin-dev]

Hi Eric,

> A node (software) doesn’t enforce anything. Merchants enforce consensus
rules

… by running a node which they believe to enforce the rules of Bitcoin.

A node definitely enforces consensus rules and defines what is Bitcoin. I
am quite disturbed that this is even being debated here.

Zac


On Wed, 30 Jun 2021 at 11:17, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Prayank,
>
>
>
> > So majority hash power not following the consensus rules can result in
> chain split?
>
>
>
> Any two people on different rules implies a chain split. That’s presumably
> why rule changes are called forks. There is no actual concept of “the
> rules” just one set of rules or another.
>
>
>
> > Why would majority of miners decide to mine a chain that nobody wants to
> use?
>
>
>
> I don’t presume to know why people prefer one thing over another, or what
> people want to use, nor does economics.
>
>
>
> > What are different things possible in this case based on game theory?
>
>
>
> I’ve seen no actual demonstration of the relevance of game theory to
> Bitcoin. People throw the words around quite a bit, but I can’t give you an
> answer because I have found no evidence of a valid game theoretic model
> applicable to Bitcoin. It’s not a game, it’s a market.
>
>
>
> > Do miners and mining pools participate in discussions before signaling
> for a soft fork begins?
>
>
>
> Who knows, I don’t get invited to round table meetings.
>
>
>
> > Can they still mine something else post activation even if signaling
> readiness for soft fork?
>
>
>
> A person can mine whatever they want. Signaling does not compel a miner to
> enforce. Each block mined is anonymous. But each miner seeing the signals
> of others, unless they are coordinating, would presumably assume that
> others will enforce.
>
>
>
> > Who enforces consensus rules technically in Bitcoin? Full nodes or
> Miners?
>
>
>
> A node (software) doesn’t enforce anything. Merchants enforce consensus
> rules when they reject trading for something that they don’t consider
> money. Every time two people trade both party validates what they receive
> (not what they trade away). Those receiving Bitcoin are economically
> relevant and their power is a function of how much they are doing so.
>
>
>
> Miners censor, which is inconsequential unless enforced. Majority miners
> can enforce censorship by simply not building on any non-censoring blocks.
> This is what soft fork enforcement is.
>
>
>
> > Is soft fork signaling same as voting?
>
>
>
> I don’t see that it needs a label apart from signaling. There are many
> kinds of voting. It would be hard to equate signaling with any of them.
> It’s a public signal that the miner who mined a given block miner intends
> to censor, 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 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.
>
>
>
> 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:
>
>
>
> > 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? What are different things possible in this case based
> on game theory?
>
>
>
> > And activation without majority hash power certainly does not “ensure”
> this.
>
>
>
> Do miners and mining pools participate in discussions before signaling for
> a soft fork begins? Can they still mine something else post activation even
> if signaling readiness for soft fork?
>
>
>
> > If one wants to enforce a soft fork (or otherwise censor) this is
> accomplished by mining (or paying others to do so). Anyone can mine, so
> everyone gets a say. Mining is trading capital now for more later. If
> enough people want to do that, they can enforce a soft fork. It’s time
> Bitcoiners stop thinking of miners as other people. Anyone can mine, and
> that’s your vote.
>
>
>
> Who enforces consensus rules technically in Bitcoin? Full nodes or Miners?
>
>
>
> Is soft fork signaling same as voting?
>
>
>
> According to my understanding, miners follow the consensus rules enforced
> by full nodes and get (subsidy + fees) for their work. Signaling is not
> voting although lot of people consider it voting including some mining
> pools and exchanges.
>
>
>
>
>
> --
>
> Prayank
> ___
> bitcoin-dev mailing list
> bi

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[raymo via bitcoin-dev]

Dear ZmnSCPxj

Thanks for dedicating time to read carefully the Sabu proposal and many
thanks for your accurate point. So, lets fix it.

I didn’t suppose Alice has only one UTXO, instead I expect every issuer
use hundreds or even millions UTXOs (for optimal benefit each worth
exactly 40,000 Satoshi) in Sabu protocol in order to earn notable
Sabu-transactions-fees daily.

Your scenario is correct and Alice can send a batch transaction which
has higher feeRate, but less fee amount comparing total fees of N number
of GT transaction.
It is true, the batch transaction will win the race and will go to next
block instead of N small GT transactions.
But Alice herself is not the winner, since she paid a huge transaction
fee to miner, while in honest acting didn’t have to pay at all.
Let’s show it by numbers.

Imagine Alice convinced some people to pay her money and accept the MT
and GT transactions in exchange.
Alice issued N transactions and delivered to these guys.
Till now Alice got money equal to N * Maximum debt per transaction,
which is 20,000 N.

A single GT length = length of Critical part of GT (named C) + length of
Redundant part of GT (named R)

Coefficient of Honesty benefits (called H) = C/R
The bigger H means less Redundant part, means less benefit in batch
transaction.
The worst H would be 1 or less than 1. I can guess H in Bitcoin
transaction is 4 or higher, but for now we take it 4. Probably you can
help us and tell what H is exactly.

The N GTs length = N * (C + R)
One batch transaction length = (N * C) + R

The GT feeRate = GTfee / (C + R)
The batch transaction feeRate = batchFee / ((N * C) + R)

We need to batch transaction feeRate be higher than each single GT
feeRate (more or less the feeRate for all GTs are same).
Thus
batchFee / ((N * C) + R) must be bigger or at least equal to GTfee / (C
+ R)
so,
batchFee / ((N * C) + R) >= GTfee / (C + R)

we already knew H = C/R then C = HR

after simplifying

batchFee >= (GTfee * ((N * H) + 1)) / (H + 1)

So, this is the minimum fee that Alice has to pay for her batch
transaction in order to compete with GTs feeRate.

Let’s put the numbers
From my previous example for @Alex Schoof, we already knew that the
GTfee is 25,500 Satoshi
H is 4 (please let me know what is more realistic number)
I think N in max exploitation is 10,000. If Alice takes entire block
space, she won’t be able to put more than 10,000 inputs in a single
transaction in one block.

So,
batchFee must be higher than (25,500 * ((10,000 * 4) + 1)) / (4 + 1)
batchFee must be higher than 2.04 Bitcoins. While if Alice was acting
honestly, she had to pay zero BTC-transaction-fee, since the Sabu
transactions are aimed to be circulated in Sabu network forever.

But how much benefit Alice got? We already knew that Alice had fooled
Some people by 10,000 transactions and got 10,000 transaction * 20,000
Max debt per transaction. She got 2 Bitcoins.

After all, she lost 0.04 BTC. She definitely is a loser, unless she has
conspiracy with miners which is another scenario and I already explained
it.

Note these facts:
H is higher than 4.
It is impossible to fit a batch transaction with 10,000 inputs and one
output in one block.
And after all we can simply hedge batch transaction benefits by fine
tuning the “maximum allowed debt per transaction”.

Finally, the complementary protection to cover 0.01% remind risk of
issuer irrationality, would be the BIPxxx “for flagging/unflagging
promised UTXOs” which is my suggestion.
It will be good for Sabu.
It will be good for adapting wide range of innovative smart contracts on
top of current Bitcoin with no risk and cost.
@James Hilliard
If it implemented wisely, never won't affect on network stability.


> your analysis is based on assuming that miners are perfect rational beings of 
> perfect rationality,
> ***and*** are omniscient.
That’s not true! The proposal just assume miners are looking for more
profit.
The suggested BIPxxx “for flagging/unflagging promised UTXOs” (if
community accept it) would prepare a knowledge about promised UTXOs for
miner.


> Even if Alice is in possession of only a single UTXO, Alice can still feed 
> miners a transaction
> with lower feerate than the MT, then feed the rest of the network with a 
> valid MT.
It is not important in what order Alice propagate which (MT, or whatever
transaction) to Bitcoin network.
The point is, before putting this transaction in next block, the
creditor wallet will be aware of this renege and will send the GT to
network.
The rest is miner’s decision to put transaction with higher fee rate to
next block.


> This attack is essentially costless to Alice,
> especially for big enough transactions where mining fees are a negligible 
> part of the payment.
No, in Sabu we have not big payments. Each big payment must be managed
through N small transactions with each transaction max output less than
20,000 Satoshi.


Regards
Raymo




On 2021-06-29 21:42, ZmnSCPxj wrote:
> Good morning Raymo,
> 
>> Hey Alex,
>> 

Re: [bitcoin-dev] Trinary Version Signaling for softfork

[Prayank via bitcoin-dev]

> I’ve seen no actual demonstration of the relevance of game theory to Bitcoin. 
>People throw the words around quite a bit, but I can’t give you an answer 
>because I have found no evidence of a valid game theoretic model applicable to 
>Bitcoin. It’s not a game, it’s a market.

Agree its difficult to predict and include all the possible things that may 
happen. Two articles I had read in past that explained few things based on game 
theory:

https://jimmysong.medium.com/uasf-bip148-scenarios-and-game-theory-9530336d953e

https://jimmysong.medium.com/segwit2x-game-theory-scenarios-part-1-7f863904a72

> Who knows, I don’t get invited to round table meetings.

My question was related to discussions on mailing list, IRC channels, Reddit, 
Twitter, GitHub etc. Not sure if everyone does but few had no issues with 
Taproot before signaling according to 
https://web.archive.org/web/20210316221837/https://taprootactivation.com/

> Every time two people trade both party validates what they receive (not what 
>they trade away). Those receiving Bitcoin are economically relevant and their 
>power is a function of how much they are doing so.

Agree. Running and 'using' the node for economic activity can be considered 
enforcing consensus rules.

> Majority miners can enforce censorship by simply not building on any 
>non-censoring blocks. This is what soft fork enforcement is.

I am not sure about this. 

> I don’t see that it needs a label apart from signaling. There are many kinds 
>of voting. It would be hard to equate signaling with any of them. It’s a 
>public signal that the miner who mined a given block miner intends to censor, 
>that’s all.

Signaling can be done for many things. In this case I think miners are 
signaling 'readiness'.  Pieter Wuille had answered a related question on SE: 
https://bitcoin.stackexchange.com/questions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/

Since this is misunderstood or misinterpreted by many, I had even requested 
Hampus Sjöberg to mention this in https://taproot.watch/ : 
https://github.com/hsjoberg/fork-explorer/issues/57


-- 
 Prayank


Jun 30, 2021, 14:47 by e...@voskuil.org:

>
> Hi Prayank,
>
>
>  
>
>
> > So majority hash power not following the consensus rules can result in 
> > chain split?
>
>
>  
>
>
> Any two people on different rules implies a chain split. That’s presumably 
> why rule changes are called forks. There is no actual concept of “the rules” 
> just one set of rules or another.
>
>
>  
>
>
> > Why would majority of miners decide to mine a chain that nobody wants to 
> > use?
>
>
>  
>
>
> I don’t presume to know why people prefer one thing over another, or what 
> people want to use, nor does economics.
>
>
>  
>
>
> > What are different things possible in this case based on game theory?
>
>
>  
>
>
> I’ve seen no actual demonstration of the relevance of game theory to Bitcoin. 
> People throw the words around quite a bit, but I can’t give you an answer 
> because I have found no evidence of a valid game theoretic model applicable 
> to Bitcoin. It’s not a game, it’s a market.
>
>
>  
>
>
> > Do miners and mining pools participate in discussions before signaling for 
> > a soft fork begins?
>
>
>  
>
>
> Who knows, I don’t get invited to round table meetings.
>
>
>  
>
>
> > Can they still mine something else post activation even if signaling 
> > readiness for soft fork? 
>
>
>  
>
>
> A person can mine whatever they want. Signaling does not compel a miner to 
> enforce. Each block mined is anonymous. But each miner seeing the signals of 
> others, unless they are coordinating, would presumably assume that others 
> will enforce.
>
>
>  
>
>
> > Who enforces consensus rules technically in Bitcoin? Full nodes or Miners?
>
>
>  
>
>
> A node (software) doesn’t enforce anything. Merchants enforce consensus rules 
> when they reject trading for something that they don’t consider money. Every 
> time two people trade both party validates what they receive (not what they 
> trade away). Those receiving Bitcoin are economically relevant and their 
> power is a function of how much they are doing so.
>
>
>  
>
>
> Miners censor, which is inconsequential unless enforced. Majority miners can 
> enforce censorship by simply not building on any non-censoring blocks. This 
> is what soft fork enforcement is.
>
>
>  
>
>
> > Is soft fork signaling same as voting?
>
>
>  
>
>
> I don’t see that it needs a label apart from signaling. There are many kinds 
> of voting. It would be hard to equate signaling with any of them. It’s a 
> public signal that the miner who mined a given block miner intends to censor, 
> 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 earn the 
> block reward.
>
>
>  
>
>
> > Signaling is not voting although lot of people cons

Re: [bitcoin-dev] Trinary Version Signaling for softfork

[Zac Greenwood via bitcoin-dev]

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 network of
consensus-compatible nodes that we call Bitcoin.

Zac


On Wed, Jun 30, 2021 at 2:03 PM Eric Voskuil  wrote:

> 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 anything at the
> time, he is not enforcing anything.
>
> The idea of a non-economic node is well established, nothing new here.
>
> e
>
> On Jun 30, 2021, at 04:33, Zac Greenwood  wrote:
>
> 
> Hi Eric,
>
> > A node (software) doesn’t enforce anything. Merchants enforce consensus
> rules
>
> … by running a node which they believe to enforce the rules of Bitcoin.
>
> A node definitely enforces consensus rules and defines what is Bitcoin. I
> am quite disturbed that this is even being debated here.
>
> Zac
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

[Corey Haddad via bitcoin-dev]

We cannot prevent people from choosing to take an action based on an
unconfirmed transaction. Even though it is trivial to have a
double-spending transaction confirmed, accepting a 0-conf tx can be
rational in many cases.  0-conf can be interpreted as the customer
signaling their 'intent to pay', and where there is an established
relationship between customer and merchant, or where there merchant is
providing a cancelable e-service, signaling intent may be enough. These use
cases do not depend on making it difficult for the user to attempt to
double-spend the merchant.

Bitcoin is a system designed around a consensus on the blockchain, not the
mempool. I am in favor of providing the spender of bitcoins with all
possible tools and methods to help them submit their transactions -
double-spending or not - to miners for consideration. More than making RBF
the default, I would prefer to see nodes forward any transaction
conflicting transaction, so long as it has a higher fee. Is there a reason
this would be undesirable?

Corey

On Sat, Jun 26, 2021 at 3:00 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If the parties trust each other, rbf is still opt-in. Just don't do it?
>
> On Sat, Jun 26, 2021, 9:30 AM Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> >  services providers are offering zero-conf channels, where you can
>> start to spend instantly [0]. I believe that's an interesting usage
>>
>> I agree those are interesting and useful cases. I suppose I should
>> clarify that when I asked if bitcoin should continue supporting 0-conf
>> transactions, I meant: should we make design decisions based on whether it
>> makes raw 0-conf transactions more or less difficult to double spend on? I
>> do think 0-conf transactions can be useful in situations where there is
>> some level of trust (either direct trust between the interacting parties,
>> or disperse trust that most people won't try to double spend, perhaps
>> because the transaction is small or their identity is tied to it). Fidelity
>> bonds sound like an interesting way to mitigate sybil attacks in a
>> reputation system.
>>
>> On Thu, Jun 24, 2021 at 5:23 PM Antoine Riard 
>> wrote:
>>
>>> > Do we as a community want to support 0-conf payments in any way at this
>>> > point? It seems rather silly to make software design decisions to
>>> > accommodate 0-conf payments when there are better mechanisms for fast
>>> > payments (ie lightning).
>>>
>>> Well, we have zero-conf LN channels ? Actually, Lightning channel
>>> funding transactions should be buried under a few blocks, though few
>>> services providers are offering zero-conf channels, where you can start to
>>> spend instantly [0]. I believe that's an interesting usage, though IMHO as
>>> mentioned we can explore different security models to make 0-conf safe
>>> (reputation/fidelity-bond).
>>>
>>> > One question I have is: how does software generally inform the user
>>> about
>>> 0-conf payment detection?
>>>
>>> Yes generally it's something like an "Unconfirmed" annotation on
>>> incoming txn, though at least this is what Blockstream Green or Electrum
>>> are doing.
>>>
>>> > But I
>>> suppose it would depend on how often 0-conf is used in the bitcoin
>>> ecosystem at this point, which I don't have any data on.
>>>
>>> There are few Bitcoin services well-known to rely on 0-conf. Beyond how
>>> much of the Bitcoin traffic is tied to a 0-conf is a hard question, a lot
>>> of 0-confs service providers are going to be reluctant to share the
>>> information, for a really good reason you will learn a subset of their
>>> business volumes.
>>>
>>> I'll see if I can come up with some Fermi estimation on this front.
>>>
>>> [0] https://www.bitrefill.com/thor-turbo-channels/
>>>
>>> Le mer. 16 juin 2021 à 20:58, Billy Tetrud  a
>>> écrit :
>>>
 Russel O'Connor recently opined
 
 that RBF should be standard treatment of all transactions, rather than as a
 transaction opt-in/out. I agree with that. Any configuration in a
 transaction that has not been committed into a block yet simply can't be
 relied upon. Miners also have a clear incentive to ignore RBF rules and
 mine anything that passes consensus. At best opting out of RBF is a weak
 defense, and at worst it's simply a false sense of security that is likely
 to actively lead to theft events.

 Do we as a community want to support 0-conf payments in any way at this
 point? It seems rather silly to make software design decisions to
 accommodate 0-conf payments when there are better mechanisms for fast
 payments (ie lightning).

 One question I have is: how does software generally inform the user
 about 0-conf payment detection? Does software generally tell the user
 something along the lines of "This payment has not been finalized yet. All
 recip

Re: [bitcoin-dev] Trinary Version Signaling for softfork

[Eric Voskuil via bitcoin-dev]

> 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 to transact bitcoin in a way 
> that violates the set of rules enforced by the network of 
> consensus-compatible nodes that we call Bitcoin.

When Fincen walks into Coinbase and every other exchange (and white market 
business in the country), and tells them to change a rule or they are taking 
the CEO out in hancuffs for money laundering, I’m pretty sure that their node 
with not be able to prevent it.

Enforcement is always people. We use the term node as a metaphorical term for 
people who use the node to avoid taking bad money. Like those machines that 
test paper money, they offer no resistance themselves.

A node in a closet checking transactions, unconnected to any human actually 
rejecting the money in trade, offers no resistance to anything. It can be 
forked off without any consequence whatsoever. 

This subject was discussed here during the BCH split. People were setting up 
nodes on cloud services, to boost numbers. These non-economic nodes were of 
course of no consequence, which was not a matter of debate. I’m explaining to 
you why that is.

The network ignores non-economic nodes as if they never existed.

> Zac
> 
> 
>> On Wed, Jun 30, 2021 at 2:03 PM Eric Voskuil  wrote:
>> 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 anything at the 
>> time, he is not enforcing anything.
>> 
>> The idea of a non-economic node is well established, nothing new here.
>> 
>> e
>> 
 On Jun 30, 2021, at 04:33, Zac Greenwood  wrote:
 
>>> 
>>> Hi Eric,
>>> 
>>> > A node (software) doesn’t enforce anything. Merchants enforce consensus 
>>> > rules
>>> 
>>> … by running a node which they believe to enforce the rules of Bitcoin.
>>> 
>>> A node definitely enforces consensus rules and defines what is Bitcoin. I 
>>> am quite disturbed that this is even being debated here.
>>> 
>>> Zac
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

[Billy Tetrud via bitcoin-dev]

>  I would prefer to see nodes forward any transaction conflicting
transaction, so long as it has a higher fee. Is there a reason this would
be undesirable?

There is a spam risk there, where someone could intend to pay a fee of 1000
sats, but every time they make a payment, they generate a transaction with
the minimum fee, then a transaction with a fee 1 sat higher, etc etc until
they've generated about 1000 sats. So I think what nodes do is that they
only forward transactions that have a fee at least X sats higher than one
they already have in their mempool. The minimum delta between fees should
probably be just as high as the absolute minimum fee, since it accounts for
the cost of broadcasting the transaction.

But on broader strokes, as long as you're bumping the fee by a significant
amount, I agree that any transaction should be forwarded regardless of any
RBF flag.

On Wed, Jun 30, 2021 at 7:07 AM Corey Haddad via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> We cannot prevent people from choosing to take an action based on an
> unconfirmed transaction. Even though it is trivial to have a
> double-spending transaction confirmed, accepting a 0-conf tx can be
> rational in many cases.  0-conf can be interpreted as the customer
> signaling their 'intent to pay', and where there is an established
> relationship between customer and merchant, or where there merchant is
> providing a cancelable e-service, signaling intent may be enough. These use
> cases do not depend on making it difficult for the user to attempt to
> double-spend the merchant.
>
> Bitcoin is a system designed around a consensus on the blockchain, not the
> mempool. I am in favor of providing the spender of bitcoins with all
> possible tools and methods to help them submit their transactions -
> double-spending or not - to miners for consideration. More than making RBF
> the default, I would prefer to see nodes forward any transaction
> conflicting transaction, so long as it has a higher fee. Is there a reason
> this would be undesirable?
>
> Corey
>
> On Sat, Jun 26, 2021 at 3:00 PM Jeremy via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> If the parties trust each other, rbf is still opt-in. Just don't do it?
>>
>> On Sat, Jun 26, 2021, 9:30 AM Billy Tetrud via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> >  services providers are offering zero-conf channels, where you can
>>> start to spend instantly [0]. I believe that's an interesting usage
>>>
>>> I agree those are interesting and useful cases. I suppose I should
>>> clarify that when I asked if bitcoin should continue supporting 0-conf
>>> transactions, I meant: should we make design decisions based on whether it
>>> makes raw 0-conf transactions more or less difficult to double spend on? I
>>> do think 0-conf transactions can be useful in situations where there is
>>> some level of trust (either direct trust between the interacting parties,
>>> or disperse trust that most people won't try to double spend, perhaps
>>> because the transaction is small or their identity is tied to it). Fidelity
>>> bonds sound like an interesting way to mitigate sybil attacks in a
>>> reputation system.
>>>
>>> On Thu, Jun 24, 2021 at 5:23 PM Antoine Riard 
>>> wrote:
>>>
 > Do we as a community want to support 0-conf payments in any way at
 this
 > point? It seems rather silly to make software design decisions to
 > accommodate 0-conf payments when there are better mechanisms for fast
 > payments (ie lightning).

 Well, we have zero-conf LN channels ? Actually, Lightning channel
 funding transactions should be buried under a few blocks, though few
 services providers are offering zero-conf channels, where you can start to
 spend instantly [0]. I believe that's an interesting usage, though IMHO as
 mentioned we can explore different security models to make 0-conf safe
 (reputation/fidelity-bond).

 > One question I have is: how does software generally inform the user
 about
 0-conf payment detection?

 Yes generally it's something like an "Unconfirmed" annotation on
 incoming txn, though at least this is what Blockstream Green or Electrum
 are doing.

 > But I
 suppose it would depend on how often 0-conf is used in the bitcoin
 ecosystem at this point, which I don't have any data on.

 There are few Bitcoin services well-known to rely on 0-conf. Beyond how
 much of the Bitcoin traffic is tied to a 0-conf is a hard question, a lot
 of 0-confs service providers are going to be reluctant to share the
 information, for a really good reason you will learn a subset of their
 business volumes.

 I'll see if I can come up with some Fermi estimation on this front.

 [0] https://www.bitrefill.com/thor-turbo-channels/

 Le mer. 16 juin 2021 à 20:58, Billy Tetrud  a
 écrit :

> Russel O'Connor rece

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Billy Tetrud via bitcoin-dev]

@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 really saying that we should just hard fork every time instead
of soft fork?
> No

So what are you advocating for then, exactly?

>> Are you not at all worried about the costs associated with an increased
orphan rate and reorg rate?
> Orphan blocks are bad, yes, not sure what the point of your question is.

The point is that if we just deployed with BIP8 LOT=true (as that seems to
be the kind of thing you're advocating for) and only 60% of miners had
upgraded to the new update by the time it activates, orphans and reorg rate
and depths would greatly increase. The point of the question is: shouldn't
we avoid that "when possible"?

> What do you think of bip99?

I haven't read it before, but after reading it, it seems like a reasonable
discussion of possibilities and types of forks. It looks like you advocated
that "miner voting" is appropriate for some of the types of forks. And yet,
from the way you're talking in this thread, it sounds like you don't think
any consensus rule change deployment should consider miner signaling. So
I'm confused because it seems like the things you're saying here conflict
with some of the things you wrote in BIP99.

What specifically did you want me to get out of BIP99 in this context?

@Eric
> I’d also question the use of the term “majority”

I just want to clarify that by "economic majority" I mean a set of users
that presently accept more than 50% of the volume of payments in a given
period of time. I definitely agree that no majority of any kind is needed
for a split.


On Wed, Jun 30, 2021 at 2:52 AM  wrote:

> > 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 continue to operate without
> modification. Non-upgraded nodes, however, will not see nor validate the
> witness data and will consider all witness programs as anyone-can-spend
> scripts (except a few edge cases where the witness programs are equal to 0,
> which the script must fail). Wallets should always be wary of
> anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes
> are strongly encouraged to upgrade in order to take advantage of the new
> features."
>
> The explanation is however incomplete. If majority hash power does not
> enforce the new rules, the above is incorrect. Granted the word "operate"
> is vague, but clearly what is intended is that "non-upgraded" nodes will
> not be on a different coin. But in fact they would be. The underlying
> presumption is that BIP141 is not only signaled, but enforced by majority
> hash power.
>
> >> "Soft forks without miner support cause splits".
> > No, what causes splits are 3 things:
> >
> > 1) bugs
> > 2) coordination mistakes
> > 3) people wanting different rules.
>
> #3 (and possibly #4) is what we're talking about, so it's not at all clear
> why you said "no".
>
> People change their rules, because #3. If majority hash power does not
> enforce this (soft) change, it's a chain split.
>
> > Let me give an example. Let's say all users want change A.
> >
> > Only 60% miners want it.
> > When it activates with LOT=true, will this cause a split?
>
> No, regardless of percentage adoption. You've proposed that it' is
> majority hash power enforced.
>
> Furthermore, the term compatibility (see above) implies that not everyone
> (your impossible presumption of 100%) is aligned.
>
> This is not a debatable subject as far as I'm concerned, but it's worth
> discussion for those who aren't familiar.
>
> e
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Billy Tetrud via bitcoin-dev]

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 hybrid deployment, even flag days).

The main relevant actually to my proposal that have been mentioned, as far
as I can tell, is that Luke opined that explicit signaling of opposition
was unnecessary, because he thinks we shouldn't try to avoid chain splits
when there's any opposition. Jorge agreed that we shouldn't try to avoid
chain splits. But I don't really understand what either of you (Luke or
Jorge) are actually proposing is better than using my proposal. Are you
proposing LOT=true be added as an option to my proposal? Are you proposing
that we should always use a LOT=true style flag day, and not even consider
the option of permanent failure for a deployment? Or are you simply saying
that miner opposition is never relevant or useful to know during a
deployment?

Everything else has been only tenuously related:

* Who "controls" or "defines" bitcoin"?
* Who "controls" what happens during a deployment?
* Should we deploy based on miner signaling at all?

If there's so much to discuss on these philosophical points, maybe it makes
sense to branch that off into a separate thread. I'd appreciate it if we
can reconnect this discussion with the proposal this thread is about.



On Wed, Jun 30, 2021 at 12:30 PM Billy Tetrud 
wrote:

> @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 really saying that we should just hard fork every time
> instead of soft fork?
> > No
>
> So what are you advocating for then, exactly?
>
> >> Are you not at all worried about the costs associated with an
> increased orphan rate and reorg rate?
> > Orphan blocks are bad, yes, not sure what the point of your question is.
>
> The point is that if we just deployed with BIP8 LOT=true (as that seems to
> be the kind of thing you're advocating for) and only 60% of miners had
> upgraded to the new update by the time it activates, orphans and reorg rate
> and depths would greatly increase. The point of the question is: shouldn't
> we avoid that "when possible"?
>
> > What do you think of bip99?
>
> I haven't read it before, but after reading it, it seems like a reasonable
> discussion of possibilities and types of forks. It looks like you advocated
> that "miner voting" is appropriate for some of the types of forks. And yet,
> from the way you're talking in this thread, it sounds like you don't think
> any consensus rule change deployment should consider miner signaling. So
> I'm confused because it seems like the things you're saying here conflict
> with some of the things you wrote in BIP99.
>
> What specifically did you want me to get out of BIP99 in this context?
>
> @Eric
> > I’d also question the use of the term “majority”
>
> I just want to clarify that by "economic majority" I mean a set of users
> that presently accept more than 50% of the volume of payments in a given
> period of time. I definitely agree that no majority of any kind is needed
> for a split.
>
>
> On Wed, Jun 30, 2021 at 2:52 AM  wrote:
>
>> > 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 continue to operate without
>> modification. Non-upgraded nodes, however, will not see nor validate the
>> witness data and will consider all witness programs as anyone-can-spend
>> scripts (except a few edge cases where the witness programs are equal to 0,
>> which the script must fail). Wallets should always be wary of
>> anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes
>> are strongly encouraged to upgrade in order to take advantage of the new
>> features."
>>
>> The explanation is however incomplete. If majority hash power does not
>> enforce the new rules, the above is incorrect. Granted the word "operate"
>> is vague, but clearly what is intended is that "non-upgraded" nodes will
>> not be on a different coin. But in fact they would be. The underlying
>> presumption is that BIP141 is not only signaled, but enforced by majority
>> hash power.
>>
>> >> "Soft forks without miner support cause splits".
>> > No, what causes splits are 3 things:
>> >
>> > 1) bugs
>> > 2) coordination mistakes
>> > 3) people wanting different rules.
>>
>> #3 (and possibly #4) is what we're talking about, so it's not at all
>> clear why you said "no".
>>
>

[bitcoin-dev] Bitcoin Knots 0.21.1.knots20210629 released

[Luke Dashjr via bitcoin-dev]

Bitcoin Knots version 0.21.1.knots20210629 is now available from:

  https://bitcoinknots.org/files/0.21.x/0.21.1.knots20210629/

This release includes new features, various bug fixes and performance 
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  https://github.com/bitcoinknots/bitcoin/issues

To receive security and update notifications, please subscribe to:

  https://bitcoinknots.org/list/announcements/join/

For the full release notes and change log, see:

https://github.com/bitcoinknots/bitcoin/blob/v0.21.1.knots20210629/doc/release-notes.md


signature.asc
Description: This is a digitally signed message part.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev