Re: [bitcoin-dev] How to evaluate block size increase suggestions.

Re: [bitcoin-dev] How to evaluate block size increase suggestions.

[Mariusz Nowostawski]

> Date: Fri, 13 Nov 2015 11:37:51 -0500
> From: Emin G?n Sirer <el33th4x0r@gmail.com>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: [bitcoin-dev] How to evaluate block size increase
> 	suggestions.
> Message-ID:
> 	<CAPkFh0s-o6BXAEC-s9s1UmFwVfMFQKStoJaM0u2Lct9yiP5QBQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> By now, we have seen quite a few proposals for the block size increase.
> It's hard not to notice that there are potentially infinitely many
> functions for future block size increases. One could, for instance, double
> every N years for any rational number N, one could increase linearly, one
> could double initially then increase linearly, one could ask the miners to
> vote on the size, one could couple the block size increase to halvings,
> etc. Without judging any of these proposals on the table, one can see that
> there are countless alternative functions one could imagine creating.
> 
> I'd like to ask a question that is one notch higher: Can we enunciate what
> grand goals a truly perfect function would achieve? That is, if we could
> look into the future and know all the improvements to come in network
> access technologies, see the expansion of the Bitcoin network across the
> globe, and precisely know the placement and provisioning of all future
> nodes, what metrics would we care about as we craft a function to fit what
> is to come?
> 
> To be clear, I'd like to avoid discussing any specific block size increase
> function. That's very much the tangible (non-meta) block size debate, and
> everyone has their opinion and best good-faith attempt at what that
> function should look like. I've purposefully stayed out of that issue,
> because there are too many options and no metrics for evaluating proposals.
> 
> Instead, I'm asking to see if there is some agreement on how to evaluate a
> good proposal. So, the meta-question: if we were looking at the best
> possible function, how would we know? If we have N BIPs to choose from,
> what criteria do we look for?
> 
> To illustrate, a possible meta goal might be: "increase the block size,
> while ensuring that large miners never have an advantage over small miners
> that [they did not have in the preceding 6 months, in 2012, pick your time
> frame, or else specify the advantage in an absolute fashion]." Or "increase
> block size as much as possible, subject to the constraint that 90% of the
> nodes on the network are no more than 1 minute behind one of the tails of
> the blockchain 99% of the time." Or "do not increase the blocksize until at
> least date X." Or "the increase function should be monotonic." And it's
> quite OK (and probably likely) to have a combination of these kinds of
> metrics and constraints.
> 
> For disclosure, I personally do not have a horse in the block size debate,
> besides wanting to see Bitcoin evolve and get more widely adopted. I ask
> because as an academic, I'd like to understand if we can use various
> simulation and analytic techniques to examine the proposals.  A second
> reason is that it is very easy to have a proliferation of block size
> increase proposals, and good engineering would ask that we define the
> meta-criteria first and then pick. To do that, we need some criteria for
> judging proposals other than gut feeling.
> 
> Of course, even with meta-criteria in hand, there will be room for lots of
> disagreement because we do not actually know the future and reasonable
> people can disagree on how things will evolve. I think this is good because
> it makes it easier to agree on meta-criteria than on an actual, specific
> function for increasing the block size.
> 
> 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.
> 
> Best,
> 
> - egs



Hi,

Good point. I found it also to be important. Enumerating first exactly
WHAT and WHY is being solved and then formulating HOW the proposed
solutions can be evaluated, resonates with me, probably because I'm an
academic. We need to be able to predict if a given proposal addresses
the actual problem at hand and we need to know how to evaluate the
proposals.

But first, we need to re-evaluate the problem.  I think the original
problem of the increasing demands on the transaction throughput of the
bitcoin blockchain have been derailed into a rather constrained
discussion on the block size increase. This is fundamentally broken. The
debate should be reverted back to the actual problem: how to deal with
the increasing demands of the transaction throughput on the bitcoin
blockchain, what exactly is the problem, and what possible ways exist in
dealing with those problems? In other words, how to deal with the
scalability of the bitcoin blockchain.


Somewhat surprisingly, all the solutions proposals so far focused on a
"centralized" model in which Bitcoin blockchain plays the central role
in any future economy. Bitcoin has been compared to VISA and questions
have been asked how to handle 1000s of transactions per second - via the
Bitcoin blockchain. Should any form of electronic value transfer such as
assets, currencies, etc be handled by THE SINGLE CHAIN? A single chain
that does it ALL? Is that the objective for the Bitcoin blockchain?
There are some contradictions: from one hand the Bitcoin blockchain
offers transparent, distributed ledger that can be used for verification
of transactions, which is a good thing. At the same time, it uses p2p
technology, consensus, and limited transaction throughput (regardless of
where the actual block size limit sits), which are bad when considering
processing and validating large volumes of financial transactions such
as currently processed by VISA.

Planning the Bitcoin blockchain to handle everything will simply never
scale, it might turn out impossible, and also it will hinder innovation,
and can ultimately work against the Bitcoin blockchain (e.g. by
inadvertent and irreversible centralization of verification nodes, or
simply reducing the full verification nodes count).


(Devil's advocate): limit stays on 1MB and there are more transactions
generated every 10min that can potentially fit into the block. Then,
this follows:

1. There will be a strong incentive for fees to grow.
Is it a bad thing? Are growing fees unavoidable anyway? Miners need to
recover the costs of mining when the crossing-point of rewards/fees
happens, and that means growing fees, right?  Can this be modeled? Can
we predict how much the fees will actually grow to weed out all the
"noise" transactions that currently get through because it is cheap to
do so?

2. Some transactions will simply never made it to the chain.
Is it a bad thing? Perhaps it is just a self-adaptation to weed out
"invaluable" transactions from the system? Do we need to process and
cater for ALL the transactions? Including all the NOISE that doesn't
really contribute to anything? Can we model this?

Personally, I think transaction fees for electronic transfers should be
close to ZERO, but, at the same time, I think transaction costs of
Bitcoin blockchain should be high enough to keep this chain special,
noise free, and compact, with large number of validating nodes working
in p2p fashion.

So are points 1 and 2 really fundamentally BAD, or are they just a
self-regulating anti-noise mechanism? I can pack-up thousands of
transactions in auxiliary systems, and validate them via a SINGLE
bitcoin blockchain transaction, and this would scale.


3. Companies generating large number of transactions will have to look
into ways of saving costs and combining multiple individual transactions
into larger ones to save on FEE costs.
Is it a bad thing? No - it is a very good thing, and the sooner it
happens the better ;)


4. Companies, governments and institutions would have to look into ways
of improving their own performance and scalability OUTSIDE of the
Bitcoin blockchain. For example through client-server, extremely
efficient centralised blockchains, Open Chain-like models, and only
using Bitcoin blockchain for validation/verification in a transparent
and verifiable manner. How about running thousands of financial
transactions per second on open chain and only recording merkel root
hashes for batches of transactions every 10min in a Bitcoin blockchain
for transparency and verification?




So, coming back to the original question about CRITERIA:

*1* The ability to setup and run low-cost fully validating node should
remain the same or should improve; upon deployment of a given proposal
there should be an increase in a number of fully validating nodes, or at
worst, there should be no decrease.

*2* The ability to include additional data into Bitcoin blockchain (e.g.
via OP_RETURN) should improve or, at worst, remain the same as it is now.

*3* Upon deployment of a given proposal, the noise in the ledger should
be reduced, or at worst, remain the same.

*4* A proposal should address long-term scalability, and offer the
possibility of combining Bitcoin blockchain with well-defined auxiliary
protocols to offer high-transaction throughputs.



cheers
Mariusz

[bitcoin-dev] How to evaluate block size increase suggestions.

[Emin Gün Sirer]

[-- Attachment #1: Type: text/plain, Size: 3527 bytes --]

By now, we have seen quite a few proposals for the block size increase.
It's hard not to notice that there are potentially infinitely many
functions for future block size increases. One could, for instance, double
every N years for any rational number N, one could increase linearly, one
could double initially then increase linearly, one could ask the miners to
vote on the size, one could couple the block size increase to halvings,
etc. Without judging any of these proposals on the table, one can see that
there are countless alternative functions one could imagine creating.

I'd like to ask a question that is one notch higher: Can we enunciate what
grand goals a truly perfect function would achieve? That is, if we could
look into the future and know all the improvements to come in network
access technologies, see the expansion of the Bitcoin network across the
globe, and precisely know the placement and provisioning of all future
nodes, what metrics would we care about as we craft a function to fit what
is to come?

To be clear, I'd like to avoid discussing any specific block size increase
function. That's very much the tangible (non-meta) block size debate, and
everyone has their opinion and best good-faith attempt at what that
function should look like. I've purposefully stayed out of that issue,
because there are too many options and no metrics for evaluating proposals.

Instead, I'm asking to see if there is some agreement on how to evaluate a
good proposal. So, the meta-question: if we were looking at the best
possible function, how would we know? If we have N BIPs to choose from,
what criteria do we look for?

To illustrate, a possible meta goal might be: "increase the block size,
while ensuring that large miners never have an advantage over small miners
that [they did not have in the preceding 6 months, in 2012, pick your time
frame, or else specify the advantage in an absolute fashion]." Or "increase
block size as much as possible, subject to the constraint that 90% of the
nodes on the network are no more than 1 minute behind one of the tails of
the blockchain 99% of the time." Or "do not increase the blocksize until at
least date X." Or "the increase function should be monotonic." And it's
quite OK (and probably likely) to have a combination of these kinds of
metrics and constraints.

For disclosure, I personally do not have a horse in the block size debate,
besides wanting to see Bitcoin evolve and get more widely adopted. I ask
because as an academic, I'd like to understand if we can use various
simulation and analytic techniques to examine the proposals.  A second
reason is that it is very easy to have a proliferation of block size
increase proposals, and good engineering would ask that we define the
meta-criteria first and then pick. To do that, we need some criteria for
judging proposals other than gut feeling.

Of course, even with meta-criteria in hand, there will be room for lots of
disagreement because we do not actually know the future and reasonable
people can disagree on how things will evolve. I think this is good because
it makes it easier to agree on meta-criteria than on an actual, specific
function for increasing the block size.

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.

Best,

- egs


P.S. This message is an off-shoot of this blog post:

http://hackingdistributed.com/2015/11/13/suggestion-for-the-blocksize-debate/

[-- Attachment #2: Type: text/html, Size: 3959 bytes --]

Re: [bitcoin-dev] How to evaluate block size increase suggestions.

[Angel Leon]

[-- Attachment #1: Type: text/plain, Size: 4524 bytes --]

I believe in the end it's the usability of bitcoin that matters.

For instance, a goal could be that no user on the network should wait more
than an hour to get 3 confirmations on the blockchain so that they can
actually have useful Bitcoins.

We can debate all we want about lots of technical aspects, but if you can't
send money what's the point?

My humble proposal tried to take that into consideration, but I like way
way more what you propose with NG.

http://twitter.com/gubatron

On Fri, Nov 13, 2015 at 11:37 AM, Emin Gün Sirer <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> By now, we have seen quite a few proposals for the block size increase.
> It's hard not to notice that there are potentially infinitely many
> functions for future block size increases. One could, for instance, double
> every N years for any rational number N, one could increase linearly, one
> could double initially then increase linearly, one could ask the miners to
> vote on the size, one could couple the block size increase to halvings,
> etc. Without judging any of these proposals on the table, one can see that
> there are countless alternative functions one could imagine creating.
>
> I'd like to ask a question that is one notch higher: Can we enunciate what
> grand goals a truly perfect function would achieve? That is, if we could
> look into the future and know all the improvements to come in network
> access technologies, see the expansion of the Bitcoin network across the
> globe, and precisely know the placement and provisioning of all future
> nodes, what metrics would we care about as we craft a function to fit what
> is to come?
>
> To be clear, I'd like to avoid discussing any specific block size increase
> function. That's very much the tangible (non-meta) block size debate, and
> everyone has their opinion and best good-faith attempt at what that
> function should look like. I've purposefully stayed out of that issue,
> because there are too many options and no metrics for evaluating proposals.
>
> Instead, I'm asking to see if there is some agreement on how to evaluate a
> good proposal. So, the meta-question: if we were looking at the best
> possible function, how would we know? If we have N BIPs to choose from,
> what criteria do we look for?
>
> To illustrate, a possible meta goal might be: "increase the block size,
> while ensuring that large miners never have an advantage over small miners
> that [they did not have in the preceding 6 months, in 2012, pick your time
> frame, or else specify the advantage in an absolute fashion]." Or "increase
> block size as much as possible, subject to the constraint that 90% of the
> nodes on the network are no more than 1 minute behind one of the tails of
> the blockchain 99% of the time." Or "do not increase the blocksize until at
> least date X." Or "the increase function should be monotonic." And it's
> quite OK (and probably likely) to have a combination of these kinds of
> metrics and constraints.
>
> For disclosure, I personally do not have a horse in the block size debate,
> besides wanting to see Bitcoin evolve and get more widely adopted. I ask
> because as an academic, I'd like to understand if we can use various
> simulation and analytic techniques to examine the proposals.  A second
> reason is that it is very easy to have a proliferation of block size
> increase proposals, and good engineering would ask that we define the
> meta-criteria first and then pick. To do that, we need some criteria for
> judging proposals other than gut feeling.
>
> Of course, even with meta-criteria in hand, there will be room for lots of
> disagreement because we do not actually know the future and reasonable
> people can disagree on how things will evolve. I think this is good because
> it makes it easier to agree on meta-criteria than on an actual, specific
> function for increasing the block size.
>
> 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.
>
> Best,
>
> - egs
>
>
> P.S. This message is an off-shoot of this blog post:
>
>
> http://hackingdistributed.com/2015/11/13/suggestion-for-the-blocksize-debate/
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 5400 bytes --]

Re: [bitcoin-dev] How to evaluate block size increase suggestions.

[Jorge Timón]

I agree with the usefulness of at least trying to define a formal set
of criteria.
I'm afraid that with proposals that schedule future increases to the
blocksize consensus maximum or leave it for miners to decide (like
BIP100, BIP101 and BIP103) cannot be evaluated without making
assumptions about the future (or what miners will decide in the
future).
Since limiting resource consumption and mining centralization dynamics
are the reasons to have blocksize consensus maximum in the first
place, I think it would be ideal to have some simulation +
benchmarking software that is able to analyze a given proposal, give
resource consumption benchmark data about average and worst cases, and
also give some kind of metric from "mining centralization dynamics
simulations".
We could start with just a metric for concrete block sizes (for
arbitrary maximum blocksizes testchains see #6382).
Note that this is unrelated to the deployment mechanism, proposed
activation date and other details.

On Fri, Nov 13, 2015 at 5:52 PM, Angel Leon via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> For instance, a goal could be that no user on the network should wait more
> than an hour to get 3 confirmations on the blockchain so that they can
> actually have useful Bitcoins.

That depends on block space demand on a particular moment in time, the
fee paid by the example user and local relay and mining policies in
the network (and how they treat transactions with the specific form of
the transaction example) and even the network topology.
There's no consensus rule that can guarantee that all transaction from
all users will be included at most 3 blocks after they are relayed.
For starters, any user can create infinite transactions (without fee)
for free while the network will never have infinite computing
resources.
What we have is a fee estimator that observes the chain and can
estimate the market situation to tell you the average number of blocks
for a given transaction with a given feerate. I know that number was
only 14 blocks or so for free (not a single satoshi in fees)
transactions, but that has probably changed with the recent attacks...

Re: [bitcoin-dev] How to evaluate block size increase suggestions.

[Peter R]

> 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

Re: [bitcoin-dev] How to evaluate block size increase suggestions.

[Johnathan Corgan]

[-- Attachment #1: Type: text/plain, Size: 2410 bytes --]

This topic is straying from Bitcoin development into general Bitcoin
governance, policy, or other meta-issues.

We have now the new bitcoin-discuss mailing list now, specifically for
these more free-flowing topics:

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss

Please take further discussion of this thread to that forum.

Thank you,

The bitcoin-dev moderation team


On Sat, Nov 14, 2015 at 1:45 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3609 bytes --]