public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Adam Back <adam@cypherspace.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] comments on BIP 100
Date: Sun, 14 Jun 2015 23:23:55 +0200	[thread overview]
Message-ID: <CALqxMTHrnSS9MGgKO-5+=fVhiOOvk12Recs11S0PcSUxQT1wdQ@mail.gmail.com> (raw)

Hi

I made these comments elsewhere, but I think really we should be
having these kind of conversations here rather than scattered around.

These are about Jeff Garzik's outline draft BIP 100 I guess this is
the latest draft:  (One good thing about getting off SF would be
finally JGarzik's emails actually not getting blocked!).

http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf

may have changed since the original [1]

Over the original proposal:

1. there should be a hard cap, not indefinitely growing.

2. there should be  a growth limiter (no more than X%/year)

3. I think the miners should not be given a vote that has no costs to
cast, because their interests are not necessarily aligned with users
or businesses.

I think Greg Maxwell's difficulty adjust [2] is better here for that
reason.  It puts quadratic cost via higher difficulty for miners to
vote to increase block-size, which miners can profitably do if there
are transactions with fees available to justify it. There is also the
growth limiter as part of Greg's proposal. [3]

I think bitcoin will have to involve layering models that uplift
security to higher layers, but preserve security assurances, and
smart-contracts even, with protocols that improve the algorithmic
complexity beyond O(n^2) in users, like lightning, and there are
multiple other candidates with useful tradeoffs for various use-cases.

One thing that is concerning is that few in industry seem inclined to
take any development initiatives or even integrate a library.  I
suppose eventually that problem would self-correct as new startups
would make a more scalable wallet and services that are layer2 aware
and eat the lunch of the laggards.  But it will be helpful if we
expose companies to the back-pressure actually implied by an O(n^2)
scaling protocol and don't just immediately increase the block-size to
levels that are dangerous for decentralisation security, as an
interventionist subsidy to save them having to do basic integration
work.  Otherwise I think whichever any kind of kick the can some 2-5
years down the road we consider, we risk the whole saga repeating in a
few years, when no algorithmic progress has been made and even more
protocol inertia has set in.

Adam

[1] original proposal comments on reddit
https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/

[2] flexcap propoal by Greg Maxwell see post by Mark Freidenbach
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html

[3] growth limited proposal for flexcap by Greg Maxwell
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html



             reply	other threads:[~2015-06-14 21:24 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-14 21:23 Adam Back [this message]
2015-06-14 22:23 ` [Bitcoin-development] comments on BIP 100 Mike Hearn
2015-06-14 23:58   ` Adam Back
2015-06-15  0:53     ` Eric Lombrozo
2015-06-15  0:55       ` Eric Lombrozo
2015-06-15  4:11       ` Peter Todd
2015-06-15  4:43         ` Eric Lombrozo
2015-06-15  9:27     ` Mike Hearn
2015-06-15  9:39       ` Eric Lombrozo
2015-06-15 10:24       ` Pieter Wuille
2015-06-15 10:36         ` Mike Hearn
2015-06-15 10:40           ` Pieter Wuille
2015-06-15 10:50             ` Mike Hearn
2015-06-15 11:16               ` Rebroad (sourceforge)
2015-06-15 17:53                 ` Raystonn .
2015-06-15 18:14                   ` Adam Back
2015-06-15 18:57                     ` [Bitcoin-development] The Bitcoin Node Market Raystonn .
2015-06-15 19:18                       ` sickpig
2015-06-15 19:36                         ` Raystonn .
2015-06-15 20:12                           ` sickpig
2015-06-16  3:30                             ` Kevin Greene
2015-06-16  3:41                               ` Luke Dashjr
2015-06-16  3:49                                 ` Kevin Greene
2015-06-16  4:05                                   ` Kevin Greene
2015-06-16  4:12                                   ` Aaron Voisine
2015-06-16  5:28                                   ` justusranvier
2015-06-16  5:30                                     ` Potter QQ
2015-06-16  7:55                                     ` Aaron Voisine
2015-06-16 13:32                                       ` justusranvier
2015-06-16 17:04                                         ` Aaron Voisine
2015-06-16 17:22                                         ` Aaron Voisine
2015-06-16 15:52                                       ` devrandom
2015-06-15  4:43   ` [Bitcoin-development] comments on BIP 100 Peter Todd
2015-06-15  9:06     ` Mike Hearn
2015-06-15  2:28 ` Jeff Garzik
2015-06-15  2:44   ` Jeff Garzik

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='CALqxMTHrnSS9MGgKO-5+=fVhiOOvk12Recs11S0PcSUxQT1wdQ@mail.gmail.com' \
    --to=adam@cypherspace.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    /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