From: Eric Lombrozo <elombrozo@gmail.com>
To: Owen Gunden <ogunden@phauna.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] The need for larger blocks
Date: Fri, 26 Jun 2015 19:54:37 -0700 [thread overview]
Message-ID: <2C8D5EFF-AB1E-4003-A264-707CAF7CA1F4@gmail.com> (raw)
In-Reply-To: <2107342B-1D9E-4575-B7E4-3B69D51B1A17@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4882 bytes --]
I should add that a strategy of “let’s avoid fee pressure as much as possible. let’s avoid even thinking about how we’ll transition as much as possible.” strikes me as at least a tad bit myopic.
- Eric Lombrozo
> On Jun 26, 2015, at 7:18 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:
>
> I’ve been pondering this whole scale issue considerably…and am left with the conclusion that blockchains are ultimately dispute resolution mechanisms. The vast majority of crypto negotiation will be taking place at levels lesser than global consensus in the future - global consensus is just far too expensive to require for every single cappuccino. There really is little need to take most cases globally…unless the participants disagree. I’ve commented in other places that blockchains are essentially a “fix” to the prisoner’s dilemma - they make cooperation the equilibrium strategy.
>
> Regardless of whatever linear factor we scale the blockchain by, it is simple math to see that any exponential growth (even if for a short time) in usage will overwhelm the current network. If we ever intend to take bitcoin mainstream, we will most likely experience at least a short time of exponential growth…at least until we either reach an inherent limitation or until we saturate. As Pieter said earlier, FAPP right now the demand for payments might as well be infinite. We’re nowhere near the ability to service it all.
>
> The block size issue is really a usability issue at this point. There are two fundamental things we need to solve:
>
> 1) There’s no model for how we’ll introduce a fee market, even though the design of Bitcoin fundamentally depends on fees for its survival (at least in the current form of the design.)
>
> 2) There’s no mechanism for how to perform fee bidding and estimation. Most wallets simply have no way to do this without serious usability problems.
>
>
>
> If we’re going to talk about block fees, let’s keep it in the context of these relevant issues and not confound it with the scalability issue…these are two very different issues.
>
>
> - Eric Lombrozo
>
>
>> On Jun 26, 2015, at 1:44 PM, Owen Gunden <ogunden@phauna.org> wrote:
>>
>> On 06/26/2015 02:23 PM, Jeff Garzik wrote:
>>> Failure to plan now for a hard fork increase 6(?) months in the future
>>> produces that lumpy, unpredictable market behavior.
>>>
>>> The market has baked in the years-long behavior of low fees. From the
>>> market PoV, inaction does lead to precisely that, a sudden change over
>>> the span of a few months.
>>
>> Which market participants are you referring to?
>>
>> I entered the bitcoin market with open eyes, aware that it faces hard scalability challenges by design. I was also aware that because of these challenges, eventually transaction fees would have to rise.
>>
>> Nevertheless, I made the decision to invest because of the utility I gain from the anti-censorship, privacy, control, store of value, and security aspects of bitcoin -- many of which stem from decentralization, which others have demonstrated to be linked to the block size.
>>
>> On the other hand, there are undoubtedly other market participants who heard hype about "zero fee transactions to anywhere in the world", believed it would scale, and made (mal)investments as a result.
>>
>> As for how many market participants of each flavor, and how deep their respective pockets, who knows? My experience in markets has lead me to realize that it's never wise to assume I know what "the market" does and doesn't know. If Jeff Garzik is right about what the market has priced in, then yes, filled blocks will be rocking the boat. But who's to say that the smartest, biggest investors and traders don't already see this scaling problem, and have already priced it in? In this case, a sudden large increase in the block size is actually rocking the boat. The point is, you can't know either way, so trying to pre-empt the market in this way is erroneous.
>>
>> Regarding entrepreneurial investment specifically, why should we favor the entrepreneurs who require a more centralized bitcoin over those who were more considerate of the possibility of rising transaction fees when making their business models?
>>
>> In my mind, we should favor neither, which is why I'm basically in agreement with Pieter that this sense of "emergency" shouldn't really be a part of the debate.
>>
>> Not that I'm taking a stand on the specific block size issue either way. I just think this particular line of reasoning (presupposing what information the market has and has not already baked in) is unsound.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
next prev parent reply other threads:[~2015-06-27 2:54 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-26 14:09 [bitcoin-dev] The need for larger blocks Pieter Wuille
2015-06-26 14:38 ` Venzen Khaosan
2015-06-26 15:22 ` Milly Bitcoin
2015-06-26 15:24 ` Pieter Wuille
2015-06-26 18:05 ` Jeff Garzik
2015-06-26 18:32 ` Milly Bitcoin
2015-06-26 15:38 ` Tom Harding
2015-06-26 16:22 ` Venzen Khaosan
2015-06-26 17:04 ` Tom Harding
2015-06-26 17:55 ` Gavin Andresen
2015-06-26 17:57 ` Jeff Garzik
2015-06-26 18:12 ` Pieter Wuille
2015-06-26 18:23 ` Jeff Garzik
2015-06-26 18:31 ` Mark Friedenbach
2015-06-26 19:05 ` Aaron Voisine
2015-06-26 18:34 ` Pieter Wuille
2015-06-26 19:18 ` Ross Nicoll
2015-06-26 19:36 ` Peter Todd
2015-06-27 6:13 ` Filipe Farinha
2015-06-27 7:14 ` Aaron Voisine
2015-06-27 15:13 ` Peter Todd
2015-06-27 19:40 ` Aaron Voisine
2015-06-26 18:47 ` Patrick Strateman
2015-06-26 19:03 ` Tier Nolan
2015-06-26 19:12 ` Mark Friedenbach
2015-06-26 20:44 ` Owen Gunden
2015-06-27 2:18 ` Eric Lombrozo
2015-06-27 2:54 ` Eric Lombrozo [this message]
2015-06-27 8:16 ` Venzen Khaosan
2015-06-26 18:29 ` Alex Morcos
2015-06-27 7:43 ` Wladimir J. van der Laan
2015-06-27 9:55 ` NxtChg
2015-06-27 10:04 ` Wladimir J. van der Laan
2015-06-27 10:29 ` NxtChg
2015-06-27 11:04 ` Jorge Timón
2015-06-27 11:18 ` Eric Lombrozo
2015-06-27 11:43 ` Jorge Timón
2015-06-27 12:10 ` NxtChg
2015-06-28 12:13 ` Jorge Timón
2015-06-28 13:51 ` Ivan Brightly
2015-06-28 14:13 ` Eric Lombrozo
2015-06-28 14:16 ` Eric Lombrozo
2015-06-28 14:22 ` Ivan Brightly
2015-06-28 15:05 ` Jorge Timón
2015-06-28 16:01 ` Ivan Brightly
2015-06-28 15:28 ` s7r
2015-06-28 15:45 ` Jorge Timón
2015-06-27 10:19 ` Venzen Khaosan
2015-06-27 19:55 ` Aaron Voisine
2015-06-28 16:37 ` Venzen Khaosan
2015-06-28 20:56 ` Aaron Voisine
2015-06-27 10:13 ` Jorge Timón
2015-06-27 12:09 ` Wladimir J. van der Laan
2015-06-27 12:15 ` NxtChg
2015-06-27 12:17 ` Greg Sanders
2015-06-27 12:25 ` NxtChg
2015-06-27 12:35 ` Greg Sanders
2015-06-27 12:25 ` Wladimir J. van der Laan
2015-06-27 12:50 ` NxtChg
2015-06-27 13:01 ` Wladimir J. van der Laan
2015-06-28 12:03 ` Jorge Timón
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=2C8D5EFF-AB1E-4003-A264-707CAF7CA1F4@gmail.com \
--to=elombrozo@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=ogunden@phauna.org \
/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