From: Peter R <peter_r@gmx•com>
To: "Emin Gün Sirer" <el33th4x0r@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] How to evaluate block size increase suggestions.
Date: Sat, 14 Nov 2015 13:45:25 -0800 [thread overview]
Message-ID: <B2C858C1-B15F-49F1-BF7E-02EA7C3FE474@gmx.com> (raw)
In-Reply-To: <CAPkFh0s-o6BXAEC-s9s1UmFwVfMFQKStoJaM0u2Lct9yiP5QBQ@mail.gmail.com>
> It looks like some specific meta-level criteria would help more at this point than new proposals all exploring a different variants of block size increase schedules.
I agree. In fact, I’ll go meta on your meta and suggest that we should first discuss how Bitcoin should be governed in the first place. Should Bitcoin evolve from the “bottom up,” or from the “top down”?
If one’s answer is from the “top-down,” then the meta-level criteria can be endlessly debated, for they all involve some sort of tradeoff, they all require some sort of compromise. The “top down” perspective holds that people might make poor choices if given the freedom to easily do so--it holds that the trade-offs must be balanced instead by experts.
However, if one's answer is from the “bottom up,” then the meta-level criteria is very easy: we do what the people wants. We allow the people to weigh the tradeoffs and then we watch as consensus emerges through a decentralized process, objectively represented by the longest proof-of-work chain.
Regarding the block size limit debate, at the end of the day it comes down to two things:
1. How big of a block will my node accept today?
2. What do I want my node to do if the longest chain includes a block larger than the limit I set?
If one concedes that Bitcoin should be governed from the “bottom up,” then it is already possible to empower each node operator to more easily express his free choice regarding the size of blocks he is willing to accept, while simultaneously ensuring that his node tracks consensus.
Best regards,
Peter
next prev parent reply other threads:[~2015-11-14 21:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-13 16:37 Emin Gün Sirer
2015-11-13 16:52 ` Angel Leon
2015-11-14 13:48 ` Jorge Timón
2015-11-14 21:45 ` Peter R [this message]
2015-11-15 6:04 ` Johnathan Corgan
[not found] <mailman.1887.1447451888.1619.bitcoin-dev@lists.linuxfoundation.org>
2015-11-14 16:08 ` Mariusz Nowostawski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B2C858C1-B15F-49F1-BF7E-02EA7C3FE474@gmx.com \
--to=peter_r@gmx$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=el33th4x0r@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox