public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Michael Naber <mickeybob@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>,
	Peter Todd <pete@petertodd.org>,
	 Adam Back <adam@cypherspace.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
Date: Sun, 28 Jun 2015 17:23:51 -0400	[thread overview]
Message-ID: <CALgxB7uuC0NbQnAVLqypF6OdZ-ETJVGn5T6FGMfuB2f=zR0VnA@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T3Xhu4n3LzjEjanbAnUr5UeG0DzY7HXchfOvEa+BNqakw@mail.gmail.com>

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

Bitcoin Core exists to solve the global consensus problem. Global network
consensus means that there is global network recognition that a particular
transaction has occurred and is irreversible. Systems like hub-and-spoke,
payment channels, Lightning, etc. are useful, but they are not solutions to
the global consensus problem, because they do not meet this definition of
global consensus.

Let us focus our efforts on the goal of making Bitcoin Core the best
solution to the global consensus problem. Let us address Peter Todd’s
requirements to raise the block size limit to 8MB:

1) Run a successful test-net with 8MB blocks and show that the network
works and small miners are not unduly disadvantaged

2) Address Peter Todd's concern: “without scarcity of blockchain space
there is no reason to think that transaction fees won’t fall to the
marginal cost of including a transaction, which doesn’t leave anything to
pay for proof-of-work security”

Regarding 1: This is not done yet, though it seems reasonable enough to do.

Regarding 2: It is a fallacy to believe that artificially constraining
capacity of Bitcoin Core below the limits of technology will lead to
increased fees and therefore lead to sufficient security in the far-future.
Constraining capacity below the limits of technology will ultimately only
drive users seeking global consensus to solutions other than Bitcoin Core,
perhaps through a fork.

Demand for user access to high-capacity global consensus is real, and the
technology exists to deliver it; if we don't meet that demand in Bitcoin
Core, it's inevitably going to get met through some other product. Let's
not let that happen. Let's keep Bitcoin Core the best solution to the
global consensus problem.

Thoughts? Is there anything else not mentioned above which anyone would
like done in order to raise the block size to a static 8 MB?

On Sun, Jun 28, 2015 at 5:05 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:

> On Sun, Jun 28, 2015 at 2:58 PM, Adam Back <adam@cypherspace.org> wrote:
>
>> This is probably going to sound impolite, but I think it's pertinent.
>>
>> Gavin, on dwelling on the the fact that you appear to not understand
>> the basics of the lightning network, I am a little alarmed about this
>
>
> If I don't see how switching from using the thousands of fully-validating
> bitcoin nodes with (tens? hundreds?) of Lightning Network hubs is better in
> terms of decentralization (or security, in terms of Sybil/DoS attacks),
> then I doubt other people do, either. You need to do a better job of
> explaining it.
>
> But even if you could convince me that it WAS better from a
> security/decentralization point of view:
>
> a) Lightning Network is nothing but a whitepaper right now. We are a long
> way from a practical implementation supported by even one wallet.
>
> b) The Lightning Network paper itself says bigger blocks will be needed
> even if (especially if!) Lightning is wildly successful.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

  reply	other threads:[~2015-06-28 21:23 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-28  5:34 [bitcoin-dev] A Proposed Compromise to the Block Size Limit Raystonn
2015-06-28 10:07 ` Adam Back
2015-06-28 10:29   ` Benjamin
2015-06-28 12:37     ` Adam Back
2015-06-28 16:32       ` Raystonn .
2015-06-28 17:12         ` Mark Friedenbach
2015-06-28 17:18           ` Benjamin
2015-06-28 17:29           ` Gavin Andresen
2015-06-28 17:45             ` Mark Friedenbach
2015-06-28 17:51             ` Adam Back
2015-06-28 18:58               ` Adam Back
2015-06-28 21:05                 ` Gavin Andresen
2015-06-28 21:23                   ` Michael Naber [this message]
2015-06-28 22:07                   ` Adam Back
2015-06-29  0:59                     ` Eric Lombrozo
2015-06-29  1:13                     ` Eric Lombrozo
2015-06-29  1:45                     ` Andy Schroder
2015-06-30  0:42                     ` Tom Harding
2015-07-10  2:55                 ` Tom Harding
2015-06-28 17:53             ` Jorge Timón
2015-06-28 19:22             ` Andrew Lapp
2015-06-28 19:40               ` Benjamin
2015-06-28 12:32   ` Milly Bitcoin
  -- strict thread matches above, loose matches on Subject: below --
2015-06-27 14:39 Michael Naber
2015-06-27 15:21 ` Peter Todd
2015-06-27 15:29   ` Randi Joseph
2015-06-27 15:32     ` Peter Todd
2015-06-27 16:19   ` Michael Naber
2015-06-27 17:20     ` Peter Todd
2015-06-27 17:26       ` Benjamin
2015-06-27 17:37         ` Peter Todd
2015-06-27 17:46           ` Benjamin
2015-06-27 17:54             ` Peter Todd
2015-06-27 17:58               ` Venzen Khaosan
2015-06-27 19:34               ` Benjamin
2015-06-27 15:33 ` Adam Back
2015-06-27 16:09   ` Michael Naber
2015-06-27 16:28     ` Mark Friedenbach
2015-06-27 16:37     ` Peter Todd
2015-06-27 17:25       ` Michael Naber
2015-06-27 17:34         ` Peter Todd
2015-06-27 18:02           ` Jameson Lopp
2015-06-27 18:47             ` Peter Todd

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='CALgxB7uuC0NbQnAVLqypF6OdZ-ETJVGn5T6FGMfuB2f=zR0VnA@mail.gmail.com' \
    --to=mickeybob@gmail.com \
    --cc=adam@cypherspace.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gavinandresen@gmail.com \
    --cc=pete@petertodd.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