public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Will Madden <will.madden@bridge21inc.com>
To: Oliver Egginger <bitcoin@olivere.de>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Core Devs : can you share your thoughts about all BIPs on this website ?
Date: Fri, 21 Aug 2015 12:07:56 -0600	[thread overview]
Message-ID: <ABDE1ED5-F181-4F16-8210-4FAF80DD750C@bridge21inc.com> (raw)
In-Reply-To: <55D7606F.3050501@olivere.de>

I’m replying all just because my point was changed in your response.

> As a protocol Bitcoin could support millions of full nodes. What you
> talking about is the number of shareholders. But these are poorly
> determined by the block size. The number of shareholders is determined
> by many parameter but manly by the decreasing-supply algorithm. Which
> "was chosen because it approximates the rate at which commodities like
> gold are mined". See: https://en.bitcoin.it/wiki/Controlled_supply


  I am not talking about "shareholders” who own bitcoin, or the supply of bitcoin at all.  I’m talking about active users of bitcoin.  I don’t care if they send 10,000 BTC, or .01 BTC, usage is adoption.  Putting a 1MB cap on block size caps transaction volume, which by definition blocks adoption and use.  

> While the decreasing-supply algorithm of Bitcoin has many advantage it's
> very hard to believe that the block chain will ever reach mass adoption.
> Even after 6 years, hardly anyone owns Bitcoins. Like Gold Bitcoin is
> distributed in large blocks to a few. Exceptions prove the rule. In the
> last 6 years the 1MB limit has been sufficient. I don't think that we
> will hit the 8MB limit in the next 6 years, except for stress tests and
> spam.


You can think what you like, but I find your position on this specious.  You don’t know if we will hit that limit in the next 6 years.  All it takes is one moderately successful application and we could be hitting that limit with very little warning.  It could be open bazaar, or something else.  Stating that “even after 6 years, hardly anyone owns Bitcoins.” as a justification that it will stay small doesn’t hold water either in terms of common sense or when looking at other standards evolving through history.  TCP/IP was declared as a standard by the US Military in 1982 and became a public standard in 1985.  Normal people didn’t start using TCP/IP until much later, when Mark Andreessen created the Mosaic internet browser, the precursor to Netscape.  It was released in 1993.  Widespread use didn’t really kick in until the second half of that decade.  The reference bitcoin client was released in January 2009.  So it’s basically 1988 for bitcoin, if we use the internet as a proxy - one way to look at it.  The telephone even took 50 years to become widespread. 

> I don't think that a relative tight block size could harm Bitcoin
> middle-term. Only experienced users penetrate the block chain directly.
> They know what they are doing and deal with problems. When space for
> transactions starts to become scarce and the fees rise too much, the
> developers have enough time to make a change. It would then also not so
> controversial. A matter of a few days or weeks. Especially if all
> necessary preparations have already been taken.


This is insane.  You actually believe this?  Capping the block size at 1MB doesn’t just cause fees to rise.  It caps transactions that can be performed.  This caps the number of users who can access bitcoin, directly cuts demand, which kills the price, which kills the mining, and BAM Rome falls.  Only experienced users can “penetrate’ the block chain directly?  Seriously?  You download a software application, or sign up for a web wallet, buy some bitcoin on an exchange or have a friend send you some, and send it.  Try bread wallet.  My mom can do it.  She is in her 70’s and couldn’t program a VCR 20 years ago.

I am just going to stop here.  I really hope you change the way you are looking at bitcoin.  This is not what it was meant to be, and if it ever becomes this, I’m not going to be interested in it.

> On Aug 21, 2015, at 11:31 AM, Oliver Egginger <bitcoin@olivere.de> wrote:
> 
> Am 21.08.2015 um 15:34 schrieb Will Madden:
>> Keeping the block size at 1mb restricts the number of active users of bitcoin to around 100,000 people transacting twice a day on blockchain.  
>> BItcoin is a protocol.  Protocols are successful because of their network effect.  Capping the block size freezes bitcoin’s network effect, limits users and prevents new users from joining (which will cut demand to exchange bitcoin) and also freeze the economic incentive to mine, because it will hurt the price.  
> 
> As a protocol Bitcoin could support millions of full nodes. What you
> talking about is the number of shareholders. But these are poorly
> determined by the block size. The number of shareholders is determined
> by many parameter but manly by the decreasing-supply algorithm. Which
> "was chosen because it approximates the rate at which commodities like
> gold are mined". See: https://en.bitcoin.it/wiki/Controlled_supply
> 
> While the decreasing-supply algorithm of Bitcoin has many advantage it's
> very hard to believe that the block chain will ever reach mass adoption.
> Even after 6 years, hardly anyone owns Bitcoins. Like Gold Bitcoin is
> distributed in large blocks to a few. Exceptions prove the rule. In the
> last 6 years the 1MB limit has been sufficient. I don't think that we
> will hit the 8MB limit in the next 6 years, except for stress tests and
> spam.
> 
>> Freezing bitcoin’s growth for any meaningful length of time will
>> threaten its position as the leading cryptocurrency.
> 
> I don't think that a relative tight block size could harm Bitcoin
> middle-term. Only experienced users penetrate the block chain directly.
> They know what they are doing and deal with problems. When space for
> transactions starts to become scarce and the fees rise too much, the
> developers have enough time to make a change. It would then also not so
> controversial. A matter of a few days or weeks. Especially if all
> necessary preparations have already been taken.
> 
> But I know that my opinion is very different from other claims. However,
> reliable people share some more fatalism as I'm currently find in some
> parts of the the Bitcoin community. Fear is a very bad adviser and can
> make a genius stupid.
> 
> - oliver
> 



  reply	other threads:[~2015-08-21 18:08 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-19  4:57 [bitcoin-dev] Core Devs : can you share your thoughts about all BIPs on this website ? Nicolas Dorier
2015-08-21  3:10 ` Btc Drak
2015-08-21  4:45 ` Gregory Maxwell
2015-08-21  5:10   ` Nicolas Dorier
2015-08-21  9:09     ` Btc Drak
2015-08-21  9:32       ` Peter Todd
2015-08-21  9:29   ` Peter Todd
2015-08-21  9:31     ` Btc Drak
2015-08-21  9:35       ` Peter Todd
2015-08-21 10:55         ` Yifu Guo
2015-08-21 11:28           ` Btc Drak
2015-08-21 12:28             ` Yifu Guo
2015-08-21 13:18               ` Oliver Egginger
2015-08-21 13:34                 ` Will Madden
2015-08-21 17:31                   ` Oliver Egginger
2015-08-21 18:07                     ` Will Madden [this message]
2015-08-22  3:02             ` odinn
2015-08-21 16:58         ` Nicolas Dorier
2015-08-21  3:38 Nicolas Dorier
2015-08-21  3:45 ` Eric Lombrozo
2015-08-21  3:54   ` Nicolas Dorier

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=ABDE1ED5-F181-4F16-8210-4FAF80DD750C@bridge21inc.com \
    --to=will.madden@bridge21inc.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=bitcoin@olivere.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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