* [bitcoin-dev] Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it
@ 2015-06-30 15:34 Michael Naber
2015-06-30 16:03 ` Richard Moore
2015-06-30 16:15 ` Venzen Khaosan
0 siblings, 2 replies; 6+ messages in thread
From: Michael Naber @ 2015-06-30 15:34 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]
As you know I'm trying to lobby for a block size increase to a static 8MB.
I'm happy to try to get the testing done that people want done for this,
but I think the real crux of this issue is that we need to get consensus
that we intend to continually push the block size upward as bounded only by
technology.
Imagine an engineer (Gavin) at Boeing (Bitcoin Core) said he was going to
build an airplane (block) that was going to move 8x as many people
(transactions) as today’s planes (blocks), all while costing about the same
amount to operate. Imagine he then went on to tell you that he expects to
double the plane’s (block's) capacity every two years!
Without full planes (blocks), will the airlines (miners) go out of
business, since planes (blocks) will never be full and the cost to add
people (transactions) to a plane (block) will approach zero? Probably not.
Airlines (miners) still have to pay for pilots, security screening staff,
fuel, etc (engineers, hash rate, electricity, etc) so even if their
airplanes (blocks) can hold limitless people (transactions), they would
still have to charge sufficient fees to stay in business.
What tests do you need done to move to 8MB? Pitch in and help get those
tests done; agree that we'll run more tests next year or the year after
when technology might allow for 16 MB blocks. Do you really want to be the
guy holding back bigger planes? Do you really want to artificially
constrain block size below what technology allows?
In the face of such strong market demand for increased capacity in globally
aware global consensus, do you really think you can prevent supply from
meeting demand when the technology exists to deliver it? Do you really want
to force a fork because you and others won't agree to a simple raise to a
static 8MB?
Do what's best for Bitcoin and define what needs to get done to agree to a
simple block size increase to a static 8MB.
[-- Attachment #2: Type: text/html, Size: 2125 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it
2015-06-30 15:34 [bitcoin-dev] Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it Michael Naber
@ 2015-06-30 16:03 ` Richard Moore
2015-06-30 16:15 ` Venzen Khaosan
1 sibling, 0 replies; 6+ messages in thread
From: Richard Moore @ 2015-06-30 16:03 UTC (permalink / raw)
To: Michael Naber; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3563 bytes --]
I’m not planning to take a firm stance against or for, but one problem with your analogy is that airplanes [currently] are not elastic (until we get TARDIS technology, or semi-TARDIS-like technology); they take up space and resources proportional to their capacity.
It is not the block size that is increasing, it is the *maximum* block size… So, it’s more like saying the *maximum* airplane size is increasing, which I think may be somewhat true (although, I agree, probably not exponentially). It would be more like an airplane whose capacity was doubling every two years, but would shrink when that extra capacity was not needed and only consume the maintenance, fuel, et cetera needed for its current size.
My semi-firm-ish stance is that kicking the can down the road with a static increase is less better. We can always soft-fork the limit down if the *actual* block size is growing too fast. When (and/or if) we need to. I also think 8MB is a rather large jump, for either static or dynamic.
*shrug*
RicMoo
> On Jun 30, 2015, at 11:34 AM, Michael Naber <mickeybob@gmail•com> wrote:
>
> As you know I'm trying to lobby for a block size increase to a static 8MB.
>
> I'm happy to try to get the testing done that people want done for this, but I think the real crux of this issue is that we need to get consensus that we intend to continually push the block size upward as bounded only by technology.
>
> Imagine an engineer (Gavin) at Boeing (Bitcoin Core) said he was going to build an airplane (block) that was going to move 8x as many people (transactions) as today’s planes (blocks), all while costing about the same amount to operate. Imagine he then went on to tell you that he expects to double the plane’s (block's) capacity every two years!
>
> Without full planes (blocks), will the airlines (miners) go out of business, since planes (blocks) will never be full and the cost to add people (transactions) to a plane (block) will approach zero? Probably not. Airlines (miners) still have to pay for pilots, security screening staff, fuel, etc (engineers, hash rate, electricity, etc) so even if their airplanes (blocks) can hold limitless people (transactions), they would still have to charge sufficient fees to stay in business.
>
> What tests do you need done to move to 8MB? Pitch in and help get those tests done; agree that we'll run more tests next year or the year after when technology might allow for 16 MB blocks. Do you really want to be the guy holding back bigger planes? Do you really want to artificially constrain block size below what technology allows?
>
> In the face of such strong market demand for increased capacity in globally aware global consensus, do you really think you can prevent supply from meeting demand when the technology exists to deliver it? Do you really want to force a fork because you and others won't agree to a simple raise to a static 8MB?
>
> Do what's best for Bitcoin and define what needs to get done to agree to a simple block size increase to a static 8MB.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo@geneticmistakes•com <mailto:ricmoo@geneticmistakes•com>
www: http://GeneticMistakes.com <http://geneticmistakes.com/>
[-- Attachment #2: Type: text/html, Size: 5390 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it
2015-06-30 15:34 [bitcoin-dev] Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it Michael Naber
2015-06-30 16:03 ` Richard Moore
@ 2015-06-30 16:15 ` Venzen Khaosan
2015-06-30 16:25 ` Peter Todd
1 sibling, 1 reply; 6+ messages in thread
From: Venzen Khaosan @ 2015-06-30 16:15 UTC (permalink / raw)
To: Michael Naber; +Cc: bitcoin-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael, I snipped some of your comparison example to comment. I agree
with your sentiment to lobby for testing the change and your offer to
provide resources, yet it presents some (surmountable) challenges:
On 06/30/2015 10:34 PM, Michael Naber wrote:
> As you know I'm trying to lobby for a block size increase to a
> static 8MB.
>
> I'm happy to try to get the testing done that people want done for
> this, but I think the real crux of this issue is that we need to
> get consensus that we intend to continually push the block size
> upward as bounded only by technology.
Peter Todd, on 23/06/15, proposed a combined back-test and ongoing
forward test as follows:
"... the creation (via reorg) of a realistic full-load blockchain on
testnet to fully test the real-world behavior of the entire
infrastructure ecosystem, including questions like the scalability of
block explorers, SPV wallets, feasibility of initial syncronization,
scalability of the UTXO set, etc. While this is of course inconvenient
- - 2 years of 8MB blocks is 840GB worth of data..."
So, with a working dataset of that size, jumping to 8MB is excluding a
lot of participants and contributors to the testing - someone like
myself for example.
> Do what's best for Bitcoin and define what needs to get done to
> agree to a simple block size increase to a static 8MB.
And this then leads back to the core issue: if an 8MB blocksize
excludes many on this list from testnet, then the proposed 8MB blocks
will exclude a lot of mainnet participants (miners) and degrade the
quality of diversity and decentralization.
How about testing at double the capacity: 2MB?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVksCfAAoJEGwAhlQc8H1m3E8H/jbfdoYPN3dvJuWWpaEEU+P4
SbdPHLd08ya7dmZEqmJcGBH29aHCD1roqs5PDA6pwNFb7CTD/6aoRGeQnkU16wMj
FQ5UQkmT96niQhtHE17vdpeMHI+LK8ox1n0R3de+3QRn1HbXEN+Q68jPl16KLd8+
SArZfVUauVGUtoJDVLxXv1q2mx2huTUTX/QNeYcTZ5IjB5huMypjwN7VpL9bM8gT
xoN8pd3tjBGAt1zoRFUWk5ZgCR5iDbRdujq032gIyc5CxtP3w+N/cfDKcEwmUd1j
MTX680NODq3K1ACIz+odEd1O6VFTQjHPZdF2SEtI5eHZRNH3RcccwZUJ7S04Fic=
=CHiQ
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it
2015-06-30 16:15 ` Venzen Khaosan
@ 2015-06-30 16:25 ` Peter Todd
2015-06-30 16:35 ` Michael Naber
0 siblings, 1 reply; 6+ messages in thread
From: Peter Todd @ 2015-06-30 16:25 UTC (permalink / raw)
To: Venzen Khaosan; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 769 bytes --]
On Tue, Jun 30, 2015 at 11:15:31PM +0700, Venzen Khaosan wrote:
> > Do what's best for Bitcoin and define what needs to get done to
> > agree to a simple block size increase to a static 8MB.
>
> And this then leads back to the core issue: if an 8MB blocksize
> excludes many on this list from testnet, then the proposed 8MB blocks
> will exclude a lot of mainnet participants (miners) and degrade the
> quality of diversity and decentralization.
>
> How about testing at double the capacity: 2MB?
Which of course raises another issue: if that was the plan, then all you
can do is double capacity, with no clear way to scaling beyond that.
Why bother?
--
'peter'[:-1]@petertodd.org
00000000000000001599522de3e8ed28f0189ddccfa1d6db5eb380cacffc79d7
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it
2015-06-30 16:25 ` Peter Todd
@ 2015-06-30 16:35 ` Michael Naber
2015-06-30 19:59 ` Bryan Cheng
0 siblings, 1 reply; 6+ messages in thread
From: Michael Naber @ 2015-06-30 16:35 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]
Re: Why bother doubling capacity? So that we could have 2x more network
participants of course.
Re: No clear way to scaling beyond that: Computers are getting more capable
aren't they? We'll increase capacity along with hardware.
It's a good thing to scale the network if technology permits it. How can
you argue with that?
On Tue, Jun 30, 2015 at 12:25 PM, Peter Todd <pete@petertodd•org> wrote:
> On Tue, Jun 30, 2015 at 11:15:31PM +0700, Venzen Khaosan wrote:
> > > Do what's best for Bitcoin and define what needs to get done to
> > > agree to a simple block size increase to a static 8MB.
> >
> > And this then leads back to the core issue: if an 8MB blocksize
> > excludes many on this list from testnet, then the proposed 8MB blocks
> > will exclude a lot of mainnet participants (miners) and degrade the
> > quality of diversity and decentralization.
> >
> > How about testing at double the capacity: 2MB?
>
> Which of course raises another issue: if that was the plan, then all you
> can do is double capacity, with no clear way to scaling beyond that.
> Why bother?
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000001599522de3e8ed28f0189ddccfa1d6db5eb380cacffc79d7
>
[-- Attachment #2: Type: text/html, Size: 1880 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it
2015-06-30 16:35 ` Michael Naber
@ 2015-06-30 19:59 ` Bryan Cheng
0 siblings, 0 replies; 6+ messages in thread
From: Bryan Cheng @ 2015-06-30 19:59 UTC (permalink / raw)
To: Michael Naber; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3913 bytes --]
One thing that seems to have been forgotten is that the 1MB block size does
not represent any particular rigorous design choice; it is purely arbitrary.
It does not represent any type of technical sweet-spot; it neither falls
under any reasonable MTU to prevent TCP fragmentation, nor does it
guarantee in any unique way ease of transmission or lower latency. Chinese
mining pool operators, noted as one of the more constrained stakeholders in
this decision, have indicated that 8MB is a reasonable compromise in their
situation. Unless individuals with specific, concrete use cases come
forward with exactly how they will be marginalized by blocks in the 1-8MB
range, we should consider 8MB the minimum applicable size for technical
objections to raising the block size from a network propagation point of
view.
It also does not represent any kind of economic sweet spot. If we accept
the arguments on the mailing list that economic incentives for the creation
of the fee market depend entirely on a single variable, the scarcity of
space for transactions in a block, we should be talking about _decreasing_
the block size. In reality, this is clearly laughable. The real economic
analysis would consist of a balance between the space for transactions in a
block, the number of transactions being attempted at any given time, and
the block subsidy, among many other factors. Viewing it in this light, the
chance that 1MB by some divine miracle is the perfect balance of those
economic considerations becomes exceedingly small.
(Personally, I believe that increasing the block size has a greater chance
of creating a fee market after coinbase subsidies decline, as having
competition for space in a block depends not only on the number of
transactions that fit in the block, but also the number of people
attempting to spend; if success rates fall dramatically, significantly
fewer people will attempt to transact bitcoin. However, this is a
discussion for another post).
If we stop considering 1MB to be some magic number, perhaps we can enter
into a real discussion about finding what the right sweet spot is. We very
well may decide that 1MB is _too big_; what should not be acceptable is
conflating pressures to decrease the block size with reasons for inaction
altogether. The end game of this debate should be to decide the new block
size that balances, within reason, the various pressures in every direction.
On Tue, Jun 30, 2015 at 9:35 AM, Michael Naber <mickeybob@gmail•com> wrote:
> Re: Why bother doubling capacity? So that we could have 2x more network
> participants of course.
>
> Re: No clear way to scaling beyond that: Computers are getting more
> capable aren't they? We'll increase capacity along with hardware.
>
> It's a good thing to scale the network if technology permits it. How can
> you argue with that?
>
>
> On Tue, Jun 30, 2015 at 12:25 PM, Peter Todd <pete@petertodd•org> wrote:
>
>> On Tue, Jun 30, 2015 at 11:15:31PM +0700, Venzen Khaosan wrote:
>> > > Do what's best for Bitcoin and define what needs to get done to
>> > > agree to a simple block size increase to a static 8MB.
>> >
>> > And this then leads back to the core issue: if an 8MB blocksize
>> > excludes many on this list from testnet, then the proposed 8MB blocks
>> > will exclude a lot of mainnet participants (miners) and degrade the
>> > quality of diversity and decentralization.
>> >
>> > How about testing at double the capacity: 2MB?
>>
>> Which of course raises another issue: if that was the plan, then all you
>> can do is double capacity, with no clear way to scaling beyond that.
>> Why bother?
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 00000000000000001599522de3e8ed28f0189ddccfa1d6db5eb380cacffc79d7
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 5164 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-06-30 19:59 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-30 15:34 [bitcoin-dev] Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it Michael Naber
2015-06-30 16:03 ` Richard Moore
2015-06-30 16:15 ` Venzen Khaosan
2015-06-30 16:25 ` Peter Todd
2015-06-30 16:35 ` Michael Naber
2015-06-30 19:59 ` Bryan Cheng
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox