📅 Original date posted:2015-12-23
📝 Original message:> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for
> making changes to it in order to satisfy economic demand. If that is
> the case, Bitcoin has failed, in my opinion.
Pieter, what's actually happening is that the bitcoin-core release has
become a Schelling point in the consensus game:
https://en.wikipedia.org/wiki/Schelling_point
Due to the strong incentives for consensus, everyone is looking for an
obvious reference point that they think everyone else will also pick, even
though the point itself isn't critical, only that everyone agree on
whatever point is picked. Like it or not, the bitcoin-core release, and by
extension it's committers have a great degree of influence over what the
community as a whole decides to do. If core screws things up badly enough,
yes, the community will settle on some other focal point for consensus, but
the cost and risk of doing so is high, so there is indeed unavoidable moral
hazard for whoever has control over any such focus point.
Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com>;
On Wed, Dec 16, 2015 at 10:34 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>
> What the Bitcoin Core team should do, in my opinion, is merge any
> consensus change that is uncontroversial. We can certainly -
> individually or not - propose solutions, and express opinions, but as
> far as maintainers of the software goes our responsibility is keeping
> the system running, and risking either a fork or establishing
> ourselves as the de-facto central bank that can make any change to the
> system would greatly undermine the system's value.
>
> Hard forking changes require that ultimately every participant in the
> system adopts the new rules. I find it immoral and dangerous to merge
> such a change without extremely widespread agreement. I am personally
> fine with a short-term small block size bump to kick the can down the
> road if that is what the ecosystem desires, but I can only agree with
> merging it in Core if I'm convinced that there is no strong opposition
> to it from others.
>
> Soft forks on the other hand only require a majority of miners to
> accept them, and everyone else can upgrade at their leisure or not at
> all. Yes, old full nodes after a soft fork are not able to fully
> validate the rules new miners enforce anymore, but they do still
> verify the rules that their operators opted to enforce. Furthermore,
> they can't be prevented. For that reason, I've proposed, and am
> working hard, on an approach that includes Segregated Witness as a
> first step. It shows the ecosystem that something is being done, it
> kicks the can down the road, it solves/issues half a dozen other
> issues at the same time, and it does not require the degree of
> certainty needed for a hardfork.
>
> --
> Pieter
> _______________________________________________
> 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/20151222/2a316e8d/attachment.html>;
Aaron Voisine [ARCHIVE] /
npub18g…knkzl
2023-06-07 17:46:25
in reply to nevent1q…jqp7
Author Public Key
npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzlPublished at
2023-06-07 17:46:25Event JSON
{
"id": "be3d4a7fc76bb0ef872121ef3eae51135b6a56bbface93538100fe9f319db03d",
"pubkey": "3a24ce2145c5488aebfb0fc113e7d44234e9d3733afa45e2d880eb259c3eade3",
"created_at": 1686159985,
"kind": 1,
"tags": [
[
"e",
"d58ef5f27c55f40f82225aaaf9d4842ef2ec79260053b36e96980654a30d74c7",
"",
"root"
],
[
"e",
"a1a322d1d198d018aa89a96a9f098027d0e6206fbe526b1626f070bf453ab443",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2015-12-23\n📝 Original message:\u003e You present this as if the Bitcoin Core development team is in charge\n\u003e of deciding the network consensus rules, and is responsible for\n\u003e making changes to it in order to satisfy economic demand. If that is\n\u003e the case, Bitcoin has failed, in my opinion.\n\nPieter, what's actually happening is that the bitcoin-core release has\nbecome a Schelling point in the consensus game:\n\nhttps://en.wikipedia.org/wiki/Schelling_point\n\nDue to the strong incentives for consensus, everyone is looking for an\nobvious reference point that they think everyone else will also pick, even\nthough the point itself isn't critical, only that everyone agree on\nwhatever point is picked. Like it or not, the bitcoin-core release, and by\nextension it's committers have a great degree of influence over what the\ncommunity as a whole decides to do. If core screws things up badly enough,\nyes, the community will settle on some other focal point for consensus, but\nthe cost and risk of doing so is high, so there is indeed unavoidable moral\nhazard for whoever has control over any such focus point.\n\nAaron Voisine\nco-founder and CEO\nbreadwallet \u003chttp://breadwallet.com\u003e\n\nOn Wed, Dec 16, 2015 at 10:34 AM, Pieter Wuille via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e 2) If block size stays at 1M, the Bitcoin Core developer team should\n\u003e sign a\n\u003e \u003e collective note stating their desire to transition to a new economic\n\u003e policy,\n\u003e \u003e that of \"healthy fee market\" and strongly urge users to examine their fee\n\u003e \u003e policies, wallet software, transaction volumes and other possible User\n\u003e \u003e impacting outcomes.\n\u003e\n\u003e You present this as if the Bitcoin Core development team is in charge\n\u003e of deciding the network consensus rules, and is responsible for making\n\u003e changes to it in order to satisfy economic demand. If that is the\n\u003e case, Bitcoin has failed, in my opinion.\n\u003e\n\u003e What the Bitcoin Core team should do, in my opinion, is merge any\n\u003e consensus change that is uncontroversial. We can certainly -\n\u003e individually or not - propose solutions, and express opinions, but as\n\u003e far as maintainers of the software goes our responsibility is keeping\n\u003e the system running, and risking either a fork or establishing\n\u003e ourselves as the de-facto central bank that can make any change to the\n\u003e system would greatly undermine the system's value.\n\u003e\n\u003e Hard forking changes require that ultimately every participant in the\n\u003e system adopts the new rules. I find it immoral and dangerous to merge\n\u003e such a change without extremely widespread agreement. I am personally\n\u003e fine with a short-term small block size bump to kick the can down the\n\u003e road if that is what the ecosystem desires, but I can only agree with\n\u003e merging it in Core if I'm convinced that there is no strong opposition\n\u003e to it from others.\n\u003e\n\u003e Soft forks on the other hand only require a majority of miners to\n\u003e accept them, and everyone else can upgrade at their leisure or not at\n\u003e all. Yes, old full nodes after a soft fork are not able to fully\n\u003e validate the rules new miners enforce anymore, but they do still\n\u003e verify the rules that their operators opted to enforce. Furthermore,\n\u003e they can't be prevented. For that reason, I've proposed, and am\n\u003e working hard, on an approach that includes Segregated Witness as a\n\u003e first step. It shows the ecosystem that something is being done, it\n\u003e kicks the can down the road, it solves/issues half a dozen other\n\u003e issues at the same time, and it does not require the degree of\n\u003e certainty needed for a hardfork.\n\u003e\n\u003e --\n\u003e Pieter\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151222/2a316e8d/attachment.html\u003e",
"sig": "5f3b1d76a7221c2db2cbcf38244c8a4b5ab6dcabfb88f98e37dce2713988222433984d17f83f75536a1dce0c45c112722a72b0465e87c7a5296544c0532c6ebd"
}