From: Jameson Lopp <jameson.lopp@gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Date: Thu, 23 Jul 2015 14:10:22 -0400 [thread overview]
Message-ID: <CADL_X_exckh5T2BfzPEp26fPR3TD69QarwroDEdS_9wtnKbf+g@mail.gmail.com> (raw)
In-Reply-To: <C5A70F53-4779-457A-A06A-686877706F89@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3366 bytes --]
On Thu, Jul 23, 2015 at 1:43 PM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I'd really like to move from "IMPOSSIBLE because... (electrum hasn't been
> optimized
> (by the way: you should run on SSDs, LevelDB isn't designed for spinning
> disks),
> what if the network is attacked? (attacked HOW???), current p2p network
> is using
> the simplest, stupidest possible block propagation algorithm...)"
>
> ... to "lets work together and work through the problems and scale it up."
>
>
> Let’s be absolutely clear about one thing - block size increases are *not*
> about scaling the network. Can we please stop promoting this falsehood? It
> doesn’t matter by what number we multiply the block size…we can NEVER
> satisfy the full demand if we insist on every single transaction from every
> single person everywhere in the world being on the blockchain…it’s just
> absurd.
>
>
Increasing block size only temporarily addresses one significant issue -
> how to postpone having to deal with transaction fees, which by design, are
> how the cost of operating the Bitcoin network (which is already very
> expensive) is supposed to be paid for ultimately. Suggesting we avoid
> dealing with this constitutes a new economic policy - dealing with it is
> the default economic policy we’ve all known about from the beginning…so
> please stop claiming otherwise.
>
>
Larger block sizes don't scale the network, they merely increase how much
load we allow the network to bear. On the flip side, the scalability
proposals will still require larger blocks if we are ever to support
anything close to resembling "mainstream" usage. This is not an either/or
proposition - we clearly need both.
- Jameson
> On Jul 23, 2015, at 9:50 AM, cipher anthem via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Why not help on a project that actually seems to offer great scalability
> like the lightning network? There have been great progress there.
>
>
> Exactly. There’s been tremendous progress here in addressing scalability,
> yet I don’t see you participating in that discussion, Gavin.
>
> On Jul 23, 2015, at 5:17 AM, Jorge Timón via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> But it seems to me that the "not now side" has no centralization
> concerns at all and their true position is "not ever hit the blocksize
> limit", that's the only explanation I can find to their lack of
> answers to the "when do you think we should allow users to notice that
> there's a limit in the blocksize to guarantee that the system can be
> decentralized?".
>
>
> I agree with what you’re saying, Jorge…but It’s even worse than that. The
> July 4th fork illustrated that the security model of the network itself
> could be at risk from the increasing costs in validation causing people to
> rely on others to validate for them…and increasing block size only makes
> the problem worse.
>
> - Eric Lombrozo
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 7136 bytes --]
next prev parent reply other threads:[~2015-07-23 18:10 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
2015-07-22 16:52 ` [bitcoin-dev] Bitcoin Core and hard forks Pieter Wuille
2015-07-22 17:18 ` Ross Nicoll
2015-07-22 17:32 ` Milly Bitcoin
2015-07-22 18:45 ` Bryan Cheng
2015-07-22 17:33 ` Jeff Garzik
2015-07-22 18:01 ` Jeff Garzik
2015-07-22 18:03 ` Alex Morcos
2015-07-22 18:24 ` Jeff Garzik
2015-07-23 12:17 ` Jorge Timón
2015-07-23 16:17 ` Tom Harding
2015-07-23 16:28 ` Gavin Andresen
2015-07-23 16:50 ` cipher anthem
2015-07-23 17:14 ` Robert Learney
2015-07-23 18:21 ` Eric Lombrozo
2015-07-23 18:47 ` Jorge Timón
2015-07-23 17:43 ` Eric Lombrozo
2015-07-23 18:10 ` Jameson Lopp [this message]
2015-07-23 19:14 ` Eric Lombrozo
2015-07-23 19:35 ` Gavin Andresen
2015-07-23 19:39 ` Eric Lombrozo
2015-07-23 19:51 ` Eric Lombrozo
2015-07-23 19:52 ` Jameson Lopp
2015-07-23 20:26 ` Jorge Timón
2015-07-23 20:52 ` Eric Lombrozo
2015-07-23 23:42 ` Benedict Chan
[not found] ` <42BF7FEB-320F-43BE-B3D9-1D76CB8B9975@gmai>
2015-07-23 23:57 ` Eric Lombrozo
2015-07-24 0:04 ` Eric Lombrozo
2015-07-24 0:20 ` Simon Liu
2015-07-24 0:22 ` Jean-Paul Kogelman
2015-07-24 0:32 ` Eric Lombrozo
2015-07-24 0:38 ` Eric Lombrozo
2015-07-24 0:45 ` Jean-Paul Kogelman
2015-07-24 0:49 ` Jean-Paul Kogelman
2015-07-24 0:53 ` Peter Todd
2015-07-24 1:03 ` Jean-Paul Kogelman
2015-07-24 1:08 ` Eric Lombrozo
2015-07-24 1:25 ` Jean-Paul Kogelman
2015-07-24 1:28 ` Eric Lombrozo
2015-07-24 1:37 ` Eric Lombrozo
2015-07-24 1:42 ` Jean-Paul Kogelman
2015-07-24 1:55 ` Eric Lombrozo
2015-07-24 2:12 ` [bitcoin-dev] Bitcoin, Perceptions, and Expectations Raystonn .
2015-07-24 8:48 ` Jonas Schnelli
2015-07-24 9:42 ` Jorge Timón
2015-07-24 14:37 ` Vincent Truong
2015-07-25 2:18 ` gb
2015-07-25 11:22 ` Slurms MacKenzie
2015-07-25 15:04 ` Thomas Kerin
2015-07-24 0:56 ` [bitcoin-dev] Bitcoin Core and hard forks Eric Lombrozo
2015-07-24 1:05 ` Jean-Paul Kogelman
2015-07-23 18:12 ` Slurms MacKenzie
2015-07-23 18:57 ` Mike Hearn
2015-07-23 17:51 ` Jorge Timón
2015-07-24 6:30 ` Tom Harding
2015-07-24 9:24 ` Jorge Timón
2015-07-24 22:50 ` Tom Harding
2015-07-28 11:29 ` Jorge Timón
2015-07-28 11:32 ` Jorge Timón
2015-07-28 16:44 ` Tom Harding
2015-07-28 17:33 ` Jorge Timón
2015-07-22 19:17 ` Eric Lombrozo
2015-07-22 21:43 ` Mike Hearn
2015-07-22 21:56 ` Eric Lombrozo
2015-07-22 22:01 ` Mike Hearn
2015-07-22 22:09 ` Eric Lombrozo
2015-07-23 1:53 ` Eric Lombrozo
2015-07-22 22:30 ` Jeff Garzik
2015-07-23 0:27 ` Tom Harding
2015-07-23 0:37 ` Eric Lombrozo
2015-07-23 4:40 ` Edmund Edgar
2015-07-27 12:08 ` Peter Todd
2015-07-27 12:44 ` Milly Bitcoin
2015-07-22 22:40 Raystonn
2015-07-22 23:42 ` Cory Fields
2015-07-22 23:53 ` Eric Lombrozo
2015-07-23 0:05 ` Cory Fields
2015-07-23 0:13 ` Eric Lombrozo
2015-07-23 0:34 ` Cory Fields
2015-07-23 0:43 ` Eric Lombrozo
2015-07-23 7:24 ` Ross Nicoll
2015-07-23 0:49 ` Eric Voskuil
2015-07-23 18:12 ` Jorge Timón
[not found] <BA7ACCE1-81B2-4AC1-B6DD-7A856FD27D52@gmail.com>
2015-07-23 8:24 ` Gareth Williams
2015-07-27 17:05 Alice Larson
2015-07-27 17:22 ` Eric Voskuil
2015-07-28 4:55 ` Wladimir J. van der Laan
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=CADL_X_exckh5T2BfzPEp26fPR3TD69QarwroDEdS_9wtnKbf+g@mail.gmail.com \
--to=jameson.lopp@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=elombrozo@gmail.com \
/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