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
next 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 ` 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$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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