From: Andrew Johnson <andrew.johnson83@gmail•com>
To: Luke Dashjr <luke@dashjr•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
Date: Fri, 27 Jan 2017 00:13:34 -0600 [thread overview]
Message-ID: <CAAy62_LeNi1djDmArX0RWW=rD0GJU9eSqCy0o4G9eg3Y7O+0Wg@mail.gmail.com> (raw)
In-Reply-To: <CAAy62_LHtrx7k73kznMpPvheA--0T9YiHkjHArf2KK0Qt+ViUg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3283 bytes --]
On Jan 26, 2017 10:15 PM, "Luke Dashjr" <luke@dashjr•org> wrote:
On Friday, January 27, 2017 3:04:50 AM Andrew Johnson wrote:
> Comment on #1. You're dropping the blocksize limit to 300KB and only
> reaching the limit that we have in place today 7 years later?
The limit only drops all the way to 300k if it activates before 2017 April.
Considering that this requires the consensus of a hardfork, followed by a
release in software, and then actual activation by miners using BIP9, I
think
it's extremely unlikely to activate by then.
But more importantly: such a drop would probably be good for the network in
the long-term. As explained in the Rationale section, 300k is necessary to
maintain our *current* IBD (first-time node sync) costs even with
technological improvements (which appear to be slowing lately).
Other researchers have come to the conservative conclusion that we could
handle 4MB blocks today. Imagine bitcoin had been invented in 1987 and had
a block size correspondent to the internet connections and hard drive sizes
of the day. Your proposal would have probably brought us from 1Kb(then
reduced to 300 bytes) and up to a whopping 20Kb or so today. Yet even you
think we can handle 15x that today.
You drastically underestimate the speed of technological progression, and
seem to fancy yourself the central planner of bitcoin. Isn't that one of
the things we're trying to get away from, centrally planned economics?
> We're already at capacity today, surely you're not serious with this
> proposal?
We are only at capacity because the space is available below actual costs,
and/or because efficient alternatives are not yet widely supported. A
reduction of block size will likely squeeze out spam, and perhaps some
unsustainable microtransaction use, but the volume which actually *benefits
from* the blockchain's security should continue along fine. Furthermore,
once
Lightning is widely implemented as well-tested, at least microtransactions
are
likely to gain a huge improvement in efficiency, reducing legitimate usage
of
block sizes well below 300k naturally - that is frankly when I first expect
this proposal to be seriously considered for activation (which is
independent
from the consensus to include support for it in nodes).
Legitimate usage is a transaction that pays the appropriate fee to be
included. The term legitimate transaction should be stricken from one's
vocabulary when describing a censorship resistant system such as bitcoin.
> When you promised code for a hard forking block size increase in the HK
> agreement I don't believe that a decrease first was made apparent. While
> not technically in violation of the letter of the agreement, I think this
> is a pretty obviously not in the spirit of it.
I did not mention the HK "roundtable", because this is indeed not in the
spirit of what we set out to do, and do not wish this to be interpreted as
some kind of slap in the face of the honest participants of that discussion.
Too late for that, I suspect.
This proposal is, however, the best I am currently able to honestly
recommend
that meets the hard criteria outlined at Hong Kong a year ago. (Continued
work
on the MMHF/SHF concept may eventually deliver a better solution, but it is
not yet ready.)
Luke
[-- Attachment #2: Type: text/html, Size: 4764 bytes --]
next prev parent reply other threads:[~2017-01-27 6:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-27 1:06 Luke Dashjr
[not found] ` <CAAy62_L-mLhokVy4_WeLBVnxM0Y76dtFBaaDrRvQozxw=J1Ctw@mail.gmail.com>
[not found] ` <CAAy62_+1OjF3V5g4wpOyW0KtNGodddJu_cxOfG-f+8LB7D=rPA@mail.gmail.com>
2017-01-27 3:04 ` Andrew Johnson
2017-01-27 4:14 ` Luke Dashjr
[not found] ` <CAAy62_LHtrx7k73kznMpPvheA--0T9YiHkjHArf2KK0Qt+ViUg@mail.gmail.com>
2017-01-27 6:13 ` Andrew Johnson [this message]
[not found] ` <CAMZUoKnxqxvPQehdWo1ZaHB-1-od4cHvJRDTmF5x7ty1CdLbUQ@mail.gmail.com>
[not found] ` <CAMZUoK=eb3jgA7Rwt38tvZt0tYk7gRVPc_2=HUWg1L_vaD93uw@mail.gmail.com>
2017-01-27 20:34 ` Russell O'Connor
2017-01-27 20:47 ` Greg Sanders
2017-01-27 21:28 ` Christian Decker
2017-01-27 23:53 ` Andrew Johnson
2017-01-28 4:03 ` Luke Dashjr
2017-01-28 10:36 ` Natanael
2017-01-28 18:29 ` Peter Todd
2017-01-29 19:15 ` Tom Harding
2017-01-29 19:37 ` Eric Voskuil
2017-02-11 15:26 ` Staf Verhaegen
2017-01-29 19:39 ` David Vorick
2017-01-28 19:43 ` Luke Dashjr
2017-01-28 21:54 ` Peter Todd
2017-02-06 16:24 ` mbtc-dev
2017-02-07 20:32 ` Eric Voskuil
2017-01-28 18:22 ` Peter Todd
2017-01-27 4:21 ` Johnson Lau
2017-01-27 18:54 ` t. khan
2017-01-27 12:12 Daniele Pinna
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='CAAy62_LeNi1djDmArX0RWW=rD0GJU9eSqCy0o4G9eg3Y7O+0Wg@mail.gmail.com' \
--to=andrew.johnson83@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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