<unnamed>

Public Key

npub1zw5sx3at9e7k6yvpuw7dnsxdcfmch5ngrkfvxdsuwwmn5c0ue4wqajkh0g

Profile Code

nprofile1qqsp82grg74jultdzxq780xecrxuyaut6f5pmykrxcw88de6v87v6hqpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqyq0yc7

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:42:49 CEST

- reply

📅 Original date posted:2015-07-22
📝 Original message:Pieter, I agree with the overall gist of your statement (that Bitcoin is a
consensus-driven protocol that's incompatible with certain forms of central
governance) but I respectfully disagree with some of the conclusions you're
drawing.
> Consensus changes should be done using consensus, _and the default in
case of controversy is no change_.
(emphasis mine)
I think that there's a disconnect between the idea that Bitcoin Core making
a consensus-driven change in turn means that the network is being forced
down a certain path. This takes away a great deal of the individual agency
that makes Bitcoin what it is today. Upgrading to a version of Bitcoin Core
that is incompatible with your ideals is in no way a forced choice, as you
have stated in your email; forks, alternative clients, or staying on an
older version are all valid choices. If the majority of the network chooses
not to endorse a specific change, then the majority of the network will
continue to operate just fine without it, and properly structured consensus
rules will pull the minority along as well. (For example, re: block sizes,
if the majority of hashing power remains on a version or fork that does not
mine >1MB blocks, a chain of <1MB blocks will continue to be the longest,
and up to date clients will still respect that. That is consensus at work,
pure and simple.)
Obviously Core is in a unique position as a reference client and ignoring
that would be irresponsible. If broad consensus among the developers cannot
be reached, then Core should not make a given change. However, freezing
Core's ability to make changes in light of _any_ controversy is allowing a
few voices to dictate direction and is counter to any kind of
consensus-driven decision making.
Placing Core and its developers on some sort of pedestal where we believe
that they dictate policy and therefore shouldn't be allowed to take any
risks will create the very situation that you're advocating against- that a
small group of developers have control over Bitcoin's policies. Instead, we
should strive to treat Core as _just another Bitcoin Client_, we should
educate users to make informed choices about the version of software they
are running and the choices implicit in that, and we should allow consensus
at the protocol level to make the decisions on the overall direction of the
network.
> My personal opinion is that we - as a community - should indeed let a fee
market develop, and rather sooner than later
I will keep this brief because this is straying off topic of the idea of
this thread- but I don't believe that increasing Bitcoin's capacity as a
network is inherently incompatible with the development of a fee market,
and considering a fee market to be formed of only a single set of variables
(transaction rate versus block size) is not sound economic analysis.
On Wed, Jul 22, 2015 at 10:32 AM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> default in case of controversy is no change.
>>
>
> I think the result of this would probably be that no controversial changes
> ever get implemented via this process so others will hard fork the code and
> eventually make this process irrelevant. Since you need close to 100%
> agreement the irrelevance would have to come as a step function which will
> manifest itself in a rather disruptive manner.
>
> The question is really is this hark-forking disruption worse than coming
> up with some kind of process to handle controversial changes.
>
> Russ
>
>
>
> _______________________________________________
> 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/20150722/6f2fbfdd/attachment.html>

2023-06-07 17:34:09 CEST

- reply

📅 Original date posted:2015-05-29
📝 Original message:On Fri, May 29, 2015 at 5:39 AM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> What do other people think?
>
>
> If we can't come to an agreement soon, then I'll ask for help
> reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a
> big increase now that grows over time so we may never have to go through
> all this rancor and debate again.
>
> I'll then ask for help lobbying the merchant services and exchanges and
> hosted wallet companies and other bitcoind-using-infrastructure companies
> (and anybody who agrees with me that we need bigger blocks sooner rather
> than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they
> are running it. We'll be able to see uptake on the network by monitoring
> client versions.
>
>
>
While I think we'd all prefer Core to make changes like this, the current
environment may make that impossible. If this change happens in XT, we will
support the necessary changes in our own implementation. The block size
limit is a problem _today_, and I'd rather we solve today's problems with
today's understanding rather than let speculation about future unknowns
stop our ability to respond to known issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/64fa5360/attachment.html>