Nostr notes by

📅 Original date posted:2023-05-11 🗒️ Summary of this ...

2023-06-19T19:42:07+02:00

In reply to nevent1q…7nfu
_________________________

📅 Original date posted:2023-05-11
🗒️ Summary of this message: The author challenges Jeremy Rubin to a public debate to defend themselves against accusations and censorship, but doubts it will happen.
📝 Original message:
I challenge jeremy to a public debate somewhere. I forgot to say the name
on that sentence. Just to clarify.
If he believes he is on the right and I am on the wrong and "clearly
delusional" (or whatever he accuses me of), then he shouldn't be scared of
the debate, no?
Oh, let me guess..."I don't want to give him a platform, he is worse than
kanye west"?
Yeah, I bet the excuses are going to be along those lines.

Good bye, guys, I guess this will get me kicked out from another forum.
I lost count, but it feels like more than 109 forums, just saying.
For no reason at all, of course.

On Thu, May 11, 2023, 09:55 Jorge Timón <jtimon at jtimon.cc> wrote:

> Pressumption of innocence?
> Right to defend yourself?
>
> Wow, that sounds amazing, but, for example, wouldn't me defendibg myself
> from jeremy rubin be offtopic like...pretty much everywhere?
> Not sure you're familiar with that story, certainly you didn't hear my
> side of the story, did you?
> Where would it be fine for me to defend myself?
> I don't want to keep cosing bitcoin anymore, novody would review my PRs
> anyway once jeremy made sure everyone thought I am evil. Or perhaps I'm
> paranoid. Anyway, I would juat like to find the right venue to clean my
> name or at least be allowed to try. If that venue exists at all, that is.
>
> Personally, I feel extremely censored.
> I also feel I've been judged unfairly and margibalized by many.
> If it was because of my mistakes and not because jeremy and others lied
> about me behind my back, well, I would like to know at least.
>
> Am I really asking that much?
> I'm surprised at how very few people are in favor of the american first
> amendment, btw.
>
> I know, I know. Offtopic. Everywhere. Every time.
> If something it's offtopic everywhere, that's a censored taboo, I think.
>
> Therefore I challenge to a public debate somewhere. For me to defend
> myself and for him to defend himself too (if that's possible).
> I know it's never going to happen, but I want to make sure it is known
> that it is because of him, I'm more than ready to defend myself against
> him. Is he?
>
> He can call me a nazi and even though I'm not one (I'm not even racist),
> it is not so easy to sue for defamation in international jurisdictions.
> Imagine if I called him a pederast (kethuboth 11b, sanhesrin 69b) or a
> cannibal (samhedrin 64a) without giving him a chance to defend himself.
> Wouldn't that be nasty?
> I want him to be able to defend himself too, or at least try it.
>
> Now, moderators, censor this email for being offtopic and prove my point.
> Jeremy will still get the email and I bet he won't want a public debate.
> But I'm biased because I think he is guilty. Just like jeffrey epstein.
> Is jeremy rubin a mossad agent?
> Is there any reason to think so?
> Or are these just rummors?
> He should have a chance to try to clean his name, in my opinion. Again,
> just like jeffrey epstein.
>
> On Wed, May 10, 2023, 17:57 Antoine Riard <antoine.riard at gmail.com> wrote:
>
>> Hi Tony,
>>
>> > Is there a better place to have public communication? Unfortunately
>> since one off topic email was sent here, it's been a ghost town. It appears
>> that there's many emails being held and only one moderator that checks them
>> once a week.
>>
>> As I think you're referring to my post of March 21th and as the author of
>> this post, I'll politely refuse the qualification of "off-topic". I had and
>> I still have the concerns of "frivolous legal claims" being used between
>> bitcoin developers/organizations provoking a distortion of the neutrality
>> of the development and a chilling effect of the technical discussions (i.e
>> code we compile and spec we implement). For those reasons, it was my legal
>> right and moral duty to inform the community of what is happening between
>> Chaincode and myself. And here I'm following the recommendation of one of
>> the moderators of the Lightning mailing list himself "If this worries you
>> too, let's make sure we keep each other honest, OK?" [0].
>>
>> When you think a group of people with open-source responsibilities are in
>> a situation of conflict of interests or "moral hazards", or even the
>> appearance of them, you have the right to expose the wrongdoing, including
>> the _proportional_ revelation of private elements. People have done the
>> "free choice" to conduct a career in open-source, for some even declaring
>> in some context to maintain integrity and accept their actions to be
>> submitted to external accountability [1]. While the exposure of private
>> elements of public personalities might break common courtesy, it's a
>> morally valid practice if you're familiar with the public institutions of
>> US and Europe, and I think this practice has found validity in the history
>> of open-source commons or IETF's protocol development [1].
>>
>> Beyond, the Bitcoin and Lightning development communication channels
>> constitute a public forum, where by nature the participants are exchanging
>> ideas and defending competing interests. In consequence, the participants'
>> rights and capabilities to contribute and speak their minds in those
>> communication channels should be protected. Those communication channels
>> are not your usual corporate workplace, and in case of conflicting
>> principles, the maintainers of those communication channels should ensure a
>> balance of rights and a proportionality in any restraining measure.
>>
>> And this new post is not to exonerate myself of any legal responsibility
>> for personal matters that could be recognized as the outcome of a judicial
>> process, respective of both rights of the accusation and rights of the
>> defense. Rather to enlighten the Bitcoin community that the formal
>> separation between private matters and open-source responsibilities, and
>> the adequate check-and-balances to guarantee this separation is somehow
>> what are the underlying stakes for this feud between Chaincode and myself,
>> from my perspective. I can say missing an open-source engineering meeting
>> or being revoked a few Github permissions matters far less than the clear
>> affirmation and respect of the freedom of expression, the presumption of
>> innocence and due process in the Bitcoin common space, all proportions
>> conserved.
>>
>> I don't blame any party involved in this issue, nor assign "bad
>> intentions''. One position is really a function of your life experiences,
>> knowledge of the legal and cultural framework and access to the factual
>> elements. As all human conflicts it is not binary rather "grey". People can
>> be top executives at a billion-dollar company, having successful ventures
>> with hundreds of folks under management, or have a lot of responsibilities
>> for their relative young age, and still disagree on the set of legal and
>> moral principles to apply in the present case.
>>
>> Finally, thanks to the Bitcoin friends who have reached out to call for
>> level-headedness and cool-mindness in the public discussion of this complex
>> topic. Like I said to them, in the lack of more suspected wrongdoing from
>> the other side, I won't communicate further on this subject on the Bitcoin
>> and Lightning technical channels. However I still firmly believe the
>> discussion on the principles, abstract in the maximum from its private
>> elements, should still be pursued on other channels. Independently, there
>> is a legal channel opened between Chaincode and myself and good progress is
>> made to find a serene and long-standing resolution to this issue.
>>
>> Best,
>> Antoine
>>
>> [0]
>> https://rusty-lightning.medium.com/the-corrosion-of-ethics-in-cryptocurrencies-f7ba77e9dfc3
>> [1]
>> https://github.com/btrustteam/board-book/blob/main/vision/genesis_principles.md
>> [2]
>> https://www.ietf.org/about/administration/policies-procedures/conflict-interest/
>>
>> Le lun. 8 mai 2023 à 21:26, Tony Giorgio via Lightning-dev <
>> lightning-dev at lists.linuxfoundation.org> a écrit :
>>
>>> Is there a better place to have public communication? Unfortunately
>>> since one off topic email was sent here, it's been a ghost town. It appears
>>> that there's many emails being held and only one moderator that checks them
>>> once a week.
>>>
>>> Would hate to see this list die but wondering if there's a better place
>>> for discussions?
>>>
>>> Tony
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------- Original Message --------
>>> On Apr 29, 2023, 9:57 PM, niftynei < niftynei at gmail.com> wrote:
>>>
>>>
>>> Hi all,
>>>
>>> When I joined the lightning community a few years ago, I was relatively
>>> new to open source software and specification work. Rusty really impressed
>>> on me on the importance of holding conversations, as much as possible in
>>> public.
>>>
>>> Practically speaking, this encompasses IRC, this mailing list, and
>>> github issues/PRs.
>>>
>>> The reason for this is twofold. It helps document the range of options
>>> considered for technical decisions and it provides an interface point for
>>> new participants to contribute to the discussion.
>>>
>>> Given some recent mails that were posted to this list, now seems like a
>>> good time to reiterate the importance and preference of public
>>> communication whenever possible, especially for specification or technical
>>> discussions.
>>>
>>>
>>> ~ nifty
>>>
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230511/7f6c0cd5/attachment-0001.html>;

📅 Original date posted:2023-05-11 🗒️ Summary of this ...

2023-06-19T19:42:06+02:00

In reply to nevent1q…9dun
_________________________

📅 Original date posted:2023-05-11
🗒️ Summary of this message: The author challenges for a public debate to defend themselves against accusations made by Jeremy Rubin and feels censored and marginalized.
📝 Original message:
Pressumption of innocence?
Right to defend yourself?

Wow, that sounds amazing, but, for example, wouldn't me defendibg myself
from jeremy rubin be offtopic like...pretty much everywhere?
Not sure you're familiar with that story, certainly you didn't hear my side
of the story, did you?
Where would it be fine for me to defend myself?
I don't want to keep cosing bitcoin anymore, novody would review my PRs
anyway once jeremy made sure everyone thought I am evil. Or perhaps I'm
paranoid. Anyway, I would juat like to find the right venue to clean my
name or at least be allowed to try. If that venue exists at all, that is.

Personally, I feel extremely censored.
I also feel I've been judged unfairly and margibalized by many.
If it was because of my mistakes and not because jeremy and others lied
about me behind my back, well, I would like to know at least.

Am I really asking that much?
I'm surprised at how very few people are in favor of the american first
amendment, btw.

I know, I know. Offtopic. Everywhere. Every time.
If something it's offtopic everywhere, that's a censored taboo, I think.

Therefore I challenge to a public debate somewhere. For me to defend myself
and for him to defend himself too (if that's possible).
I know it's never going to happen, but I want to make sure it is known that
it is because of him, I'm more than ready to defend myself against him. Is
he?

He can call me a nazi and even though I'm not one (I'm not even racist), it
is not so easy to sue for defamation in international jurisdictions.
Imagine if I called him a pederast (kethuboth 11b, sanhesrin 69b) or a
cannibal (samhedrin 64a) without giving him a chance to defend himself.
Wouldn't that be nasty?
I want him to be able to defend himself too, or at least try it.

Now, moderators, censor this email for being offtopic and prove my point.
Jeremy will still get the email and I bet he won't want a public debate.
But I'm biased because I think he is guilty. Just like jeffrey epstein.
Is jeremy rubin a mossad agent?
Is there any reason to think so?
Or are these just rummors?
He should have a chance to try to clean his name, in my opinion. Again,
just like jeffrey epstein.

On Wed, May 10, 2023, 17:57 Antoine Riard <antoine.riard at gmail.com> wrote:

> Hi Tony,
>
> > Is there a better place to have public communication? Unfortunately
> since one off topic email was sent here, it's been a ghost town. It appears
> that there's many emails being held and only one moderator that checks them
> once a week.
>
> As I think you're referring to my post of March 21th and as the author of
> this post, I'll politely refuse the qualification of "off-topic". I had and
> I still have the concerns of "frivolous legal claims" being used between
> bitcoin developers/organizations provoking a distortion of the neutrality
> of the development and a chilling effect of the technical discussions (i.e
> code we compile and spec we implement). For those reasons, it was my legal
> right and moral duty to inform the community of what is happening between
> Chaincode and myself. And here I'm following the recommendation of one of
> the moderators of the Lightning mailing list himself "If this worries you
> too, let's make sure we keep each other honest, OK?" [0].
>
> When you think a group of people with open-source responsibilities are in
> a situation of conflict of interests or "moral hazards", or even the
> appearance of them, you have the right to expose the wrongdoing, including
> the _proportional_ revelation of private elements. People have done the
> "free choice" to conduct a career in open-source, for some even declaring
> in some context to maintain integrity and accept their actions to be
> submitted to external accountability [1]. While the exposure of private
> elements of public personalities might break common courtesy, it's a
> morally valid practice if you're familiar with the public institutions of
> US and Europe, and I think this practice has found validity in the history
> of open-source commons or IETF's protocol development [1].
>
> Beyond, the Bitcoin and Lightning development communication channels
> constitute a public forum, where by nature the participants are exchanging
> ideas and defending competing interests. In consequence, the participants'
> rights and capabilities to contribute and speak their minds in those
> communication channels should be protected. Those communication channels
> are not your usual corporate workplace, and in case of conflicting
> principles, the maintainers of those communication channels should ensure a
> balance of rights and a proportionality in any restraining measure.
>
> And this new post is not to exonerate myself of any legal responsibility
> for personal matters that could be recognized as the outcome of a judicial
> process, respective of both rights of the accusation and rights of the
> defense. Rather to enlighten the Bitcoin community that the formal
> separation between private matters and open-source responsibilities, and
> the adequate check-and-balances to guarantee this separation is somehow
> what are the underlying stakes for this feud between Chaincode and myself,
> from my perspective. I can say missing an open-source engineering meeting
> or being revoked a few Github permissions matters far less than the clear
> affirmation and respect of the freedom of expression, the presumption of
> innocence and due process in the Bitcoin common space, all proportions
> conserved.
>
> I don't blame any party involved in this issue, nor assign "bad
> intentions''. One position is really a function of your life experiences,
> knowledge of the legal and cultural framework and access to the factual
> elements. As all human conflicts it is not binary rather "grey". People can
> be top executives at a billion-dollar company, having successful ventures
> with hundreds of folks under management, or have a lot of responsibilities
> for their relative young age, and still disagree on the set of legal and
> moral principles to apply in the present case.
>
> Finally, thanks to the Bitcoin friends who have reached out to call for
> level-headedness and cool-mindness in the public discussion of this complex
> topic. Like I said to them, in the lack of more suspected wrongdoing from
> the other side, I won't communicate further on this subject on the Bitcoin
> and Lightning technical channels. However I still firmly believe the
> discussion on the principles, abstract in the maximum from its private
> elements, should still be pursued on other channels. Independently, there
> is a legal channel opened between Chaincode and myself and good progress is
> made to find a serene and long-standing resolution to this issue.
>
> Best,
> Antoine
>
> [0]
> https://rusty-lightning.medium.com/the-corrosion-of-ethics-in-cryptocurrencies-f7ba77e9dfc3
> [1]
> https://github.com/btrustteam/board-book/blob/main/vision/genesis_principles.md
> [2]
> https://www.ietf.org/about/administration/policies-procedures/conflict-interest/
>
> Le lun. 8 mai 2023 à 21:26, Tony Giorgio via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> a écrit :
>
>> Is there a better place to have public communication? Unfortunately since
>> one off topic email was sent here, it's been a ghost town. It appears that
>> there's many emails being held and only one moderator that checks them once
>> a week.
>>
>> Would hate to see this list die but wondering if there's a better place
>> for discussions?
>>
>> Tony
>>
>>
>>
>>
>>
>>
>> -------- Original Message --------
>> On Apr 29, 2023, 9:57 PM, niftynei < niftynei at gmail.com> wrote:
>>
>>
>> Hi all,
>>
>> When I joined the lightning community a few years ago, I was relatively
>> new to open source software and specification work. Rusty really impressed
>> on me on the importance of holding conversations, as much as possible in
>> public.
>>
>> Practically speaking, this encompasses IRC, this mailing list, and github
>> issues/PRs.
>>
>> The reason for this is twofold. It helps document the range of options
>> considered for technical decisions and it provides an interface point for
>> new participants to contribute to the discussion.
>>
>> Given some recent mails that were posted to this list, now seems like a
>> good time to reiterate the importance and preference of public
>> communication whenever possible, especially for specification or technical
>> discussions.
>>
>>
>> ~ nifty
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230511/8bc90abd/attachment.html>;

📅 Original date posted:2023-05-02 🗒️ Summary of this ...

2023-06-19T19:42:03+02:00

In reply to nevent1q…k6pu
_________________________

📅 Original date posted:2023-05-02
🗒️ Summary of this message: A member of the Lightning community emphasizes the importance of public communication for technical discussions and decision-making.
📝 Original message:
Can you clarify which "recent mails that were posted to this list" are you
referring to?

On Sun, Apr 30, 2023 at 3:57 AM niftynei <niftynei at gmail.com> wrote:

> Hi all,
>
> When I joined the lightning community a few years ago, I was relatively
> new to open source software and specification work. Rusty really impressed
> on me on the importance of holding conversations, as much as possible in
> public.
>
> Practically speaking, this encompasses IRC, this mailing list, and github
> issues/PRs.
>
> The reason for this is twofold. It helps document the range of options
> considered for technical decisions and it provides an interface point for
> new participants to contribute to the discussion.
>
> Given some recent mails that were posted to this list, now seems like a
> good time to reiterate the importance and preference of public
> communication whenever possible, especially for specification or technical
> discussions.
>
>
> ~ nifty
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230502/6488a9c4/attachment-0001.html>;

📅 Original date posted:2022-04-23 📝 Original ...

2023-06-08T01:07:53+02:00

In reply to nevent1q…xzdt
_________________________

📅 Original date posted:2022-04-23
📝 Original message:I've been calling them "controversial softforks" for long.
I hate to be right some times, but I guess I'm happy that I'm not the only
one who distrusts jeremy rubin anymore.

Can we agree now that resisting a bip8 proposal is simpler and cleaner than
resisting a speedy trial proposal?
I guess now we don't need to discuss it in hypothetical terms anymore, do
we?

Is there any PR to actively resist the proposal on bitcoin core?

On Thu, Apr 21, 2022 at 8:16 PM Michael Folkson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Ok so we've had to scramble a bit as I don't think anyone except perhaps
> Jeremy thought that there would be a Speedy Trial signaling period for a
> CTV soft fork planned to start on May 5th [1]. That is two weeks away.
>
> (I have to take what he says at face value. I can understand why one would
> be skeptical.)
>
> Understandably this has angered and surprised a few people including some
> of those who have voiced opposition to a CTV soft fork activation being
> attempted in the first place [2].
>
> As I've said in a previous post [3] the Bitcoin Core 23.0 release
> candidate (and older versions) does not include any CTV code or CTV
> activation code. If a miner runs Bitcoin Core 23.0 out the box it will not
> signal for CTV. If by some chance CTV was to activate through some other
> software release Bitcoin Core releases would not apply CTV rules but they
> also wouldn't reject blocks that apply CTV rules. Hence it is prudent to
> prepare for an eventuality where the miner signaling threshold might be
> reached but the community wants to prevent the attempted soft fork from
> activating. (I personally don't think a 90 percent miner signaling
> threshold will be reached but I wouldn't want to bet Bitcoin's future on
> it.)
>
> I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but
> I'm open to better names. I certainly don't want to discourage those who
> dislike or oppose UASFs from contributing to this effort and potentially
> ultimately running a URSF release. If you don't want this rushed CTV soft
> fork to activate we are all on the same side whatever we call it.
>
> For now I've set up a ##ursf channel on Libera IRC to monitor developments
> and discuss working on an additional release that if run may ultimately
> reject blocks that signal for CTV.
>
> The intention of this would be to provide additional direction and
> incentive to miners that the community does not want this soft fork to be
> activated. To repeat running a Bitcoin Core release will not signal for a
> CTV soft fork out the box. If a miner runs a Bitcoin Core release it will
> not signal for CTV.
>
> Apologies that this is rushed. But as always with Jeremy caution and
> conservatism seems to be thrown out the window and we have to react to
> that. It goes without saying that this is not how Bitcoin consensus changes
> should be attempted.
>
> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
> [2]:
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
> [3]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220423/a732ee49/attachment.html>;

📅 Original date posted:2022-04-24 📝 Original ...

2023-06-08T01:07:04+02:00

In reply to nevent1q…fu9v
_________________________

📅 Original date posted:2022-04-24
📝 Original message:You're not even considering user resistance in your cases. You're purely
relying on miners and calling speedy trial superior. I don't know if you're
being obtuse on purpose, I'm explaining myself very badly...

I DON'T WANT TO RELY ON MINERS TO RESIST CHANGES I DON'T WANT TO.
Sorry for the tone, but, please, make sure you understand that before
answering further, or otherwise it is a waste of time.

Note that it doesn't have to be in bitcoin core, speedy trial could be used
for attempting to activate a controversial softfork (it doesn't need to be
an evil fork, even) outside of core. Like what jeremy is trying to do with
his proposal, for example.
Now, go ahead and tell me that if miners reject it, then doesn't matter,
because nobody ever has told me that before, I need to hear it one more
time.
And I'll tell you I don't care about what miners will do, because you
obviously need to hear it one more time as well.
Or just tell the list that you resolved all my concerns, like jeremy does
about any criticism of his proposals, "well, it has consensus because only
people seeking dissent don't like it". Likd with speedy trial.
"Some people conplained, but we told them theur concerns were addressed and
even though they disagreed and claimed we didn't understand their
concerns...it looked like they were seeking dissent, so we told them to f@$k
off and now there's consensus".

Sorry for the aggressive tone, but I when people ignore some of my points
repeteadly, I start to wonder if they do it on purpose. You're not ignoring
my points on purpose, are you?
Nah, of course not, it's just that communication is hard.
Surely it wouldn't be fair if I accused you of being dishonest or
pretending to be dumb.
Most probably, I'm not clear or direct enough.
Whatever the real explanation is for you not understanding me, you're not
understanding me and it feels luke a waste of time for both of us.
So, I'm sorry, it's over.

On Mon, Apr 11, 2022, 14:05 Anthony Towns <aj at erisian.com.au> wrote:

> On Fri, Apr 08, 2022 at 11:58:48AM +0200, Jorge Timón via bitcoin-dev
> wrote:
> > On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns <aj at erisian.com.au> wrote:
> > > > Let's discuss those too. Feel free to point out how bip8 fails at
> some
> > > > hypothetical cases speedy trial doesn't.
> > > Any case where a flawed proposal makes it through getting activation
> > > parameters set and released, but doesn't achieve supermajority
> hashpower
> > > support is made worse by bip8/lot=true in comparison to speedy trial
> > I disagree. Also, again, not the hypothetical case I want to discuss.
>
> You just said "Let's discuss those" and "Feel free to point out how bip8
> fails at some hypothetical cases speedy trial doesn't", now you're
> saying it's not what you want to discuss?
>
> But the above does include your "evil soft fork" hypothetical (I mean,
> unless you think being evil isn't a flaw?). The evil soft fork gets
> proposed, and due to some failure in review, merged with activation
> parameters set (via either speedy trial or bip8), then:
>
> a) supermajority hashpower support is achieved quickly:
> - both speedy trial and bip8+lot=true activate the evil fork
>
> b) supermajority hashpower support is achieved slowly:
> - speedy trial does *not* activate the evil fork, as it times out
> quickly
> - bip8 *does* activate the fork
>
> c) supermajority hashpower support support is never achieved:
> - speedy trial does *not* activate the evil fork
> - bip8+lot=false does *not* activate the evil fork, but only after a
> long timeout
> - bip8+lot=true *does* activate the evil fork
>
> In case (a), they both do the same thing; in case (b) speedy trial is
> superior to bip8 no matter whether lot=true/false since it blocks the
> evil fork, and in case (c) speedy trial is better than lot=false because
> it's quicker, and much better than lot=true because lot=true activates
> the evil fork.
>
> > > > > 0') someone has come up with a good idea (yay!)
> > > > > 1') most of bitcoin is enthusiastically behind the idea
> > > > > 2') an enemy of bitcoin is essentially alone in trying to stop it
> > > > > 3') almost everyone remains enthusiastic, despite that guy's
> > > incoherent
> > > > > raving
> > > > > 4') nevertheless, the enemies of bitcoin should have the power to
> stop
> > > > > the good idea
> > > > "That guy's incoherent raving"
> > > > "I'm just disagreeing".
> > >
> > > Uh, you realise the above is an alternative hypothetical, and not
> talking
> > > about you? I would have thought "that guy" being "an enemy of bitcoin"
> > > made that obvious... I think you're mistaken; I don't think your emails
> > > are incoherent ravings.
> > Do you realize IT IS NOT the hypothetical case I wanted to discuss.
>
> Yes, that's what "alternative" means: a different one.
>
> > I'm sorry, but I'm tired of trying to explain. and quite, honestly, you
> > don't seem interested in listening to me and understanding me at all, but
> > only in "addressing my concerns". Obviously we understand different
> things
> > by "addressing concerns".
> > Perhaps it's the language barrier or something.
>
> My claim is that for *any* bad (evil, flawed, whatever) softfork, then
> attempting activation via bip8 is *never* superior to speedy trial,
> and in some cases is worse.
>
> If I'm missing something, you only need to work through a single example
> to demonstrate I'm wrong, which seems like it ought to be easy... But
> just saying "I disagree" and "I don't want to talk about that" isn't
> going to convince anyone.
>
> I really don't think the claim above should be surprising; bip8 is meant
> for activating good proposals, bad ones need to be stopped in review --
> as "pushd" has said in this thread: "Flawed proposal making it through
> activation is a failure of review process", and Luke's said similar things
> as well. The point of bip8 isn't to make it easier to reject bad forks,
> it's to make it easier to ensure *good* forks don't get rejected. But
> that's not your hypothetical, and you don't want to talk about all the
> ways to stop an evil fork prior to an activation attempt...
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220424/d71c91c4/attachment-0001.html>;

📅 Original date posted:2022-04-08 📝 Original message:On ...

2023-06-08T01:07:03+02:00

In reply to nevent1q…wg0u
_________________________

📅 Original date posted:2022-04-08
📝 Original message:On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns <aj at erisian.com.au> wrote:

> On Mon, Mar 28, 2022 at 09:31:18AM +0100, Jorge Timón via bitcoin-dev
> wrote:
> > > In particular, any approach that allows you to block an evil fork,
> > > even when everyone else doesn't agree that it's evil, would also allow
> > > an enemy of bitcoin to block a good fork, that everyone else correctly
> > > recognises is good. A solution that works for an implausible
> hypothetical
> > > and breaks when a single attacker decides to take advantage of it is
> > > not a good design.
> > Let's discuss those too. Feel free to point out how bip8 fails at some
> > hypothetical cases speedy trial doesn't.
>
> Any case where a flawed proposal makes it through getting activation
> parameters set and released, but doesn't achieve supermajority hashpower
> support is made worse by bip8/lot=true in comparison to speedy trial
>

I disagree. Also, again, not the hypothetical case I want to discuss.

> That's true both because of the "trial" part, in that activation can fail
> and you can go back to the drawing board without having to get everyone
> upgrade a second time, and also the "speedy" part, in that you don't
> have to wait a year or more before you even know what's going to happen.
>
> > > 0') someone has come up with a good idea (yay!)
> > > 1') most of bitcoin is enthusiastically behind the idea
> > > 2') an enemy of bitcoin is essentially alone in trying to stop it
> > > 3') almost everyone remains enthusiastic, despite that guy's
> incoherent
> > > raving
> > > 4') nevertheless, the enemies of bitcoin should have the power to stop
> > > the good idea
> > "That guy's incoherent raving"
> > "I'm just disagreeing".
>
> Uh, you realise the above is an alternative hypothetical, and not talking
> about you? I would have thought "that guy" being "an enemy of bitcoin"
> made that obvious... I think you're mistaken; I don't think your emails
> are incoherent ravings.
>

Do you realize IT IS NOT the hypothetical case I wanted to discuss. Seems
like that hypothetical case where a crazy person can be safely ignored
covered already.

> It was intended to be the simplest possible case of where someone being
> able to block a change is undesirable: they're motivated by trying to
> harm bitcoin, they're as far as possible from being part of some economic
> majority, and they don't even have a coherent rationale to provide for
> blocking the idea.
>
> Cheers,
> aj
>

Either I'm explaining my self very badly, you don't want to understand me,
or you can't understand me for whatever reason.
I don't feel listened or that "my concerns have been addressed", but at
this point I feel we're wasting each others time.Perhaps my rational
against speedy trial is not coherent, or perhaps you haven't understand it
yet.
I'm sorry, but I'm tired of trying to explain. and quite, honestly, you
don't seem interested in listening to me and understanding me at all, but
only in "addressing my concerns". Obviously we understand different things
by "addressing concerns".
Perhaps it's the language barrier or something.

Good bye.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220408/6afa6f58/attachment.html>;

📅 Original date posted:2022-03-17 📝 Original message:On ...

2023-06-08T01:06:19+02:00

In reply to nevent1q…fvzw
_________________________

📅 Original date posted:2022-03-17
📝 Original message:On Fri, Mar 11, 2022 at 5:32 PM Billy Tetrud via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I think involving users more in activation is a good avenue of thought for improving how bitcoin does soft forks. I also think the idea you brought up of some way for people to signal opposition is a good idea. I've suggested a mechanism for signature-based user polling, I've also suggested a mechanism where miners can actively signal for opposing a soft fork. It seems like there should be some common ground between us in those ideas. Where it seems we may perhaps unreconcilably disagree are that A. miners are users too and generally have interests that are important and different than most users, and giving them at least some mechanism to force discussion is appropriate, and B. chain splits are no joke and should almost never be possible accidentally and therefore we should make a significant effort to avoid them, which almost definitely means orderly coordination of miners.

Any user polling system is going to be vulnerable to sybil attacks.

> Do you have anything concrete you want to propose? An example mechanism? Are you simply here advocating your support for BIP8+LOT=true?

Yes, I want BIP+LOT=true (aka the original bip8).
I also want users to be easily able to coordinate resistance to any
given change, as I described in this thread and others and luke has
done many times.
I also generally oppose to speedy trial being used for any consensus
rule change deployment.

Imagine someone comes and proposes a block size increase through
extension block softfork.
Would you like them to use speedy trial or BIP8+LOT=true for deployment?

📅 Original date posted:2022-03-28 📝 Original message:On ...

2023-06-08T01:06:17+02:00

In reply to nevent1q…juhu
_________________________

📅 Original date posted:2022-03-28
📝 Original message:On Sat, Mar 26, 2022, 01:45 Anthony Towns <aj at erisian.com.au> wrote:

> On Thu, Mar 24, 2022 at 07:30:09PM +0100, Jorge Timón via bitcoin-dev
> wrote:
> > Sorry, I won't answer to everything, because it's clear you're not
> listening.
>
> I'm not agreeing with you; that's different to not listening to you.
>

You're disagreeing with thw premises of the example. That's not
disagreeing, that's refusing to understand the example.

> > In the HYPOTHETICAL CASE that there's an evil for, the fork being evil
> > is a PREMISE of that hypothetical case, a GIVEN.
>
> Do you really find people more inclined to start agreeing with you when
> you begin yelling at them? When other people start shouting at you,
> do you feel like it's a discussion that you're engaged in?
>

I just wanted to make sure you catched the PREMISE word.

> > Your claim that "if it's evil, good people would oppose it" is a NON
> > SEQUITUR, "good people" aren't necessarily perfect and all knowing.
> > good people can make mistakes, they can be fooled too.
> > In the hypothetical case that THERE'S AN EVIL FORK, if "good people"
> > don't complain, it is because they didn't realize that the given fork
> > was evil. Because in our hypothetical example THE EVIL FORK IS EVIL BY
> > DEFINITION, THAT'S THE HYPOTHETICAL CASE I WANT TO DISCUSS, not the
> > hypothetical case where there's a fork some people think it's evil but
> > it's not really evil.
>
> The problem with that approach is that any solution we come up with
> doesn't only have to deal with the hypotheticals you want to discuss
>

Sure, but if it doesn't deal with this hypothetical, one canbot pretending
it does by explaing how it does in a different hypothetical.

In particular, any approach that allows you to block an evil fork,
> even when everyone else doesn't agree that it's evil, would also allow
> an enemy of bitcoin to block a good fork, that everyone else correctly
> recognises is good. A solution that works for an implausible hypothetical
> and breaks when a single attacker decides to take advantage of it is
> not a good design.
>

Let's discuss those too. Feel free to point out how bip8 fails at some
hypothetical cases speedy trial doesn't.

And I did already address what to do in exactly that scenario:
>
> > > But hey what about the worst case: what if everyone else in bitcoin
> > > is evil and supports doing evil things. And maybe that's not even
> > > implausible: maybe it's not an "evil" thing per se, perhaps [...]
> > >
> > > In that scenario, I think a hard fork is the best choice: split out a
> new
> > > coin that will survive the upcoming crash, adjust the mining/difficulty
> > > algorithm so it works from day one, and set it up so that you can
> > > maintain it along with the people who support your vision, rather than
> > > having to constantly deal with well-meaning attacks from "bitcoiners"
> > > who don't see the risks and have lost the plot.
> > >
> > > Basically: do what Satoshi did and create a better system, and let
> > > everyone else join you as the problems with the old one eventually
> become
> > > unavoidably obvious.
>
> > Once you understand what hypothetical case I'm talking about, maybe
> > you can understand the rest of my reasoning.
>
> As I understand it, your hypothetical is:
>
> 0) someone has come up with a bad idea
> 1) most of bitcoin is enthusiastically behind the idea
> 2) you are essentially alone in discovering that it's a bad idea
> 3) almost everyone remains enthusiastic, despite your explanations that
> it's a bad idea
> 4) nevertheless, you and your colleagues who are aware the idea is bad
> should have the power to stop the bad idea
> 5) bip8 gives you the power to stop the bad idea but speedy trial does not
>

Again given (0), I think (1) and (2) are already not very likely, and (3)
> is simply not plausible. But in the event that it does somehow occur,
> I disagree with (4) for the reasons I describe above; namely, that any
> mechanism that did allow that would be unable to distinguish between the
> "bad idea" case and something along the lines of
>

Ok, yeah, the bitcoin developers currently paying attention to the mailibg
list being fooled or making a review mistake is completely unfeasible.
They're all way to humble for that, obviously...sigh.

0') someone has come up with a good idea (yay!)
> 1') most of bitcoin is enthusiastically behind the idea
> 2') an enemy of bitcoin is essentially alone in trying to stop it
> 3') almost everyone remains enthusiastic, despite that guy's incoherent
> raving
> 4') nevertheless, the enemies of bitcoin should have the power to stop
> the good idea
>
> And, as I said in the previous mail, I think (5) is false, independently
> of any of the other conditions.
>

"That guy's incoherent raving"
"I'm just disagreeing".

Never mind, anthony.
Ypu absolutely understood what I'm saying. It's just that I'm also
incoherent to you, it seems. But, hey, again, no contradiction here, I
guess.

> But if you don't understand the PREMISES of my example,
>
> You can come up with hypothetical premises that invalidate bitcoin,
> let alone some activation method. For example, imagine if the Federal
> Reserve Board are full of geniuses and know exactly when to keep issuance
> predictable and when to juice the economy? Having flexibility gives more
> options than hardcoding "21M" somewhere, so clearly the USD's approach
> is the way to go, and everything is just a matter of appointing the
> right people to the board, not all this decentralised stuff.
>
> The right answer is to reject bad premises, not to argue hypotheticals
> that have zero relationship to reality
>

Ok, stop arguing a hypothetical you don't want to arhue about. But you
can't say both "I don't want to consider that hypothetical" and "we
considered all hypotheticals" at the same time.
I mean, you can, you only can't if you don't want to contradict yourself.

I'll have to wait for someone who actually can both understand the
hypothetical and ve willing to discuss it.
I think you didn't understand it, but either way: thank you for admitting
you don't want to discuss it.
Let's stop wasting each other's time then.

Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220328/8fa8285e/attachment.html>;

📅 Original date posted:2022-03-24 📝 Original message:Sorry, ...

2023-06-08T01:06:15+02:00

In reply to nevent1q…4alt
_________________________

📅 Original date posted:2022-03-24
📝 Original message:Sorry, I won't answer to everything, because it's clear you're not listening.
In the HYPOTHETICAL CASE that there's an evil for, the fork being evil
is a PREMISE of that hypothetical case, a GIVEN.
Your claim that "if it's evil, good people would oppose it" is a NON
SEQUITUR, "good people" aren't necessarily perfect and all knowing.
good people can make mistakes, they can be fooled too.
In the hypothetical case that THERE'S AN EVIL FORK, if "good people"
don't complain, it is because they didn't realize that the given fork
was evil. Because in our hypothetical example THE EVIL FORK IS EVIL BY
DEFINITION, THAT'S THE HYPOTHETICAL CASE I WANT TO DISCUSS, not the
hypothetical case where there's a fork some people think it's evil but
it's not really evil.

Repeat with me: in the hypothetical case that there's an evil fork,
then the fork is evil by definition, that's the hypothetical case
we're discussing.

Once you understand what hypothetical case I'm talking about, maybe
you can understand the rest of my reasoning.
But if you don't understand the PREMISES of my example, it is
impossible that you can understand my reasonings about the
hypothetical example.

I'm sorry about the upper cases, but I really don't know how else I
could be clearer about the PREMISES being PREMISES and not just
possibilities. If you can't imagine a scenario where good people don't
oppose an evil fork, then you can't imagine the scenario I'm talking
about, sorry.

Evil fork deployed with speedy trial vs evil fork deployed with BIP8,
that's what I'm talking about.
Please, stop the "then it's not an evil fork" contradiction of the premises.

At this point, I don't think I can be clearer about the main premise
of my example, sorry.

On Wed, Mar 23, 2022 at 12:50 AM Anthony Towns <aj at erisian.com.au> wrote:
>
> On Thu, Mar 17, 2022 at 03:04:32PM +0100, Jorge Timón via bitcoin-dev wrote:
> > On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns <aj at erisian.com.au> wrote:
> > > On Fri, Mar 11, 2022 at 02:04:29PM +0000, Jorge Timón via bitcoin-dev wrote:
> > > People opposed to having taproot transactions in their chain had over
> > > three years to do that coordination before an activation method was merged
> > > [0], and then an additional seven months after the activation method was merged before taproot enforcement began [1].
> > >
> > > [0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy
> > > trial activation parameters for mainnet and testnet were merged.
> > > [1] 2021-11-14
> > People may be opposed only to the final version, but not the initial
> > one or the fundamental concept.
> > Please, try to think of worse case scenarios.
>
> I mean, I've already spent a lot of time thinking through these worst
> cast scenarios, including the ones you bring up. Maybe I've come up with
> wrong or suboptimal conclusions about it, and I'm happy to discuss that,
> but it's a bit hard to avoid taking offense at the suggestion that I
> haven't even thought about it.
>
> In the case of taproot, the final substantive update to the BIP was PR#982
> merged on 2020-08-27 -- so even if you'd only been opposed to the changes
> in the final version (32B pubkeys perhaps?) you'd have had 1.5 months to
> raise those concerns before the code implementing taproot was merged,
> and 6 months to raise those concerns before activation parameters were
> set. If you'd been following the discussion outside of the code and BIP
> text, in the case of 32B pubkeys, you'd have had an additional 15 months
> from the time the idea was proposed on 2019-05-22 (or 2019-05-29 if you
> only follow optech's summaries) until it was included in the BIP.
>
> > Perhaps there's no opposition until after activation code has been
> > released and miners are already starting to signal.
> > Perhaps at that moment a reviewer comes and points out a fatal flaw.
>
> Perhaps there's no opposition until the change has been deployed and in
> wide use for 30 years. Aborting activation isn't the be-all and end-all
> of addressing problems with a proposal, and it's not going to be able to
> deal with every problem. For any problems that can be found before the
> change is deployed and in use, you want to find them while the proposal
> is being discussed.
>
>
>
> More broadly, what I don't think you're getting is that *any* method you
> can use to abort/veto/revert an activation that's occuring via BIP8 (with
> or without mandatory activation), can also be used to abort/veto/revert
> a speedy trial activation.
>
> Speedy trial simply changes two things: it allows a minority (~10%)
> of hashpower to abort the activation; and it guarantees a "yes" or "no"
> answer within three months, while with BIP343 you initially don't know
> when within a ~1 year period activation will occur.
>
> If you're part of an (apparent) minority trying to abort/veto/reject
> activation, this gives you an additional option: if you can get support
> from ~10% of hashpower, you can force an initial "no" answer within
> three months, at which point many of the people who were ignoring your
> arguments up until then may be willing to reconsider them.
>
> For example, I think Mark Friedenbach's concerns about unhashed pubkeys
> and quantum resistance don't make sense, and (therefore) aren't widely
> held; but if 10% of blocks during taproot's speedy trial had included a
> tagline indicating otherwise and prevented activation, that would have
> been pretty clear objective evidence that the concern was more widely
> held than I thought, and might be worth reconsidering. Likewise, there
> could have somehow been other problems that somehow were being ignored,
> that could have similarly been reprioritised in the same way.
>
> That's not the way that you *want* things to work -- ideally people
> should be raising the concerns beforehand, and they should be taken
> seriously and fixed or addressed beforehand. That did happen with Mark's
> concerns -- heck, I raised it as a question ~6 hours after Greg's original
> taproot proposal -- and it's directly addressed in the rationale section
> of BIP341.
>
> But in the worst case; maybe that doesn't happen. Maybe bitcoin-dev and
> other places are somehow being censored, or sensible critics are being
> demonised and ignored. The advantage of a hashrate veto here is that it's
> hard to fake and hard to censor -- whereas with mailing list messages and
> the like, it's both easy to fake (setup sockpuppets and pay troll farms)
> and easy to censor (ban/moderate people for spamming say). So as a last
> ditch "we've been censored, please take us seriously" method of protest,
> it seems worthwhile to have to me.
>
> (Of course, a 90% majority might *still* choose to not take the concerns
> of the 10% minority seriously, and just continue to ignore the concern
> and followup with an immediate mandatory activation. But if that's what
> happening, you can't stop it; you can't only choose whether you want to
> be a part of it, or leave)
>
> Another example: if we'd had a 3-month speedy trial for segwit, that would
> presumably have run from 2016-11-15 to 2017-02-15, and been successfully
> blocked by people objecting to segwit activation. That would have left a
> clean slate for either a simple and safe BIP149 style UASF activation of
> segwit (shaolinfry introduced the concept of "user activated softfork
> activation" in a post on 2017-02-25), or redesigning segwit to be
> compatible with covert ASICBoost (which Greg Maxwell revealed publicly
> on 2017-04-05, after apparently realising the potential interaction
> with segwit a month earlier) and retrying segwit activation with that
> approach via a new speedy trial later in the year.
>
> > > For comparison, the UASF activation attempt for segwit took between 4
> > > to 6 months to coordinate, assuming you start counting from either the
> > > "user activated soft fork" concept being raised on bitcoin-dev or the
> > > final params for BIP 148 being merged into the bips repo, and stop
> > > counting when segwit locked in.
> > That was extremely risky and could have been a disaster.
>
> The question that comment was addressing wasn't whether BIP148 was a
> good idea, it was how quickly users can coordinate a software update to
> respond to consensus rules heading in a direction they find unacceptable.
>
> All the risk and potential for disaster was due to the goals of BIP148:
> to get segwit locked in prior to its activation timeout in Nov 2017,
> even if only supported by a minority of hashrate.
>
> > > 2) If that somehow doesn't work, and people are pushing ahead with a
> > > consensus change despite significant reasonable opposition; the next
> > > thing to do would be to establish if either side is a paper tiger
> > > and setup a futures market. That has the extra benefit of giving
> > > miners some information about which (combination of) rules will be
> > > most profitable to mine for.
> > >
> > > Once that's setup and price discovery happens, one side or the other
> > > will probably throw in the towel -- there's not much point have a
> > > money that other people aren't interested in using. (And that more
> > > or less is what happened with 2X)
> > Future markets can be manipulated.
>
> Futures markets measure people's beliefs weighted by wealth and
> confidence; and unlike with hashrate signalling there's a real cost to
> lying/being wrong. They're certainly not perfect, but nothing is.
>
> > Regarding 2x, that's not how I remember it. If I remember correctly,
> > "discovered" a price in btc for bcash that was
> > orders of magnitude higher than what it is today.
>
> 2x and BCH were two different things.
>
> For BCH, the only futures market was run by viabtc (one of the main
> advocates of BCH), was only available a week before the split, and was
> (I think?) only available to Chinese investors (at least, it was only
> traded against CNY). Nevertheless, the price stabilised at around
> $300USD equivalent (0.1 BTC) prior to the split, and that was fairly
> in line with the spot price after the split had occurred. That price
> dropped during the next two weeks to ~0.07 BTC, then rose to ~0.2 BTC,
> and has since dropped to ~0.008 BTC. Coincidentally that's about $300USD
> in today's market, so if you're pricing things in USD, the futures market
> was actually weirdly accurate.
>
> Viabtc also launched a market for BIP148, though in addition to the
> problems with its BCH market, it was pretty unusable in that if the
> BIP148-valid chain was the most-work chain, the BIP148 token wouldn't
> be redeemed.
>
> But the 2x market I was thinking of was bitfinex's; afaik bitfinex is
> reasonably unbiased, the market was fairly accessible and could be traded
> against the USD, and it was open for a month before the question of 2x
> was definitevely resolved. The discovered price was about 0.2 BTC up
> until it was announced that 2x was being abandoned at which point it
> dropped to something like 0.02 BTC, representing holding costs until
> the market was finalised about 2 months later.
>
> > > If a futures market like that is going to be setup, I think it's
> > > best if it happens before signalling for the soft fork starts --
> > > the information miners will get from it is useful for figuring out
> > > how much resources to invest in signalling, eg. I think it might even
> > > be feasible to set something up even before activation parameters are
> > > finalised; you need something more than just one-on-one twitter bets
> > > to get meaningful price discovery, but I think you could probably
> > > build something based on a reasonably unbiassed oracle declaring an
> > > outcome, without precisely defined parameters fixed in a BIP.
> > Whatever miners signal, until there are two chains and their real
> > rewards can be traded, it's hard to know what they will mine
> > afterwards.
>
> I don't agree. The BCH futures market accurately predicted the rewards
> (and hence hashrate) for mining BCH in the first couple of weeks after
> the split.
>
> On the same basis, the 2x futures market predicted that mining the 2x
> chain would be massively unprofitable: immediately after the split,
> both the 2x chain and the original-rules chain would have the same
> difficulty and hence have the same expected cost to mine a block; but
> the 2x chain would only have 25% of the reward (0.2 vs 0.8 valuation per
> the futures market). Without someone subsidising the first 2016 blocks on
> the 2x chain to the tune of about ~15,000 pre-split bitcoin (or ~75,000
> post-split 2x coins; or between $80M-$150M USD), either directly, or by
> mining at an economic loss, the 2x chain could only collapse.
>
> BCH avoided that fate by having a new difficulty adjustment algorithm
> that allowed the difficulty to drop immediately, rather than only on
> the next 2016 block boundary.
>
> > They could signal a change with 100% and then after it is activated on
> > one chain and resisted on another, they 95% of them may switch to the
> > old chain simply because its rewards are 20 times more valuable. This
> > may happen 3 days after activation or 3 months, or more.
>
> If it's an either-or choice, it's likely that 99.9% of hashrate will
> switch even if the rewards are only 0.1 times more valuable (or 1.1
> times as valuable if you prefer). That's why you run a futures market,
> to figure out which will be more valuable and by how much.
>
> We saw the either-or case happen with BCH vs BTC; the difficulty of BCH
> would drop quickly due to the "EDA", but only rise slowly, making BCH
> mining more profitable for an extended period so that opportunistic miners
> would switch to BCH for a while until it got expensive again then switch
> back to BTC, causing both chains' hashrate to be unstable.
>
> But if you don't hard fork to a different difficulty adjustment algorithm
> the way BCH did on day one, then it doesn't matter how long miners
> don't mine on your chain, your chain's difficulty won't adjust, and so
> you'll need to instead wait until BTC's difficulty doubles or more,
> or its reward halves or more, or some combination of the two. That's
> likely much more than 3 months away. I can't imagine why anyone would
> still care about your proposed chain months or years later.
>
> So hardforking in merge-mining (so it's not an either-or question) or
> a new difficulty adjustment algorithm (so you don't have to wait months
> or years) seems a much more realistic approach.
>
> > > So if acting like reasonable people and talking it through doesn't
> > > work, this seems like the next step to me.
> > Not to me, but you're free to create your future markets or trade in them.
> > I wouldn't do any of them, and I would advice against it.
>
> *shrug* Do what you like (and I mean, I don't trade in futures markets
> either) but I think you'd be missing out on very useful information,
> and losing a chance for people who aren't devs to offer tangible and
> objective support for your cause.
>
> > > I think the speedy trial approach here is ideal for a last ditch
> > > "everyone stays on the same chain while avoiding this horrible change"
> > > attempt. The reason being that it allows everyone to agree to not
> > > adopt the new rules with only very little cost: all you need is for
> > > 10% of hashpower to not signal over a three month period.
> > No, 10% of hashpower is not "very little cost", that's very expensive.
>
> If we're talking about consensus changes, the target is 100% of hashpower,
> and also something approaching 100% of nodes. By comparison 10% of
> hashpower is *much* cheaper, especially when the 100% have to actively
> upgrade in order to support, while the 10% just have to not do anything
> in order to oppose.
>
> To be clear: You don't have to setup the 10% of hashpower yourself,
> you just have to convince the existing owners of 10% of hashpower to
> not actively support the change.
>
> > > That's cheaper than bip9 (5% over 12 months requires 2x the
> > > cumulative hashpower), and much cheaper than bip8 which requires
> > > users to update their software
> > Updating software is not expensive. the code for bip8 could have been
> > merged long before taproot was even initially proposed.
> > It could be merged now before another proposal.
>
> The BIP8 spec we have today is very different to the BIP8 spec when
> taproot was merged, let alone before it was even proposed. As it was,
> it had serious problems that hadn't been addressed, and the version we
> have today likewise has significant problems that haven't been addressed,
> which is why it wasn't and shouldn't be merged.
>
> > Updating software is certainly not more expensive than getting 10% of
> > the hashrate.
>
> Updating software (or not updating software) is precisely *how* to get
> 10% of hashrate. It's not more or less expensive -- it *is* the expense.
>
> > > 4) At this point, if you were able to prevent activation, hopefully
> > > that's enough of a power move that people will take your concerns
> > > seriously, and you get a second chance at step (1). If that still
> > > results in an impasse, I'd expect there to be a second, non-speedy
> > > activation of the soft fork, that either cannot be blocked at all, or
> > > cannot be blocked without having control of at least 60% of hashpower.
> > And if you never got 10% hashpower, we move to the next step, I guess.
>
> Yes; you then move to the next step knowing that what level of
> interest/support you actually have.
>
> > > 5) If you weren't able to prevent activation (whether or not you
> > > prevented speedy trial from working), then you should have a lot
> > > of information:
> > >
> > > - you weren't able to convince people there was a problem
> > >
> > > - you either weren't in the economic majority and people don't
> > > think your concept of bitcoin is more valuable (perhaps they
> > > don't even think it's valuable enough to setup a futures market
> > > for you)
> > >
> > > - you can't get control of even 10% of hashpower for a few months
> > >
> > > and your only option is to accept defeat or create a new chain.
> > What if it's still the other people who are lacking information?
>
> If it's other people that lack information, there's two options. One,
> you might be able to explain things to them, so that they learn and gain
> the information. The other is that for whatever reason they're not willing
> to listen to the truth and will remain ignorant. If it's the first case,
> you'd have succeeded in an earlier step. If it's the latter, then it's
> not something you can change, and it doesn't really matter in how you
> decide what to do next.
>
> > It wouldn't be a new chain, it would be the old chain without the new
> > evil change, until you manage to show the other people that the change
> > was indeed evil.
> > Remember, in this example, the new change being evil is not a
> > possibility, but an assumption.
>
> It's extremely unhelpful to call things "evil" if what you want is a
> reasonable discussion. And if reasonable discussion isn't what you want,
> you're in the wrong place.
>
> At this point in the hypothetical you're in a small minority, and have
> been unable to convince people of your point of view. Calling the people
> you disagree with "evil" (and saying they support something that's evil
> is exactly that) isn't going to improve your situation, and doing it in
> a hypothetical sure feels like bad faith.
>
> > What you're arguing is "if you haven't been able to stop the evil
> > change, then perhaps it wasn't evil all along and the people trying to
> > resist it were wrong and don't know it".
>
> If it's an evil change, then good people will oppose it. You've tried
> convincing devs in the "discuss the proposal" stage, whales in the
> "futures market" stage, and miners in the "hashpower signalling" phase,
> and failed each time because the good people in each of those groups
> haven't opposed it. So yes, I think the most likely explanation is that
> you're wrong in thinking it's evil.
>
> But hey what about the worst case: what if everyone else in bitcoin
> is evil and supports doing evil things. And maybe that's not even
> implausible: maybe it's not an "evil" thing per se, perhaps it's simply
> equally "misguided" as the things that central banks or wall street or
> similar are doing today. Perhaps bitcoin becomes the world currency,
> and in 100 or 200 years time, whether through complacency and forgetting
> the lessons of the past, or too much adherence to dogma that no longer
> matches reality, or just hitting some new problem that's never been seen
> before and an inability to perfectly predict the future, and as a result
> most of the world opts into some change that will cause bitcoin to fail.
>
> In that scenario, I think a hard fork is the best choice: split out a new
> coin that will survive the upcoming crash, adjust the mining/difficulty
> algorithm so it works from day one, and set it up so that you can
> maintain it along with the people who support your vision, rather than
> having to constantly deal with well-meaning attacks from "bitcoiners"
> who don't see the risks and have lost the plot.
>
> Basically: do what Satoshi did and create a better system, and let
> everyone else join you as the problems with the old one eventually become
> unavoidably obvious.
>
> > But that contradicts the premise: an evil change being deployed using
> > speedy trial.
>
> Again: any change that could be avoided if it were deployed via BIP8,
> can also be avoided *by the exact same techniques* if it were deployed
> via speedy trial or a similar approach.
>
> > > Since your new chain won't have a hashpower majority, you'll likely
> > > have significant problems if you don't hard fork in a change to
> > > how proof-of-work works; my guess is you'd either want to switch
> > > to a different proof-of-work algorithm, or make your chain able
> > > to be merge-mined against bitcoin, though just following BCH/BSV's
> > > example and tweaking the difficulty adjustment to be more dynamic
> > > could work too.
> > No, I disagree. You'll just get the hashpower you pay for with subsidy and fees.
>
> The value of the subsidy is something you can directly figure out from
> running a futures market; and unless you're deliberately subsidising fees,
> they'll almost certainly be ~0.
>
> > > (For comparison, apparently BCH has 0.8% of bitcoin's hashrate,
> > > BSV has 0.2%. Meanwhile, Namecoin, RSK and Syscoin, which support
> > > merge-mining, are apparently at 68%, 42% and 17% respectively)
> > Google tells me 0.0073BTC.
>
> I think you're reading too much precision into those numbers? When
> I looked again the other day, I got a figure of 0.66%; today I get
> 0.75%. I'm sure I rounded whatever figure I saw to one significant figure,
> so it might have been 0.75% then too.
>
> https://bitinfocharts.com/comparison/bitcoin-hashrate.html#3y
> https://bitinfocharts.com/comparison/bitcoin%20cash-hashrate.html#3y
>
> > In perfect competition and leaving fees aside (in which probably
> > bitcoin wins too), BCH should have approximately 0.0073% the hashrate
> > bitcoin hash.
>
> Oh, or you're just getting the percentage conversion wrong -- 0.0073
> BTC is 0.73% of a BTC, and thus it would be expected to have about 0.73%
> of the hashrate.
>
> > > At the point that you're doing a hard fork, making a clean split is
> > > straightforward: schedule the hard fork for around the same time as
> > > the start of enforcement of the soft fork you oppose, work out how
> > > to make sure you're on your own p2p network, and figure out how
> > > exchanges and lightning channels and everything else are going to
> > > cope with the coin split.
> > You shouldn't need to do a hardfork to resist a consensus change you don't like.
>
> Of course; that's why option (1) is to talk to people about why it's a
> bad idea so it doesn't get proposed in the first place.
>
> But if you want to resist a consensus change that is overwhelmingly
> supported by the rest of the bitcoin economy, and for which your reasons
> aren't even considered particularly logical by everyone else, then yeah,
> if you really want to go off on your own because everyone else is wrong,
> you *should* do a hardfork.
>
> If a change doesn't have overwhelming support, then hopefully the costs
> to get 90% of hashrate signalling is a significant impediment. If you do
> have overwhelming support, then the cost to get 90% of hashrate signalling
> (or even apparently 99.8%, see getdeploymentinfo on block 693503) --
> doesn't seem to be too bad.
>
> > "around the same time", with bip8 and the resistance mechanism
> > proposed by luke, it doesn't need to be "around the same time
> > according to some expert who will tell you what to put in your
> > software", but "exactly at the same time, and you only need to know
> > which pproposal version bit you're opposing".
>
> (Arguing semantics: You can't do the split at exactly the same time,
> because the split starts with each chain finding a new block, and blocks
> are found probabilistically depending on hashrate, so they won't be found
> at the same time. Or, alternatively, the split happens whenever either
> client considers the other chain invalid, and always happens at the
> "same" time)
>
> If you want to do things at exactly the same height, you can do that if
> the soft fork is activated by speedy trial as well.
>
> I'd say the same height approach works better on speedy trial than
> with BIP8/BIP343, since with speedy trial signalling is only for a
> short period, and hence you know well in advance if and when you'll be
> splitting, whereas with an extended signalling period that goes for a
> year past the minimum activation height, you may find yourself splitting
> at any point in that year with as little as two week's notice.
>
> If I were doing a hardfork coin split to avoid following some new soft
> forked rules that I think were horrible, I think I'd prefer to do the
> split in advance of the softfork -- that way exchanges/wallets/lightning
> channels/etc that have to do work to deal with the coinsplit aren't
> distracted by simultaneously having to pay attention to the new softfork.
> YMMV of course.
>
> > Yeah, great example. It doesn't have to be an "evil change" as such,
> > it can just be a "deeply wrong change" or something.
> > Or if we were using BIP8 and had the resistance mechanism proposed by
> > luke, all we would need to do is change one line and recompile:
> > I don't remember his enumeration constants but, something like...
> > - bip8Params.EvilProposalActivationMode = FORCE_ACTIVATION;
> > + bip8Params.EvilProposalActivationMode = FORBID_ACTIVATION;
> > Say we discover it 3 days before forced activation.
> > Well, that would still be much less rushed that the berkeleyDB thing,
> > wouldn't it?
>
> No, exactly the opposite.
>
> In order to abort a BIP8 activation, 100% of hashpower and 100% of
> node software needs to downgrade from anything that specifies BIP8 with
> mandatory activation.
>
> The "berkelyDB thing" was an accidental hard fork due to the updated
> software with leveldb being able to accept larger blocks than the old
> bdb-based bitcoind could.
>
> The result was two chains: one with a large block in it, that could
> only be validated by the newer software, and a less work chain with only
> smaller chains, that could be validated by both versions of the software;
> the problem was ~60% of hashpower was on the larger-block chain, but
> many nodes including those with ~40% hashpower. The problem was quickly
> mitigated by encouraging a majority of hashpower to downgrade to the
> old software, resulting in them rejecting the larger-block chain,
> at which point a majority of hashpower was mining the smaller-block
> chain, and the smaller-block chain eventually having more work than
> the larger-block chain. At that point any newer nodes reorged to the
> more-work, smaller-block chain, and everyone was following the same chain.
>
> What that means is that the operators of *two* pools downgraded their
> software, and everything was fixed. That's a *lot* less work than
> everyone who upgraded their node having to downgrade/re-update, and
> it was done that way to *avoid* having to rush to get everyone to do
> an emergency update of their node software to be compatible with the
> larger-block chain.
>
> See https://bitcoin.org/en/alert/2013-03-11-chain-fork
> and https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
>
> On the other hand, that approach only works because it takes advantage
> of a lot of hashrate being centralised around a few pools; if we succeed
> in making block construction more decentralised, solutions here will
> only become harder.
>
> > If there's only opposition after it is deployed, whatever the
> > activation mechanism, in that particular case, would be irrelevant.
>
> Once you've released software with a softfork activated via BIP8 with
> mandatory activation (ie, lot=true), and it has achieved any significant
> adoption, the soft fork is already deployed and you need to treat it as
> such. If you want to have an easier way of undoing the softfork than
> you would have for one that's already active on the network, you need
> a different activation method than BIP8/lot=true.
>
> Cheers,
> aj
>

📅 Original date posted:2022-03-17 📝 Original message:On ...

2023-06-08T01:06:14+02:00

In reply to nevent1q…m2wk
_________________________

📅 Original date posted:2022-03-17
📝 Original message:On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns <aj at erisian.com.au> wrote:
>
> On Fri, Mar 11, 2022 at 02:04:29PM +0000, Jorge Timón via bitcoin-dev wrote:
> People opposed to having taproot transactions in their chain had over
> three years to do that coordination before an activation method was merged
> [0], and then an additional seven months after the activation method was merged before taproot enforcement began [1].
>
> [0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy
> trial activation parameters for mainnet and testnet were merged.
> [1] 2021-11-14

People may be opposed only to the final version, but not the initial
one or the fundamental concept.
Please, try to think of worse case scenarios.
Perhaps there's no opposition until after activation code has been
released and miners are already starting to signal.
Perhaps at that moment a reviewer comes and points out a fatal flaw.

> For comparison, the UASF activation attempt for segwit took between 4
> to 6 months to coordinate, assuming you start counting from either the
> "user activated soft fork" concept being raised on bitcoin-dev or the
> final params for BIP 148 being merged into the bips repo, and stop
> counting when segwit locked in.

That was extremely risky and could have been a disaster. It went well,
but in my opinion a BIP8 approach from the beginning would have been
much less risky. Instead of improvising these things we should plan
ahead. But for "user forced" activations and for "user forced"
rejections.
Just remember you may reject your own code.

> > Please, try to imagine an example for an activation that you wouldn't like
> > yourself. Imagine it gets proposed and you, as a user, want to resist it.
>
> Sure. There's more steps than just "fork off onto a minority chain"
> though.
>
> 1) The first and most important step is to explain why you want to
> resist it, either to convince the proposers that there really is
> a problem and they should stand down, or so someone can come up
> with a way of fixing the proposal so you don't need to resist it.
> Ideally, that's all that's needed to resolve the objections. (That's
> what didn't happen with opposition to segwit)

Agreed, for any given proposal, the first approach should be rational
discussion.
Some times we consider other arguments irrational simply because we
don't understand them though.

> 2) If that somehow doesn't work, and people are pushing ahead with a
> consensus change despite significant reasonable opposition; the next
> thing to do would be to establish if either side is a paper tiger
> and setup a futures market. That has the extra benefit of giving
> miners some information about which (combination of) rules will be
> most profitable to mine for.
>
> Once that's setup and price discovery happens, one side or the other
> will probably throw in the towel -- there's not much point have a
> money that other people aren't interested in using. (And that more
> or less is what happened with 2X)

Future markets can be manipulated.
Regarding 2x, that's not how I remember it. If I remember correctly,
"discovered" a price in btc for bcash that was
orders of magnitude higher than what it is today.

> If a futures market like that is going to be setup, I think it's
> best if it happens before signalling for the soft fork starts --
> the information miners will get from it is useful for figuring out
> how much resources to invest in signalling, eg. I think it might even
> be feasible to set something up even before activation parameters are
> finalised; you need something more than just one-on-one twitter bets
> to get meaningful price discovery, but I think you could probably
> build something based on a reasonably unbiassed oracle declaring an
> outcome, without precisely defined parameters fixed in a BIP.

Whatever miners signal, until there are two chains and their real
rewards can be traded, it's hard to know what they will mine
afterwards.
They could signal a change with 100% and then after it is activated on
one chain and resisted on another, they 95% of them may switch to the
old chain simply because its rewards are 20 times more valuable. This
may happen 3 days after activation or 3 months, or more.
It could depend on how fast some relevant information about the new
change spreads.
Which is specially hard to estimate in a censored world like ours.

> So if acting like reasonable people and talking it through doesn't
> work, this seems like the next step to me.

Not to me, but you're free to create your future markets or trade in them.
I wouldn't do any of them, and I would advice against it.

> 3) But maybe you try both those and they fail and people start trying
> to activate the soft fork (or perhaps you just weren't paying
> attention until it was too late, and missed the opportunity).

Yes, some changes may be rejected late because some people weren't
paying attention or weren't paid attention, indeed.
Or perhaps it's your own proposal and you realize it is flawed
yourself. There are infinite hypothetical scenarios we could consider
for this to happen.

> I think the speedy trial approach here is ideal for a last ditch
> "everyone stays on the same chain while avoiding this horrible change"
> attempt. The reason being that it allows everyone to agree to not
> adopt the new rules with only very little cost: all you need is for
> 10% of hashpower to not signal over a three month period.

No, 10% of hashpower is not "very little cost", that's very expensive.

> That's cheaper than bip9 (5% over 12 months requires 2x the
> cumulative hashpower), and much cheaper than bip8 which requires
> users to update their software

Updating software is not expensive. the code for bip8 could have been
merged long before taproot was even initially proposed.
It could be merged now before another proposal.
Updating software is certainly not more expensive than getting 10% of
the hashrate.

> 4) At this point, if you were able to prevent activation, hopefully
> that's enough of a power move that people will take your concerns
> seriously, and you get a second chance at step (1). If that still
> results in an impasse, I'd expect there to be a second, non-speedy
> activation of the soft fork, that either cannot be blocked at all, or
> cannot be blocked without having control of at least 60% of hashpower.

And if you never got 10% hashpower, we move to the next step, I guess.

> 5) If you weren't able to prevent activation (whether or not you
> prevented speedy trial from working), then you should have a lot
> of information:
>
> - you weren't able to convince people there was a problem
>
> - you either weren't in the economic majority and people don't
> think your concept of bitcoin is more valuable (perhaps they
> don't even think it's valuable enough to setup a futures market
> for you)
>
> - you can't get control of even 10% of hashpower for a few months
>
> and your only option is to accept defeat or create a new chain.

What if it's still the other people who are lacking information?
It wouldn't be a new chain, it would be the old chain without the new
evil change, until you manage to show the other people that the change
was indeed evil.
Remember, in this example, the new change being evil is not a
possibility, but an assumption.
What you're arguing is "if you haven't been able to stop the evil
change, then perhaps it wasn't evil all along and the people trying to
resist it were wrong and don't know it".
But that contradicts the premise: an evil change being deployed using
speedy trial.

> Since your new chain won't have a hashpower majority, you'll likely
> have significant problems if you don't hard fork in a change to
> how proof-of-work works; my guess is you'd either want to switch
> to a different proof-of-work algorithm, or make your chain able
> to be merge-mined against bitcoin, though just following BCH/BSV's
> example and tweaking the difficulty adjustment to be more dynamic
> could work too.

No, I disagree. You'll just get the hashpower you pay for with subsidy and fees.
A better difficulty update filter and merge mining could help you, I
guess. But that could be a threat on its own.
Also, as pointed out earlier, "mining majority" is dynamic and depends
on the rewards.

> (For comparison, apparently BCH has 0.8% of bitcoin's hashrate,
> BSV has 0.2%. Meanwhile, Namecoin, RSK and Syscoin, which support
> merge-mining, are apparently at 68%, 42% and 17% respectively)

Google tells me 0.0073BTC.
In perfect competition and leaving fees aside (in which probably
bitcoin wins too), BCH should have approximately 0.0073% the hashrate
bitcoin hash. This tells me someone who likes BCH is throwing money
away to subsidize its security.
Or perhaps it's something else I'm not taking into account or your
estimate is wrong.
But BCH having 0.8% of bitcoin's hashrate sounds like too much to me.
And yet, what did your future markers "discovered" pre hard fork?

> At the point that you're doing a hard fork, making a clean split is
> straightforward: schedule the hard fork for around the same time as
> the start of enforcement of the soft fork you oppose, work out how
> to make sure you're on your own p2p network, and figure out how
> exchanges and lightning channels and everything else are going to
> cope with the coin split.

You shouldn't need to do a hardfork to resist a consensus change you don't like.
"around the same time", with bip8 and the resistance mechanism
proposed by luke, it doesn't need to be "around the same time
according to some expert who will tell you what to put in your
software", but "exactly at the same time, and you only need to know
which pproposal version bit you're opposing".

> 6) There's potentially also the case where a soft fork locks-in
> and later everyone realises the people who were opposing it were
> right all along and the fork is a really bad idea.
>
> If everyone agreed that some idea was irredeemably bad -- eg,
> OP_VERIF -- then we could soft fork them out and just forbid
> blocks/transactions that attempt to use them. Or conceivably we could
> do a hardfork and have more options about how to fix the problem.

Yeah, great example. It doesn't have to be an "evil change" as such,
it can just be a "deeply wrong change" or something.
Or if we were using BIP8 and had the resistance mechanism proposed by
luke, all we would need to do is change one line and recompile:
I don't remember his enumeration constants but, something like...

- bip8Params.EvilProposalActivationMode = FORCE_ACTIVATION;
+ bip8Params.EvilProposalActivationMode = FORBID_ACTIVATION;

Say we discover it 3 days before forced activation.
Well, that would still be much less rushed that the berkeleyDB thing,
wouldn't it?
As you point out, after activation it is much more painful to fix
things. In some cases a hardfork may be the best solution a
posteriori, but I guess that gets out of the scope for activation
mechanisms.
If there's only opposition after it is deployed, whatever the
activation mechanism, in that particular case, would be irrelevant.
Whatever evil change it was, we would have probably swallowed whatever
the activation mechanism, because we only thought it evil or wrong a
posteriori.

📅 Original date posted:2022-03-18 📝 Original message:On ...

2023-06-08T01:06:06+02:00

In reply to nevent1q…tnn2
_________________________

📅 Original date posted:2022-03-18
📝 Original message:On Tue, Mar 15, 2022 at 6:25 PM Jeremy Rubin via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Boker tov bitcoin devs,

I don't undesrtand what that means, sorry

>> A mechanism of soft-forking against activation exists. What more do you want?
>
>
> Agreed -- that should be enough.

No, resistance should ideally be a priori, not a posteriori.

>
>>
>> Are we supposed to write the code on behalf of this hypothetical group of users who may or may not exist for them just so that they can have a node that remains stalled on Speedy Trial lockin?
>>
>> That simply isn't reasonable, but if you think it is, I invite you to create such a fork.
>
>
> Disagree.
>
> It is a reasonable ask.
>
> I've done it in about 40 lines of python: https://github.com/jeremyrubin/forkd
>
> Merry Christmas Jorge, please vet the code carefully before running.

40 lines of python code should be easy to bet even if the author was
very bad at writing readable code and obfuscated his code on purpose.
I don't know if it's the case, because, sorry, I'm not reviewing your
code at the moment.
"Vet the code carefully before running" strikes me as arrogant and
condescending. as if you were implying my engineering capacity was
very limited. If you say these things to me publicly, I can only only
imagine what you have told other devs behind my back about my capacity
(or even my ideology) if they ever asked (or perhaps without them
asking). I really hope you haven't lied to anyone about my ideology,
J.
Perhaps I do have "prosectution complex" with you indeed. Not with
Russel, but with you.
After all, I've publicly say I don't trust you, haven't I?
But, again, what do I know about psychology?

Going back on topic, the reason I won't review your code is because
you have rushed a design before understanding the analysis.
No, I'm not asking for a stalled mechanism for speedy trial, I don't
want speedy trial.
We disagree on the analysis of the problem to solve, that's why we
disagree on the design for the solution.

https://en.wikipedia.org/wiki/Systems_development_life_cycle#Analysis

Anyway, perhaps I look at the code in the future if your proposal
consensus change seems to prosper.

Regarding "merry christmas"...what the f are you talking about? it's
not Christmas time and neither you or me are christians, are you?
If this is some sort of riddle or joke, we really must have very
different senses of humor, because I don't get it.
Come on, J, let's both try to stay on topic or people will start to
correctly point out that we both negatively discriminate each other
for offtopic reasons, be them reasonably justified or not.

> Peace,

Ama, y ensancha el alma.

> Jeremy
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-03-17 📝 Original message:On ...

2023-06-08T01:06:06+02:00

In reply to nevent1q…edqd
_________________________

📅 Original date posted:2022-03-17
📝 Original message:On Sat, Mar 12, 2022 at 2:35 PM Russell O'Connor via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón <jtimon at jtimon.cc> wrote:
> A mechanism of soft-forking against activation exists. What more do you want? Are we supposed to write the code on behalf of this hypothetical group of users who may or may not exist for them just so that they can have a node that remains stalled on Speedy Trial lockin? That simply isn't reasonable, but if you think it is, I invite you to create such a fork.

I want BIP+LOT=true to be used. I want speedy trial not to be used.
Luke wrote the code to resist BIP8+LOT=true, and if he didn't, I could
write it myself, yes.
If you think that's not reasonable code to ever run, I don't think
you're really getting the "softfork THAT YOU OPPOSE" part of the
hypothetical right. Let me try to help with an example, although I
hope we don't get derailed in the implementation details of the
hypothetical evil proposal.

Suppose someone proposes a weight size limit increase by a extension
block softfork.
Or instead of that, just imagine the final version of the covenants
proposal has a backdoor in it or something.

Would you rather that proposal be deployed with speedy trial
activation or with BIP8+LOT=true activation?

>>
>> Please, try to imagine an example for an activation that you wouldn't like yourself. Imagine it gets proposed and you, as a user, want to resist it.
>
>
> If I believe I'm in the economic majority then I'll just refuse to upgrade my node, which was option 2. I don't know why you dismissed it.

Not upgrading your node doesn't prevent the softfork from being
activated in your chain.
A softfork may affect you indirectly even if you don't use the new
features yourself directly.
You may chose to stay in the old chain even if you don't consider
you're "in the economic majority" at that moment.

> Not much can prevent a miner cartel from enforcing rules that users don't want other than hard forking a replacement POW. There is no effective difference between some developers releasing a malicious soft-fork of Bitcoin and the miners releasing a malicious version themselves. And when the miner cartel forms, they aren't necessarily going to be polite enough to give a transparent signal of their new rules. However, without the economic majority enforcing their set of rules, the cartel continuously risks falling apart from the temptation of transaction fees of the censored transactions.

It is true that a mining cartel doesn't need to use speedy trial or
BIP8+LOT=true to apply rule changes they want just because we do.
But they would do if they wanted to maintain the appearance of benevolence.

> On the other hand, If I find out I'm in the economic minority then I have little choice but to either accept the existence of the new rules or sell my Bitcoin. Look, you cannot have the perfect system of money all by your lonesome self. Money doesn't have economic value if no one else wants to trade you for it. Just ask that poor user who YOLO'd his own taproot activation in advance all by themselves. I'm sure they think they've got just the perfect money system, with taproot early and everything. But now their node is stuck at block 692261 and hasn't made progress since. No doubt they are hunkered down for the long term, absolutely committed to their fork and just waiting for the rest of the world to come around to how much better their version of Bitcoin is than the rest of us.

Well, you could also have the option to stay in the old chain with the
economic minority, it doesn't have to be you alone.
We agree that one person alone can't use a currency.

> Even though you've dismissed it, one of the considerations of taproot was that it is opt-in for users to use the functionality. Future soft-forks ought to have the same considerations to the extent possible.

Well, the same could be said about segwit. And yet all the
consequences of the change are not opt in.
For example, segwit contained a block size limit increase.
Sure, you can just not validate the witnesses, but then you're no
longer a full node.

📅 Original date posted:2022-03-17 📝 Original message:On ...

2023-06-08T01:06:04+02:00

In reply to nevent1q…tzjy
_________________________

📅 Original date posted:2022-03-17
📝 Original message:On Sat, Mar 12, 2022 at 7:34 PM Billy Tetrud via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > If I find out I'm in the economic minority then I have little choice but to either accept the existence of the new rules or sell my Bitcoin
>
> I do worry about what I have called a "dumb majority soft fork". This is where, say, mainstream adoption has happened, some crisis of some magnitude happens that convinces a lot of people something needs to change now. Let's say it's another congestion period where fees spike for months. Getting into and out of lighting is hard and maybe even the security of lightning's security model is called into question because it would either take too long to get a transaction on chain or be too expensive. Panicy people might once again think something like "let's increase the block size to 1GB, then we'll never have this problem again". This could happen in a segwit-like soft fork.

I guess this is a better explained example for a hypothetical "evil
fork" that may sound more concrete and plausible to some people than
my own, which isn't that different. Thanks.

> In a future where Bitcoin is the dominant world currency, it might not be unrealistic to imagine that an economic majority might not understand why such a thing would be so dangerous, or think the risk is low enough to be worth it. At that point, we in the economic minority would need a plan to hard fork away. One wouldn't necessarily need to sell all their majority fork Bitcoin, but they could.
>
> That minority fork would of course need some mining power. How much? I don't know, but we should think about how small of a minority chain we could imagine might be worth saving. Is 5% enough? 1%? How long would the chain stall if hash power dropped to 1%?

In perfect competition the mining power costs per chain tends to equal
the rewards offered by that chain, both in subsidy and transaction
fees.
For example, if chain A gets a reward 10 times as valuable as chain
B's reward, then one should expect it to get 10 times more hashrate
too.
Of course, perfect competition is just a theoretical concept though.

📅 Original date posted:2021-06-29 📝 Original ...

2023-06-08T00:55:33+02:00

In reply to nevent1q…s20f
_________________________

📅 Original date posted:2021-06-29
📝 Original message:"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 "politicial". Isn't miners deciding
them for users more political? Whatever you call it, it is still how free
software works: users decide what to run.
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.
How can we expect users to understand bitcoin when most developers don't
seem to understand it?

It is really sad.

On Tue, Jun 29, 2021, 19:17 Eric Voskuil <eric at voskuil.org> wrote:

>
> > On Jun 29, 2021, at 10:55, Luke Dashjr <luke at dashjr.org> 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:44:56 Eric Voskuil wrote:
> >> 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 <jtimon at jtimon.cc> 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
> >>> possible, I don't think we should avoid splits at all costs.
> >>>
> >>>> On Sun, Jun 27, 2021, 19:12 Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
> >>>> @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 estimates can sometimes
> be
> >>>> wildly wrong. It would be unfortunate if miners had a substantially
> >>>> different estimate of user support than the people putting in the work
> >>>> to release bitcoin upgrades. Even if upgrades are never released
> before
> >>>> it becomes clear that a large supermajority of users want the upgrade,
> >>>> if miners don't agree with the estimate a harmful chain split could
> >>>> occur. And I agree with Eric that the goal here is to prevent a chain
> >>>> split during an upgrade when possible. This includes permanent failure
> >>>> of an upgrade when there is unexpectedly large miner opposition.
> >>>>
> >>>> This of course does not prevent a UASF-style deployment to be done
> after
> >>>> an initial failure to deploy occurs. My proposal is essentially a
> >>>> mechanism to improve upon the speedy-trial idea, allowing for even
> >>>> speedier releases (than speedy trial) without adding additional risk
> of
> >>>> undesired chain splits.
> >>>>
> >>>>> [BIP8] already has the trinary state you seem to be describing
> >>>>
> >>>> It sounds like you're saying the trinary state of BIP8 is A. Follow
> the
> >>>> longest chain, B. Follow the upgrade chain, or C. follow the
> >>>> non-upgraded chain. I agree. However the trinary state in my proposal
> is
> >>>> materially different - it is the signaling itself that is trinary, not
> >>>> just which chain is being followed. This allows others to know and
> make
> >>>> programmatic decisions (in software) based on that signaling. I'm sure
> >>>> you can agree that does not exist in BIP8.
> >>>>
> >>>>> No additional bit is needed, as softforks are coordinated between
> >>>>> users, NOT miners
> >>>>
> >>>> And yet there is miner involvement, as you rightly pointed out. Miners
> >>>> are needed to set the nVersion in the header. So when you say "no
> >>>> additional bit is needed", could you please be clearer as to what you
> >>>> mean? Do you mean that signaling of opposition in a block can be done
> >>>> without any "additional bit"? Or are you just saying that it is
> >>>> redundant to consider what miners might be opposing an upgrade?
> >>>>
> >>>> @Jorge
> >>>>
> >>>>> If different users want different incompatible things... there's no
> >>>>> way to avoid the split
> >>>>
> >>>> I agree. This happened with bcash, and that's fine. It was painful,
> but
> >>>> there were a significant amount of users that disagreed, and they have
> >>>> the chain they want now.
> >>>>
> >>>> But we generally all want to avoid a chain split when possible.
> Because
> >>>> chain splits have a cost, and that cost can be high, its likely that
> >>>> many users would rather choose the chain with the most support rather
> >>>> than choosing the chain with their preferred rules.
> >>>>
> >>>> However, the question here is: how do we estimate what fraction of
> users
> >>>> wants which rules? We don't have a divining rod to determine with
> >>>> certainty what users want. We can only make polls of various levels of
> >>>> inaccuracy. The methods bitcoin has been using is community discussion
> >>>> and social consensus estimation as well as miner signaling during the
> >>>> actual deployment period. Neither of these are perfect, but they are
> >>>> both reasonable enough mechanisms. However, because both of these
> >>>> mechanisms are very rough estimates of user sentiment, we need to
> >>>> consider the possibility that sometimes the estimate may be
> >>>> substantially inaccurate when we design deployment procedures. This
> >>>> inaccuracy is why we need multiple barriers in place for an upgrade,
> and
> >>>> why we need to have higher thresholds of success (require larger
> >>>> supermajorities in both consensus and miner signaling).
> >>>>
> >>>> Developers obviously care about bitcoin and have an incentive
> (personal
> >>>> and probably financial) to do it right. And miners have both an
> >>>> incentive to keep the system healthy, as well as an incentive to mine
> on
> >>>> the chain that the economic majority of users is using. But measuring
> >>>> the consensus of the bitcoin community can be extraordinarily
> difficult
> >>>> to do with consistent accuracy, and so I think miner signaling as it
> has
> >>>> been used as a second barrier to entry for an upgrade is quite
> >>>> appropriate.
> >>>>
> >>>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil <eric at voskuil.org>
> wrote:
> >>>>> 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 that I object to. People who know better should be
> >>>>> honest about it.
> >>>>>
> >>>>> Far too many people have been led to believe there is some sort of
> >>>>> activation choice with “ensured” equal outcomes (maybe “slowed
> down”).
> >>>>> There is only a choice between creating a split and hash power
> >>>>> enforcement. Soft forks are rule changes, and thereby incompatible -
> >>>>> unless enforced by majority hash power.
> >>>>>
> >>>>> The statements below are grossly misleading and need to be called out
> >>>>> as such so that people can actually make this decision you speak of.
> >>>>> This idea that “users” decide the rules is not the question. The
> >>>>> question is only how to avoid a split. If one does not care he can
> >>>>> split at any time, no discussion required.
> >>>>>
> >>>>> e
> >>>>>
> >>>>>> On Jun 27, 2021, at 01:47, Jorge Timón <jtimon at jtimon.cc> wrote:
> >>>>>>
> >>>>>> 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
> >>>>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>>>>>
> >>>>>>> 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 this question of conflicting wants, but it is not a
> >>>>>>> democracy, it’s a market. One votes by trading.
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> Otherwise, as mentioned below, anyone can start a new coin. But
> it’s
> >>>>>>> dishonest to imply that one can do this and all others will surely
> >>>>>>> follow. This cannot be known, it’s merely a gamble. And it’s one
> >>>>>>> that has been shown to not always pay off.
> >>>>>>>
> >>>>>>> e
> >>>>>>>
> >>>>>>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric at voskuil.org>
> wrote:
> >>>>>>>>
> >>>>>>>> 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. The relevant question is
> >>>>>>>> how to *prevent* a split. And activation without majority hash
> >>>>>>>> power certainly does not “ensure” this.
> >>>>>>>>
> >>>>>>>> e
> >>>>>>>>
> >>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev
> >>>>>>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>>>>>>>
> >>>>>>>>> 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
> >>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they
> do
> >>>>>>>>> not follow a chain with the rules in force.
> >>>>>>>>>
> >>>>>>>>> No additional bit is needed, as softforks are coordinated between
> >>>>>>>>> users, NOT miners (who have no particular say in them, aside from
> >>>>>>>>> their role as also being users). The miner involvement is only
> out
> >>>>>>>>> of necessity (to set the bit in the header, which users
> coordinate
> >>>>>>>>> with) and potentially to accelerate activation by protecting
> >>>>>>>>> upgrade-lagging users.
> >>>>>>>>>
> >>>>>>>>> Luke
> >>>>>>>>>
> >>>>>>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev
> >>>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> 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 releases of bitcoin
> >>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=false proponents make the point
> >>>>>>>>>> that LOT=true can lead to undesirable forks that might cause a
> >>>>>>>>>> lot of chaos. I believe both points are essentially correct and
> >>>>>>>>>> have created a proposal
> >>>>>>>>>> <
> https://github.com/fresheneesz/bip-trinary-version-signaling/blo
> >>>>>>>>>> b/master/b ip-trinary-version-bits.md> for soft fork upgrades
> that
> >>>>>>>>>> solve both problems.
> >>>>>>>>>>
> >>>>>>>>>> The proposal uses trinary version signaling rather than binary
> >>>>>>>>>> signaling. For any particular prospective soft fork upgrade,
> this
> >>>>>>>>>> allows for three signaling states:
> >>>>>>>>>>
> >>>>>>>>>> * Actively support the change.
> >>>>>>>>>> * Actively oppose the change.
> >>>>>>>>>> * Not signaling (neither support or oppose). This is the default
> >>>>>>>>>> state.
> >>>>>>>>>>
> >>>>>>>>>> Using this additional information, we can release
> non-contentious
> >>>>>>>>>> upgrades much quicker (with a much lower percent of miners
> >>>>>>>>>> signaling support). For contentious upgrades, miners who oppose
> >>>>>>>>>> the change are incentivized to update their software to a
> version
> >>>>>>>>>> that can actively signal opposition to the change. The more
> >>>>>>>>>> opposition there is, the higher the threshold necessary to lock
> >>>>>>>>>> in the upgrade. With the parameters I currently recommended in
> >>>>>>>>>> the proposal, this chart shows how much support signaling would
> >>>>>>>>>> be necessary given a particular amount of active opposition
> >>>>>>>>>> signaling:
> >>>>>>>>>>
> >>>>>>>>>> [image: thresholdChart.png]
> >>>>>>>>>> If literally no one signals opposition, a 60% threshold should
> be
> >>>>>>>>>> relatively safe because it is a supermajority amount that is
> >>>>>>>>>> unlikely to change significantly very quickly (ie if 60% of
> >>>>>>>>>> miners support the change today, its unlikely that less than a
> >>>>>>>>>> majority of miners would support the change a year or two from
> >>>>>>>>>> now), and if no one is signaling opposition, chances are that
> the
> >>>>>>>>>> vast majority of the other 40% would also eventually signal
> >>>>>>>>>> support.
> >>>>>>>>>>
> >>>>>>>>>> This both gives an incentive for "lazy" miners to upgrade if
> they
> >>>>>>>>>> actually oppose the change while at the same time allowing these
> >>>>>>>>>> lazy miners to remain lazy without slowing down the soft fork
> >>>>>>>>>> activation much.
> >>>>>>>>>>
> >>>>>>>>>> I think now is the right time to discuss new soft fork upgrade
> >>>>>>>>>> mechanisms, when there are no pressing soft fork upgrades ready
> >>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to
> discuss
> >>>>>>>>>> this will only delay things and cause contention again like it
> >>>>>>>>>> did with taproot.
> >>>>>>>>>>
> >>>>>>>>>> I'm very curious to know what people think of this mechanism. I
> >>>>>>>>>> would appreciate any comments here, or written as github issues
> >>>>>>>>>> on the proposal repo itself.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> BT
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> bitcoin-dev mailing list
> >>>>>>>>> bitcoin-dev at lists.linuxfoundation.org
> >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> bitcoin-dev mailing list
> >>>>>>> bitcoin-dev at lists.linuxfoundation.org
> >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210629/7edacdb9/attachment-0001.html>;

📅 Original date posted:2021-06-27 📝 Original message:If ...

2023-06-08T00:55:26+02:00

In reply to nevent1q…vvzx
_________________________

📅 Original date posted:2021-06-27
📝 Original message: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
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 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 this question of conflicting wants, but it is not a democracy, it’s a market. One votes by trading.
>
> 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.
>
> Otherwise, as mentioned below, anyone can start a new coin. But it’s dishonest to imply that one can do this and all others will surely follow. This cannot be known, it’s merely a gamble. And it’s one that has been shown to not always pay off.
>
> e
>
> > On Jun 26, 2021, at 14:43, Eric Voskuil <eric at voskuil.org> wrote:
> >
> > 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. The relevant question is how to *prevent* a split. And activation without majority hash power certainly does not “ensure” this.
> >
> > e
> >
> >> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> 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 signal (whether MASF or UASF) as
> >> invalid, thereby ensuring they do not follow a chain with the rules in force.
> >>
> >> No additional bit is needed, as softforks are coordinated between users, NOT
> >> miners (who have no particular say in them, aside from their role as also
> >> being users). The miner involvement is only out of necessity (to set the bit
> >> in the header, which users coordinate with) and potentially to accelerate
> >> activation by protecting upgrade-lagging users.
> >>
> >> Luke
> >>
> >>
> >>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote:
> >>> 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 releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
> >>> proponents make the point that LOT=true can lead to undesirable forks that
> >>> might cause a lot of chaos. I believe both points are essentially correct
> >>> and have created a proposal
> >>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/master/b
> >>> ip-trinary-version-bits.md> for soft fork upgrades that solve both problems.
> >>>
> >>> The proposal uses trinary version signaling rather than binary signaling.
> >>> For any particular prospective soft fork upgrade, this allows for three
> >>> signaling states:
> >>>
> >>> * Actively support the change.
> >>> * Actively oppose the change.
> >>> * Not signaling (neither support or oppose). This is the default state.
> >>>
> >>> Using this additional information, we can release non-contentious upgrades
> >>> much quicker (with a much lower percent of miners signaling support). For
> >>> contentious upgrades, miners who oppose the change are incentivized to
> >>> update their software to a version that can actively signal opposition to
> >>> the change. The more opposition there is, the higher the threshold
> >>> necessary to lock in the upgrade. With the parameters I currently
> >>> recommended in the proposal, this chart shows how much support signaling
> >>> would be necessary given a particular amount of active opposition
> >>> signaling:
> >>>
> >>> [image: thresholdChart.png]
> >>> If literally no one signals opposition, a 60% threshold should be
> >>> relatively safe because it is a supermajority amount that is unlikely to
> >>> change significantly very quickly (ie if 60% of miners support the change
> >>> today, its unlikely that less than a majority of miners would support the
> >>> change a year or two from now), and if no one is signaling opposition,
> >>> chances are that the vast majority of the other 40% would also eventually
> >>> signal support.
> >>>
> >>> This both gives an incentive for "lazy" miners to upgrade if they actually
> >>> oppose the change while at the same time allowing these lazy miners to
> >>> remain lazy without slowing down the soft fork activation much.
> >>>
> >>> I think now is the right time to discuss new soft fork upgrade mechanisms,
> >>> when there are no pressing soft fork upgrades ready to deploy. Waiting
> >>> until we need to deploy a soft fork to discuss this will only delay things
> >>> and cause contention again like it did with taproot.
> >>>
> >>> I'm very curious to know what people think of this mechanism. I would
> >>> appreciate any comments here, or written as github issues on the proposal
> >>> repo itself.
> >>>
> >>> Thanks,
> >>> BT
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-05-22 📝 Original message:That ...

2023-06-08T00:53:50+02:00

In reply to nevent1q…xvq8
_________________________

📅 Original date posted:2021-05-22
📝 Original message:That is clearly not true. People entretain making changes to the protocol
all the time. Bitcoin is far from perfect and not improving it would be
stupid in my opinion.
Some improvements require changes to the consensus rules.
Recent changes include relative lock time verify or segwit. These are
important changes that made things like lightning much easier and efficient
than they could possibly be without them.
Taproot, which is a recent proposal, could help simplify the lightning
protocol even further, and make it more efficient and its usage more
private. And there are more use cases.

There have been consensus rule changes since bitcoin started, and with good
reason. As a user, you can always oppose new changes. And if enough users
agree with you, you will be able to maintain your own chain with the old
rules. At the same time, there's nothing you can do to stop other users who
want those changes from coordinating with each other to adopt them.

Perhaps you're interested in bip99, which discusses consensus rule changes
in more detail.

On Sat, May 22, 2021, 13:09 Raystonn . via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Suggestions to make changes to Bitcoin's consensus protocol will only ever
> be entertained if Bitcoin is completely dead without such a change. Any
> attempt to change consensus protocol without a clear and convincing
> demonstration to the entire network of participants that Bitcoin will die
> without that change is a waste of your own time. Bitcoin's resistance to
> consensus changes is a feature that makes it resistant to being coopted and
> corrupted. I recommend developers focus on making improvements that do not
> attempt to change the consensus protocol. Otherwise, you are simply
> working on an altcoin, which is off-topic here.
>
> Raystonn
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210522/a08c6bcf/attachment.html>;

📅 Original date posted:2021-02-22 📝 Original message:Sorry, ...

2023-06-07T20:28:59+02:00

In reply to nevent1q…vwgx
_________________________

📅 Original date posted:2021-02-22
📝 Original message:Sorry, I haven't read everything. I just want to say what I think is
the best option and why.
Let's say something like 2 years in which miners can signal activation
after which, the MUST signal it for their blocks to be valid (I think
this is LOT=true, but I don't remember what LOT stands for).
Some may argue than it's easier to move from LOT=false to LOT=true
than viceversa (I think I'm getting this right), but either way
different clients could interpret things more differently more easily
and, you know, that's really bad.
If anyone is against the consensus change itself, what they should do
is run a client in which the must is turned into a MUST NOT. Whenever
miners signal activation, blocks aren't valid so that it doesn't
happen.
That way both sides can be cleanly separated and both communities
(assuming there's a community of users opposing the change) can stick
together with their own in the same chain. That is, having only 2
chains in total if there are users opposing the change or only one if
not, but never 2 chains for people who want the change or 2 chains for
pople who don't want it.

Just my two sats, please nobody ask me "why would anyone oppose
taproot?" or anything similar. Because I'm trying to generalize here,
if we're talking about activation, I think the specifics of the change
are kind of irrelevant.

Separately: thanks to everyone who worked on taproot.

On Mon, Feb 22, 2021 at 3:00 PM Matt Corallo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>
> On Feb 22, 2021, at 05:16, Anthony Towns <aj at erisian.com.au> wrote:
>
> If a lockinontimeout=true node is requesting compact blocks from a
> lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
> I think that could result in a ban.
>
> More importantly, nodes on both sides of the fork need to find each other.
>
>
> (If there was going to be an ongoing fork there'd be bigger things to
> worry about...)
>
>
> I think it should be clear that a UASF-style command line option to allow consensus rule changes in the node in the short term, immediately before a fork carries some risk of a fork, even if I agree it may not persist over months. We can’t simply ignore that.
>
> I think the important specific case of this is something like "if a chain
> where taproot is impossible to activate is temporarily the most work,
> miners with lockinontimeout=true need to be well connected so they don't
> end up competing with each other while they're catching back up".
>
>
> Between this and your above point, I think we probably agree - there is material technical complexity hiding behind a “change the consensus rules“ option. Given it’s not a critical feature by any means, putting resources into fixing these issues probably isn’t worth it.
>
> Matt
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2018-08-15 📝 Original ...

2023-06-07T20:14:00+02:00

In reply to nevent1q…aujt
_________________________

📅 Original date posted:2018-08-15
📝 Original message:op_return outputs can be pruned because they are not spendable.
putting a hash on in the witness script data won't make things better
(it would actually make them worse) and it definitely doesn't help
"block size bloat".
I think I'm missing some context, but if you're using op_return purely
for timestamping I would recommend using pay 2 contract instead.

On Tue, Aug 14, 2018 at 8:34 PM, Christopher Allen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>Should we actually be using the BIP process to claim a prefix?
>
> I recommend against using an op_return prefix, as they allow for transaction
> censorship.
>
> In fact, in our case, where we use an IPFS hash in an op_return, we remove
> the IPFS multihash prefix information to post a “bare” SHA256 hash to look
> like many other hashes being posted in op_returns, to minimize any ability
> for a miner to identify our transaction. The more projects that do this the
> better — a form of herd immunity.
>
> Longer term I’m looking for more responsible ways to publish this hash, for
> instance have the hash be in the witness script data, so that it can be
> easily purged from nodes that do not wish to preserve it and prevent block
> size bloat. However, to do so everyone has to do it the same way, ideally
> have it look like any other transaction. I’ve not quite seen a solid
> proposal for best practices here.
>
> — Christopher Allen
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2018-03-28 📝 Original message:Yes, ...

2023-06-07T20:11:22+02:00

In reply to nevent1q…7cnl
_________________________

📅 Original date posted:2018-03-28
📝 Original message:Yes, you can activate softforks at a given height.
I don't see any reason why you couldn't rebase to 0.16 directly.
The block version bumping was a mistake in bip34, you don't really
need to bump the version number. In any case, I would recommend
reading bip34 and what it activates in the code. IIRC the last thing
was bip65.

On Wed, Mar 21, 2018 at 11:04 PM, Samad Sajanlal via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Is it possible to activate soft forks such as BIP65 and BIP66 without prior
> signaling from miners? I noticed in chainparams.cpp that there are block
> heights where the enforcement begins.
>
> I understand this is already active on bitcoin. I'm working on a project
> that is a clone of a clone of bitcoin, and we currently do not have BIP65 or
> BIP66 enforced - no signaling of these soft forks either (most of the
> network is on a source code fork of bitcoin 0.9). This project does not and
> never intends to attempt to replace bitcoin - we know that without bitcoin
> our project could never exist, so we owe a great deal of gratitude to the
> bitcoin developers.
>
> If the entire network upgrades to the correct version of the software (based
> on bitcoin 0.15), which includes the block height that has enforcement, can
> we simply skip over the signaling and go straight into
> activation/enforcement?
>
> At this time we are lucky that our network is very small, so it is
> reasonable to assume that the whole network will upgrade their clients
> within a short window (~2 weeks). We would schedule the activation ~2 months
> out from when the client is released, just to ensure everyone has time to
> upgrade.
>
> We have been stuck on the 0.9 code branch and my goal is to bring it up to
> 0.15 at least, so that we can implement Segwit and other key features that
> bitcoin has introduced. The 0.15 client currently works with regards to
> sending and receiving transactions but the soft forks are not active. I
> understand that activating them will segregate the 0.15 clients onto their
> own fork, which is why I'd like to understand the repercussions of doing it
> without any signaling beforehand. I also would prefer not to have to make
> intermediate releases such as 0.10, 0.11.. etc to get the soft forks
> activated.
>
> Another related question - does the block version get bumped up
> automatically at the time that a soft fork activates, or is there additional
> stuff that I need to do within the code to ensure it bumps up at the same
> time? From what I saw in the code it appears that it will bump up
> automatically, but I would like some confirmation on that.
>
> Regards,
> Samad
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2017-09-05 📝 Original message:This ...

2023-06-07T20:05:24+02:00

In reply to nevent1q…t5vn
_________________________

📅 Original date posted:2017-09-05
📝 Original message:This is not a priority, not very important either.
Right now it is possible to create 0-value outputs that are spendable
and thus stay in the utxo (potentially forever). Requiring at least 1
satoshi per output doesn't really do much against a spam attack to the
utxo, but I think it would be slightly better than the current
situation.

Is there any reason or use case to keep allowing spendable outputs
with null amounts in them?

If not, I'm happy to create a BIP with its code, this should be simple.

📅 Original date posted:2017-06-27 📝 Original message:First ...

2023-06-07T20:03:32+02:00

In reply to nevent1q…g06z
_________________________

📅 Original date posted:2017-06-27
📝 Original message:First the implementation, then the technical design (BIP)... will the
analysis come after that?
Will there be any kind of simulations of tje proposed size or will thag
come only after activation on mainnet?
I assume the very last step will be activation on testnet 3 ?

On 27 Jun 2017 8:44 am, "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

Currently the only implementation that fulfills the requirements of the NYA
agreement is the segwit2x/btc1 implementation, which is being finalized
this week.

Segwit2mb does not fulfill the NYA agreement.

I'm asking now the segwit2x development team when a BIP will be ready so
that Core has the opportunity to evaluate the technical proposal.

On Wed, Jun 21, 2017 at 1:05 AM, Jacob Eliosoff via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Well, this Saturday's "Chinese roundtable" statement from a bunch of
> miners (https://pastebin.com/b3St9VCF) says they intend "NYA" in the
> coinbase as support for "the New York consensus SegWit2x program btc1 (
> https://github.com/btc1)", whose code includes the (accelerated
> 336-block) BIP 91 change. So, other facts or interpretations could come to
> light, but until they do we should probably assume that's what the "NYA"
> (which just broke 80% over the last 24h) means.
>
>
> On Tue, Jun 20, 2017 at 10:11 PM, Mark Friedenbach <mark at friedenbach.org>
> wrote:
>
>> 80% have set "NYA" in their coinbase string. We have no idea what that
>> means. People are equating it to BIP 91 -- but BIP 91 did not exist at
>> the time of the New York agreement, and differs from the actual text
>> of the NYA in substantive ways. The "Segwit2MB" that existed at the
>> time of the NYA, and which was explicitly referenced by the text is
>> the proposal by Sergio Demian Lerner that was made to this mailing
>> list on 31 March. The text of the NYA grants no authority for
>> upgrading this proposal while remaining compliant with the agreement.
>> This is without even considering the fact that in the days after the
>> NYA there was disagreement among those who signed it as to what it
>> meant.
>>
>> I feel it is a very dangerous and unwarranted assumption people are
>> making that what we are seeing now is either 80% support for BIP-91 or
>> for the code in the btc1 repo.
>>
>> On Tue, Jun 20, 2017 at 6:36 PM, Erik Aronesty <erik at q32.com> wrote:
>> > # Jacob Eliosoff:
>> >
>> >> will start orphaning non-bit-1 blocks before Aug 1, and we avoid a
>> split.
>> >
>> > Correct. There are 2 short activation periods in BIP91 either of which
>> > would avoid a split.
>> >
>> > # Gregory Maxwell:
>> >
>> >> unclear to me _exactly_ what it would need to implement to be
>> consistent.
>> >
>> > This is the relevant pull req to core:
>> >
>> > https://github.com/bitcoin/bitcoin/pull/10444
>> >
>> > Seems OK. It's technically running now on testnet5. I think it (or a
>> > -bip148 option) should be merged as soon as feasible.
>> >
>> >> previously debunked "XT" and "Classic" hysteria.
>> >
>> > apples vs oranges, imo. segwit is not a contentious feature. the
>> > "bundling" in segwit2x is, but that's not the issue here. the issue
>> is we
>> > are indirectly requiring miners that strongly support segwit to install
>> > consensus protocol changes outside of bitcoin's standard reference.
>> 80% of
>> > them have signaled they will do so. these are uncharted waters.
>> >
>> >
>> > On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev
>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>
>> >> I could be wrong, but the latest BIP91 implementation (also included in
>> >> Segwit2x) cuts the activation period to 336 blocks (2.33 days). (This
>> has
>> >> been updated at
>> >> https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.) So
>> if 80%
>> >> of hashpower is actually running that code and signaling on bit 4 by
>> July 25
>> >> or so, then those 80+% will start orphaning non-bit-1 blocks before
>> Aug 1,
>> >> and we avoid a split.
>> >>
>> >> There may still be a few non-bit-1 blocks that get orphaned after Aug
>> 1,
>> >> because they're mined by old BIP141 nodes. But it seems like very few
>> >> miners won't be signaling either Segwit2x *or* BIP141 by then...
>> >>
>> >> Make sense?
>> >>
>> >>
>> >> On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <
>> mark at friedenbach.org>
>> >> wrote:
>> >>>
>> >>> Why do you say activation by August 1st is likely? That would require
>> an
>> >>> entire difficulty adjustment period with >=95% bit1 signaling. That
>> seems a
>> >>> tall order to organize in the scant few weeks remaining.
>> >>>
>> >>> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev
>> >>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>
>> >>> If segwit is activated before Aug 1, as now seems likely, there will
>> be
>> >>> no split that day. But if activation is via Segwit2x (also likely),
>> and at
>> >>> least some nodes do & some don't follow through with the HF 3mo later
>> >>> (again, likely), agreed w/ Greg that *then* we'll see a split -
>> probably in
>> >>> Sep/Oct. How those two chains will match up and how the split will
>> play out
>> >>> is anyone's guess...
>> >>>
>> >>>
>> >>>
>> >>> On Jun 20, 2017 6:16 PM, "Hampus Sjöberg via bitcoin-dev"
>> >>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>
>> >>> > Ironically, it looks like most of the segwit2x signaling miners are
>> >>> > faking it (because they're not signaling segwit which it requires).
>> >>> > It'll be unfortunate if some aren't faking it and start orphaning
>> >>> > their own blocks because they are failing to signal segwit.
>> >>>
>> >>> Well, they're doing some kind of "pre-signaling" in the coinbase at
>> the
>> >>> moment, because the segwit2x project is still in alpha-phase
>> according to
>> >>> the timeline. They're just showing commitment.
>> >>> I'm sure they will begin signaling on version bit 4/BIP91 as well as
>> >>> actually running a segwit2x node when the time comes.
>> >>>
>> >>>
>> >>> > As far as prevent a chain split goes, all those things
>> >>> > (148/91/segwit2x(per today)) effectively guarantee a chainsplit--
>> so I
>> >>> > don't think that holds.
>> >>>
>> >>> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x
>> (or
>> >>> BIP148) node, because they wouldn't have the new consensus rule of
>> requiring
>> >>> all blocks to signal for segwit.
>> >>> I don't believe there would be any long lasting chainsplit though
>> >>> (because of the ~80% hashrate support on segwit2x), perhaps 2-3
>> blocks if we
>> >>> get unlucky.
>> >>>
>> >>> Hampus
>> >>>
>> >>> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev
>> >>> <bitcoin-dev at lists.linuxfoundation.org>:
>> >>>>
>> >>>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
>> >>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>> > Because a large percentage of miners are indifferent, right now
>> miners
>> >>>> > have
>> >>>> > to choose between BIP148 and Segwit2x if they want to activate
>> Segwit.
>> >>>>
>> >>>> Miners can simply continuing signaling segwit, which will leave them
>> >>>> at least soft-fork compatible with BIP148 and BIP91 (and god knows
>> >>>> what "segwit2x" is since they keep changing the actual definition and
>> >>>> do not have a specification; but last I saw the near-term behavior
>> the
>> >>>> same as BIP91 but with a radically reduced activation window, so the
>> >>>> story would be the same there in the near term).
>> >>>>
>> >>>> Ironically, it looks like most of the segwit2x signaling miners are
>> >>>> faking it (because they're not signaling segwit which it requires).
>> >>>> It'll be unfortunate if some aren't faking it and start orphaning
>> >>>> their own blocks because they are failing to signal segwit.
>> >>>>
>> >>>> I don't think the rejection of segwit2x from Bitcoin's developers
>> >>>> could be any more resolute than what we've already seen:
>> >>>> https://en.bitcoin.it/wiki/Segwit_support
>> >>>>
>> >>>> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
>> >>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>> > I think it is very naïve to assume that any shift would be
>> temporary.
>> >>>> > We have a hard enough time getting miners to proactively upgrade to
>> >>>> > recent versions of the reference bitcoin daemon. If miners
>> interpret
>> >>>> > the situation as being forced to run non-reference software in
>> order
>> >>>> > to prevent a chain split because a lack of support from Bitcoin
>> Core,
>> >>>> > that could be a one-way street.
>> >>>>
>> >>>> I think this is somewhat naive and sounds a lot like the repeat of
>> the
>> >>>> previously debunked "XT" and "Classic" hysteria.
>> >>>>
>> >>>> There is a reason that segwit2x is pretty much unanimously rejected
>> by
>> >>>> the technical community. And just like with XT/Classic/Unlimited
>> >>>> you'll continue to see a strong correlation with people who are
>> >>>> unwilling and unable to keep updating the software at an acceptable
>> >>>> level of quality-- esp. because the very founding on their fork is
>> >>>> predicated on discarding those properties.
>> >>>>
>> >>>> If miners want to go off and create an altcoin-- welp, thats
>> something
>> >>>> they can always do, and nothing about that will force anyone to go
>> >>>> along with it.
>> >>>>
>> >>>> As far as prevent a chain split goes, all those things
>> >>>> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so
>> I
>> >>>> don't think that holds.
>> >>>> _______________________________________________
>> >>>> bitcoin-dev mailing list
>> >>>> bitcoin-dev at lists.linuxfoundation.org
>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> bitcoin-dev mailing list
>> >>> bitcoin-dev at lists.linuxfoundation.org
>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> bitcoin-dev mailing list
>> >>> bitcoin-dev at lists.linuxfoundation.org
>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> >
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170627/6fe6606e/attachment-0001.html>;

📅 Original date posted:2017-04-11 📝 Original message:The ...

2023-06-07T19:59:53+02:00

In reply to nevent1q…e5au
_________________________

📅 Original date posted:2017-04-11
📝 Original message:The discussion is going offtopic. Can we please take vague discussions
about changing pow, so called "asic resistance", the environment etc
to bitcoin-disscuss or some other forum?

📅 Original date posted:2017-04-09 📝 Original message:Why ...

2023-06-07T19:59:50+02:00

In reply to nevent1q…km7f
_________________________

📅 Original date posted:2017-04-09
📝 Original message:Why won't the attacker use asicboost too? (Please don't say because of
patents)

On 9 Apr 2017 12:26 am, "Jimmy Song" <jaejoon at gmail.com> wrote:

> Jorge,
>
> Suppose someone figures out an ASIC optimization that's completely
> unrelated that gives X% speed boost over your non-ASICBoosted
> implementation. If you ban ASICBoost, someone with this optimization can
> get 51% of the network by adding N machines with their new optimization. If
> you allow ASICBoost and assuming this gets a 20% speed boost over
> non-ASICBoosted hardware, someone with this optimization would need 1.2N
> machines to get 51%. The network in that sense is 20% stronger against this
> attack in terms of cost.
>
> Jimmy
>
> On Sat, Apr 8, 2017 at 12:22 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>> To be more specific, why "being higher will secure the Bitcoin network
>> better against newer optimizations"?
>> Or, to be more clear, let's forget about future "optimizations", let's
>> just think of an attacker. Does asicboost being used by all miners
>> make the system more secure against an attacker? No, for the attacker
>> can use asicboost too.
>> What about the case when not all the miners are using asicboost? Then
>> the attacker can actually get an advantage by suing asicboost.
>>
>> Sometimes people compare asicboost with the use of asics in general as
>> both providing more security for the network and users. But I don't
>> think this is accurate. The existence of sha256d asics makes an attack
>> with general purpose computing hardware (or even more specialized
>> architectures like gpgpu) much more expensive and unlikely. As an
>> alternative the attacker can spend additional resources investing in
>> asics himself (again, making many attacks more expensive and
>> unlikely).
>>
>> But as far as I know, asicboost can be implemented with software
>> running on general purpose hardware that integrates with regular
>> sha256d asics. There is probably an advantage on having the asicboost
>> implementation "in the same box" as the sha256d, yet again the
>> attacker can invest in hardware with the competitive advantage from
>> having asicboost more intergrated with the sha256d asics too.
>>
>> To reiterate, whether all miners use asicboost or only a subset of
>> them, I remain unconvinced that provides any additional security to
>> the network (to be more precise whether that makes "tx history harder
>> to rewrite"), even if it results on the hashrate charts looking "more
>> secure".
>>
>>
>> On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>> >
>> >
>> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > Praxeology Guy,
>> >
>> >> Why would the actual end users of Bitcoin (the long term and short term
>> >> owners of bitcoins) who run fully verifying nodes want to change
>> Bitcoin
>> >> policy in order to make their money more vulnerable to 51% attack?
>> >
>> >
>> > Certainly, if only one company made use of the extra nonce space, they
>> would
>> > have an advantage. But think of it this way, if some newer ASIC
>> optimization
>> > comes up, would you rather have a non-ASICBoosted hash rate to defend
>> with
>> > or an ASICBoosted hash rate? Certainly, the latter, being higher will
>> secure
>> > the Bitcoin network better against newer optimizations.
>> >
>> >
>> > Why?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170409/96cbca19/attachment.html>;

📅 Original date posted:2017-04-09 📝 Original message:On 8 ...

2023-06-07T19:59:49+02:00

In reply to nevent1q…ahzv
_________________________

📅 Original date posted:2017-04-09
📝 Original message:On 8 Apr 2017 8:31 pm, "praxeology_guy via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

There is the equation:
Power Cost + Captial Rent + Labor ~= block reward + fees

I don't know why many people insist on calling the subsidy the blick
reward. Thw block reward is both the block subsidy plus the block fees.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170409/72862f71/attachment.html>;

📅 Original date posted:2017-04-08 📝 Original message:To be ...

2023-06-07T19:59:49+02:00

In reply to nevent1q…7jyq
_________________________

📅 Original date posted:2017-04-08
📝 Original message:To be more specific, why "being higher will secure the Bitcoin network
better against newer optimizations"?
Or, to be more clear, let's forget about future "optimizations", let's
just think of an attacker. Does asicboost being used by all miners
make the system more secure against an attacker? No, for the attacker
can use asicboost too.
What about the case when not all the miners are using asicboost? Then
the attacker can actually get an advantage by suing asicboost.

Sometimes people compare asicboost with the use of asics in general as
both providing more security for the network and users. But I don't
think this is accurate. The existence of sha256d asics makes an attack
with general purpose computing hardware (or even more specialized
architectures like gpgpu) much more expensive and unlikely. As an
alternative the attacker can spend additional resources investing in
asics himself (again, making many attacks more expensive and
unlikely).

But as far as I know, asicboost can be implemented with software
running on general purpose hardware that integrates with regular
sha256d asics. There is probably an advantage on having the asicboost
implementation "in the same box" as the sha256d, yet again the
attacker can invest in hardware with the competitive advantage from
having asicboost more intergrated with the sha256d asics too.

To reiterate, whether all miners use asicboost or only a subset of
them, I remain unconvinced that provides any additional security to
the network (to be more precise whether that makes "tx history harder
to rewrite"), even if it results on the hashrate charts looking "more
secure".

On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>
> On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Praxeology Guy,
>
>> Why would the actual end users of Bitcoin (the long term and short term
>> owners of bitcoins) who run fully verifying nodes want to change Bitcoin
>> policy in order to make their money more vulnerable to 51% attack?
>
>
> Certainly, if only one company made use of the extra nonce space, they would
> have an advantage. But think of it this way, if some newer ASIC optimization
> comes up, would you rather have a non-ASICBoosted hash rate to defend with
> or an ASICBoosted hash rate? Certainly, the latter, being higher will secure
> the Bitcoin network better against newer optimizations.
>
>
> Why?

📅 Original date posted:2017-04-08 📝 Original message:On 8 ...

2023-06-07T19:59:49+02:00

In reply to nevent1q…4n4t
_________________________

📅 Original date posted:2017-04-08
📝 Original message:On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

Praxeology Guy,

Why would the actual end users of Bitcoin (the long term and short term
> owners of bitcoins) who run fully verifying nodes want to change Bitcoin
> policy in order to make their money more vulnerable to 51% attack?
>

Certainly, if only one company made use of the extra nonce space, they
would have an advantage. But think of it this way, if some newer ASIC
optimization comes up, would you rather have a non-ASICBoosted hash rate to
defend with or an ASICBoosted hash rate? Certainly, the latter, being
higher will secure the Bitcoin network better against newer optimizations.

Why?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/9bce75cb/attachment.html>;

📅 Original date posted:2017-03-29 📝 Original message:While ...

2023-06-07T19:58:05+02:00

In reply to nevent1q…qfce
_________________________

📅 Original date posted:2017-03-29
📝 Original message:While Segwit's change from 1 mb size limit to 4 mb weight limit seems to be
controversial among some users (I find that very often it is because they
have been confused about what segwit does or even outright lied about it) I
don't think it's very interesting to discuss further size increases.
I find more interesting to talk to the users and see how they think Segwit
harms them, maybe we missed something in segwit that needs to be removed
for segwit to become uncontroversial, or maybe it is just disinformation.

On the other hand, we may want to have our first uncontroversial hardfork
asap, independently of block size. For example, we could do something as
simple as fixing the timewarp attack as bip99 proposes. I cannot think of a
hf that is easier to implement or has less potential for controversy than
that.

On 29 Mar 2017 8:32 am, "Bram Cohen via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

On Tue, Mar 28, 2017 at 9:59 AM, Wang Chun via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> The basic idea is, as many of us agree, hard fork is risky and should
> be well prepared. We need a long time to deploy it.
>

Much as it may be appealing to repeal the block size limit now with a grace
period until a replacement is needed in a repeal and replace strategy, it's
dubious to assume that an idea can be agreed upon later when it can't be
agreed upon now. Trying to put a time limit on it runs into the possibility
that you'll find that whatever reasons there were for not having general
agreement on a new setup before still apply, and running into the
embarrassing situation of winding up sticking with the status quo after
much sturm and drang.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/6b3c913e/attachment.html>;

📅 Original date posted:2017-01-04 📝 Original message:There ...

2023-06-07T19:55:08+02:00

In reply to nevent1q…4n8q
_________________________

📅 Original date posted:2017-01-04
📝 Original message:There were talks about implementing spv mode for bitcoin core without using
bloom filters. Less efficient because it downloads full blocks, but better
for privacy. Perhaps other spv implementations should consider doing the
same instead of committing the filters in the block?

Now I feel I was missing something. I guess you can download the whole
block you're interested in instead of only your txs and that gives you
privacy.
But how do you get to know which blocks are you interested in?

If the questions are too basic or offtopic for the thread, I'm happy
getting answers privately (but then maybe I get them more than once).

On 4 Jan 2017 09:57, "Aaron Voisine via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

It's easy enough to mark a transaction as "pending". People with bank
accounts are familiar with the concept.

Although the risk of accepting gossip information from multiple random
peers, in the case where the sender does not control the receivers network
is still minimal. Random node operators have no incentive to send fake
transactions, and would need to control all the nodes a client connects to,
and find a non-false-positive address belonging to the victims wallet.

It's not impossible, but it's non trivial, would only temporarily show a
pending transaction, and provide no benefit to the node operator. There are
much juicier targets for an attacker with the ability to sybil attack the
entire bitcoin p2p network.

Aaron

On Tue, Jan 3, 2017 at 11:47 PM Jonas Schnelli <dev at jonasschnelli.ch> wrote:

> Hi
>
>
>
> > Unconfirmed transactions are incredibly important for real world use.
>
> > Merchants for instance are willing to accept credit card payments of
>
> > thousands of dollars and ship the goods despite the fact that the
>
> > transaction can be reversed up to 60 days later. There is a very large
>
> > cost to losing the ability to have instant transactions in many or
>
> > even most situations. This cost is typically well above the fraud risk.
>
> >
>
> > It's important to recognize that bitcoin serves a wide variety of use
>
> > cases with different profiles for time sensitivity and fraud risk.
>
> >
>
> I agree that unconfirmed transactions are incredibly important, but not
>
> over SPV against random peers.
>
>
>
> If you offer users/merchants a feature (SPV 0-conf against random
>
> peers), that is fundamentally insecure, it will – sooner or later – lead
>
> to some large scale fiasco, hurting Bitcoins reputation and trust from
>
> merchants.
>
>
>
> Merchants using and trusting 0-conf SPV transactions (retrieved from
>
> random peers) is something we should **really eliminate** through
>
> education and by offering different solution.
>
>
>
> There are plenty, more sane options. If you can't run your own full-node
>
> as a merchant (trivial), maybe co-use a wallet-service with centralized
>
> verification (maybe use two of them), I guess Copay would be one of
>
> those wallets (as an example). Use them in watch-only mode.
>
>
>
> For end-users SPV software, I think it would be recommended to...
>
> ... disable unconfirmed transactions during SPV against random peers
>
> ... enable unconfirmed transactions when using SPV against a trusted
>
> peer with preshared keys after BIP150
>
> ... if unconfirmed transactions are disabled, show how it can be enabled
>
> (how to run a full-node [in a box, etc.])
>
> ... educate, inform users that a transaction with no confirmation can be
>
> "stopped" or "redirected" any time, also inform about the risks during
>
> low-conf phase (1-5).
>
>
>
> I though see the point that it's nice to make use of the "incoming
>
> funds..." feature in SPV wallets. But – for the sake of stability and
>
> (risk-)scaling – we may want to recommend to scarify this feature and –
>
> in the same turn – to use privacy-preserving BFD's.
>
>
>
> </jonas>
>
>
>
>
>
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170104/f762bf24/attachment-0001.html>;

📅 Original date posted:2016-12-15 📝 Original message:On ...

2023-06-07T19:54:58+02:00

In reply to nevent1q…8jmp
_________________________

📅 Original date posted:2016-12-15
📝 Original message:On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Older node versions may generate issues because some upgrades will make
> several of the nodes running older protocol versions obsolete and or
> incompatible. There may be other hard to predict behaviors on older versions
> of the client.

Hard to predict or not, you can't force people to run newer software.

> In order to avoid such wide fragmentation of "Bitcoin Core” node versions
> and to help there be a more predictable protocol improvement process, I
> consider it worth it to analyze introducing some planned obsolescence in
> each new version. In the last year we had 4 new versions so if each version
> is valid for about 1 year (52560 blocks) this may be a reasonable time frame
> for node operators to upgrade. If a node does not upgrade it will stop
> working instead of participating in the network with an outdated protocol
> version.

When you introduce anti-features like this in free software they can
be trivially removed and they likely will.

> These changes may also simplify the developer's jobs in some cases by
> avoiding them having to deal with ancient versions of the client.

There's a simpler solution for this which is what is being done now:
stop maintaining and giving support for older versions.
There's limited resources and developers are rarely interested in
fixing bugs for very old versions. Users shouldn't expect things to be
backported to old versions (if developers do it and there's enough
testing, there's no reason not to do more releases of old versions, it
is just rarely the case).

📅 Original date posted:2016-11-16 📝 Original message:On ...

2023-06-07T19:54:21+02:00

In reply to nevent1q…5vfk
_________________________

📅 Original date posted:2016-11-16
📝 Original message:On Wed, Nov 16, 2016 at 3:18 PM, Thomas Kerin via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> BIP30 actually was given similar treatment after a reasonable amount of time
> had passed.
> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392

This is not really the same. BIP30 is not validated after BIP34 is
active because blocks complying with BIP34 will always necessarily
comply with BIP30 (ie coinbases cannot be duplicated after they
include the block height).

📅 Original date posted:2016-02-06 📝 Original message:On Feb ...

2023-06-07T19:48:42+02:00

In reply to nevent1q…7xsa
_________________________

📅 Original date posted:2016-02-06
📝 Original message:On Feb 6, 2016 16:37, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
>
> Responding to "28 days is not long enough" :

Any thoughts on the "95% better than 75%" and "grace period before miner
coordination instead of after" comments ?

> I suspect there ARE a significant percentage of un-maintained full
nodes-- probably 30 to 40%. Losing those nodes will not be a problem, for
three reasons:

None of the reasons you list say anything about the fact that "being lost"
(kicked out of the network) is a problem for those node's users.

> I strongly disagree with the statement that there is no cost to a longer
grace period.

I didn't say that.

> To bring it back to bitcoin-dev territory: are there any TECHNICAL
arguments why an upgrade would take a business or individual longer than 28
days?

Their own software stack may require more work to integrate the new rules
or their resources may not be immediately available to focus on this within
28 days they hadn't planned.

I believe it wold be less controversial to chose something that nobody can
deny is more than plenty of time for everyone to implement the changes
like, say, 1 year. I wouldn't personally oppose to something shorter like 6
months for really simple changes, but I don't see how 28 can ever be
considered uncontroversial and safe for everyone. Just trying to help in
removing controversy from the PR, but if you still think 28 can be safe and
uncontroversial, feel free to ignore these comments on the concrete length
and please let me know what you think about the other points I raised.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160206/567808a2/attachment.html>;

📅 Original date posted:2016-02-06 📝 Original message:If it ...

2023-06-07T19:48:37+02:00

In reply to nevent1q…wadf
_________________________

📅 Original date posted:2016-02-06
📝 Original message:If it is to be uncontroversial and everybody will upgrade, there's no
fear of a "veto power" and there's no good reason not to wait for 95%
block version signaling for deployment coordination, ideally using
bip9.
But that's for chosing the exact block where to start. The grace
period to give time to all users to upgrade should be before and not
after miner's final confirmation: that simplifies and accelerates
things. Assuming we chose a grace period that is really adequate,
nearly 100% of miners will have likely upgraded long before everyone
(since miners are a subset of "everyone"). If that is not the case and
miners happen to be the latest to upgrade, using bip9 after the grace
period (aka starting median-time/height) will make sure the hardfork
doesn't get activated without 95% of the miners having upgraded.

28 days seems extremely short (specially if the grace period comes
first), some people have suggested one year for simple hardforks like
this one.

On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev wrote:
>> Blog post on a couple of the constants chosen:
>> http://gavinandresen.ninja/seventyfive-twentyeight
>
> Can you put this in the BIP's Rationale section (which appears to be mis-named
> "Discussion" in the current draft)?
>
>> Signature operations in un-executed branches of a Script are not counted
>> OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a
>> 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top
>> of the execution stack, it is counted as one signature operation. If it is
>> satisfied by the public key nearest the bottom of the execution stack, it
>> is counted as twenty signature operations. Signature operations involving
>> invalidly encoded signatures or public keys are not counted towards the
>> limit
>
> These seem like they will break static analysis entirely. That was a noted
> reason for creating BIP 16 to replace BIP 12. Is it no longer a concern? Would
> it make sense to require scripts to commit to the total accurate-sigop count
> to fix this?
>
>> The amount of data hashed to compute signature hashes is limited to
>> 1,300,000,000 bytes per block.
>
> The rationale for this wasn't in your blog post. I assume it's based on the
> current theoretical max at 1 MB blocks? Even a high-end PC would probably take
> 40-80 seconds just for the hashing, however - maybe a lower limit would be
> best?
>
>> Miners express their support for this BIP by ...
>
> But miners don't get to decide hardforks. How does the economy express their
> support for it? What happens if miners trigger it without consent from the
> economy?
>
> If you are intent on using the version bits to trigger the hardfork, I suggest
> rephrasing this such that miners should only enable the bit when they have
> independently confirmed economic support (this means implementations need a
> config option that defaults to off).
>
>> SPV (simple payment validation) wallets are compatible with this change.
>
> Would prefer if this is corrected to "Light clients" or something. Actual SPV
> wallets do not exist at this time, and would not be compatible with a
> hardfork.
>
>> In the short term, an increase is needed to continue the current economic
>> policies with regards to fees and block space, matching market expectations
>> and preventing market disruption.
>
> IMO this sentence is the most controversial part of your draft, and it
> wouldn't suffer a loss to remove it (or at least make it subjective).
>
> I would also prefer to see any hardfork:
>
> 1. Address at least the simple tasks on the hardfork wishlist (eg, enable some
> disabled opcodes; fix P2SH for N-of->15 multisig; etc).
> 2. Be deployed as a soft-hardfork so as not to leave old nodes entirely
> insecure.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2016-01-11 📝 Original message:On ...

2023-06-07T19:47:46+02:00

In reply to nevent1q…35ee
_________________________

📅 Original date posted:2016-01-11
📝 Original message:On Fri, Jan 8, 2016 at 4:50 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> And to fend off the messag that I bet somebody is composing right now:
>
> Yes, I know about a "security first" mindset. But as I said earlier in the
> thread, there is a tradeoff here between crypto strength and code
> complexity, and "the strength of the crypto is all that matters" is NOT
> security first.

If the crypto code is properly encapsulated, the code complexity costs
of choosing one hashing function over another should be non-existent.
You made the space argument which is valid, but in my opinion code
complexity shouldn't be a valid concern in this discussion.

As a maybe uninteresting anecdote, I proposed the asset IDs in
https://github.com/ElementsProject/elements/tree/alpha-0.10-multi-asset
to do the same ```ripemd160 . sha256``` choice that Mark Friedenbach
had proposed and I had approved for
https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#asset-tags
. More humble than me, he admitted he had made a design mistake much
earlier than me, who (maybe paradoxically) probably had less knowledge
for making crypto choices at the low level. In the end I was convinced
with examples I failed to write down for documentation and can't
remember.

That's not to say I have anything to say in this debate other than
code complexity (which I do feel qualified to talk about) shouldn't be
a concern in this debate. Just want to focus the discussion on what it
should be: security vs space tradeoff.
Since I am admittedly in doubt, I tend to prefer to play safe, but
neither my feelings nor my anecdote are logical arguments and should,
therefore, be ignored for any conclusions in the ```ripemd160 .
sha256``` vs sha256d debate. Just like you non-sequitor "sha256d will
lead to more code complexity", if anything, sha256d should be simpler
than ```ripemd160 . sha256``` (but not simpler enough that it matters
much).

📅 Original date posted:2015-12-26 📝 Original message:The ...

2023-06-07T19:47:09+02:00

In reply to nevent1q…v6u3
_________________________

📅 Original date posted:2015-12-26
📝 Original message:The hashpower is a function of the block reward (subsidy + fees): it's
economically irrational to have costs greater than the reward (better just
turn off your miners) and in a perfect competition (a theoretical model)
profits tend to zero. That is, the costs tend to equal revenue (block
reward).
On Dec 26, 2015 6:38 PM, "Eric Lombrozo" <elombrozo at gmail.com> wrote:

> For simplicity, assume total network hashpower is constant. Also, assume
> the soft fork activates at the beginning of a retarget period.
>
> At the moment the soft fork activates, the effective difficulty is
> increased (by adding a second independent PoW check that must also be
> satisfied) which means more hashes on average (and proportionally more
> time) are required to find a block. At the end of the retarget period, the
> difficulty is lowered so that if the second PoW difficulty were to be kept
> constant the block interval would again average 10 mins.
>
> If we were to keep the second PoW difficulty constant, we would restore
> the same total PoW-to-time-unit ratio and the retarget difficulty would
> stabilize again so each block would once more require the same number of
> hashes (and same amount of time) on average as before.
>
> But we don't keep the second PoW difficulty constant - we increase it so
> once again more hashes on average are required to find a block by the same
> proportion as before. And we keep doing this.
>
> Now, the assumption that hashpower is constant is obviously unrealistic.
> If this is your bone of contention, then yes, I agree my model is overly
> simplistic.
>
> My larger point was to explore the extent of what's possible with only a
> soft fork - and we can actually go pretty far and even compensate for these
> economic shifts by increasing block size and rewards. The whole thing is
> clearly a huge mess - and I wouldn't recommend actually doing it.
>
>
>
> On December 26, 2015 7:33:53 AM PST, "Jorge Timón" <jtimon at jtimon.cc>
> wrote:
>>
>>
>> On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> > Unfortunately, this also means longer confirmation times, lower
>> throughput, and lower miner revenue. Note, however, that confirmations
>> would (on average) represent more PoW, so fewer confirmations would be
>> required to achieve the same level of security.
>> >
>>
>> I'm not sure I understand this. If mining revenue per unit of time drops,
>> total pow per unit of time should also drop. Even if the inter-block time
>> is increased, it's not clear to me that the pow per block would necessarily
>> be higher.
>> What am I missing?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/f9473770/attachment.html>;

📅 Original date posted:2015-12-26 📝 Original message:On Dec ...

2023-06-07T19:47:08+02:00

In reply to nevent1q…d7st
_________________________

📅 Original date posted:2015-12-26
📝 Original message:On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Unfortunately, this also means longer confirmation times, lower
throughput, and lower miner revenue. Note, however, that confirmations
would (on average) represent more PoW, so fewer confirmations would be
required to achieve the same level of security.
>

I'm not sure I understand this. If mining revenue per unit of time drops,
total pow per unit of time should also drop. Even if the inter-block time
is increased, it's not clear to me that the pow per block would necessarily
be higher.
What am I missing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/071e9e45/attachment.html>;

📅 Original date posted:2015-12-18 📝 Original message:I ...

2023-06-07T19:46:51+02:00

In reply to nevent1q…7r5c
_________________________

📅 Original date posted:2015-12-18
📝 Original message:I believe the attacks are the same for height or median time of the prev
block are equal, only the time of the current block has more edge cases.
On Dec 18, 2015 9:15 PM, "Jeff Garzik" <jgarzik at gmail.com> wrote:

> My preference is height activation + one step per block (i.e. also
> height). Height seems KISS.
>
> AFAICT most of the attacks would occur around the already-heavily-watched
> flag day activation event, in a height based environment, a useful
> attribute.
>
> However I would like to hear from others about possible attacks with the
> various approaches, before diverging from the default community approach of
> switch-based-on-time.
>
>
>
>
>
>
> On Fri, Dec 18, 2015 at 3:10 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>> Well, if it's not going to be height, I think median time of the previous
>> block is better than the time of the current one, and would also solve Chun
>> Wang's concerns.
>> But as said I prefer to use heights that correspond to diff recalculation
>> (because that's the window that bip9 will use for the later 95%
>> confirmation anyway).
>> On Dec 18, 2015 9:02 PM, "Jeff Garzik" <jgarzik at gmail.com> wrote:
>>
>>> From a code standpoint, based off height is easy.
>>>
>>> My first internal version triggered on block 406,800 (~May 5), and each
>>> block increased by 20 bytes thereafter.
>>>
>>> It was changed to time, because time was the standard used in years past
>>> for other changes; MTP flag day is more stable than block height.
>>>
>>> It is preferred to have a single flag trigger (height or time), rather
>>> than the more complex trigger-on-time, increment-on-height, but any
>>> combination of those will work.
>>>
>>> Easy to change code back to height-based...
>>>
>>>
>>>
>>> On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> I agree that nHeight is the simplest option and is my preference.
>>>> Another option is to use the median time from the previous block (thus
>>>> you know whether or not the next block should start the miner confirmation
>>>> or not). In fact, if we're going to use bip9 for 95% miner upgrade
>>>> confirmation, it would be nice to always pick a difficulty retarget block
>>>> (ie block.nHeight % DifficultyAdjustmentInterval == 0).
>>>> Actually I would always have an initial height in bip9, for softforks
>>>> too.
>>>> I would also use the sign bit as the "hardfork bit" that gets activated
>>>> for the next diff interval after 95% is reached and a hardfork becomes
>>>> active (that way even SPV nodes will notice when a softfork or hardfork
>>>> happens and also be able to tell which one is it).
>>>> I should update bip99 with all this. And if the 2 mb bump is
>>>> uncontroversial, maybe I can add that to the timewarp fix and th recovery
>>>> of the other 2 bits in block.nVersion (given that bip102 doesn't seem to
>>>> follow bip99's recommendations and doesn't want to give 6 full months as
>>>> the pre activation grace period).
>>>> On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> In many BIPs we have seen, include the latest BIP202, it is the block
>>>>> time that determine the max block size. From from pool's point of
>>>>> view, it cannot issue a job with a fixed ntime due to the existence of
>>>>> ntime roll. It is hard to issue a job with the max block size unknown.
>>>>> For developers, it is also easier to implement if max block size is a
>>>>> function of block height instead of time. Block height is also much
>>>>> more simple and elegant than time.
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/984ddbc3/attachment.html>;

📅 Original date posted:2015-12-18 📝 Original message:Well, ...

2023-06-07T19:46:50+02:00

In reply to nevent1q…g9x9
_________________________

📅 Original date posted:2015-12-18
📝 Original message:Well, if it's not going to be height, I think median time of the previous
block is better than the time of the current one, and would also solve Chun
Wang's concerns.
But as said I prefer to use heights that correspond to diff recalculation
(because that's the window that bip9 will use for the later 95%
confirmation anyway).
On Dec 18, 2015 9:02 PM, "Jeff Garzik" <jgarzik at gmail.com> wrote:

> From a code standpoint, based off height is easy.
>
> My first internal version triggered on block 406,800 (~May 5), and each
> block increased by 20 bytes thereafter.
>
> It was changed to time, because time was the standard used in years past
> for other changes; MTP flag day is more stable than block height.
>
> It is preferred to have a single flag trigger (height or time), rather
> than the more complex trigger-on-time, increment-on-height, but any
> combination of those will work.
>
> Easy to change code back to height-based...
>
>
>
> On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I agree that nHeight is the simplest option and is my preference.
>> Another option is to use the median time from the previous block (thus
>> you know whether or not the next block should start the miner confirmation
>> or not). In fact, if we're going to use bip9 for 95% miner upgrade
>> confirmation, it would be nice to always pick a difficulty retarget block
>> (ie block.nHeight % DifficultyAdjustmentInterval == 0).
>> Actually I would always have an initial height in bip9, for softforks too.
>> I would also use the sign bit as the "hardfork bit" that gets activated
>> for the next diff interval after 95% is reached and a hardfork becomes
>> active (that way even SPV nodes will notice when a softfork or hardfork
>> happens and also be able to tell which one is it).
>> I should update bip99 with all this. And if the 2 mb bump is
>> uncontroversial, maybe I can add that to the timewarp fix and th recovery
>> of the other 2 bits in block.nVersion (given that bip102 doesn't seem to
>> follow bip99's recommendations and doesn't want to give 6 full months as
>> the pre activation grace period).
>> On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> In many BIPs we have seen, include the latest BIP202, it is the block
>>> time that determine the max block size. From from pool's point of
>>> view, it cannot issue a job with a fixed ntime due to the existence of
>>> ntime roll. It is hard to issue a job with the max block size unknown.
>>> For developers, it is also easier to implement if max block size is a
>>> function of block height instead of time. Block height is also much
>>> more simple and elegant than time.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/20ab7c5a/attachment.html>;

📅 Original date posted:2015-12-17 📝 Original ...

2023-06-07T19:46:35+02:00

In reply to nevent1q…hykx
_________________________

📅 Original date posted:2015-12-17
📝 Original message:Although I agree that how safe a pre-hardfork upgrade period is depends on
the complexity of the changes (we should assume everyone may need time to
reimplementat it themselves in their own implementations, not just upgrade
bitcoin core) and bip102 is indeed a very simple hardfork, I think less
than 6 months for a hardfork is starting to push it too much.
For a more complex hardfork (say, a SW hardfork or a collection of many
little fixes) I believe 1 year or more would make more sense.

BIP99 recommends a time threshold (height or median time) + 95% miner
upgrade confirmation with BIP9 (version bits).
So how about the following plan?

1) Deploy BIP102 when its ready + 6 median time months + 95% miner upgrade
confirmation

2) Deploy SW when it's ready + 95% miner upgrade confirmation via bip9.

Note that both "when it's ready" depend on something we are not paying a
lot of attention to: bip9's implementation (just like bip113, bip68-112,
bip99, the coinbase-commitments-cleanup post-SW uncontroversial hardfork,
etc).

Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
equivalent to the 2-4-8 "compromise" proposal (which by the way I never
liked, because I don't think anybody should be in a position to
"compromise" anything and because I don't see how "let's avoid an
unavoidable economic change for a little bit longer" arguments can
reasoably claim that "we need to kick the can down the road exactly 3 more
times" or whatever is the reasoning behind it).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151217/e44914d7/attachment.html>;

📅 Original date posted:2015-12-11 📝 Original message:On Dec ...

2023-06-07T19:45:45+02:00

In reply to nevent1q…2kju
_________________________

📅 Original date posted:2015-12-11
📝 Original message:On Dec 9, 2015 5:40 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
>
> On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I think it would be logical to do as part of a hardfork that moved
>> commitments generally; e.g. a better position for merged mining (such
>> a hardfork was suggested in 2010 as something that could be done if
>> merged mining was used), room for commitments to additional block
>> back-references for compact SPV proofs, and/or UTXO set commitments.
>> Part of the reason to not do it now is that the requirements for the
>> other things that would be there are not yet well defined. For these
>> other applications, the additional overhead is actually fairly
>> meaningful; unlike the fraud proofs.
>
>
> So just design ahead for those future uses. Make the merkle tree:
>
>
> root_in_block_header
> / \
> tx_data_root other_root
> / \
> segwitness_root reserved_for_future_use_root

This is basically what I meant by

struct hashRootStruct
{
uint256 hashMerkleRoot;
uint256 hashWitnessesRoot;
uint256 hashextendedHeader;
}

but my design doesn't calculate other_root as it appears in your tree (is
not necessary).

Since stop requiring bip34 (height in coinbase) is also a hardfork (and a
trivial one) I suggested to move it at the same time. But thinking more
about it, since BIP34 also elegantly solves BIP30, I would keep the height
in the coinbase (even if we move it to the extented header tree as well for
convenience).
That should be able to include future consensus-enforced commitments (extra
back-refs for compact proofs, txo/utxo commitments, etc) or non-consensus
data (merged mining data, miner-published data).
Greg Maxwell suggested to move those later and I answered fair enough. But
thinking more about it, if the extra commitments field is extensible, we
don't need to move anything now, and therefore we don't need for those
designs (extra back-refs for compact proofs, txo/utxo commitments, etc) to
be ready to deploy a hardfork segregated witness: you just need to make
sure that your format is extensible via softfork in the future.

I'm therefore back to the "let's better deploy segregated witness as a
hardfork" position.
The change required to the softfork segregated witnesses implementation
would be relatively small.

Another option would be to deploy both parts (sw and the movement from the
coinbase to the extra header) at the same time but with different
activation conditions, for example:

- For sw: deploy as soon as possible with bip9.
- For the hardfork codebase to extra header movement: 1 year grace + bip9
for later miner upgrade confirmation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151211/2a7a0a4a/attachment.html>;

📅 Original date posted:2015-12-09 📝 Original message:Fair ...

2023-06-07T19:45:44+02:00

In reply to nevent1q…lp6l
_________________________

📅 Original date posted:2015-12-09
📝 Original message:Fair enough.
On Dec 9, 2015 4:03 PM, "Gregory Maxwell" <greg at xiph.org> wrote:

> On Wed, Dec 9, 2015 at 7:54 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> > From this question one could think that when you said "we can do the
> > cleanup hardfork later" earlier you didn't really meant it. And that
> > you will oppose to that hardfork later just like you are opposing to
> > it now.
> > As said I disagree that making a softfork first and then move the
> > commitment is less disruptive (because people will need to adapt their
> > software twice), but if the intention is to never do the second part
> > then of course I agree it would be less disruptive.
> > How long after the softfork would you like to do the hardfork?
> > 1 year after the softfork? 2 years? never?
>
> I think it would be logical to do as part of a hardfork that moved
> commitments generally; e.g. a better position for merged mining (such
> a hardfork was suggested in 2010 as something that could be done if
> merged mining was used), room for commitments to additional block
> back-references for compact SPV proofs, and/or UTXO set commitments.
> Part of the reason to not do it now is that the requirements for the
> other things that would be there are not yet well defined. For these
> other applications, the additional overhead is actually fairly
> meaningful; unlike the fraud proofs.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/0845be33/attachment.html>;

📅 Original date posted:2015-12-08 📝 Original message:On ...

2023-06-07T19:45:41+02:00

In reply to nevent1q…vglg
_________________________

📅 Original date posted:2015-12-08
📝 Original message:On Wed, Dec 9, 2015 at 1:58 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> struct hashRootStruct
> {
> uint256 hashMerkleRoot;
> uint256 hashWitnessesRoot;
> int32_t nHeight;
> }

Or better, for forward compatibility (we may want to include more
things apart from nHeight and hashWitnessesRoot in the future):

struct hashRootStruct
{
uint256 hashMerkleRoot;
uint256 hashWitnessesRoot;
uint256 hashextendedHeader;
}

For example, we may want to chose to add an extra nonce there.

📅 Original date posted:2015-12-08 📝 Original message:On ...

2023-06-07T19:45:40+02:00

In reply to nevent1q…eetq
_________________________

📅 Original date posted:2015-12-08
📝 Original message:On Wed, Dec 9, 2015 at 12:59 AM, Gregory Maxwell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> We already have consensus critical enforcement there, the height,
> which has almost never been problematic. (A popular block explorer
> recently misimplemented the var-int decode and suffered an outage).

It would be also a nice opportunity to move the height to a more
accessible place.
For example CBlockHeader::hashMerkleRoot (and CBlockIndex's) could be
replaced with a hash of the following struct:

struct hashRootStruct
{
uint256 hashMerkleRoot;
uint256 hashWitnessesRoot;
int32_t nHeight;
}

> From a risk reduction perspective, I think it is much preferable to
> perform the primary change in a backwards compatible manner, and pick
> up the data reorganization in a hardfork if anyone even cares.

But then all wallet software will need to adapt their software twice.
Why introduce technical debt for no good reason?

> I think thats generally a nice cadence to split up risks that way; and
> avoid controversy.

Uncontroversial hardforks can also be deployed with small risks as
described in BIP99.

📅 Original date posted:2015-12-08 📝 Original message:On Dec ...

2023-06-07T19:45:39+02:00

In reply to nevent1q…2ac2
_________________________

📅 Original date posted:2015-12-08
📝 Original message:On Dec 9, 2015 7:41 AM, "Jonathan Toomim via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I also think that a hard fork is better for SegWit, as it reduces the
size of fraud proofs considerably, makes the whole design more elegant and
less kludgey, and is safer for clients who do not upgrade in a timely
fashion.

I agree, although I disagree with the last reason.

> I don't like the idea that SegWit would invalidate the security
assumptions of non-upgraded clients (including SPV wallets). I think that
for these clients, no data is better than invalid data. Better to force
them to upgrade by cutting them off the network than to let them think
they're validating transactions when they're not.

I don't undesrtand. SPV nodes won't think they are validating transactions
with the new version unless they adapt to the new format. They will be
simply unable to receive payments using the new format if it is a softfork
(although as said I agree with making it a hardfork on the simpler design
and smaller fraud proofs grounds alone).

>
> On Dec 8, 2015, at 11:55 PM, Justus Ranvier via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > If such a change is going to be deployed via a soft fork instead of a
> > hard fork, then the coinbase is the worst place to put the segwitness
> > merkle root.
> >
> > Instead, put it in the first output of the generation transaction as an
> > OP_RETURN script.
> >
> > This is a better pattern because coinbase space is limited while output
> > space is not. The next time there's a good reason to tie another merkle
> > tree to a block, that proposal can be designated for the second output
> > of the generation transaction.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/2af9dc6d/attachment.html>;

📅 Original date posted:2015-12-08 📝 Original message:On Dec ...

2023-06-07T19:45:37+02:00

In reply to nevent1q…felq
_________________________

📅 Original date posted:2015-12-08
📝 Original message:On Dec 8, 2015 7:08 PM, "Wladimir J. van der Laan via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> - Gregory linked to an implementation but as he mentions it is not
completely
> finished yet. ETA for a Segwit testnet is later this month, then you
can test as well.

Testnet4 ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/bcac0700/attachment.html>;

📅 Original date posted:2015-11-15 📝 Original message:Thank ...

2023-06-07T19:44:58+02:00

In reply to nevent1q…zgyu
_________________________

📅 Original date posted:2015-11-15
📝 Original message:Thank you for incorporating the feedback, specifically thank you for
using the genesis block hash as the unique chain ID.

I wen't through the BIP draft and left a few of comments, but I really
like its simplicity and focus. Good work!

On Sun, Nov 15, 2015 at 3:14 AM, Marco Pontello via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi!
>
> To anyone that followed the discussion (from some time ago) about the
> proposed new URI for Blockchain references / exploration, I just wanted to
> point out that I have collected the feedback provided, reworked the text,
> put the BIP on GitHub and created a pull request:
>
> https://github.com/MarcoPon/bips/blob/master/bip-MarcoPon-01.mediawiki
> https://github.com/bitcoin/bips/pull/202
>
> The need for an URI for this come to mind again in the last days looking at
> Eternity Wall, which IMHO provide a use case that we will see more and more
> in the (near) future: http://eternitywall.it/
> Using that service, when you want to check for the proof that a specific
> message was written in the Blockchain, it let you choose from 5 different
> explorer.
> Mycelium wallet recently added the option to select one of 15 block
> explorers.
> And there's the crypto_bot on reddit/r/bitcoin that detect reference to
> transaction an add a message with links to 7 different explorers.
>
> I think that's clearly something that's needed.
>
> Bye!
>
>
> On Sat, Aug 29, 2015 at 1:48 PM, Marco Pontello <marcopon at gmail.com> wrote:
>>
>> Hi!
>> My first post here, hope I'm following the right conventions.
>> I had this humble idea for a while, so I thought to go ahead and propose
>> it.
>>
>> BIP: XX
>> Title: URI scheme for Blockchain exploration
>> Author: Marco Pontello
>> Status: Draft
>> Type: Standards Track
>> Created: 29 August 2015
>>
>> Abstract
>> ========
>> This BIP propose a simple URI scheme for looking up blocks, transactions,
>> addresses on a Blockchain explorer.
>>
>> Motivation
>> ==========
>> The purpose of this URI scheme is to enable users to handle all the
>> requests for details about blocks, transactions, etc. with their preferred
>> tool (being that a web service or a local application).
>>
>> Currently a Bitcoin client usually point to an arbitrary blockchain
>> explorer when the user look for the details of a transaction (es. Bitcoin
>> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
>> Other times resorting to cut&paste is needed.
>> The same happens with posts and messages that reference some particular
>> txs or blocks, if they provide links at all.
>>
>> Specification
>> =============
>> The URI follow this simple form:
>>
>> blockchain: <hash/string>
>>
>> Examples:
>>
>>
>> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
>> blockchain:001949
>>
>> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>>
>> Rationale
>> =========
>> I thought about using some more complex scheme, or adding qualifiers to
>> distinguish blocks from txs, but in the end I think that keeping it simple
>> should be practical enough. Blockchain explorers can apply the same
>> disambiguation rules they are already using to process the usual search
>> box.
>>
>> From the point of view of a wallet developer (or other tool that need to
>> show any kind of Blockchain references), using this scheme mean that he
>> can simply make it a blockchain: link and be done with it, without having
>> to worry about any specific Blockchain explorer or provide a means for the
>> user to select one.
>>
>> Blockchain explorers in turn will simply offer to handle the blockchain:
>> URI, the first time the user visit their website, or launch/install the
>> application, or even set themselves if there isn't already one.
>>
>> Users get the convenience of using always their preferred explorer, which
>> can be especially handy on mobile devices, where juggling with cut&paste
>> is far from ideal.
>>
>>
>
>
>
> --
> Try the Online TrID File Identifier
> http://mark0.net/onlinetrid.aspx
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-10-05 📝 Original message:On ...

2023-06-07T19:42:01+02:00

In reply to nevent1q…jy7f
_________________________

📅 Original date posted:2015-10-05
📝 Original message:On Mon, Oct 5, 2015 at 2:10 PM, Mike Hearn <hearn at vinumeris.com> wrote:
> Hi Jorge,
>
> I'm glad we seem to be reaching agreement that hard forks aren't so bad
> really and can even have advantages. It seems the remaining area of
> disagreement is this rollout specifically.
>>
>> a non-upgraded full node and an upgraded full will converge on what they
>> see: "the most-work valid chain" will be the same for both.
>
> Indeed it will, but the point of fully verifying is to not converge with the
> miner majority, if something goes wrong and they aren't following the same
> rules as you. Defining "work" as "converge with miner majority" is fine for
> SPV wallets and a correct or at least reasonable definition. But not for
> fully verifying nodes, where non-convergence is an explicit design goal!
> That's the only thing that stops miners awarding themselves infinite free
> money!

As Greg explained to you repeatedly, a softfork won't cause a
non-upgraded full node to start accepting blocks that create more
subsidy than is valid.
It's only the new rule (in this case, BIP65) that they won't validate.
That's very different security from an SPV node, and as Greg also
explained, SPV nodes could be much more secure than bitcoinj nodes
(they could, for example, validate the coinbase transaction of every
block).
If a non-upgraded node it's not a "full node" for you, that's fine,
but it is for everyone else. So please stop confusing other people.
Assuming the majority of the hashrate upgraded, there's almost no risk
for non-upgraded full nodes.

>> Are you going to produce a bip65 hardfork alternative to try to convince
>> people of its advantages over bip65 (it is not clear to me how you include a
>> new script operand via hardfork)?
>
> No, I'm focused on the block size issue right now. I don't think there's
> much point in improving the block chain protocol if most users are going to
> be unable to use it. But the modification is simple, right? You just replace
> this bit:
>
> CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode
>
> with this
>
> CHECKLOCKTIMEVERIFY defines a new opcode (0xc0)
>
> and that's it. The section upgrade and testing plan only says TBD so that
> part doesn't even need to change at all, as it's not written yet.

Thanks, I wasn't aware that there was room for new opcodes that
weren't noops already.
Can you give an example of an attack in which a non-upgraded full node
wallet is defrauded with BIP65 but could not with the hardfork
alternative (that nobody seems to be willing to implement)?
Please, don't assume 0 confirmation transactions or similar
unreasonable assumptions (ie see section 11 "Calculations" of the
Bitcoin whitepaper).

📅 Original date posted:2015-10-05 📝 Original message:On Oct ...

2023-06-07T19:42:00+02:00

In reply to nevent1q…9ck0
_________________________

📅 Original date posted:2015-10-05
📝 Original message:On Oct 5, 2015 2:08 PM, "Clément Elbaz" <clem.ds at gmail.com> wrote:
>
> It will get correct results about :
> - the existence every block
> - the existence of every transaction
>
> It will get incorrect results :
> - about the nature of some transactions

Given the assumptions above, only of transactions without enough
confirmations.

> - and therefore, about the balances of some wallets.

Not if the wallet waits for enough confirmations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/51a36627/attachment.html>;

📅 Original date posted:2015-10-05 📝 Original message:On ...

2023-06-07T19:42:00+02:00

In reply to nevent1q…7l6a
_________________________

📅 Original date posted:2015-10-05
📝 Original message:On Mon, Oct 5, 2015 at 2:29 PM, Clément Elbaz <clem.ds at gmail.com> wrote:
> The problem is that some transactions that are meaningless to you are
> actually meaningful to people using an upgraded Bitcoin software.
>
> Therefore during a softfork, while you can not miss the existence of a
> transaction, you can miss its meaning.

Why would you care about payments to other people?
The scriptPubKey's that you give to your payers certainly have meaning to you.

> But as soon as you try to actually use Bitcoin (that is, calculate the
> accurate balance of a wallet in a very broad sense), you can be led a wrong
> result if you did not upgrade, which is a critical problem for financial
> software.

What is it important that you are able to calculate balances of
wallets that aren't yours?

> And because nothing prevent people to send you transactions of a new type,
> you have no way to "opt out" of this problem.

Why would anyone "pay you" to a scriptPubKey you don't understand?

I can "pay" the bill of my internet services by burying cash in a park
nearby my house for my provider to pick up later.
But if I don't tell my provider, it will never know. If I inform it, I
will get an answer: "no, sorry, we won't accept this new 'form of
payment' of yours as payment".

📅 Original date posted:2015-10-05 📝 Original message:On Oct ...

2023-06-07T19:41:59+02:00

In reply to nevent1q…redv
_________________________

📅 Original date posted:2015-10-05
📝 Original message:On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Well, let's agree to disagree on these two things:
>
> - I define "working" for a full node as verifying everything; if a node
starts skipping bits then I'd say it's not really "working" according to
its original design goals

But assuming the hashrate majority has upgraded (and we're using 95% as the
miner upgrade confirmation threshold to start activation, so that
assumption seems pretty safe), a non-upgraded full node and an upgraded
full will converge on what they see: "the most-work valid chain" will be
the same for both. A non-upgraded full node wallet waiting for several
confirmations (for example, 6 confirmations) will be just as safe as an
upgraded one. In that sense, it keeps working. On top of that, nodes (of
any kind) can use unknown block version numbers to notify the user or even
stop working (the same notification mechanism you would use with hardforks).

I agree that hardforks are necessary and we should deploy a hardfork asap
to show the world they are indeed possible (bip99 proposes a likely
uncontroversial one), but I still believe that is clear that softfork
deployment is preferrable in many cases like this one.

Are you going to produce a bip65 hardfork alternative to try to convince
people of its advantages over bip65 (it is not clear to me how you include
a new script operand via hardfork)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/b9f495ac/attachment.html>;

📅 Original date posted:2015-09-30 📝 Original message:On Oct ...

2023-06-07T19:41:56+02:00

In reply to nevent1q…nxf7
_________________________

📅 Original date posted:2015-09-30
📝 Original message:On Oct 1, 2015 12:14 AM, "Jorge Timón" <jtimon at jtimon.cc> wrote:
>
> On Wed, Sep 30, 2015 at 11:06 PM, Mike Hearn <hearn at vinumeris.com> wrote:
> >> Exactly, all those "mini divergences" eventually disappear
> >
> > A miner that has accepted a newly invalid transaction into its memory
pool
> > and is trying to mine it, will keep producing invalid blocks forever
until
> > the owner shuts it down and upgrades. This was happening for weeks after
> > P2SH triggered.
> >
> > For instance, any miner that has modified/bypassed IsStandard() can do
this,
> > or any miner that accepts direct transaction submission, or any miner
that
> > runs an old node from before OP_NOPs were made non-standard.
>
> That is correct. But doesn't seem to contradict anything I said.

Actually, no, sorry, the second paragraph is not correct as explained by
Greg Maxwell.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151001/a24e6353/attachment.html>;

📅 Original date posted:2015-09-28 📝 Original message:On Sep ...

2023-06-07T19:41:36+02:00

In reply to nevent1q…43ye
_________________________

📅 Original date posted:2015-09-28
📝 Original message:On Sep 28, 2015 7:14 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>> In a hardfork, however, there is no mechanism to stop the old fork and
we may have 2 chains co-exist for a long time.
>
>
> There isn't any difference in how long the divergent state exists for.
That depends only on how fast people upgrade, which is unaffected by the
rollout strategy used.
>

Yes, there is a difference. Assuming the hashrate majority upgrades, in the
case of a softfork non-upgraded miners will try to build on top of the
longest chain (the upgraded one) but their blocks will get consistently
orphaned for having a too old block version (and if they just increment the
version without implementing the new restrictions, then their blocks will
be orphaned when they fail to enforce the new restrictions). In the case of
a hardfork, the non-upgraded miners will keep on building their own longest
valid chain (the upgraded chain is not valid in their eyes), potentially
forever.
That's not to say softforks are always preferrable. There's cases when a
feature can be implemented as a softfork or a hardfork, but the softfork
solution is clearly inferior and introduces technical debt.
In those cases I prefer a hardfork, but this is not one of those cases.

In any case, maybe you want to provide some feedback to bip99, which is
about possible consensus rule changes scenarios and a recommended
deployment path for each of them (softforks and hardforks are subdivided in
several types). This discussion about the general desirability of softforks
seems offtopic for the concrete cltv deployment discussion, which assumes
softforks as deployment mechanism (just like bip66 assumed it).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/66e45ae4/attachment-0001.html>;

📅 Original date posted:2015-09-18 📝 Original message:Well, ...

2023-06-07T19:40:57+02:00

In reply to nevent1q…z6t7
_________________________

📅 Original date posted:2015-09-18
📝 Original message:Well, with utxo commitments at some point maybe is enough to validate the
full headers history but only the last 5 years of ttansaction history
(assuming utxo commitments are buried 5 years worth of blocks in the past).
This scales much better than validating the full history and if we get a 5
year reorg something is going really wrong anyway...
Maybe after validating the last 5 years you also want to validate the rest
of the history backards to get the "fully-full node" security.
Of course 5 years it's just an arbitrary number: 2 or maybe even 1 would
probably be secure enough for most people. I've referred to this idea as
"hard checkpoints" or "moving the genesis block forward" in the past.
On Sep 18, 2015 4:18 PM, "Rune Kjær Svendsen" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> There are a couple of points I’d like to address.
>
> Firstly, yes, >50% attacks are a problem for Bitcoin. Bitcoin does not
> function if the majority of mining power is dishonest. There is no way
> around that. It’s how proof-of-work functions. And if we lose
> proof-of-work, we lose Bitcoin.
>
> Secondly, I’m not suggesting that UTXO set hashes *replace* block hashes,
> or even that it should be in the block header (probably in the coinbase
> somewhere). I suggest it as an *addition* to the existing consensus rules.
> Full nodes can still verify the chain with the added step of hashing the
> UTXO set for every block. Of course, this can easily be deferred to after
> proof-of-work has been verified already, such that no work is wasted.
> Unless a 51% attack is in effect. But I argue that this is a moot point,
> since Bitcoin is useless anyway under such circumstances.
>
> Lastly, I’m not suggesting miners discard the blockchain history. A miner
> has an incentive to be absolutely sure that the chain he’s building on is
> the right one. If he’s wrong, he loses money/income. There’s simply no
> reason for a professional miner *not* to do the full initial sync, which
> only needs to be done once. Non-miners, who just want to check the balance
> of their wallet, however, really don’t need to retrieve information about
> Hal Finney sending bitcoins to Satoshi in 2010. In any case, this practice
> isn’t sustainable.
>
> In the end, it isn’t possible to control whether a miner verifies the
> entire blockchain anyway (anyone can send the UTXO set over the wire). Not
> letting the proof-of-work cover the UTXO hash doesn’t solve this problem,
> it only makes it impossible to know whether a given UTXO set is the one
> that the majority is mining on without retrieving the entire blockchain,
> and doing the verification yourself. People can choose to skip that
> regardless of what we do.
>
> Furthermore, all nodes have the option of deciding which level of security
> they want. We’re not lessening security of the protocol, we’re
> strengthening the security of something that’s already possible to do
> (build on top of an unverified blockchain), but we’d rather want that
> people not do.
>
> /Rune
>
>
> > On 18 Sep 2015, at 21:43, Patrick Strateman via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Full nodes using UTXO set commitments is a change to the bitcoin
> > security model.
> >
> > Currently an attacker with >50% of the network hashrate can rewrite
> history.
> >
> > If full nodes rely on UTXO set commitments such an attacker could create
> > an infinite number of bitcoins (as in many times more than the current
> > 21 million bitcoin limit).
> >
> > Before we consider mechanisms for UTXO set commitments, we should
> > seriously discuss whether the security model reduction is reasonable.
> >
> > On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote:
> >> Currently, when a new node wants to join the network, it needs to
> retrieve the entire blockchain history, starting from January 2009 and up
> until now, in order to derive a UTXO set that it can verify new
> blocks/transactions against. With a blockchain size of 40GB and a UTXO size
> of around 1GB, the extra bandwidth required is significant, and will keep
> increasing indefinitely. If a newly mined block were to include the UTXO
> set hash of the chain up until the previous block — the hash of the UTXO
> set on top of which this block builds — then new nodes, who want to know
> whether a transaction is valid, would be able to acquire the UTXO set in a
> trustless manner, by only verifying proof-of-work headers, and knowing that
> a block with an invalid UTXO set hash would be rejected.
> >>
> >> I’m not talking about calculating a complicated tree structure from the
> UTXO set, which would put further burden on already burdened Bitcoin Core
> nodes. We simply include the hash of the current UTXO set in a newly
> created block, such that the transactions in the new block build *on top*
> of the UTXO set whose hash is specified. This actually alleviates Bitcoin
> Core nodes, as it will now become possible for nodes without the entire
> blockchain to answer SPV queries (by retrieving the UTXO set trustlessly
> and using this to answer queries). It also saves bandwidth for Bitcore Core
> nodes, who only need to send roughly 1GB of data, in order to synchronise a
> node, rather than 40GB+. I will continue to run a full Bitcoin Core node,
> saving the entire blockchain history, but it shouldn’t be a requirement to
> hold the entire transaction history in order to start verifying new
> transactions.
> >>
> >> As far as I can see, this also forces miners to actually maintain an
> UTXO set, rather than just build on top of the chain with the most
> proof-of-work. Producing a UTXO set and verifying a block against a chain
> is the same thing, so by including the hash of the UTXO set we force miners
> to verify the block that they want to build on top of.
> >>
> >> Am I missing something obvious, because as far as I can see, this
> solves the problem of quadratic time complexity for initial sync:
> http://www.youtube.com/watch?v=TgjrS-BPWDQ&t=2h02m12s
> >>
> >> The only added step to verifying a block is to hash the UTXO set. So it
> does require additional computation, but most modern CPUs have a SHA256
> throughput of around 500 MB/s, which means it takes only two seconds to
> hash the UTXO set. And this can be improved further (GPUs can do 2-3 GB/s).
> A small sacrifice for the added ease of initial syncing, in my opinion.
> >>
> >> /Rune
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/a57078f8/attachment-0001.html>;

📅 Original date posted:2015-09-17 📝 Original message:Fill ...

2023-06-07T19:40:44+02:00

In reply to nevent1q…f5q7
_________________________

📅 Original date posted:2015-09-17
📝 Original message:Fill or kill us normally used for trades and I think it can be confusing.
Previous times this has been discussed it has been discussed under
nExpiryTime or op_height (which enables expiration), for example, in the
freimarkets white paper.

As Mark points out this can be made safe by requiring that all the outputs
of a transaction that can expire have op_maturity/csv/rcltv of 100. That
makes them as reorg-safe as coinbase transactions. Unfortunately this
doesn't play very well with p2sh...
On Sep 17, 2015 3:08 PM, "Mark Friedenbach via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Note that this violates present assumptions about transaction validity,
> unless a constraint also exists that any output of such an expiry block is
> not spent for at least 100 blocks.
>
> Do you have a clean way of ensuring this?
>
> On Thu, Sep 17, 2015 at 2:41 PM, jl2012 via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Fill-or-kill tx is not a new idea and is discussed in the Scaling Bitcoin
>> workshop. In Satoshi's implementation of nLockTime, a huge range of
>> timestamp (from 1970 to 2009) is wasted. By exploiting this unused range
>> and with compromise in the time resolution, a fill-or-kill system could be
>> built with a softfork.
>>
>> -----------
>> Two new parameters, nLockTime2 and nKillTime are defined:
>>
>> nLockTime2 (Range: 0-1,853,010)
>> 0: Tx could be confirmed at or after block 420,000
>> 1: Tx could be confirmed at or after block 420,004
>> .
>> .
>> 719,999: Tx could be confirmed at or after block 3,299,996 (about 55
>> years from now)
>> 720,000: Tx could be confirmed if the median time-past >= 1,474,562,048
>> (2016-09-22)
>> 720,001: Tx could be confirmed if the median time-past >= 1,474,564,096
>> (2016-09-22)
>> .
>> .
>> 1,853,010 (max): Tx could be confirmed if the median time-past >=
>> 3,794,966,528 (2090-04-04)
>>
>> nKillTime (Range: 0-2047)
>> if nLockTime2 < 720,000, the tx could be confirmed at or before block
>> (nLockTime2 + nKillTime * 4)
>> if nLockTime2 >= 720,000, the tx could be confirmed if the median
>> time-past <= (nLockTime2 - 720,001 + nKillTime) * 2048
>>
>> Finally, nLockTime = 500,000,000 + nKillTime + nLockTime2 * 2048
>>
>> Setting a bit flag in tx nVersion will activate the new rules.
>>
>> The resolution is 4 blocks or 2048s (34m)
>> The maximum confirmation window is 8188 blocks (56.9 days) or 16,769,024s
>> (48.5 days)
>>
>> For example:
>> With nLockTime2 = 20 and nKillTime = 100, a tx could be confirmed only
>> between block 420,080 and 420,480
>> With nLockTime2 = 730,000 and nKillTime = 1000, a tx could be confirmed
>> only between median time-past of 1,495,042,048 and 1,497,090,048
>>
>> ----------------
>> Why is this a softfork?
>>
>> Remember this formula: nLockTime = 500,000,000 + nKillTime + nLockTime2 *
>> 2048
>>
>> For height based nLockTime2 (<= 719,999)
>>
>> For nLockTime2 = 0 and nKillTime = 0, nLockTime = 500,000,000, which
>> means the tx could be confirmed after 1970-01-01 with the original lock
>> time rule. As the new rule does not allow confirmation until block 420,000,
>> it's clearly a softfork.
>>
>> It is not difficult to see that the growth of nLockTime will never catch
>> up nLockTime2.
>>
>> At nLockTime2 = 719,999 and nKillTime = 2047, nLockTime = 1,974,559,999,
>> which means 2016-09-22. However, the new rule will not allow confirmation
>> until block 3,299,996 which is decades to go
>>
>>
>>
>> For time based nLockTime2 (> 720,000)
>>
>> For nLockTime2 = 720,000 and nKillTime = 0, nLockTime = 1,974,560,000,
>> which means the tx could be confirmed after median time-past 1,474,560,000
>> (assuming BIP113). However, the new rule will not allow confirmation until
>> 1,474,562,048, therefore a soft fork.
>>
>> For nLockTime2 = 720,000 and nKillTime = 2047, nLockTime = 1,974,562,047,
>> which could be confirmed at 1,474,562,047. Again, the new rule will not
>> allow confirmation until 1,474,562,048. The 1 second difference makes it a
>> soft fork.
>>
>> Actually, for every nLockTime2 value >= 720,000, the lock time with the
>> new rule must be 1-2048 seconds later than the original rule.
>>
>> For nLockTime2 = 1,853,010 and nKillTime = 2047, nLockTime =
>> 4,294,966,527, which is the highest possible value with the 32-bit nLockTime
>>
>> ----------------
>> User's perspective:
>>
>> A user wants his tx either filled or killed in about 3 hours. He will set
>> a time-based nLockTime2 according to the current median time-past, and set
>> nKillTime = 5
>>
>> A user wants his tx get confirmed in the block 630000, the first block
>> with reward below 10BTC. He is willing to pay high fee but don't want it
>> gets into another block. He will set nLockTime2 = 210,000 and nKillTime = 0
>>
>> ----------------
>> OP_CLTV
>>
>> Time-based OP_CLTV could be upgraded to support time-based nLockTime2.
>> However, height-based OP_CLTV is not compatible with nLockTime2. To spend a
>> height-based OP_CLTV output, user must use the original nLockTime.
>>
>> We may need a new OP_CLTV2 which could verify both nLockTime and
>> nLockTime2
>>
>> ----------------
>> 55 years after?
>>
>> The height-based nLockTime2 will overflow in 55 years. It is very likely
>> a hard fork will happen to implement a better fill-or-kill system. If not,
>> we could reboot everything with another tx nVersion for another 55 years.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150917/3db9f191/attachment-0001.html>;

📅 Original date posted:2015-09-03 📝 Original message:On Sep ...

2023-06-07T19:39:19+02:00

In reply to nevent1q…a0dx
_________________________

📅 Original date posted:2015-09-03
📝 Original message:On Sep 3, 2015 5:58 PM, "Btc Drak via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Thu, Sep 3, 2015 at 3:34 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
> > A discussion of rolling out BIP 100 will not be avoided :)
> >
> > It is a hard fork; it would be silly to elide discussion of these key
> > issues.
> >
> > I don't get the community's recent interest in avoiding certain topics.
>
> It's not a matter of avoiding the subject, it's a whole separate
> discussion and in the interests of efficient discussion, it is best
> done separately. There's a whole BIP dedicated to the discussion of
> consensus forks which you should probably give some input in also,
> BIP99 [1]
>
> Once we come to an agreement and can say "here's what we're doing
> about blocksize, it will be X, or we'll raise by this algo", then we
> can discuss the best way to implement the hard fork.
>
> [1] https://github.com/bitcoin/bips/pull/181

In fact, that discussion can happen in parallel. But it is more efficient
to do so in one place instead of in each of the 5+ hardfork proposals
(bip99 itself has a hardfork proposal with its code ready).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/a11ae3c3/attachment.html>;

📅 Original date posted:2015-08-26 📝 Original message:On ...

2023-06-07T19:38:13+02:00

In reply to nevent1q…acsr
_________________________

📅 Original date posted:2015-08-26
📝 Original message:On Thu, Aug 27, 2015 at 12:22 AM, Daniele Pinna via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I don't get how it's very risky to have the Mike and Gavin redirect the
> course of the bitcoin protocol but it's totally fine to consider complex
> miner voting protocols as a hard fork option.

Maybe this helps undesrtanding the risks of a contentious/schism
hardfork: https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR137
That section can be greatly improved though.

> I believe that this community has not given due weight to the analysis
> proposed by Peter__R on the existence of fee markets with uncapped max
> blocksizes. The critiques made toward his work were in no way definitive and
> discussion just stopped. Is it the math that bothers people?

I have only skimmed the document, but I believe its conclusions (or
some of them) are right for the current propagation code.
The assumption may not stand if we move to something like IBLT though.
I believe that document also proves that it is
irrational/noncompetitive for miners to include ANY free transactions
at all (like they currently do).
But the analysis is about the effect of the maximum block size on
fees: there's more effects of that consensus rule.
The most important one being that it limits mining centralization (and
centralization in general).
This is true for at least 2 reasons: one is related to block
propagation and it is what is usually described.
At a bigger scale (even with crazy assumptions like constant time
infinite bandwidth, instant [superluminal] communication, zkSNARKS
block validity proofs ) minimum CPU costs will be something to limit
through the maximum block size consensus rule. There's a scale at
which the minimum CPU costs for a miner to be competitive may be so
high that some small miners without the resources to meet that minimum
will become unprofitable.
Admittedly we're not near that scale yet, but if something to take into account.

> The main critique to uncapped max blocksizes which I've heard stems from our
> incapacity to quantify the advantages that large miners have over smaller
> ones.

There are some simulations. See:
http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners

The goal of https://github.com/bitcoin/bitcoin/pull/6382 is to allow
people to do more realistic simulations (by using real full nodes).
That doesn't mean that more simplified simulations are worthless, but
I didn't want people to have to create their own testchain every time
they want to simulate a different size, like rusty had to do for:

http://rusty.ozlabs.org/?p=509

So the "incapacity to quantify the advantages that large miners have
over smaller ones" doesn't really exist.
It would be nice to have more data about this (more sizes, more
network topologies, etc) though.

> As I will show in an upcoming paper, these advantages do not stem from
> the act of propagating large blocks but rather from the block subsidies
> which allow miners to mine unnecessary large blocks irregardless of the fees
> contained therein. One typical example is Peter Todd's suggested attack
> whereby a miner creates a massive block filled with spam transactions that
> pay himself solely to slow down the rest of the network and gain an
> advantage. Putting aside the increased orphan risk arising from the
> propagation of such a large block, this attack would never be viable if it
> weren't for the existence of current block subsidies.

Although smaller subsidies will remove some problems we currently
have, for example, SPV mining (there's no incentive to SPV mine
worthless empty blocks), I don't understand your claim that they will
also solve mining centralization problems related to block
propagation.

> As such, exponential increases to the max blocksize make perfect sense since
> the block reward decreases exponentially also. All arguments invoking rates
> of technological advances (see Gavin's original posts) don't mean anything.

I really dislike basing the consensus rules on predictions about
future technology. For all I know, a terrible war could destroy half
of the global internet infrastructure in the next 5 years.
I prefer simpler increments like in bip102 (although I don't have the
data to know if 2MB is safe mining-centralization-wise at this point
[when mining centralization is pretty bad]).
Arguments against that kind of change are usually along the lines
"then we will have to repeat this same discussion in 1 or 2 years".
I believe that with the proper simulation tools being deployed and a
better general understanding of what the concerns are, the
conversation should be much simpler the next time.

> Rational miners will NOT be incentivized to mine gargantuan spam filled
> blocks in the presence of a vanishing block reward.

Actually some simulations show they in fact have incentive to do just
that in some cases.
But more importantly, we shouldn't assume that all attackers are
rational miners. Maybe a potential attacker is a secret service or a
financial cartel attempting to destroy Bitcoin for whatever reason.

> I truly hope this matter gets the consideration it deserves. Particularly
> with the upcoming scaling workshops.

I truly hope that the discussion can move forward into more productive
territories after the workshop, and I'm particularly interested in
Peter R's presentation, even if I haven't found the time to read his
paper yet. Even if fees are not the main reason why we want to have a
block size maximum, fees are certainly very relevant and anything that
he has mathematically proven in that regard will be useful to this
discussion.

> On Aug 21, 2015 11:35 PM, "Daniele Pinna" <daniele.pinna at gmail.com> wrote:
>
> "I ran some simulations, and if blocks take 20 seconds to propagate, a
> network with a miner that has 30% of the hashing power will get 30.3% of the
> blocks."
>
> Peter_R's analysis of fee markets in the absence of blocksize limits [1]
> shows that the hashrate advantage of a large miner is a side-effect of
> coinbase subsidization. As the block rewards get smaller, so will large
> miner advantages. An easy way to think about this is as follows:
>
> Currently, the main critique of larger blocksizes is that we'll connected
> miners can cut out smaller miners by gratuitously filling up blocks with
> self-paying transactions. This only works because block subsidies exist. The
> moment block rewards become comparable to block TX fees, this exploit ceases
> to be functional.
>
> Basically, large miners will still be forced to move full blocks, but it
> will go against their interest to fill them with spam since their main
> source of income is the fees themselves. As a result, large miners (unlike
> smaller ones) will lose the incentive to mine an un full block this evening
> the playing field.
>
> In this context, large blocksizes as proposed by BIP100-101 hope to
> stimulate the increase of TX fees by augmenting the network's capacity. The
> sooner block rewards become comparable to block fees, the sooner we will get
> rid of mine centralization.
>
> Dpinna
>
> [1]
> http://www.scribd.com/mobile/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-08-30 📝 Original message:On ...

2023-06-07T19:37:56+02:00

In reply to nevent1q…uqeu
_________________________

📅 Original date posted:2015-08-30
📝 Original message:On Sun, Aug 30, 2015 at 7:13 PM, <jl2012 at xbt.hk> wrote:
> This is based on the assumption that miners would always like to use up the
> last byte of the available block size. However, this is just not true:
>
> 1. The 6 year blockchain history has shown that most miners have a soft cap
> with their block size.
>
> 2. Chinese miners, controlling 60% of the network, rejected Gavin's initial
> 20MB proposal and asked for 8MB:
> http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size
> [...]

No, I'm not making such assumption. I'm focusing on what they CAN do,
while suspending judgement on their good will and not trying to
predict their future behavior from historic behaviour.
With 60% of the hashrate, you can easily get 100% by orphaning
everybody else's blocks. More importantly, being under the same
jurisdiction they can be forced to behave in certain way (for example,
censor transactions) by law.
I'm very worried about the current situation no matter how benevolent
current miners are. Thus weakening the only limit to mining
centralization that we have at the consensus rule level seems
extremely risky at this point.

> For many reasons miners may want to have a smaller block size, which we
> don't need to list them here. Although they can limit it by a softfork or
> even 51% attack, it is a very violent process. Why don't we just allow them
> to vote for a lower limit?
>
> So I think the right way is to choose a mining-centralization-safe limit,
> and let it free float within a range based on miner's vote. If we are lucky
> enough to have some responsible miners, they will keep it as low as
> possible, until the legitimate tx volume catches up. Even in the worst case,
> the block size is still mining-centralization-safe. The upper limit may
> increase linearly, if not exponentially, until we find a better long-term
> solution. (sort of a combination of BIP100 and 101, with different
> parameters)

My point is, a "soft cap" determined by miners clearly doesn't protect
us from mining centralization: the "hard cap" does.
Knowing that, and given that miners can currently set their own policy
block size maximum, what does this "voting on a lower limit" achieve?
What are the gains? Why are we "lucky" if they keep the lower one as
low as possible?

> For the matter of "urgency", I agree with you that there is no actual
> urgency AT THIS MOMENT. However, if a hardfork may take 5 years to deploy
> (as you suggested), we really have the urgency to make a decision now.

Thank you for admitting it is not urgent!
I suggested 5 years for the concrete hardfork in bip99 because it's
clearly non-urgent and I wanted to be very conservative. I'm happy to
reduce that to say, 1 year (specially given that the change is very
simple to implement).
For a simple block size change (like, say bip102) 1 year (maybe 6
months + miner's confirmation) is probably more than enough as well.
And we can always deploy an urgency hardfork if it is necessary.

> Actually, the main point is not urgency but uncertainty. We have debated for
> 5 years. Why won't we have 5 more years of debate, plus 5 years of
> deployment delay? Are we sticking to 1MB for 10 years? In that case Bitcoin
> Core must be abandoned by the economic majority and a Schism fork must
> occur.

Fortunately we haven't been discussing this for 5 years, I don't know
where you get that from.
A schism fork it's certainly always a possibility but I would only
consider it after an urgency hardfork (once the issue becomes urgent)
fails due to not being uncontroversial.
Would you agree with me on that?
What would be your criterion for considering an increase in block size urgent?

Mine is: we should consider a block increase only when minimum market
fees for transactions to be mined (currently zero satoshis) increase
above a high fee (admittedly undefined, but certainly greater than
zero).
Even if it's "urgent", I think we should only increase the maximum if,
at the same time, the new size can be considered safe
mining-centralization-wise (unfortunately we don't have any metric to
measure that nor enough tools to realistically simulate different
sizes in different network topologies at the moment). But once we have
them, the next discussion will be much simpler, so I don't see the
need for block size maximum that changes over time (neither
exponentially nor linearly).

Would you agree with me that mining centralization should be the most
important criterion when changing the block size maximum rule rather
than the level of minimum fees?
If the community can't agree on this, I'm afraid there will be a
schism hardfork eventually. Another possibility is that those who
aren't concerned with mining centralization start their own altcoin
(centralizedcoin? ), maybe a spinoff [
https://bitcointalk.org/index.php?topic=563972.0 ] if they want to
keep Bitcoin's utxo at the moment of the separation.

But if the community agrees with this and just disagrees on the
maximum block size consensus rule having any effect on mining
centralization (like Gavin and I disagree), we should calm down and
use scientific processes to find out what the relation between the two
actually is (if there's any relation at all).

Would you agree with me on this?

📅 Original date posted:2015-08-29 📝 Original message:On ...

2023-06-07T19:37:55+02:00

In reply to nevent1q…usll
_________________________

📅 Original date posted:2015-08-29
📝 Original message:On Sat, Aug 29, 2015 at 12:15 PM, Btc Drak <btcdrak at gmail.com> wrote:
> On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Ah, then my mistake. It seemed so similar to an idea that was proposed
>> before on this mailing list:
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
>>
>> that my mind just filled in the gaps. I concur -- having miners -- or any
>> group -- vote on block size is not an intrinsically good thing. The the
>> original proposal due to Greg Maxwell et al was not a mechanism for "voting"
>> but rather a feedback control that made the maximum block size that which
>> generated the most fees.
>
> Mark and Jorge,
>
> I am very glad you have brought up this particular objection because
> it's something I thought about but was unclear if it was an opinion
> that would be shared by others. I chose to omit it from the proposal
> to see if it would come up during peer review.
>
> I feel that giving miners a blank cheque to increase blocksize, by any
> means, goes against a key design of bitcoin's security model. Full
> nodes keep miners honest by ensuring by validating their blocks. Under
> any voting-only scheme there is no way for full nodes to keep miners
> in cheque because miner have free reign to increase the blocksize.
>
> This problem can be solved by introducing a hard cap on blocksize. By
> introducing an upper limit miners now have the freedom to increase
> blocksize but only within defined parameters. Remember my proposal
> allows blocksize to increase and decrease in such a way that miners
> must collectively agree if they want the size to increase.

Then I only care about the hard cap (for example, to me bip100 is
practically equivalent to just raise the limit to 32 MB directly).
Miners can always produce smaller blocks by modifying their local policy.
So if we need a maximum that cannot be altered by miners anyway, why
take the additional complexity of miners voting on a lower and
changing maximum size?

> With respect to the flexicap idea where miners can create a larger
> block by paying extra difficulty, I believe that proposal has a
> critical flaw because, as Gavin pointed out, it makes it very
> expensive (and risky) to include a few extra transactions. I believe
> it suffers from tragedy of the commons because there is no incentive
> for the mining community to reach consensus. Each and every block is
> going to be a gamble, "should we include a few extra transactions at
> the risk of losing the block?".

How expensive it is depends on the concrete function f(extra_nBits) =
extra_size_allowed
But the goal of that proposal is not to raise the size maximum
permanently, but rather temporarily allow bigger blocks when there are
spikes in demand (ie many fees to collect in unconfirmed
transactions).
Yes miners will ask that question to themselves, and the answer will
depend on the concrete function and on the fees of those extra
transactions.
The miner paying for the costs will get the gains: no tragedy of the
commons here.

> Under my proposal miners can
> collectively agree to change the blocksize. Let's say they want a 10%
> increase, they can collude together to make that increase and once
> reached, it remains until they want to change it again. Yet, the upper
> hard limit keeps the ultimate control of the maximum block size
> squarely in the hands of full nodes.

I believe the tragedy of the commons actually happens with your
proposal. Why would I pay alone for something that benefits all
miners?

> An alternative methodology to voting in the coinbase would be to
> change the vote to be the blocksize itself
>
> 1. miners pay extra difficulty to create a larger block.
> 2. every 2016 blocks the average or median of the last 2016 blocks is
> calculated and becomes the new maximum blocksize limit.
>
> This would retain incentive to collude to increase blocksize, as well
> as the property of costing to increase while being free to propose
> decrease.

This seems to solve the tragedy of the commons problem with your
current proposal.
It would be like flexcap but instead of the change in size being
temporary, it affects the next maximum size permanently.
One thing to worry about is miners filling blocks with
pay-to-themselves garbage to avoid reducing the size when they don't
have enough attractive transactions to include (ie it may not be free
for the network for miners to vote on "maintain current size").

> It would still require an upper blocksize limit in order for full
> nodes to retain control. Without an upper limit, any proposal is going
> to break the security model as full nodes give up some oversight
> control over miners.
>
> Another way of looking at these ideas is we're raising blocksize hard
> limit (to 8MB or whatever is decided), but making a soft of "softer"
> or inner limit part of consensus. Such a concept is not really
> departing from the current idea of a soft limit except to make it
> consensus enforced. Obviously it's not identical, but I think you can
> see the similarities.
>
> Does that make sense?

I still don't see the point in having a lower moving size maximum.
If 8 MB is mining-centralization-safe, let's move directly to 8 MB
without adding this seemingly useless extra complexity.
If it's not, mining voting on a lower moving maximum won't make it safer.

Once we have more objective tools (centralization metrics, simulators,
etc...) to determine whether or not a block size is
mining-centralization-safe for a given point in time (looking at
current centralization and current technology available), I don't see
the problem with repeating the equivalent of bip102 periodically
(every 2 years?) to adapt the size to better technology or lower
mining centralization.
It would be also helpful to have a tool to somehow measure "size
increase urgency" (ie right now free transactions get mined and blocks
aren't full or close to be full, I don't think the current general
sense of urgency on this matter is justified).

With all respect, I believe bip100 and this proposal are
over-engineering; and bip101 and bip103 (pieter's) are
overly-optimistic (in their exponential technological growth
assumptions).

📅 Original date posted:2015-08-28 📝 Original message:On ...

2023-06-07T19:37:53+02:00

In reply to nevent1q…7th4
_________________________

📅 Original date posted:2015-08-28
📝 Original message:On Sat, Aug 29, 2015 at 1:38 AM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> It is in their individual interests when the larger block that is allowed
> for them grants them more fees.

I realize now that this is not what Greg Maxwell proposed (aka
flexcap): this is just miner's voting on block size but paying with
higher difficulty when they vote for bigger blocks.
As I said several times in other places, miners should not decide on
the consensus rule to limit mining centralization.
People keep talking about miners voting on the block size or
"softforking the size down if we went too far". But what if the
hashing majority is perfectly fine with the mining centralization at
that point in time?
Then a softfork won't be useful and we're talking about an "anti-miner
fork" (see https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR158
and https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR175
).

I believe miner's voting on the rule to limit mining centralization is
a terrible idea.
It sounds as bad as letting pharma companies write the regulations on
new drugs safety, letting big food chains deciding on minimum food
controls or car manufacturers deciding on indirect taxes for fuel.
That's why I dislike both this proposal and BIP100.

📅 Original date posted:2015-08-19 📝 Original message:I ...

2023-06-07T19:36:58+02:00

In reply to nevent1q…8zju
_________________________

📅 Original date posted:2015-08-19
📝 Original message:I don't think just using version=4 for cltv and friends would be a
problem if it wasn't for the XT/nonXT issue.

On Wed, Aug 19, 2015 at 12:20 PM, Btc Drak <btcdrak at gmail.com> wrote:
> On Wed, Aug 19, 2015 at 10:34 AM, Jorge Timón
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Seems like 3 is something we want to do no matter what and therefore
>> is the "most future-proof" solution.
>> I wonder if I can help with that (and I know there's more people that
>> would be interested).
>> Where's the current "non-full" nVersion bits implementation?
>> Why implement a "non-full" version instead of going with the full
>> implementation directly?
>
>
> There is a simple answer to this, convenience: versionbits has not been
> implemented yet, and I believe the BIP is still in review stage. As it seems
> likely the remaining locktime pull requests will be ready by or before the
> next major release, we need a deployment method if versionbits is not ready
> (which is unlikely because no-one appears to be working on it at the
> moment). Pieter indicated he is OK with another IsSuperMajority() rollout in
> the interim. Personally, I dont think we should let perfection be the enemy
> of progress here because at the end of the day, the deployment method is
> less important than the actual featureset being proposed.
>
> That said, the features in the next soft fork proposal are all related and
> best deployed as one featureset softfork, but moving forward, versionbits
> seems essential to be able to roll out multiple features in parallel without
> waiting for activation and enforcement each time.
>
>
>
>
>

📅 Original date posted:2015-08-19 📝 Original message:Seems ...

2023-06-07T19:36:57+02:00

In reply to nevent1q…xyhf
_________________________

📅 Original date posted:2015-08-19
📝 Original message:Seems like 3 is something we want to do no matter what and therefore
is the "most future-proof" solution.
I wonder if I can help with that (and I know there's more people that
would be interested).
Where's the current "non-full" nVersion bits implementation?
Why implement a "non-full" version instead of going with the full
implementation directly?

On Wed, Aug 19, 2015 at 8:10 AM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> We can use nVersion & 0x8 to signal support, while keeping the consensus
> rule as nVersion >= 4, right? That way we don't waste a bit after this all
> clears up.
>
> On Aug 18, 2015 10:50 PM, "Peter Todd via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Deployment of the proposed CLTV, CSV, etc. soft-forks has been recently
>> complicated by the existence of XT(1) and Not-Bitcoin-XT(2) miners. Both
>> mine blocks with nVersion=0x20000007, which would falsely trigger the
>> previously suggested implementation using the IsSuperMajority()
>> mechanism and nVersion=4 blocks. Additionally while the
>> XT/Not-Bitcoin-XT software claims to support Wuille/Todd/Maxwell's
>> nVersion soft-fork mechanism(3) a key component of it - fork
>> deadlines(3) - is not implemented.
>>
>>
>> XT/Not-Bitcoin-XT behavior
>> --------------------------
>>
>> Both implementations produce blocks with nVersion=0x20000007,
>> or in binary: 0b001...111
>>
>> Neither implementation supports a fork deadline; both Not-Bitcoin-XT and
>> XT will produce blocks with those bits set indefinitely under any
>> circumstance, with the proviso that while XT has a hashing power
>> majority, blocks it produces might not be part of the Bitcoin blockchain
>> after Jan 11th 2016. (though this can flap back and forth if reorgs
>> happen)
>>
>> Curiously the BIP101 draft was changed(4) at the last minute from using
>> the nVersion bits compliant 0x20000004 block nVersion, to using two more
>> bits unnecessarily. The rational for doing this is unknown; the git
>> commit message associated with the change suggested "compatibility
>> concerns", but what the concerns actually were isn't specified. Equally
>> even though implementing the fork deadline would be very each in the XT
>> implementation, this was not done. (the XT codebase has had almost no
>> peer review)
>>
>>
>> Options for CLTV/CSV/etc. deployment
>> ------------------------------------
>>
>> 1) Plain IsSuperMajority() with nVersion=4
>>
>> This option can be ruled out immediately due to the high risk of
>> premature triggering, without genuine 95% miner support.
>>
>>
>> 2) nVersion mask, with IsSuperMajority()
>>
>> In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would
>> be masked away, prior to applying standard IsSuperMajority() logic:
>>
>> block.nVersion & ~0x20000007
>>
>> This means that CLTV/CSV/etc. miners running Bitcoin Core would create
>> blocks with nVersion=8, 0b1000. From the perspective of the
>> CLTV/CSV/etc. IsSuperMajority() test, XT/Not-Bitcoin-XT miners would be
>> advertising blocks that do not trigger the soft-fork.
>>
>> For the perpose of soft-fork warnings, the highest known version can
>> remain nVersion=8, which is triggered by both XT/Not-Bitcoin-XT blocks
>> as well as a future nVersion bits implementation. Equally,
>> XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an
>> unknown bit set.
>>
>> When nVersion bits is implemented by the Bitcoin protocol, the plan of
>> setting the high bits to 0b001 still works. The three lowest bits will
>> be unusable for some time, but will be eventually recoverable as
>> XT/Not-Bitcoin-XT mining ceases.
>>
>> Equally, further IsSuperMajority() softforks can be accomplished with
>> the same masking technique.
>>
>> This option does complicate the XT-coin protocol implementation in the
>> future. But that's their problem, and anyway, the maintainers
>> (Hearn/Andresen) has strenuously argued(5) against the use of soft-forks
>> and/or appear to be in favor of a more centralized mandatory update
>> schedule.(6)
>>
>>
>> 3) Full nVersion bits implementation
>>
>> The most complex option would be to deploy via full nVersion bits
>> implementation using flag bit #4 to trigger the fork. Compliant miners
>> would advertise 0x20000008 initially, followed by 0x20000000 once the
>> fork had triggered. The lowest three bits would be unusable for forks
>> for some time, although they could be eventually recovered as
>> XT/Not-Bitcoin-XT mining ceases.
>>
>> The main disadvantage of this option is high initial complexity - the
>> reason why IsSuperMajority() was suggested for CLTV/CSV in the first
>> place. That said, much of the code required has been implemented in XT
>> for the BIP101 hard-fork logic, although as mentioned above, the code
>> has had very little peer review.
>>
>>
>> References
>> ----------
>>
>> 1) https://github.com/bitcoinxt/bitcoinxt
>>
>> 2) https://github.com/xtbit/notbitcoinxt
>>
>> 3) "Version bits proposal",
>> Pieter Wuille, May 26th 2015, Bitcoin-development mailing list,
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008282.html,
>> https://gist.github.com/sipa/bf69659f43e763540550
>>
>> 4)
>> https://github.com/bitcoin/bips/commit/3248c9f67bd7fcd1d05b8db7c5c56e4788deebfe
>>
>> 5) "On consensus and forks - What is the difference between a hard and
>> soft fork?",
>> Mike Hearn, Aug 12th 2015,
>> https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7
>>
>> 6) 2013 San Jose Bitcoin conference developer round-table
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-08-19 📝 Original message:By the ...

2023-06-07T19:35:54+02:00

In reply to nevent1q…e28k
_________________________

📅 Original date posted:2015-08-19
📝 Original message:By the way, now that I remember why I subscribed to the libbitcoin
list I want to share it with you.
I met Amir Taaki in person in a spanish hackmeeting and had the chance
to talk a lot with him, very interesting person whose input in this
blocksize matter I would greatly appreciate. He explained some of his
concerns with Bitcoin Core (Bitcoin-qt at the time) and he
specifically named 2 persons: Mike Hearn and Gavin Andresen. If I
remember correctly, Hearn had recently proposed a blacklisting scheme
for Bitcoin.

I remember I said something along the lines:
"Mike Hearn has certainly proposed some nasty things but I don't think
other devs will ever accept that kind of changes in Bitcoin-qt.
Regarding Gavin, I believe he is someone that can be trusted even if
he visited the CIA. If anything, I think he is overly conservative
about some changes, but that's very understandable given how fragile
Bitcoin is (specially at this early stage)".

Looking back, I now realize that his concerns were not exaggerated at
all and I was clearly wrong thinking Gavin was overly conservative.
He was also worried about the payment protocol and we agreed to
disagree there (maybe I should read all the payment protocol stuff
more deeply).

I don't want this to be taken as an argument of authority "Mike and
Gavin cannot be trusted because Amir didn't trust them", just as a
curious anecdote.
Amir, I wouldn't like to put words in your mouth: that's why I cc'ed
you so you can correct me in case my memory is failing.

📅 Original date posted:2015-08-19 📝 Original message:On ...

2023-06-07T19:35:53+02:00

In reply to nevent1q…h9kv
_________________________

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 10:04 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> But the consensus code should NOT be subject to the same commit policies…and we should make an effort to separate the two clearly. And we should find a way to communicate the difference succinctly and clearly to laypeople (which is something I think the XT opponents have been horrible at doing so far).

I think that effort is in progress (again, much slower that I would
like it to be) and it's called libconsensus.
Once we have libconsensus Bitcoin Core it's just another
implementation (even if it is the reference one) and it's not "the
specification of the consensus rules" which is a "privileged" position
that brings all sorts of misunderstandings and problems (the block
size debate is just one example).

📅 Original date posted:2015-08-19 📝 Original message:On ...

2023-06-07T19:35:52+02:00

In reply to nevent1q…feuv
_________________________

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 9:48 PM, Eric Lombrozo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> [...]
> core devs” and relying on the fact that many people out there can’t seem to
> tell the difference between a source code fork and a blockchain fork.

And this is precisely why we should make perfectly clear that we're
not against a code fork where Hearn or anyone else acts as a
"benevolent dictator", just against the controversial hardfork it is
attempting to deploy.
Otherwise the PR battle is probably lost (which may mean users sell
all their BTC for XTBTC [or just forget about their BTC and only care
about their XTBTC]).

📅 Original date posted:2015-08-19 📝 Original message:On ...

2023-06-07T19:35:50+02:00

In reply to nevent1q…th73
_________________________

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 6:53 PM, Adam Back via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> (and that in a hard fork it is not a miner vote really
> as in soft-forks).

I think calling it "miner vote" was the first mistake: miner's
shouldn't have a "voting power" the rest of the users lack.
I prefer to call it "miner upgrade confirmation" and in BIP99 the
recommendation is to use 95% for both uncontroversial softforks and
uncontroversial hardforks (the uncontroversial harforks also have a
minimum height before starting the miner confirmation/voting to give
users additional time to upgrade).
To me it's no different that the mechanism is used for uncontroversial
softforks or hardforks, the main question is that it is NOT a "miners'
democracy/oligopoly".
If you expect everyone (including all miners) to upgrade, I don't
think any less than 95% makes sense. On the other hand, 100% makes it
relatively cheap for an attacker to block uncontroversial consensus
changes.

For a Schism hardfork, bip99 doesn't recommend to use miner's
confirmation/vote at all. Miners could be against the change, for
example in an ASIC-reset Schism hardfork or in a "hardfork" (it cannot
be a softfork if miners oppose to it) to reduce the block size), but
that shouldn't stop the hardforkers if they think dividing the
currency in 2 is the best solution to whatever is the problem at hand
(which I don't think it's the case now).

Of course, BIP99 is still a draft and can still be changed. But I
would really like that we focused on "how to do hardforks in general"
first and only then focus on how to make a blocksize hardfork
concretely.

📅 Original date posted:2015-08-17 📝 Original message:On ...

2023-06-07T19:35:45+02:00

In reply to nevent1q…645s
_________________________

📅 Original date posted:2015-08-17
📝 Original message:On Mon, Aug 17, 2015 at 9:28 PM, Gregory Maxwell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>> enter the mining game. A bit like making P2Pool the one and only pool
>> allowed on the network.
>
> Thats been suggested, though scalablity reasons make this hard: in the
> P2Pool design there is a substantial tradeoff in variance reduction vs
> communicatoin costs.

Pools could be somehow required to do p2pool between them, but there
would still be pools to further reduce variance, no?

📅 Original date posted:2015-08-17 📝 Original message:On ...

2023-06-07T19:35:39+02:00

In reply to nevent1q…pdqg
_________________________

📅 Original date posted:2015-08-17
📝 Original message:On Mon, Aug 17, 2015 at 1:51 PM, Oliver Egginger <bitcoin at olivere.de> wrote:
> Am 17.08.2015 um 13:44 schrieb Jorge Timón:
>>
>> On Aug 17, 2015 1:40 PM, "Oliver Egginger via bitcoin-dev"
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>> That made it to the news and is now discussed in various places. Could
>>> you please delete Satoshis old email addresses from the list and block
>>> them? Sorry to post this to all members but I can't find an owner for
>>> this list.
>>
>> Why should we block any email address?
>
> To avoid such discussions.

You mean to avoid discussions about his authenticity?
Should that matter at all?
Does the content of the post matter less than its author?

📅 Original date posted:2015-08-17 📝 Original message:On ...

2023-06-07T19:35:39+02:00

In reply to nevent1q…a4a2
_________________________

📅 Original date posted:2015-08-17
📝 Original message:On Mon, Aug 17, 2015 at 7:01 PM, Oliver Egginger <bitcoin at olivere.de> wrote:
> Am 17.08.2015 um 18:32 schrieb Jorge Timón:
>> On Mon, Aug 17, 2015 at 1:51 PM, Oliver Egginger <bitcoin at olivere.de> wrote:
>>> Am 17.08.2015 um 13:44 schrieb Jorge Timón:
>>>>
>>>> On Aug 17, 2015 1:40 PM, "Oliver Egginger via bitcoin-dev"
>>>> <bitcoin-dev at lists.linuxfoundation.org
>>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>>>> That made it to the news and is now discussed in various places. Could
>>>>> you please delete Satoshis old email addresses from the list and block
>>>>> them? Sorry to post this to all members but I can't find an owner for
>>>>> this list.
>>>>
>>>> Why should we block any email address?
>>>
>>> To avoid such discussions.
>>
>> You mean to avoid discussions about his authenticity?
>> Should that matter at all?
>> Does the content of the post matter less than its author?
>
> It just creates confusion. Particularly in the media. I also find it
> unfair if people abuses Satoshi's name to submit their personal views on
> an issue.

Yes, people have been abusing his name in the block size debate to
present their own personal views, almost from the beginning, and that
has been very annoying.
But I don't remember you proposing to block their emails from the list
in those occasions.
For all I know this could have been the real Satoshi. But I just
maintain what I've said when arguments of authority (an old fallacy)
have been used: only the arguments matter, not who makes them (which
is also what logic says).
Maybe the people using the arguments of authority actually care about
whether the author is Satoshi or not to determine what they think
about what the content says.
But I personally don't care: I can say that I agree with what the post
says no matter if it is written by Satoshi or someone else (because
the identity of the author doesn't change what I think of the
content).

📅 Original date posted:2015-08-17 📝 Original message:On Aug ...

2023-06-07T19:35:38+02:00

In reply to nevent1q…xhxn
_________________________

📅 Original date posted:2015-08-17
📝 Original message:On Aug 17, 2015 1:40 PM, "Oliver Egginger via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> That made it to the news and is now discussed in various places. Could
> you please delete Satoshis old email addresses from the list and block
> them? Sorry to post this to all members but I can't find an owner for
> this list.

Why should we block any email address?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/7f1252bc/attachment.html>;

📅 Original date posted:2015-08-19 📝 Original message:On ...

2023-06-07T19:35:32+02:00

In reply to nevent1q…3l4g
_________________________

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 5:41 PM, s7r <s7r at sky-ip.org> wrote:
> Hello Jorge, Eric,
>
> With all this noise on the -dev mail list I had to implement application
> level filters so I can treat with priority posts from certain people,
> you are on that list. While I agree with your arguments, I think it is
> _very_ important to highlight some things. I am neither for the
> blocksize increase neither against it, because plain and simple I don't
> have enough arguments to take some definitive decision on this topic.

I think everyone is in that position (we just don't have enough data
about the proposed sizes) or it's just too optimistic.

> What I am angry about is spreading FUD that a fork could kill Bitcoin
> and what we are experiencing now is somehow terrible.
>
> 1. Bitcoin XT is not necessarily an attack over Bitcoin and will not
> split it into 2 different coins. It is the result of an open source free
> system which lacks centralization. It is just at early stage, it could
> have thousands for forks (or fork attempts) during its life.

Bitcoin XT is just a software fork and nobody seem to have a problem
with that (as repeated in other threads), people are worried about the
way bip101 is going to be attempted to be deployed using Bitcoin XT.
We already have more than 5000 software forks and that's totally fine.

A Schism fork may not kill Bitcoin but it will certainly create 2
different coins.
The claim that "there will be a winner and everybody will just move
there" is incredibly naive and uninformative.
Many people will sell their xtbtc and reject the hardfork
independently of its support by miners.
Nobody knows what the result will be, but both currencies' prices
dropping near zero is certainly a possibility that Gavin and Mike are
not aware about or are not informing their followers about.
Here's something a little bit longer about this topic:
https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR137
Note the last part:

"
+This is very disruptive and hopefully will never be needed. But if
+it's needed the best deployment path is just to activate the rule
+changes after certain block height in the future. On the other hand,
+it is healthy decentralization-wise that many independent software
+projects are ready to deploy a schism hardfork.
"

> 2. We have no proof that Mike Hearn and Gavin Andresen are trying to do
> something bad to Bitcoin. So far everything they have done is (or should
> be) allowed. They have forked an open source software and implemented a
> voting system for a consensus rule change - doesn't sound like they are
> committing a crime here (either legally or morally). If they are
> qualified enough to maintain the software, or if the decision is
> technically correct or not is another story, and it should only matter
> to whoever uses / wants to use -XT.

Again, no problem with the code fork, but the Schism hardfork is very
risky regardless of their intentions.

> 3. If Bitcoin's value can be decreased (or Bitcoin as a project killed)
> just by 2 people forking the software and submitting a consensus rule to
> a vote, it means Bitcoin is dead already and it should be worthless! We
> can't go around and panic every time somebody forks Bitcoin and tries to
> change something - this should be allowed by the nature of its license.
> If tomorrow 5 more people fork 5 different software implementing the
> bitcoin protocol and submit 5 different new consensus rules to a vote,
> then what? We should all sell so the price will drop to 1 cent, because
> it is somehow not good enough, not stable enough?

If they don't extensively lobby Bitcoin companies, they don't start a
massive PR campaign labbeling other developers as "obstructionists"
and don't misinform a big part of the Bitcoin users (often using
logical fallacies, intentionally or not), probably those 5 new
currencies will be ignored and nothing bad will happen.
Unfortunately in this case a great division between users is being created.

> I can fork tomorrow Bitcoin Core to a Bitcoin-XYZ software which at some
> block in the future spends all the longest dusted coins to me, out of
> which I give away 50% to the miners (so the hashing power will have
> incentive to use my fork).
>
> Can they do it? YES
> Will they do it? NO
> Should the world care about this? NO
>
> It's as simple as that. We cannot continue to panic that "Bitcoin as a
> project" is at threat because somebody forked it.

Can you please stop conflating "Bitcoin Core as a project" and
"Bitcoin consensus rules".
They are different things and nobody is or can be "in charge" of the
later, face it.

Can you please also stop conflating software fork and
"Schism/controversial/contentious hardfork"? Nobody has anything
against the former and as you point out it is allowed by its free
software license.

> 4. By having a software fork and consensus rule submitted to vote we
> actually prove how open Bitcoin is, and how there is lack of control
> over it from all parties (developers, miners, engineers on the mail
> list). This is reason to increase Bitcoin's value! It is a feature, not
> a flaw!

Why should miners have a voting power that the rest of the users lack?

> It's very important for everyone in the ecosystem to understand:
>
> - yes, Bitcoin is open source, even you can fork it tomorrow if you want
> and you think enough users might follow you.
>
> - no, it's not a requirement for 100% of the nodes in the network to be
> running Core, or -XT or other implementation. The more we have, the better.
>
> - yes, there is absolutely no authority in Bitcoin - this is what lead
> to this dispute in the first place. This is the truly decentralized
> nature of the software, not important if we have 10.000 full nodes or
> 1000 full nodes.

All this sounds reasonable.

> - no, Bitcoin won't split / die or whatever because of this fork.
> Regardless what it happens, if XT will reach the threshold or not,
> Bitcoin will go on just because it has some unique advantages and has no
> competitor from some points of view.

But you cannot know this will happen this way!
If the threshold is reached (let's forget about noXT for now), the
remaining miners cannot be forced to adopt bip101.
And users can never be forced to adopt hardforks.
It is possible that 75% of the hashrate moves to the bip101 chain
while 99% of the users remain in the old Bitcoin chain. Or 50/50,
40/60...nobody knows.

> - Bitcoin by its design has many many advantages, but also the
> limitation that it relies on majority being honest / doing the right
> thing! This is just the way it is, and the benefits it is offering
> heavily win over this fundamental limitation.

No, it doesn't rely on that. It just relies on the majority of the
miners not attacking the network for too long (ie the number of
confirmations people are waiting).
If I'm running a full node, I'm not isolated from the network and the
majority of the hashrate is not reorging the chain I am safe no matter
how dishonest the "majority" (whatever that means in this context) is.

📅 Original date posted:2015-08-19 📝 Original message:On ...

2023-06-07T19:35:31+02:00

In reply to nevent1q…05q9
_________________________

📅 Original date posted:2015-08-19
📝 Original message:On Mon, Aug 17, 2015 at 1:02 AM, Cameron Garnham via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I think that it is important to note that Bitcoin XT faces a natural
> uphill battle.
>
> Since it is possible to setup atomic inter-fork coin trades. I do not
> see how Bitcoin XT could possibly win if Satoshi decides to sell 10000
> XTBTC for BTC everyday for the first 100 days after the fork.
>
> In many ways Satoshi gets to decide the winning fork just by his huge
> economic investment in Bitcoin.
>
>
> Here is some simple game-theory for non-consensus forks:
>
> 1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version
> string.
>
> 2. Encourage all miners to false vote for the Bitcoin XT fork.
>
> - Now people have no-idea what % of the economy Bitcoin XT holds. -
> Making it impossible for people to put economic faith behind Bitcoin XT.
>
> 3. Setup good Atomic Swap markets.
> [...]
> The price for XTBTC coins will plummet, Satoshi progressively dumping
> his 1M stash over a year or it so will make sure that it doesn't recover
> either.

Some XTBTC advocates may sell all their BTC for XTBTC and viceversa.
But I'm afraid that what most currency speculators (thus most Bitcoin
holders) will do is just sell both all their BTC and XTBTC for fiat,
and wait for things to settle before deciding whether to re-enter or
not.
This could result in both currencies' prices going down to 1 usd cent,
nobody knows.

> I cannot see how Bitcoin XT is but-not in a extremely weak position from
> game theory.

Unfortunately it also puts Bitcoin core in an extremely weaker
position than it was before the Schism hardfork.
Even if XT fails in making blocks bigger, it may destroy Bitcoin.
That's probably not the goal of Bitcoin XT, but I don't think Andresen
and Hearn fully undesrtand the risks of a Schism hardfork (not to
mention their "followers" in the interwebs).

Since we want to discard the assumption that Hearn and Andresen want
to make Bitcoin centralized or destroy it, it's reasonable to conclude
that have serious misunderstandings on how the global consensus works.
This is consistent with some of their strong positions on Bitcoin Core
policy defaults (like maintaining the first seen spending-conflict
replacement policy [the dumbest possible one after "last seen"]
forever).

On Mon, Aug 17, 2015 at 2:33 PM, Eric Lombrozo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Or can’t you create a transaction that’s still within the op count and sig ops limits but is larger than 1MB?

Yes, it seems the simplest way to permanently separate your BTC from
your XTBTC is to move them all in transactions bigger than 1MB. You
may need too many outputs to increase the size (thus also hurting the
utxo size in Bitcoin XT), but that's just a side effect.

📅 Original date posted:2015-08-23 📝 Original message:On ...

2023-06-07T19:34:59+02:00

In reply to nevent1q…0gqr
_________________________

📅 Original date posted:2015-08-23
📝 Original message:On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
> discussion has any thought been given to represent one block with more
> than one increment? This would leave additional space for future
> signaling, or allow, for example, higher resolution numbers for a
> sharechain commitement.

No, I don't think anybody thought about this. I just explained this to
Pieter using "for example, 10 instead of 1".
He suggested 600 increments so that it is more similar to timestamps.

📅 Original date posted:2015-08-19 📝 Original message:I ...

2023-06-07T19:34:57+02:00

In reply to nevent1q…4kvx
_________________________

📅 Original date posted:2015-08-19
📝 Original message:I repeated my nit on https://github.com/bitcoin/bips/pull/179

On Mon, Aug 17, 2015 at 9:58 PM, Btc Drak via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Please note there is now a PR for this BIP[1] and also a pull request for
> the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].
>
> [1] https://github.com/bitcoin/bips/pull/179
> [2] https://github.com/bitcoin/bitcoin/pull/6564
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-08-14 📝 Original message:I ...

2023-06-07T19:34:56+02:00

In reply to nevent1q…s4a8
_________________________

📅 Original date posted:2015-08-14
📝 Original message:I extremely dislike the inversion to preserve the "previous nSequence
semantics". The "previous nSequence semantics" were
consensus-unenforceable but we can cover the same use cases (or the
realistic ones at least) with nMaturity. Let's face it and move on
without technical debt we don't need and may regret. If we do this
inversion we will likely carry it for very long if not forever.
As a side effect, I believe documentation can become much clearer
(maybe even shorter simultaneusly).

📅 Original date posted:2015-08-14 📝 Original message:On ...

2023-06-07T19:34:48+02:00

In reply to nevent1q…ezm5
_________________________

📅 Original date posted:2015-08-14
📝 Original message:On Thu, Aug 13, 2015 at 11:52 AM, Ashley Holman via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> A concern I have is about security (hash rate) as a function of block size.
>
> I am assuming that hash rate is correlated with revenue from mining.
>
> Total revenue from fees as a function of block size should be a curve. On
> one extreme of the curve, if blocks are too big, fee revenue tends towards 0
> as there is no competition for block space. At the other extreme, if blocks
> are too small, fee revenue is limited only to what the most valuable use
> case(s) can afford. Somewhere in the middle there should be a sweet spot
> where fee revenue is maximised. It's not a static curve though, it should
> change as demand for block space changes.
>
> Failing to scale the block size as demand grows might be forfeiting
> potential miner revenue and hence security.
>
> (I don't think that should be a primary concern though since
> decentralisation should come first, but I'm just pointing it out as a
> secondary concern).

I believe your concerns are included in:

1) Potential indirect consequence of rising fees.
[...]
1.4) Less users than we could have had with a bigger size
1.4.2) Not enough fees when subsidy is lower

📅 Original date posted:2015-08-14 📝 Original message:On ...

2023-06-07T19:34:46+02:00

In reply to nevent1q…qmh9
_________________________

📅 Original date posted:2015-08-14
📝 Original message:On Wed, Aug 12, 2015 at 9:52 PM, Elliot Olds <elliot.olds at gmail.com> wrote:
> On Wed, Aug 12, 2015 at 2:59 AM, Jorge Timón
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I believe all concerns I've read can be classified in the following
>> groups:
>>
>> > 1) Potential indirect consequence of rising fees.
>
>
> I'd rephrase this as "Consequences of high fees." It's the level of fees
> that is the main issue, not their movement.

I think potential is more general since it allows us to list uncertain
consequences (aren't all consequences just projections and thus
uncertain anyway?).

> Moving from 0 satoshi to 1 satoshi fees makes no real difference.

It is a big difference to me (it may mean policy code has improved a
lot in the process).
Anyway, I'm heppy to hear again that this is not a concern, at some
point I thought this was the ONLY concern, so I was clearly
misinterpreting people's arguments.

> Moving from $0 to $1 fees makes a
> huge difference. Some consequences are indirect, but others are not (the
> first three below are not indirect). Some of the consequences are uncertain,
> but others we can have very high confidence in (again: the first three) and
> it's only their effect size that can be reasonably disputed.

Let's list them all first and then identify which are more worrying in
the short term.

> Here are lots of reasons that you're missing. High fees do the following:
>
> -Reduce the utility of people using the network, even if the higher fees
> don't reduce their amount of transactions.

"Utility" like "value" is always subjective and very vague. I prefer
to identify more concrete ways in which "utility is reduced".

> -Make some use cases nonviable, depriving people of Bitcoin's decentralized
> benefits.

It is clear that not all use cases fit the blockchain, but it's still
unclear which ones don't fit yet.
But the amount of use cases supported is not a valid metric for
decentralization.
In any case, it would be interesting if we could list some concrete
cases that would be lost.

> -Makes level 2 infrastructure like Lightning less valuable by increasing the
> minimum value of anchor txns that make sense, and increasing the amount of
> pain suffered when your counterparty misbehaves.

This is correct. Layer 2 can become more expensive in total as well
(it doesn't mean layer 2 doesn't scale though).
I wil add it as 1.3

> -Discourage experimentation with new Bitcoin use cases, making it more
> unlikely that such cases are discovered/improved/popular before Bitcoin's
> security relies on having many users.

Experimentation can be done with worthless testchains. I'm not sure
I'm following on this one.

> -Makes Bitcoin more vulnerable to regulation by keeping its user base from
> growing, meaning regulators face less pressure to keep it unregulated (see:
> Uber)

Added:

1.4) Less users than we could have had with a bigger size
1.4.1) More regulation pressure

> -Reduce the amount of time we have between now and when tx fees need to pay
> for a significant portion of Bitcoin's security, by keeping the exchange
> rate and thus the value of block rewards low
> (https://en.wikipedia.org/wiki/Equation_of_exchange)

Related to exchange rate.

> -By slowing usage growth, make it less likely that we have a large enough
> base of transactions by the time we need to fund network security via tx
> fees.

Added:

1.4.2) Not enough fees when subsidy is lower

Resulting list:

1) Potential indirect consequence of rising fees.

1.1) Lowest fee transactions (currently free transactions) will become
more unreliable.
1.2) People will migrate to competing systems (PoW altcoins) with lower fees.
1.3) Layer 2 settlements become more expensive
1.4) Less users than we could have had with a bigger size
1.4.1) More regulation pressure
1.4.2) Not enough fees when subsidy is lower

2) Software problem independent of a concrete block size that needs to
be solved anyway, often specific to Bitcoin Core (ie other
implementations, say libbitcoin may not necessarily share these
problems).

2.1) Bitcoin Core's mempool is unbounded in size and can make the program
crash by using too much memory.

2.2) There's no good way to increase the fee of a transaction that is
taking too long to be mined without the "double spending" transaction
with the higher fee being blocked by most nodes which follow Bitcoin
Core's default policy for conflicting spends replacements (aka "first
seen" replacement policy).

📅 Original date posted:2015-08-14 📝 Original message:On ...

2023-06-07T19:34:45+02:00

In reply to nevent1q…d7xk
_________________________

📅 Original date posted:2015-08-14
📝 Original message:On Sat, Aug 15, 2015 at 12:35 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> On Wed, Aug 12, 2015 at 1:21 PM, Venzen Khaosan <venzen at mail.bihthai.net> wrote:
>> 4) General, undefined fear that something bad is going to happen when
>> nodes choke up on a backlog of transactions.
>> - - no specific symptoms are pointed at but presumably there is
>> "pre-traumatic stress" at play.
>> - - Bitcoin-based businesses are going to lose money, customers and
>> potentially fail
>> - - people will flee Bitcoin for another cryptocoin and Bitcoin will be
>> left in the corner, collecting dust and memories of it will fade as
>> SuperCoin with its big blocks becomes all things to all people.
>
> I believe thisbelongs in 2, not really sure if 2.1 or 2.2 since it's
> related to both.

I was tempted to add it as a sub-sub-risk in both, since both things
need to be solved before that stop being a concern. But they may be
more things to do to solve that so I'm listing it as a separate
sub-risk in 2:

2.3) Big list of valid unconfirmed transactions

resulting list:

1) Potential indirect consequence of rising fees.

1.1) Lowest fee transactions (currently free transactions) will become
more unreliable.
1.2) People will migrate to competing systems (PoW altcoins) with lower fees.
1.3) Layer 2 settlements become more expensive
1.4) Less usage than we could have had with a bigger size
1.4.1) More regulation pressure
1.4.2) Not enough fees when subsidy is lower

2) Software problem independent of a concrete block size that needs to
be solved anyway, often specific to Bitcoin Core (ie other
implementations, say libbitcoin may not necessarily share these
problems).

2.1) Bitcoin Core's mempool is unbounded in size and can make the program
crash by using too much memory.

2.2) There's no good way to increase the fee of a transaction that is
taking too long to be mined without the "double spending" transaction
with the higher fee being blocked by most nodes which follow Bitcoin
Core's default policy for conflicting spends replacements (aka "first
seen" replacement policy).

2.3) Big list of valid unconfirmed transactions

📅 Original date posted:2015-08-14 📝 Original message:To be ...

2023-06-07T19:34:45+02:00

In reply to nevent1q…nsdc
_________________________

📅 Original date posted:2015-08-14
📝 Original message:To be clear, these two are just my personal lists of arguments on
"each side" to clear my mind and try to be perfectly objective.
The resulting lists may not have any practical value but I'm going to
maintain them locally nonetheless. If that's is not useful for the
participants they can just leave the thread.
I'm not going to be impartial: I will only add to my lists the
arguments that I consider reasonable and, more importantly, I
understand.

The lists are in the public domain and everybody is free to use it and
modify it in any way, feel free to fork the threads with other
criteria different from "whatever jtimon thinks is reasonable", but if
you want to participate, face it, it's what these 2 threads are about.

Here's the updated both-thread lists:

http://0bin.net/paste/igHZMgeoIbYjCJd9#ovaOUlSAKvQYT2p3VXuIuUmNk2XyLH-GnjR5NZMZgFb

📅 Original date posted:2015-08-14 📝 Original message:On ...

2023-06-07T19:34:44+02:00

In reply to nevent1q…62yu
_________________________

📅 Original date posted:2015-08-14
📝 Original message:On Wed, Aug 12, 2015 at 1:21 PM, Venzen Khaosan <venzen at mail.bihthai.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jorge, you say 3 concerns at the end of your message but I only see 1)
> and 2). Assuming you've got a 3) and will add it, I'll contribute:

No, sorry it's 2 concerns/risks with 2 sub-concerns/risks each:

1) Potential indirect consequence of rising fees.

1.1) Lowest fee transactions (currently free transactions) will become
more unreliable.
1.2) People will migrate to competing systems (PoW altcoins) with lower fees.

2) Software problem independent of a concrete block size that needs to
be solved anyway, often specific to Bitcoin Core (ie other
implementations, say libbitcoin may not necessarily share these
problems).

2.1) Bitcoin Core's mempool is unbounded in size and can make the program
crash by using too much memory.

2.2) There's no good way to increase the fee of a transaction that is
taking too long to be mined without the "double spending" transaction
with the higher fee being blocked by most nodes which follow Bitcoin
Core's default policy for conflicting spends replacements (aka "first
seen" replacement policy).

> 4) General, undefined fear that something bad is going to happen when
> nodes choke up on a backlog of transactions.
> - - no specific symptoms are pointed at but presumably there is
> "pre-traumatic stress" at play.
> - - Bitcoin-based businesses are going to lose money, customers and
> potentially fail
> - - people will flee Bitcoin for another cryptocoin and Bitcoin will be
> left in the corner, collecting dust and memories of it will fade as
> SuperCoin with its big blocks becomes all things to all people.

I believe thisbelongs in 2, not really sure if 2.1 or 2.2 since it's
related to both.

> 5) Specific belief that the exchange rate will decline on network
> unreliability
> - - traders and investors will bid the price down, or
> - - traders/investors will stop speculating all together because even if
> their speculation is successful, they're not sure they'll be able to
> get their bitcoin out of exchanges, what with the broken network and all.
> - - The exchange rate reflects Bitcoin's value and not just speculation
> guided by a few large players like in other markets.

I believe "fear of exchange rate declining" can probably be added to
any concern/risk "leaf", so we should probably leave that for the end
or just omit it.

> 6) Belief that Bitcoin's "cargo" is about to be delivered by fate:
> - - see https://en.wikipedia.org/wiki/Cargo_cult
> - - the cargo is variably presumed to be a range of hoped-for events: an
> adoption surge, a speculative rally similar to (or bigger than) 2013,
> or a global financial crisis that sees Bitcoin become the safe haven
> of choice.
> - - for the cargo to be delivered, a "runway" must be built - the larger
> the runway, the larger the cargo delivery. If the current runway is
> not expanded, then the cargo plane will go to a different island and
> won't come to Bitcoin Island.
> - - it is short-sighted and, in a way, ungrateful of the "generals" not
> to expand the runway - it will be their fault that the cargo doesn't
> get delivered and all the island's people, no the whole ocean's
> islands, will suffer because of silly security concerns.
> - - some people have taken the blueprints of the airbase and are
> building a large airstrip elsewhere on Bitcoin Island, but nobody is
> helping them build that long and wide runway. Everybody wants to
> expand this moderate runway - even the renegades who started Big
> Blocks Great Success airstrip.
> - - The sacred site of No-Middle-Zero-Attack-Point is at the start of
> the current runway. To expand it the site must be destroyed, but some
> former generals and many people say: It doesn't matter, we want Cargo,
> not a small attack surface. Just blast it!

I'm not sure I understood this but seems related to the exchange rate.

📅 Original date posted:2015-08-12 📝 Original message:I ...

2023-06-07T19:34:43+02:00

In reply to nevent1q…nf6n
_________________________

📅 Original date posted:2015-08-12
📝 Original message:I believe all concerns I've read can be classified in the following groups:

> 1) Potential indirect consequence of rising fees.

- Lowest fee transactions (currently free transactions) will become
more unreliable.
- People will migrate to competing systems (PoW altcoins) with lower fees.

> 2) Software problem independent of a concrete block size that needs to
> be solved anyway, often specific to Bitcoin Core (ie other
> implementations, say libbitcoin may not necessarily share these
> problems).

- Bitcoin Core's mempool is unbounded in size and can make the program
crash by using too much memory.
- There's no good way to increase the fee of a transaction that is
taking too long to be mined without the "double spending" transaction
with the higher fee being blocked by most nodes which follow Bitcoin
Core's default policy for conflicting spends replacements (aka "first
seen" replacement policy).

I have started with the 3 concerns that I read more often, but please
suggest more concerns for these categories and suggest other
categories if you think there's more.

📅 Original date posted:2015-08-10 📝 Original message:On Aug ...

2023-06-07T19:33:58+02:00

In reply to nevent1q…rc0j
_________________________

📅 Original date posted:2015-08-10
📝 Original message:On Aug 10, 2015 4:12 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
>
> On Fri, Aug 7, 2015 at 1:33 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>>
>>
>> On Aug 7, 2015 5:55 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
> Executive summary: when networks get over-saturated, they become
unreliable. Unreliable is bad.
>
> Unreliable and expensive is extra bad, and that's where we're headed
without an increase to the max block size.

I'm not trying to be obstinate but I seriously can't see how they are
different.
When you say unreliable I think you mean "unreliable for cheap fee
transactions". Transactions with the highest fees will always confirm
reliably. For example, a 1 btc fee tx will probably always confirm very
reliably even if capacity never increases and demands increases a lot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150810/7a3b9433/attachment.html>;

📅 Original date posted:2015-08-12 📝 Original message:On Aug ...

2023-06-07T19:33:54+02:00

In reply to nevent1q…97ds
_________________________

📅 Original date posted:2015-08-12
📝 Original message:On Aug 12, 2015 10:11 AM, "Thomas Zander via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Tuesday 11. August 2015 21.51.59 Pieter Wuille via bitcoin-dev wrote:
> > If people are doing transactions despite being unreliable, there
> > must be a use for them.
>
> Thats one usage of the form unreliable.
> Yes, if people start getting their transactions thrown out because of full
> blocks or full memory pools, then its unreliable to send stuff.
>
> Much more importantly is the software is unreliable at such loads. Bitcoin
> core will continue to grow in memory consumption, and eventually crash.
Or,
> worse, crash the system its running on.
> We know of some issues in the software with regards to running at > 100%
> capacity, I'm sure we'll find more when it actually happens.

Don't fear this happening at 1 MB, fear this happening at any size. This
needs to be solved regardless of the block size.
Don't worry, the "doing nothing side" is already taking care of this. I
will give the link for the second time...

https://github.com/bitcoin/bitcoin/pull/6470
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150812/bc8295bc/attachment.html>;

📅 Original date posted:2015-08-11 📝 Original message:On Aug ...

2023-06-07T19:33:45+02:00

In reply to nevent1q…duxr
_________________________

📅 Original date posted:2015-08-11
📝 Original message:On Aug 11, 2015 8:46 PM, "Michael Naber" <mickeybob at gmail.com> wrote:
>
> Hi Jorge: Many people would like to participate in a global consensus
network -- which is a network where all the participating nodes are aware
of and agree upon every transaction. Constraining Bitcoin capacity below
the limits of technology will only push users seeking to participate in a
global consensus network to other solutions which have adequate capacity,
such as BitcoinXT or others. Note that lightning / hub and spoke do not
meet requirements for users wishing to participate in global consensus,
because they are not global consensus networks, since all participating
nodes are not aware of all transactions.

Even if you are right, first fees will raise and that will be what pushes
people to other altcoins, no?
Can we agree that the first step in any potentially bad situation is
hitting the limit and then fees rising as a consequence?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/b23a80e6/attachment.html>;

📅 Original date posted:2015-08-11 📝 Original message:On Aug ...

2023-06-07T19:33:44+02:00

In reply to nevent1q…khr6
_________________________

📅 Original date posted:2015-08-11
📝 Original message:On Aug 11, 2015 8:55 PM, "Michael Naber" <mickeybob at gmail.com> wrote:
>
> It generally doesn't matter that every node validate your coffee
transaction, and those transactions can and will probably be moved onto
offchain solutions in order to avoid paying the cost of achieving global
consensus. But you still don't get to set the cost of global consensus
artificially. Market forces will ensure that supply will meet demand there,
so if there is demand for access to global consensus, and technology exists
to meet that demand at a cost of one cent per transaction -- or whatever
the technology-limited cost of global consensus happens to be -- then
that's what the market will supply.

Assuming we maintain any block size maximum consensus rule, the market will
adapt to whatever maximum size is imposed by the consensus rules.
For example, with the current demand and the current consensus block size
maximum, the market has settled on a minimum fee of zero satoshis per
transaction. That's why I cannot understand the urgency to rise the maximum
size.

In any case, yhe consensus maximum shouldn't be based on current or
projected demand, only on centralization concerns, which is what the
consensus rule serves for (to limit centralization).
For example, Gavin advocates for 20 MB because he is not worried about how
that could increase centralization because he believes it won't.
I can't agree with that because I believe 20 MB could make mining
centralization (and centralization in general) much worse.

But if I have to chose between 2 "centralization safe" sizes, sure, the
bigger the better, why not.
In my opinion the main source of disagreement is that one: how the maximum
block size limits centralization.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/f89400cf/attachment.html>;

📅 Original date posted:2015-08-11 📝 Original message:On Aug ...

2023-06-07T19:33:42+02:00

In reply to nevent1q…ah8a
_________________________

📅 Original date posted:2015-08-11
📝 Original message:On Aug 11, 2015 12:14 AM, "Thomas Zander via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Monday 10. August 2015 13.55.03 Jorge Timón via bitcoin-dev wrote:
> > Gavin, I interpret the absence of response to these questions as a
> > sign that everybody agrees that there's no other reason to increase
> > the consensus block size other than to avoid minimum market fees from
> > rising (above zero).
> > Feel free to correct that notion at any time by answering the
> > questions yourself.
> > In fact if any other "big block size advocate" thinks there's more
> > reason I would like to hear their reasons too.
>
> See my various emails in the last hour.

I've read them. I have read gavin's blog posts as well, several times.
I still don't see what else can we fear from not increasing the size apart
from fees maybe rising and making some problems that need to be solved
rewardless of the size more visible (like a dumb unbounded mempool design).

This discussion is frustrating for everyone. I could also say "This have
been explained many times" and similar things, but that's not productive.
I'm not trying to be obstinate, please, answer what else is to fear or
admit that all your feas are just potential consequences of rising fees.

With the risk of sounding condescending or aggressive...Really, is not that
hard to answer questions directly and succinctly. We should all be friends
with clarity. Only fear, uncertainty and doubt are enemies of clarity. But
you guys on the "bigger blocks side" don't want to spread fud, do you?
Please, prove paranoid people like me wrong on this point, for the good of
this discussion. I really don't know how else to ask this without getting a
link to something I have already read as a response.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/560a774e/attachment.html>;

📅 Original date posted:2015-08-10 📝 Original message:On ...

2023-06-07T19:33:42+02:00

In reply to nevent1q…8e7d
_________________________

📅 Original date posted:2015-08-10
📝 Original message:On Mon, Aug 10, 2015 at 2:33 PM, Btc Drak <btcdrak at gmail.com> wrote:
> Additionally, correct me if I am wrong, but the net effect from preventing
> fees rising from zero would be to guarantee miners have no alternative
> income from fees as block subsidy dries up and thus harm the incentives to
> secure the chain.

I don't think that's necessarily true. Theoretically urgent
transactions could fund hashing power on their own while there are
still some free non-urgent transactions being mined from time to time.

📅 Original date posted:2015-08-11 📝 Original message:On Aug ...

2023-06-07T19:33:41+02:00

In reply to nevent1q…g63u
_________________________

📅 Original date posted:2015-08-11
📝 Original message:On Aug 9, 2015 10:44 PM, "Dave Scotese via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Sun, Aug 9, 2015 at 3:42 AM, Thomas Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev wrote:
>> > Someone mentioned that when the backlog grows faster than it shrinks,
that
>> > is a real problem. I don't think it is. It is a problem for those who
>> > don't wait for even one confirmation
>>
>> The mention you refer to was about the fact that the software doesn't
cope
>> well with a continuously growing mempool.
>> If Bitcoind starts eating more and more memory, I expect lots of people
that
>> run it now to turn it off.
>
>
> That is a real problem then. While emptying the mempool faster with
bigger blocks will help to reduce the occurrence of that problem, I propose
a user-configurable default limit to the size of the mempool as a permanent
solution regardless of block size. "This software has stopped consuming
memory necessary to validate transactions. You can override this by ..."
If anyone feels that protecting those running full nodes from bitcoind
eating more and more memory this way is a good idea, I can make a BIP out
of it if that would help.

You are completely right: this problem has nothing to do with the consensus
block size maximum and it has to be solved regardless of what the maximum
is. No BIP is necessary for this. The "doing nothing side" has been working
on this too:
https://github.com/bitcoin/bitcoin/pull/6470
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/277e1f15/attachment.html>;

📅 Original date posted:2015-08-10 📝 Original message:Gavin, ...

2023-06-07T19:33:41+02:00

In reply to nevent1q…4h84
_________________________

📅 Original date posted:2015-08-10
📝 Original message:Gavin, I interpret the absence of response to these questions as a
sign that everybody agrees that there's no other reason to increase
the consensus block size other than to avoid minimum market fees from
rising (above zero).
Feel free to correct that notion at any time by answering the
questions yourself.
In fact if any other "big block size advocate" thinks there's more
reason I would like to hear their reasons too.

On Fri, Aug 7, 2015 at 7:33 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Aug 7, 2015 5:55 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
>>
>> I think there are multiple reasons to raise the maximum block size, and
>> yes, fear of Bad Things Happening as we run up against the 1MB limit is one
>> of the reasons.
>
> What are the other reasons?
>
>> I take the opinion of smart engineers who actually do resource planning
>> and have seen what happens when networks run out of capacity very seriously.
>
> When "the network runs out of capacity" (when we hit the limit) do we expect
> anything to happen apart from minimum market fees rising (above zero)?
> Obviously any consequences of fees rising are included in this concern.

📅 Original date posted:2015-08-07 📝 Original message:On Aug ...

2023-06-07T19:33:37+02:00

In reply to nevent1q…tjvk
_________________________

📅 Original date posted:2015-08-07
📝 Original message:On Aug 7, 2015 5:55 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
>
> I think there are multiple reasons to raise the maximum block size, and
yes, fear of Bad Things Happening as we run up against the 1MB limit is one
of the reasons.

What are the other reasons?

> I take the opinion of smart engineers who actually do resource planning
and have seen what happens when networks run out of capacity very seriously.

When "the network runs out of capacity" (when we hit the limit) do we
expect anything to happen apart from minimum market fees rising (above
zero)?
Obviously any consequences of fees rising are included in this concern.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/71828dbc/attachment-0001.html>;

📅 Original date posted:2015-08-05 📝 Original message:There ...

2023-06-07T19:33:21+02:00

In reply to nevent1q…n8xl
_________________________

📅 Original date posted:2015-08-05
📝 Original message:There is a common meme that block propagation times is the only metric
that matters when it comes to value the block size maximum consensus
rule's usefulness in limiting mining centralization.
Here is an extremely optimist thought experiment for those who think
that is the case:

Imagine that superluminal communication has somehow been invented and
validity of mined blocks can be checked in constant time thanks to
some sort of snarks magic. This doesn't mean that block propagation is
O(1) with respect to time because each node needs to repeat that cheap
validation before relaying the block.
Still, this is the best situation we can imagine with respect to block
propagation, right?
No, wait, due to some technical or economical miracle this
superluminal communication is free for everyone:
better-than-physically-possible (our understanding of physics changes
with time as well, right?) communication and infinite bandwidth for
everyone.

At this point, does the consensus block size maximum still help
limiting mining centralization or we can just remove it entirely?
The answer is yes, it can help limit mining centralization.

Let's imagine that these amazing advancements have happened in less
than 22 years and we only had 6 more subsidy halvings, that's only 7
halvings in total, so the subsidy is still as high as 50 * (0.5 ^ 7) =
0.390625 btc/block

Although the orphan-block-probability cost for a miner to include an
extra transaction has been completely minimized, it is still not null.
Let's assume that while all these technical miracles were
happening...that 22 more years was enough for miners to realize this
fact, they have removed the special-cased-for-free-transaction policy
code that currently comes with Bitcoin Core (or it has been removed
from Bitcoin Core) and they don't mine transactions with fees lower
than 1 satoshi anymore.
<sarcasm>I hope this last assumption doesn't turn out to be more wild
than superluminal communication...</sarcasm>

But there must be a physical limit: in our example, miners will have
different CPU constraints (to further simplify, genetically-engineered
and super-fast memory also grows in the streets everywhere after an
accident in a Monsanto Lab; or better downloadmoreram.com actually
works and I just hadn't tried from windows or mac).

Miner A is able to process 100 M tx/block while miner B is only able
to process 10 M tx/block.

Will miner B be able to maintain itself competitive against miner B?

The answer is: it depends on the consensus maximum block size.
How so? Let's imagine that it has been completely removed.

Assuming a fee of 1 satoshi per transaction and no shortage of
unconfirmed transactions, miner A's block reward will be 0.390625 + 1
= 1.390625 btc vs miner B's 0.390625 + 0.1 = 0.390625 + 0.1 = 0.490625
btc.

Difficulty will tend to increase until the cost to produce a block
(including interest in all the capital needed, paid or not) is equal
to 1.390625 btc and therefore miner B will stop mining or go bankrupt.
But maybe 100 M and 10 M were too high numbers. What about 10 M and 1
M? Still, 0.400625 btc can't compete with 0.490625 btc.
You think 10x is too much of a difference? Fine, 2M vs 1M: still
0.400625 btc can't compete with 0.410625 btc

In summary, there will always be some physical limitation that may
benefit big mining players, so the block size maximum will always be
useful to limit mining centralization.
In other words (and I don't intend this to sound rude), if you want to
eventually remove the block size maximum consensus rule entirely, I
will never be able to agree with you: not even in your wildest dreams.

📅 Original date posted:2015-08-10 📝 Original message:On ...

2023-06-07T19:32:38+02:00

In reply to nevent1q…0qr6
_________________________

📅 Original date posted:2015-08-10
📝 Original message:On Fri, Aug 7, 2015 at 1:09 AM, Elliot Olds <elliot.olds at gmail.com> wrote:
> On Wed, Aug 5, 2015 at 6:26 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> I agree with you that decentralization is the most important feature of
> Bitcoin, but I also think we need to think probabilistically and concretely
> about when risks to decentralization are worthwhile.
>
> Decentralization is not infinitely valuable in relation to low fees, just
> like being alive is not infinitely valuable in relation to having money.
> [...]
> Similarly we shouldn't accept a 100% probability of Bitcoin being controlled
> by a single entity for any guarantee of cheap tx fees no matter how low they
> are, but there should be some minuscule risk of decentralization that we'd
> be willing to accept (like raising the block size to 1.01 MB) if it somehow
> allowed us to dramatically increase usability. (Imagine something like the
> Lightning Network but even better was developed, but it could only work with
> 1.01 MB blocks).

Agreed. I would just like that there was an attempt to automatically
estimate those risks before taking those risks.
Some function we're trying to optimize with simulations (based on
#6382 ) to find an ideal (according to that imperfect metric) maximum
consensus block size.
Maybe the function/simulations just take some minimum hardware
specifications and returns an block size, I don't know.

> I agree that we don't have good data about what exactly a 4 MB increase
> would do. It sounds like you think the risks are too great / uncertain to
> move from 1 MB to 4 MB blocks in the situation I described. I'm not clear
> though on which specific risks you'd be most worried about at 4 MB, and if
> there are any risks that you think don't matter at 4 MB but that you would
> be worried about at higher block size levels. I also don't know if we have
> similar ideas about the benefits of low tx fees. If we discussed exactly how
> we were evaluating this scenario, maybe we'd discover that something I
> thought was a huge benefit of low tx fees is actually not that compelling,
> or maybe we'd discover that our entire disagreement boiled down to our
> estimate of one specific risk.

The most important thing to understand in this discussion is that it
is about a trade-off between lower fees (more maximum tx volume) and
mining (and general) centralization.
I don't know what the costs and gains curves are here (for 4MB, 1 MB
or any other number, and I don't think anybody does).
But if we can't even agree on what the advantages and disadvantages of
increasing the consensus block size maximum, it is very hard that we
can agree on a universally acceptable point or range in this trade-off
rect.

> For the record, I think these are the main harms of $5 tx fees, along with
> the main risks I see from moving to 4 MB:
>
> Fees of $5/tx would:
> (a) Prevent a lot of people who could otherwise benefit from Bitcoin's
> decentralization from having an opportunity to reap those benefits.
> Especially people in poor countries with corrupt governments who could get
> immediate benefit from it now.
> (b) Prevent developers from experimenting with new Bitcoin use-cases, which
> might eventually lead to helpful services.
> (c) Prevent regular people from using Bitcoin and experimenting with it and
> getting involved, because they think it's unusable for txns under many
> hundreds of dollars in value, so it doesn't interest them. Not having the
> public on our side could make us more vulnerable to regulators.

This is all probably right, but IMO we're very far away from $5/tx.
My main point about fees is that minimum mining fees rising above zero
(theri current level) is not necessarily a bad thing or an urgent
concern.
On the other hand, we have much more data about current mining
centralization, which should be very relevant information when
discussing a block size increase.

> Changing the block size to 4 MB would:
> (1) Probably reduce the number of full nodes by around 5%. Most of the drop
> in full nodes over the past few years is probably due to Bitcoin Core being
> used by fewer regular users for convenience reasons, but the extra HD space
> required and extra bandwidth would probably make some existing people
> running full nodes stop.

As Pieter has explained repeatedly, a big block count is not a goal in
itself, just a metric.
And if you ask me, I don't think it's all that interesting as a
metric. For all I know there could be a lot more full nodes being run
that for whatever reason are not seen by people collecting this data.
The block size maximum consensus rule limits mining centralization,
not just full node centralization. Gavin, for example, disagrees with
this.
Fortunately I believe at least 2 mathematical proofs can be produced
to demonstrate Gavin and those who think like him are wrong.

> (2) Not hinder low bandwidth miners significantly, because of the relay
> network.

I believe that even with the relay network, and even assuming all
miners are connected using something like IBLT, a mathematical proof
can be constructed to demonstrate that bigger block sizes can prevent
the worse connected miners from being profitable.
It is important to note that the worse connected miners aren't
necessarily those with less bandwidth: maybe you have the best
bandwidth but you are poorly connected to the majority of the hashrate
(for example, because the majority of the hashrate is within the same
country but that country is not very well connected to the rest of the
world).

> (3) Not introduce any tx verification issues, because processors are fast
> and tx processing is ridiculously cheap and we'd need way more than 4 MB of
> txs for it to be a bottleneck.

We're certainly far away from this being a concern in practice.
But I'm working on a mathematical proof that at some scale CPU
requirements could become a discriminating factor making the smallest
mining operations unprofitable.

> So (1) is the only risk that gives me any significant concern, but I don't
> think that the number of full nodes now is at a dangerous level.

I don't think there's such a thing as a "dangerous full node count level".
It's just data that can be useful to build centralization metrics.
Probably hashrate distribution by pool is much more interesting (and
if you ask me that looks really bad right now without increasing the
block size consensus maximum).

> Anyway, the point isn't for you and I to actually discuss this particular
> hypothetical in more detail (although I would be curious to see similar
> lists from you). I haven't studied the risks enough to actually put this
> forth to the list as a good argument for what to do in this situation. My
> main point is that being very specific and concrete both about our thought
> process and about the hypothetical situation results in much better
> discussions.

I agree.

> There's one more piece of information that I can give you which will help
> you understand my position much better, and also force me to think really
> carefully about this. It's the point at which I would switch to the other
> side of the argument (either by varying the tx fee, or the block size). If
> tx fees would only rise to 60 cents or lower if we stayed at 1 MB, then I
> would be against a move to 4 MB. Or, keeping the hypothetical 1 MB fee at
> $5, I think moving to 12 MB or higher is the point at which I'd switch over
> to being a 1 MB advocate. Getting that same info from you tells me exactly
> how you weigh the risks in a way that just listing the factors can't. In
> this specific hypothetical scenario, what is the lowest block size increase
> that you'd accept? It can be extremely low, like 1.01 MB. If you tell me
> that you'd rather have $5 tx fees for the next year instead of changing the
> block size to 1.01 MB, I would be really surprised.

Great. I don't think that minimum mining fees will rise above 1 usd
cent/tx anytime soon even if we maintain the limit of 1MB.
Maybe that's why I'm not worried at all about "hitting the limit".
But I'm sorry, I don't have those concrete numbers because it is a
trade-off I don't think we've studied in enough detail.
Well, I can also say I wouldn't be worried at all about moving to,
say, 1.01 MB (because the difference in centralization pressure should
be minimal) and I would just take it as a "let's proof hardforks are
possible" change similar to the one proposed in bip99.

> Gavin is the only other person who I've seen who has defined at what block
> size he'd switch to the other side (maybe not with a concrete number, but
> with a rough range: the block size such that a normal person with a pretty
> good connection couldn't run a full node).

That would be interesting to read and I have totally missed it.
Do you have a link?

> I would say that in this case we know high tx fees could happen very soon
> because there is a clear mechanism. Bitcoin just needs to become more
> popular quickly for any number of reasons. Suppose the infrastructure for
> remittances starts falling into place within the next two months, and
> suddenly immigrants are clamoring to use Bitcoin to send money back to their
> home countries. This could result in $5 tx fees very soon (not that I think
> it's likely). Many of these immigrants would still use Bitcoin because it's
> still better than the alternative for remittances, which would price out a
> lot of people currently using Bitcoin for other reasons. As far as I know,
> there is no plausible way that subsidies could plummet in anywhere near that
> time frame, aside from the price of Bitcoin completely collapsing.

And for any size something similar could happen with some use case.
But this is a great example of a situation where I would understand
people panicking and clamoring to change the consensus rule as soon as
possible.
Even with much lower fees, say 1 usd/tx.
I think it would be a great problem to have and admittedly I'm not
worried about having it in the short term.
And if it happened overnight we could always deploy an emergency hardfork.

> But if
> that happens in the near term (specifically, with very low tx volume) a fee
> market won't help.

I think it's helping by determining who is to be served first, and
that is those who benefit more from Bitcoin (and are therefore willing
to pay higher costs for using it), in this case, people doing
international remittances.

> I would be extremely happy if Bitcoin could somehow sustain itself in the
> long run with 5 cent tx fees. I'm optimistic about Lightning to handle the
> cases where people need even cheaper txns.

Agreed.

>> I'm still missing an answer from the "big blocks size side" to the
>> following question (which I have insistently repeated with various
>> permutations):
>>
>> If "not now" when will it be a good time to let fees rise above zero?
>> After the next subsidy halving? After 4 more subsidy halvings (ie
>> about 13 years from now, subsidy = 1.5625 btc/block )? After your
>> grandmother abandons her national currency and uses Bitcoin for
>> everything? Never?
>>
>> ANY answer (maybe with the exception of the last one) would be less
>> worrying than silence.
>
>
> Before I answer, here's my reasoning about why we don't need to worry about
> a fee market now:
>
> There is nothing particularly special about a fee market in Bitcoin. We know
> how markets work, and we have no reason to suspect a fee market in Bitcoin
> will have any new properties of markets that we can't foresee. When demand
> becomes higher, there will be some equilibrium level of fee that people have
> to pay to give a certain probability of inclusion within a certain number of
> blocks. There will likely be some level of fee where if you don't pay it,
> your tx will never be confirmed.

This is what I mean by "market minimum fee".

> We have seen something like this working at various points in Bitcoin's
> history. Look at the recent "stress tests." To get your tx confirmed in a
> reasonable time frame, you had to bump your fee a little higher than the
> txns from whoever was flooding the network. If you did, everything worked
> fine. If you didn't, your tx didn't confirm (until the test ended, maybe?).
> So there's nothing complicated here. It doesn't require a decade long
> preparation to prove to ourselves that a fee market will work.

I think the code that miners use to select which transactions to
include first needs a lot of work.
As said miners are subsidizing free transactions, increasing their own
costs for nothing in exchange.
Also, yes, there is something special about this market: it is
supposed to pay for most of the global hashrate in the not-so-far
future.
If we take too long to start moving away from total seigniorage
subsidy dependence, it may be too late when we do.

> Unless in the future mining is funded mostly by charity (I think there's
> only a 25% chance of that happening), we will need a fee market eventually.
> I'd be fine if one developed now. I think 10 cents per txn right now
> wouldn't be too bad, aside from the following reason. What concerns me about
> insisting on a fee market right now is that usage is so small and the block
> size is so limited that if demand increases just a little bit, fees could
> skyrocket. It's not the 10 cent fees that would worry me, but what they say
> about the potential for a huge spike. Fees could become $10 per tx or higher
> very quickly. Yes, that would show that big organizations find Bitcoin
> useful which is nice, but it'd also put decentralized money out of reach of
> many other people. While Bitcoin still has a lot of growth ahead of it, it's
> better to not set up roadblocks (for reasons other than preserving
> decentralization) in front of that growth which will make things very
> painful if that growth happens more suddenly than we expect.
>
> I think the best argument for having a fee market right now is that if we
> move to such a market suddenly in the future, wallets won't have time to
> make the user experience good, and full nodes might not be written in such a
> way that they gracefully handle a bunch of txns that might never confirm. I
> don't think the required software changes are that complex though, so it
> seems unnecessary to start adding friction for users now for something that
> might be an issue in 10+ years.

I think you are underestimating the software costs.
And you not only have to adapt the software that we have now, but also
the software that hasn't been written yet and will be written assuming
free transactions and an underdeveloped market.
Also you are over-estimating the costs: you could hit the limit but
then rise the block size maximum as soon as you reach, say 0.00001
usd/tx.
Even if minimum fees go again to zero after rising the block size
maximum, the software improvements will remain there.

> So to answer your question: about two years before we think Bitcoin will
> need to rely heavily on txn fees for security, I'd be in favor of adjusting
> block size so that it resulted in enough total fees / security.

And when do you think "Bitcoin will need to rely heavily on txn fees
for security"?
How many more halvings is that?

> You've been arguing that 0 fee transactions will have to disappear someday,
> but this isn't necessarily true. As long as enough people care about having
> their txns confirm relatively quickly, there's no reason to make sure that
> people who pay 0 fees never have their txns confirmed.

That's not what I've been arguing, I've just being saying that I would
be completely ok with minimum fees rising above zero (say, to 1
satoshi/tx) tomorrow.
I don't think that's necessarily a bad thing (in fact, it has some
advantages) and certainly not something we should fear to the point of
rushing hardforks to avoid it.

📅 Original date posted:2015-08-06 📝 Original ...

2023-06-07T19:32:36+02:00

In reply to nevent1q…srz4
_________________________

📅 Original date posted:2015-08-06
📝 Original message:Really, thanks again for replying and not getting mad when I get your
thoughts wrong.
I believe that I've learned more about your position on the subject
today than in months of discussion and blogs (that's not a critique to
your blog post, it's just that they didn't answer to some questions
that I personally needed responded).

On Thu, Aug 6, 2015 at 9:42 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> On Thu, Aug 6, 2015 at 1:15 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>>
>> So I reformulate the question:
>>
>> 1) If "not now", when will it be a good time to let the "market
>> minimum fee for miners to mine a transaction" rise above zero?
>
>
> Two answers:
>
> 1. If you are willing to wait an infinite amount of time, I think the
> minimum fee will always be zero or very close to zero, so I think it's a
> silly question.

I'm very happy to have made the stupid question then. It has revealed
another big difference in the fundamental assumptions we're using.

My assumption is that for any reasonable size, free transactions will
eventually disappear (assuming Bitcoin doesn't "fail" for some other
reason).
Maybe I'm being too optimistic about the demand side of the market in
the long term.

In contrast, your assumption seems to be (and please correct me on
anything I get wrong) that...

"The limit will always be big enough so that free transactions are
mined forever. Therefore fees just allow users to prioritize their
urgent transactions and relay policies to protect their nodes against
DoS attacks.
Well, obviously, they also serve to pay for mining in a low-subsidy
future, but even with the presence of free transactions, fees will be
enough to cover mining costs, or a new mechanisms will be developed to
make a low-total-reward blockchain safe or expensive proof of work
will be replaced or complemented with something else that's cheaper.
The main point is that fees are not a mechanism to decide what gets
priced out of the blockchain, because advancements in technology will
always give as enough room for free transactions."
- jtimon putting words in Gavin's mouth, with the only intention to
understand him better.

I'm using "free transactions" even though you said "zero or very close to zero".
To you, "zero or very close to zero" may be the same thing, but to me
zero and very close to zero are like...different galaxies.
To me, entering the "very close to zero galaxy" is a huge step in the
development of the fee market.
I've been always assuming that moving from zero to 1 satoshi was
precisely what "big block advocates" wanted to avoid.
What they meant by "Bitcoin is going to become a high-value only
network" and similar things.
Knowing that for "big block advocates" zero and "very close to zero"
are equally acceptable changes things.

> 2. The "market minimum fee" should be determined by the market. It should
> not be up to us to decide "when is a good time."

I completely agree, but the block size limit is a consensus rule that
doesn't adapt to the market. The market will adapt to whatever limit
is chosen by the consensus rules.

>> 2) Do you have any criterion (automatic or not) that can result in you
>> saying "no, this is too much" for any proposed size?
>
>
> Sure, if keeping up with transaction volume requires a cluster of computers
> or more than "pretty good" broadband bandwidth I think that's too far.
> That's where original 20MB limit comes from, otherwise I'd have proposed a
> much higher limit.
>
>> Would you agree that blocksize increase proposals should have such a
>> criterion/test?
>
>
> Although I've been very clear with my criterion, no, I don't think all
> blocksize increase proposals should have to justify "why this size" or "why
> this rate of increase."

I would really like a more formal criterion, ideally automatic (like
any other test, the parameters can be modified as technology
advances).
But fair enough, even though your criterion is too vague or not
future-proof enough, I guess it is still a criterion.
It seems that this is a matter of disagreements and ideal ways of
doing things and not really a disagreement on fundamental assumptions.
So it seems this question wasn't so interesting after all.

> Part of my frustration with this whole debate is
> we're talking about a sanity-check upper-limit; as long as it doesn't open
> up some terrible new DoS possibility I don't think it really matters much
> what the exact number is.

That's what you think you are discussing, but I (and probably some
other people) think we are discussing something entirely different.
Because we have a fundamentally different assumption on what the block
size limit is about.
I really hope that identifying these "fundamental assumption
discrepancies" (FAD from now own) will help us avoid circular
discussions so that everything is less frustrating and more productive
for everyone.

>> Regardless of the history of the consensus rule (which I couldn't care
>> less about), I believe the only function that the maximum block size
>> rule currently serves is limiting centralization.
>> Since you deny that function, do you think the (artificial) consensus
>> rule is currently serving any other purpose that I'm missing?
>
>
> It prevents trivial denial-of-service attacks (e.g. I promise to send you a
> 1 Terabyte block, then fill up your memory or disk...).

This could be prevented in some other ways. If this is the only
concern, it doesn't need to be a consensus rule.

> And please read what I wrote: I said that the block limit has LITTLE effect
> on MINING centralization. Not "no effect on any type of centralization."
>
> If the limit was removed entirely, it is certainly possible we'd end up with
> very few organizations (and perhaps zero individuals) running full nodes.

Sorry, another try:

You think the maximum block size rule serves to limit centralization
by limiting how hard it is to run a full node.
I agree with that, but I would add something more and you wouldn't:

The maximum block size consensus rule limits how hard it is to be a
competitive miner.

In other words, you think the last statement is false or incorrect.

Meta: I think we should try to collect and list more of this "FADs"
(we have at least 2 of them already). If you think it can be useful,
I'm more than happy to repeat this process in the opposite direction:
you make the questions and I give the answers, you write what you
think I think and I correct you in iterations. Probably we should
finish with you correcting what I think you think first. I am really
excited about understanding your point of view better.

Stupid humor (hopefully not out of context and not offensive): I'm
happy to discover that what I thought it was FUD was just FAD.
More seriously, I'm really happy for your interest in understanding
and being understood.
Let's worry about where do we think differently first and about who is
right on each point later.
In the end, only the conclusions on each point will matter and not who
claimed the final conclusions (in the points where we find them) first
(if we get to final common conclusions on that point at all).

📅 Original date posted:2015-08-06 📝 Original message:First ...

2023-06-07T19:32:35+02:00

In reply to nevent1q…3d6e
_________________________

📅 Original date posted:2015-08-06
📝 Original message:First of all, thank you very much for answering the questions, and
apologies for not having formulated them properly (fortunately that's
not an irreparable mistake).

On Thu, Aug 6, 2015 at 6:03 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> On Thu, Aug 6, 2015 at 11:25 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
>>
>> 1) If "not now" when will it be a good time to let fees rise above zero?
>
>
> Fees are already above zero. See
> http://gavinandresen.ninja/the-myth-of-not-full-blocks

When we talk about "fees" we're talking about different things. I
should have been more specific.
Average fees are greatly influenced by wallet and policy defaults, and
they also include extra fees that are included for fast confirmation.
I'm not talking about fast confirmation transactions, but about
non-urgent transactions.

What is the market minimum fee for miners to mine a transaction?

That's currently zero.
If you don't want to directly look at what blocks contain, we can also
use a fee estimator and define a "non-urgent period", say 1 week worth
of blocks (1008 blocks).
The chart in your link doesn't include a 1008 blocks line, but the 15
blocks (about 2.5 hours) line seems to already show zero fees:

So I reformulate the question:

1) If "not now", when will it be a good time to let the "market
minimum fee for miners to mine a transaction" rise above zero?

>> 2) When will you consider a size to be too dangerous for centralization?
>> In other words, why 20 GB would have been safe but 21 GB wouldn't have
>> been (or the respective maximums and respective +1 for each block
>> increase proposal)?
>
>
> http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized

This just shows where the 20 GB come from, not why you would reject 21 GB.
Let me rephrase.

2) Do you have any criterion (automatic or not) that can result in you
saying "no, this is too much" for any proposed size?
Since you don't think the consensus block size maximum limits mining
centralization (as you later say), it must be based on something else.
In any case, if you lack a criterion that's fine as well: it's never
too late to have one.
Would you agree that blocksize increase proposals should have such a
criterion/test?

>> 3) Does this mean that you would be in favor of completely removing
>> the consensus rule that limits mining centralization by imposing an
>> artificial (like any other consensus rule) block size maximum?
>
>
> I don't believe that the maximum block size has much at all to do with
> mining centralization, so I don't accept the premise of the question.

Ok, this is an enormous step forward in the discussion, thank you.
In my opinion all discussions will be sterile while we can't even
agree on what are the positive effects of the consensus rule that
supposedly needs to be changed.

It's not that you don't care about centralization, it's that you don't
believe that a consensus block size maximum limits centralization at
all.
This means that if I can convince you that the consensus block size
maximum does in fact limit centralization in any way, you may change
your views about the whole blocksize consensus rule change, you may
even take back or change your own proposal.
But let's leave that aside that for now.

Regardless of the history of the consensus rule (which I couldn't care
less about), I believe the only function that the maximum block size
rule currently serves is limiting centralization.
Since you deny that function, do you think the (artificial) consensus
rule is currently serving any other purpose that I'm missing?

If the answer is something along the lines of "not really, it's just
technical debt", then I think you should be honest and consequent, and
directly advocate for the complete removal of the consensus rule.

I really think conversations can't really advance until we clarify the
different positions about the discussed consensus rule current
purpose.

📅 Original date posted:2015-08-05 📝 Original message:On ...

2023-06-07T19:32:31+02:00

In reply to nevent1q…dx4g
_________________________

📅 Original date posted:2015-08-05
📝 Original message:On Wed, Aug 5, 2015 at 9:29 AM, Elliot Olds <elliot.olds at gmail.com> wrote:
> On Tue, Aug 4, 2015 at 4:59 AM, Jorge Timón
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Also I don't think "hitting the limit" must be necessarily harmful and
>> if it is, I don't understand why hitting it at 1MB will be more
>> harmful than hitting it at 2MB, 8MB or 8GB.
>
>
> I don't think merely hitting the limit is bad. The level of tx fees in
> equilibrium give some clue as to the level of harm being done. If fees are
> at $5/tx at 1MB, it's about as bad as if fees are at $5/tx at 4MB.

This is a much more reasonable position. I wish this had been starting
point of this discussion instead of "the block size limit must be
increased as soon as possible or bitcoin will fail".
If the only fear about not increasing the block size fast enough is
that fees may rise, pieter wouldn't had to repeatedly explain that for
any reasonable block size some use case may fill the blocks rapidly.

>> There is NO criterion based on mining centralization to decide between
>> 2 sizes in favor of the small one.
>> It seems like the rationale it's always "the bigger the better" and
>> the only limitation is what a few people concerned with mining
>> centralization (while they still have time to discuss this) are
>> willing to accept. If that's the case, then there won't be effectively
>> any limit in the long term and Bitcoin will probably fail in its
>> decentralization goals.
>> I think its the proponents of a blocksize change who should propose
>> such a criterion and now they have the tools to simulate different
>> block sizes.
>
>
> In the absence of harder data, it might be interesting to use these
> simulations to graph centralization pressure as a function of bandwidth cost
> over time (or other historical variables that affect centralization). For
> instance, look at how high centralization pressure was in 2009 according to
> the simulations, given how cheap/available bandwidth was then, compared to
> 2010, 2011, etc. Then we could figure out: given today's bandwidth
> situation, what size blocks right now would give us the same centralization
> pressure that we had in 2011, 2012, 2013, etc?
>
> Of course this doesn't mean we should blindly assume that the level of
> centralization pressure in 2012 was acceptable, and therefore any block size
> increase that results in the same amount of pressure now should be
> acceptable. But it might lead to a more productive discussion.

This sounds good overall but I'm afraid you are oversimplifying some things.
Centralization pressure not only comes from global average bandwidth
costs and block propagation times is not the only concern.
Here's an extreme example: [1]
But anyway, yes, I agree, ANY metric would be better than nothing (the
current situation).

>> I want us to simulate many blocksizes before rushing into a decision
>> (specially because I disagree that taking a decision there is urgent
>> in the first place).
>
>
> IMO it is not urgent if the core devs are committed to reacting to a huge
> spike in tx fees with a modest block size increase in a relatively short
> time frame, if they judge the centralization risks of that increase to be
> small. Greg Maxwell posted on reddit a while back something to the effect of
> "the big block advocates are overstating the urgency of the block size
> increase, because if there was actually a situation that required us to
> increase block size, we could make the increase when it was actually
> needed." I found that somewhat persuasive, but I am concerned that I haven't
> seen any discussion of what the "let's wait for now" camp would consider a
> valid reason to increase block size in the short term, and how they'd make
> the tradeoff with tx fees or whatever else was necessitating the increase.

Given that for any non-absurdly-big size some transactions will
eventually be priced out, and that the consensus rule serves for
limiting mining centralization (and more indirectly centralization in
general) and not about trying to set a given average transaction fee,
I think the current level of mining centralization will always be more
relevant than the current fee level when discussing any change to the
consensus rule to limit centralization (at any point in time).
In other words, the question "can we change this without important
risks of destroying the decentralized properties of the system in the
short or long run?" should be always more important than "is there a
concerning rise in fees to motivate this change at all?".

> Jorge, if a fee equilibrium developed at 1MB of $5/tx, and you somehow knew
> with certainty that increasing to 4MB would result in a 20 cent/tx
> equilibrium that would last for a year (otherwise fees would stay around $5
> for that year), would you be in favor of an increase to 4MB?

As said, I would always consider the centralization risks first: I'd
rather have a $5/tx decentralized Bitcoin than a Bitcoin with free
transactions but effectively validated (when they validate blocks they
mine on top of) by around 10 miners, specially if only 3 of them could
easily collude to censor transactions [orphaning any block that
doesn't censor in the same manner]. Sadly I have no choice, the later
is what we have right now. And reducing the block size can't guarantee
that the situation will get better or even that fees could rise to
$5/tx (we just don't have that demand, not that it is a goal for
anyone). All I know is that increasing the block size *could*
(conditional, not necessarily, I don't know in which cases, I don't
think anybody does) make things even worse.

On the other hand, I could understand people getting worried if fees
where as high as $5/tx or even 20 cent/tx but we're very far away from
that case. How can low subsidies (a certainty) be "too far in the
future to worry about it" but $5/tx, 20 cent/tx or even 5 cent/tx an
urgent concern? For all I know, 5 cent/tx may not happen in the next
25 years: it may never happen. And if it happens, to me it will be a
symptom of Bitcoin success, even for others it means that Bitcoin has
become a "high value settlement network".
To the question

- At which minimum mining fee rate will you urge others to change the
consensus rules to increase the block size?

I'm very sorry, but my answer is:

- I honestly don't know, that may never happen.

What I can tell you is this: I will never be worried about "too high
fees" while the fees remain at 0 (null, zero, nothing, cero, nada,
zilch).
That's right, no matter what wallet's defaults chose for their users,
no matter what the minimum relay fee policy does to the "fee market"
and how much urgent transactions pay in fees; the fact remains that in
practice non-urgent transactions usually (when the raw transaction's
structure it's appropriate) don't have to pay fees.

I'm still missing an answer from the "big blocks size side" to the
following question (which I have insistently repeated with various
permutations):

If "not now" when will it be a good time to let fees rise above zero?
After the next subsidy halving? After 4 more subsidy halvings (ie
about 13 years from now, subsidy = 1.5625 btc/block )? After your
grandmother abandons her national currency and uses Bitcoin for
everything? Never?

ANY answer (maybe with the exception of the last one) would be less
worrying than silence.

> For those familiar with the distinction between near/far mode thinking
> popularized by Robin Hanson: focusing on concrete examples like this
> encourages problem solving and consensus, and focusing on abstract
> principles (like decentralization vs. usability in general) leads to people
> toward using argument to signal their alliances and reduce the status of
> their opponents.

I really appreciate your efforts to mediate in this dispute and I
honestly hope that my previous answer is useful as it is.

> I think it'd be very helpful if more 1MB advocates
> described what exactly would make them say "OK, in this situation a block
> size increase is needed, we should do one quickly!", and also if
> Gavin/Mike/Jeff described what hypothetical scenarios and/or test results
> would make them want to stick with 1MB blocks for now.

Just replace 1MB with ANY size.
But, yes, please, when will you consider a size to be too dangerous
for centralization?
Why 20 GB would have been safe but 21 GB wouldn't have been (or the
respective maximums and respective +1)?

Note that "Never, 20GB was just a number closer to infinity than 1MB
and I hoped that could had been voluntarily accepted by users. What I
really want is to completely remove this consensus rule forever." is a
perfectly valid answer. It just means that I will agree with people
that think this way as explained in [1] (yes, not even after
superluminal communication).

As an less relevant note, I feel extremely uncomfortable about being
included in the "1MB advocates" group. As I've tried to explain
several times, 1 is to me an arbitrary number like any other (at most,
the canonical arbitrary number), and so it is 1000000
(MAX_BLOCK_SIZE). I rarely like being grouped or labelled, but maybe
something more accurate like "not-recklessly-change-consensus-rules
advocates" would help.
There's nothing special about 1MB apart from being the current rule,
so I don't think the number is that much relevant to the discussion.
Grouping anyone that has raised any concern about rising the consensus
block size limit as "the 1MBers" is about as fair as grouping anyone
that has ever proposed a rise in the maximum size as "the 20GBers"
(specially when there's people that belong to both groups
simultaneously, like Pieter Wuille who started this thread, and whose
proposal we're supposed to be discussing).

[1] http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009947.html

📅 Original date posted:2015-08-04 📝 Original message:On ...

2023-06-07T19:32:30+02:00

In reply to nevent1q…z9fx
_________________________

📅 Original date posted:2015-08-04
📝 Original message:On Tue, Aug 4, 2015 at 2:19 PM, Hector Chu <hectorchu at gmail.com> wrote:
> On 4 August 2015 at 12:59, Jorge Timón <jtimon at jtimon.cc> wrote:
>>
>> That is not my position. Again, I don't know what the right blocksize
>> for the short term is (I don't think anybody does).
>
> You have no position (i.e. neutral). In other words, keeping the existing
> limit.

No, I think 1 MB is just as arbitrary as any other size proposed.
All I want is for consensus change proponents to try harder to
convince other users (including me)

>> Therefore how the change can affect mining centralization must be the
>> main concern, instead of (also artificial) projections about usage
>> growth (no matter how organic their curves look).
>
>
> The degree of mining decentralization is only one of many concerns. Users'
> main concern is timely confirmation of low-fee transactions. Miners' concern
> is the amount of profit they make.

No, if the changed rule only serves to limit centralization, then how
that limitation to centralization is affected should be the first
thing to consider.
If miners' concern was only the amount of profit they make they
wouldn't mine free transactions already.
You cannot possibly know what all users' are concern about, so I will
just ignore any further claim in that direction.
Talk for yourself: your arguments won't be more reasonable just
because you claim that all users think like you do.

>> Also I don't think "hitting the limit" must be necessarily harmful and
>> if it is, I don't understand why hitting it at 1MB will be more
>> harmful than hitting it at 2MB, 8MB or 8GB.
>
>
> The limit won't even get to be hit, because all the users that get thrown
> out of Bitcoin will have moved over to a system supporting a larger block
> size.

I disagree with this wild prediction as well.

>> I don't know where you get your "majority" from or what it even means
>> (majority of users, majority of the coins, of miners?)
>
>
> The majority which the miners are beholden to is the economic majority.
> https://en.bitcoin.it/wiki/Economic_majority

And I assume the way that vaguely defined "economic majority"
communicates with you through a crystal ball or something

>> But there's something I'm missing something there...why my position
>> doesn't matter if it's not a majority?
>
>
> Your position is only one of many and it does not carry excess weight to the
> others. Individually it won't matter, because you can't control the
> implementation that other people run.

No more, but not less either.
Nobody can't control the implementation that I (or other people
concerned with centralization) run either.

>> How is what the the majority has been told it's best an objective
>> argument?
>
>
> Don't fight the market. The way the system is designed, the miners will
> follow along with what the economic majority have decided.

How is allowing fees from rising above zero "fighting the market"?
The system is currently designed with a 1 MB limit. I don't think
that's sacred or anything, but I really don't feel like I'm fighting
"the market" or "the way the system is designed".
In any case, what do "the market" and "the way the system is designed"
have to do with what the majority have been told it's best (which you
seem to think should be a source of truth for some reason I'm still
missing)?

>> So if you say 8, I must ask, why not 9?
>> Why 9 MB is not safe for mining centralization but 8 MB is?
>
>
> 8MB has simply been the focal point for this debate. 9MB is also safe if 8MB
> is, but I suppose the opponents will be even less happy with 9 than with 8,
> and we don't want to unnecessarily increase the conflict.

Why 9 MB is safe but 10 MB isn't?
The "conflict" won't be resolved by evading hard questions...

>> It seems like the rationale it's always "the bigger the better" and
>> the only limitation is what a few people concerned with mining
>> centralization (while they still have time to discuss this) are
>> willing to accept. If that's the case, then there won't be effectively
>> any limit in the long term and Bitcoin will probably fail in its
>> decentralization goals.
>
>
> A one-time increase to 8MB is safer than a dynamically growing limit over
> time for exactly this reason. Admittedly whenever the next debate to
> increase the block size over 8MB happens it will be even more painful and
> non-obvious, but that is the safety check to prevent unbounded block size
> increase.

Will there ever be a debate that results in "further blocksize
increases at this point are very risky for mining centralization"?
How will we tell then? Can't we use the same criteria now?

📅 Original date posted:2015-08-04 📝 Original message:On ...

2023-06-07T19:32:29+02:00

In reply to nevent1q…q4ea
_________________________

📅 Original date posted:2015-08-04
📝 Original message:On Tue, Aug 4, 2015 at 1:04 PM, Hector Chu <hectorchu at gmail.com> wrote:
> Mike's position is that he wants the block size limit to eventually be
> removed. That is of course an extreme view.

I prefer to wait and let him talk by himself.

> Meanwhile, your view that the
> block size should be artificially constrained below the organic growth curve
> (in a way that will penalize a majority of existing and future users) lies
> at the other extreme.

That is not my position. Again, I don't know what the right blocksize
for the short term is (I don't think anybody does).
But I know that the maximum block size limit consensus rule (no more
artificial than any other consensus rule, like, say, the one that
prohibits double-spends) serves to limit mining centralization.
Therefore how the change can affect mining centralization must be the
main concern, instead of (also artificial) projections about usage
growth (no matter how organic their curves look).
Also I don't think "hitting the limit" must be necessarily harmful and
if it is, I don't understand why hitting it at 1MB will be more
harmful than hitting it at 2MB, 8MB or 8GB.

> The majority position lies somewhere in between (i.e.
> a one-time increase to 8MB). This is the position that ultimately matters.

I don't know where you get your "majority" from or what it even means
(majority of users, majority of the coins, of miners?)
But there's something I'm missing something there...why my position
doesn't matter if it's not a majority?
How is what the the majority has been told it's best an objective argument?

> If the block size is increased to 8MB and things get demonstrably a whole
> lot worse, then you will have a solid leg to stand on. In that case we can
> always do another hard fork later to reduce the block size back to something
> smaller, and henceforth the block size will never be touched again.

Yes.
And if we can "break things" in simulations first before we "break
things" in production, maybe we don't need the later hardfork to "fix
things" (if it's still possible to fix them without completely
restarting the ASIC market).
The fact is that we don't have a single simulation that can tell you
"too centralized/shouldn't affect mining centralization much" for a
given block size.
So if you say 8, I must ask, why not 9?
Why 9 MB is not safe for mining centralization but 8 MB is?

There is NO criterion based on mining centralization to decide between
2 sizes in favor of the small one.
It seems like the rationale it's always "the bigger the better" and
the only limitation is what a few people concerned with mining
centralization (while they still have time to discuss this) are
willing to accept. If that's the case, then there won't be effectively
any limit in the long term and Bitcoin will probably fail in its
decentralization goals.
I think its the proponents of a blocksize change who should propose
such a criterion and now they have the tools to simulate different
block sizes.

I want us to simulate many blocksizes before rushing into a decision
(specially because I disagree that taking a decision there is urgent
in the first place).

📅 Original date posted:2015-08-04 📝 Original message:On ...

2023-06-07T19:32:26+02:00

In reply to nevent1q…c0w8
_________________________

📅 Original date posted:2015-08-04
📝 Original message:On Tue, Aug 4, 2015 at 1:34 PM, Hector Chu <hectorchu at gmail.com> wrote:
> Things apparently aren't bad enough to prevent the majority from clamoring
> for larger blocks.

Nobody is preventing anyone from claiming anything. Some developers
are encouraging users to ask for bigger blocks.
Others don't want to impose consensus rule changes against the will of
the users (even if they're 10% of the users).
Still, "Things apparently aren't bad enough" is just your opinion.

> If the majority agreed that things had got worse till this point, and that
> this was to be blamed on the block size, they would be campaigning for the
> other direction. Even yourselves aren't asking for a reduction in the block
> size, as you know full well that you would be laughed out.

1) I don't care what the so-called "majority" thinks: I don't want to
impose consensus rule changes against the will of a reasonable
minority.
2) It doesn't matter who is to blame about the current centralization:
the fact remains that the blocksize maximum is the only** consensus
rule to limit mining centralization.
3) In fact I think Luke Dashjr proposed to reduced it to 400 KB, but I
would ask the same thing: please create a simulation in which the
change is better (or at least no much worse) than the current rules by
ANY metric.

Please read the point 2 with special attention because it's not the
first time I say this in this thread.

** There's also the maximum block sigops consensus rule to limit
mining centralization.

📅 Original date posted:2015-08-04 📝 Original message:On ...

2023-06-07T19:32:21+02:00

In reply to nevent1q…8q5p
_________________________

📅 Original date posted:2015-08-04
📝 Original message:On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn <hearn at vinumeris.com> wrote:
>> How more users or more nodes can bring more miners, or more importantly,
>> improve mining decentralization?
>
>
> Because the bigger the ecosystem is the more interest there is in taking
> part?

As explained by Venzen, this is a non-sequitur.

> I mean, I guess I don't know how to answer your question.

I don't know the answer either, that's fine. It's the opposite
question that I've been insistently repeating and you've been
(consciously or not) consistently evading.
But that's also fine because I believe you finally answer it a few lines below.

> When Bitcoin was
> new it had almost no users and almost no miners. Now there are millions of
> users and factories producing ASICs just for Bitcoin.

The emergence of a btc price enabled the emergence of professional
miners, which in turn enabled the emergence of sha256d-specialized
hardware production companies.
Nothing surprising there.
By no means it consitutes an example of how a bigger consensus sizes
can cause less mining centralization.

> Surely the correlation is obvious?

Correlation does not imply causation. I will better leave it at that...

>> I'm sorry, but until there's a simulation that I can run with different
>> sizes' testchains (for example using #6382) to somehow compare them, I will
>> consider any value arbitrary.
>
>
> Gavin did run simulations. 20mb isn't arbitrary, the process behind it was
> well documented here:
>
> http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
>
> I chose 20MB as a reasonable block size to target because 170 gigabytes per
> month comfortably fits into the typical 250-300 gigabytes per month data
> cap– so you can run a full node from home on a “pretty good” broadband plan.
>
> Did you think 20mb was picked randomly?

No, I think 20 MB was chosen very optimistically, considering 3rd
party services rates (not the same service as self-hosting) in the
so-called "first world". And then 20 MB goes to 20 GB, again with
optimistic and by no means scientific expectations.

But where the number comes from it's not really what I'm demaning,
what I want is some criterion that can tell you that a given size
would be "too centralized" but another one isn't.
I haven't read any analysis on why 8GB is a better option than 7GB and
9GB for a given criterion (nor one declaring 20 GB a winner over 19 GB
or 21 GB).
A simulation test passing 20 GB but not 21 GB would make it far less arbitrary.

>> Agreed on the first sentence, I'm just saying that the influence of
>> the blocksize in that function is monotonic: with bigger sizes, equal
>> or worse mining centralization.
>
>
> I have a hard time agreeing with this because I've seen Bitcoin go from
> blocks that were often empty to blocks that are often full, and in this time
> the number of miners and hash power on the network has gone up a huge amount
> too.

I'm of course talking about consensus maximum blocksize, not about
actual blocksize.
Yes, again, when mining becomes profitable, economic actors tend to
appear and get those profits.
But don't confuse total hashrate improvements with an "increase in the
number of miners" or with mining decentralization.

> You can argue that a miner doesn't count if they pool mine. But if a miner
> mines on a pool that uses exactly the same software and settings as the
> miner would have done anyway, then it makes no difference. Miners can switch
> between pools to find one that works the way they like, so whilst less
> pooling or more decentralised pools would be nice (e.g. getblocktemplate),
> and I've written about how to push it forward before, I still say there are
> many more miners than in the past.
>
> If I had to pick between two changes to improve mining decentralisation:
>
> 1) Lower block size

Finally, I think you finally answered my repetitive question here.
If I say "Mike Hearn understands that the consensus block size maximum
rule is a tool for limitting mining centralization" I'm not putting
words in your mouth, right?
I think many users advocating for an increase in the consensus limit
don't understand this, which is extremely unfortunate for the debate.

> 2) Finishing, documenting, and making the UX really slick for a
> getblocktemplate based decentralised mining pool
>
> then I'd pick (2) in a heartbeat. I think it'd be a lot more effective.

Great! Maybe after 2 mining centralization improves so much that we're
confortable not only not lowering it but rather increasing it.

>> you should be consequently advocating for full removal of the limit rather
>> than changes towards bigger arbitrary values.
>
>
> I did toy with that idea a while ago. Of course there can not really be no
> limit at all because the code assumes blocks fit into RAM/swap, and nodes
> would just end up ignoring blocks they couldn't download in time anyway.
> There is obviously a physical limit somewhere.

Did the fact that you "understand that the consensus block size
maximum rule is a tool for limitting mining centralization" influenced
your rejection of that idea at all?

> But it is easier to find common ground with others by compromising. Is 8mb
> better than no limit? I don't know and I don't care much: I think Bitcoin
> adoption is a slow, hard process and we'll be lucky to increase average
> usage 8x over the next couple of years. So if 8mb+ is better for others,
> that's OK by me.

The only way that "not caring much whther we have a consensus limit or
not" and "understand that the consensus block size maximum rule is a
tool for limitting mining centralization" at the same time is by not
caring about mining centralization at all.
Is that your position?

If you don't care about having a limit but you don't want to limit
transaction volume, then ++current_size will ALWAYs be your
"compromise position" and no blocksize increase will ever be enough
until the limit is completely removed.
Is that your position?

> Re: exchange profit. You can pick some other useful service provider if you
> like. Payment processors or cold storage providers or the TREZOR
> manufacturers or whoever.

Yes, and I believe the same points stand.

> My point is you can't have a tiny high-value-transactions only currency AND
> all the useful infrastructure that the Bitcoin community is making. It's a
> contradiction. And without the infrastructure bitcoin ceases to be
> interesting even to people who are willing to pay huge sums to use it.

You keep talking about "high-value-transactions-only" like if
non-urgent transaction fees rising from zero to, say, 1 satoshi, would
automatically result in that "high-value-transactions-only" Bitcoin.
Please, stop talking as if someone was proposing a
"high-value-transactions-only" Bitcoin. That may happen but nobody
really knows. If it happens it may not be bad thing necessarily (ie
bitcoin microtransactions can still happen using trustless payment
channels and x is still cheaper than x% for any transacted value
higher than 100) but that's really not what we're talking about here
so it seems distraction that can only help further polirizing this
discussion.

What we're talking about here is that hitting the limit would
(hopefully) make miners start caring about fees. Enough that they stop
being irrational about free transactions. If both things happen,
non-urgent transaction fees will likely rise (as said, above zero).

You think that would be a catastrophe for adoption and I disagree.
But (as Pieter has repeatedly explained) for any size there will be
use cases that will be eventually priced out.
So when rising this consensus limit, not increasing centralization
should be the priority and the potential impact in market fees a much
more secondary concern.
Do you agree with this?

I'm sure there are many intermediate positions between "caring more
about mining centralization than market fees when deciding about a
consensus rule that limits mining centralization" and "not caring
about mining centralization at all".
I really don't want to put words in your mouth, but I honestly don't
know what your position is.
I don't really know how else can I ask the same question: you don't
care the consensus maximum blocksize rule being here at all or not
(you just said that).
Is it because you don't think it limits mining centralization or
because you don't care about limiting mining centralization with
consensus rules at all?

📅 Original date posted:2015-08-30 📝 Original message:On ...

2023-06-07T17:49:20+02:00

In reply to nevent1q…2nnj
_________________________

📅 Original date posted:2015-08-30
📝 Original message:On Sun, Aug 30, 2015 at 7:13 PM, <jl2012 at xbt.hk> wrote:
> This is based on the assumption that miners would always like to use up the
> last byte of the available block size. However, this is just not true:
>
> 1. The 6 year blockchain history has shown that most miners have a soft cap
> with their block size.
>
> 2. Chinese miners, controlling 60% of the network, rejected Gavin's initial
> 20MB proposal and asked for 8MB:
> http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size
> [...]

No, I'm not making such assumption. I'm focusing on what they CAN do,
while suspending judgement on their good will and not trying to
predict their future behavior from historic behaviour.
With 60% of the hashrate, you can easily get 100% by orphaning
everybody else's blocks. More importantly, being under the same
jurisdiction they can be forced to behave in certain way (for example,
censor transactions) by law.
I'm very worried about the current situation no matter how benevolent
current miners are. Thus weakening the only limit to mining
centralization that we have at the consensus rule level seems
extremely risky at this point.

> For many reasons miners may want to have a smaller block size, which we
> don't need to list them here. Although they can limit it by a softfork or
> even 51% attack, it is a very violent process. Why don't we just allow them
> to vote for a lower limit?
>
> So I think the right way is to choose a mining-centralization-safe limit,
> and let it free float within a range based on miner's vote. If we are lucky
> enough to have some responsible miners, they will keep it as low as
> possible, until the legitimate tx volume catches up. Even in the worst case,
> the block size is still mining-centralization-safe. The upper limit may
> increase linearly, if not exponentially, until we find a better long-term
> solution. (sort of a combination of BIP100 and 101, with different
> parameters)

My point is, a "soft cap" determined by miners clearly doesn't protect
us from mining centralization: the "hard cap" does.
Knowing that, and given that miners can currently set their own policy
block size maximum, what does this "voting on a lower limit" achieve?
What are the gains? Why are we "lucky" if they keep the lower one as
low as possible?

> For the matter of "urgency", I agree with you that there is no actual
> urgency AT THIS MOMENT. However, if a hardfork may take 5 years to deploy
> (as you suggested), we really have the urgency to make a decision now.

Thank you for admitting it is not urgent!
I suggested 5 years for the concrete hardfork in bip99 because it's
clearly non-urgent and I wanted to be very conservative. I'm happy to
reduce that to say, 1 year (specially given that the change is very
simple to implement).
For a simple block size change (like, say bip102) 1 year (maybe 6
months + miner's confirmation) is probably more than enough as well.
And we can always deploy an urgency hardfork if it is necessary.

> Actually, the main point is not urgency but uncertainty. We have debated for
> 5 years. Why won't we have 5 more years of debate, plus 5 years of
> deployment delay? Are we sticking to 1MB for 10 years? In that case Bitcoin
> Core must be abandoned by the economic majority and a Schism fork must
> occur.

Fortunately we haven't been discussing this for 5 years, I don't know
where you get that from.
A schism fork it's certainly always a possibility but I would only
consider it after an urgency hardfork (once the issue becomes urgent)
fails due to not being uncontroversial.
Would you agree with me on that?
What would be your criterion for considering an increase in block size urgent?

Mine is: we should consider a block increase only when minimum market
fees for transactions to be mined (currently zero satoshis) increase
above a high fee (admittedly undefined, but certainly greater than
zero).
Even if it's "urgent", I think we should only increase the maximum if,
at the same time, the new size can be considered safe
mining-centralization-wise (unfortunately we don't have any metric to
measure that nor enough tools to realistically simulate different
sizes in different network topologies at the moment). But once we have
them, the next discussion will be much simpler, so I don't see the
need for block size maximum that changes over time (neither
exponentially nor linearly).

Would you agree with me that mining centralization should be the most
important criterion when changing the block size maximum rule rather
than the level of minimum fees?
If the community can't agree on this, I'm afraid there will be a
schism hardfork eventually. Another possibility is that those who
aren't concerned with mining centralization start their own altcoin
(centralizedcoin? ), maybe a spinoff [
https://bitcointalk.org/index.php?topic=563972.0 ] if they want to
keep Bitcoin's utxo at the moment of the separation.

But if the community agrees with this and just disagrees on the
maximum block size consensus rule having any effect on mining
centralization (like Gavin and I disagree), we should calm down and
use scientific processes to find out what the relation between the two
actually is (if there's any relation at all).

Would you agree with me on this?

📅 Original date posted:2015-08-29 📝 Original message:On ...

2023-06-07T17:49:19+02:00

In reply to nevent1q…vf6g
_________________________

📅 Original date posted:2015-08-29
📝 Original message:On Sat, Aug 29, 2015 at 12:15 PM, Btc Drak <btcdrak at gmail.com> wrote:
> On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Ah, then my mistake. It seemed so similar to an idea that was proposed
>> before on this mailing list:
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
>>
>> that my mind just filled in the gaps. I concur -- having miners -- or any
>> group -- vote on block size is not an intrinsically good thing. The the
>> original proposal due to Greg Maxwell et al was not a mechanism for "voting"
>> but rather a feedback control that made the maximum block size that which
>> generated the most fees.
>
> Mark and Jorge,
>
> I am very glad you have brought up this particular objection because
> it's something I thought about but was unclear if it was an opinion
> that would be shared by others. I chose to omit it from the proposal
> to see if it would come up during peer review.
>
> I feel that giving miners a blank cheque to increase blocksize, by any
> means, goes against a key design of bitcoin's security model. Full
> nodes keep miners honest by ensuring by validating their blocks. Under
> any voting-only scheme there is no way for full nodes to keep miners
> in cheque because miner have free reign to increase the blocksize.
>
> This problem can be solved by introducing a hard cap on blocksize. By
> introducing an upper limit miners now have the freedom to increase
> blocksize but only within defined parameters. Remember my proposal
> allows blocksize to increase and decrease in such a way that miners
> must collectively agree if they want the size to increase.

Then I only care about the hard cap (for example, to me bip100 is
practically equivalent to just raise the limit to 32 MB directly).
Miners can always produce smaller blocks by modifying their local policy.
So if we need a maximum that cannot be altered by miners anyway, why
take the additional complexity of miners voting on a lower and
changing maximum size?

> With respect to the flexicap idea where miners can create a larger
> block by paying extra difficulty, I believe that proposal has a
> critical flaw because, as Gavin pointed out, it makes it very
> expensive (and risky) to include a few extra transactions. I believe
> it suffers from tragedy of the commons because there is no incentive
> for the mining community to reach consensus. Each and every block is
> going to be a gamble, "should we include a few extra transactions at
> the risk of losing the block?".

How expensive it is depends on the concrete function f(extra_nBits) =
extra_size_allowed
But the goal of that proposal is not to raise the size maximum
permanently, but rather temporarily allow bigger blocks when there are
spikes in demand (ie many fees to collect in unconfirmed
transactions).
Yes miners will ask that question to themselves, and the answer will
depend on the concrete function and on the fees of those extra
transactions.
The miner paying for the costs will get the gains: no tragedy of the
commons here.

> Under my proposal miners can
> collectively agree to change the blocksize. Let's say they want a 10%
> increase, they can collude together to make that increase and once
> reached, it remains until they want to change it again. Yet, the upper
> hard limit keeps the ultimate control of the maximum block size
> squarely in the hands of full nodes.

I believe the tragedy of the commons actually happens with your
proposal. Why would I pay alone for something that benefits all
miners?

> An alternative methodology to voting in the coinbase would be to
> change the vote to be the blocksize itself
>
> 1. miners pay extra difficulty to create a larger block.
> 2. every 2016 blocks the average or median of the last 2016 blocks is
> calculated and becomes the new maximum blocksize limit.
>
> This would retain incentive to collude to increase blocksize, as well
> as the property of costing to increase while being free to propose
> decrease.

This seems to solve the tragedy of the commons problem with your
current proposal.
It would be like flexcap but instead of the change in size being
temporary, it affects the next maximum size permanently.
One thing to worry about is miners filling blocks with
pay-to-themselves garbage to avoid reducing the size when they don't
have enough attractive transactions to include (ie it may not be free
for the network for miners to vote on "maintain current size").

> It would still require an upper blocksize limit in order for full
> nodes to retain control. Without an upper limit, any proposal is going
> to break the security model as full nodes give up some oversight
> control over miners.
>
> Another way of looking at these ideas is we're raising blocksize hard
> limit (to 8MB or whatever is decided), but making a soft of "softer"
> or inner limit part of consensus. Such a concept is not really
> departing from the current idea of a soft limit except to make it
> consensus enforced. Obviously it's not identical, but I think you can
> see the similarities.
>
> Does that make sense?

I still don't see the point in having a lower moving size maximum.
If 8 MB is mining-centralization-safe, let's move directly to 8 MB
without adding this seemingly useless extra complexity.
If it's not, mining voting on a lower moving maximum won't make it safer.

Once we have more objective tools (centralization metrics, simulators,
etc...) to determine whether or not a block size is
mining-centralization-safe for a given point in time (looking at
current centralization and current technology available), I don't see
the problem with repeating the equivalent of bip102 periodically
(every 2 years?) to adapt the size to better technology or lower
mining centralization.
It would be also helpful to have a tool to somehow measure "size
increase urgency" (ie right now free transactions get mined and blocks
aren't full or close to be full, I don't think the current general
sense of urgency on this matter is justified).

With all respect, I believe bip100 and this proposal are
over-engineering; and bip101 and bip103 (pieter's) are
overly-optimistic (in their exponential technological growth
assumptions).

📅 Original date posted:2015-08-28 📝 Original message:On ...

2023-06-07T17:49:17+02:00

In reply to nevent1q…u4sk
_________________________

📅 Original date posted:2015-08-28
📝 Original message:On Sat, Aug 29, 2015 at 1:38 AM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> It is in their individual interests when the larger block that is allowed
> for them grants them more fees.

I realize now that this is not what Greg Maxwell proposed (aka
flexcap): this is just miner's voting on block size but paying with
higher difficulty when they vote for bigger blocks.
As I said several times in other places, miners should not decide on
the consensus rule to limit mining centralization.
People keep talking about miners voting on the block size or
"softforking the size down if we went too far". But what if the
hashing majority is perfectly fine with the mining centralization at
that point in time?
Then a softfork won't be useful and we're talking about an "anti-miner
fork" (see https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR158
and https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR175
).

I believe miner's voting on the rule to limit mining centralization is
a terrible idea.
It sounds as bad as letting pharma companies write the regulations on
new drugs safety, letting big food chains deciding on minimum food
controls or car manufacturers deciding on indirect taxes for fuel.
That's why I dislike both this proposal and BIP100.