From: jl2012 <jl2012@xbt•hk>
To: Jeff Garzik <jgarzik@gmail•com>
Cc: Bitcoin development mailing list <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard
Date: Wed, 16 Dec 2015 13:36:00 -0500 [thread overview]
Message-ID: <9a02d94fbc78afaa3e9668e0294eef64@xbt.hk> (raw)
In-Reply-To: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
I would also like to summarize my observation and thoughts after the
Hong Kong workshop.
1. I'm so glad that I had this opportunity to meet so many smart
developers who are dedicated to make Bitcoin better. Regular conference
like this is very important for a young project, and it is particularly
important for Bitcoin, with consensus as the core value. I hope such a
conference could be conducted at least once in 2 years in Hong Kong,
which is visa-friendly for most people in both East and West.
2. I think some consensus has emerged at/after the conference. There is
no doubt that segregated witness will be implemented. For block size, I
believe 2MB as the first step is accepted by the super majority of
miners, and is generally acceptable / tolerable for devs.
3. Chinese miners are requesting consensus among devs nicely, instead of
using their majority hashing power to threaten the community. However,
if I were allowed to speak for them, I think 2MB is what they really
want, and they believe it is for the best interest of themselves and the
whole community
4. In the miners round table on the second day, one of the devs
mentioned that he didn't want to be seen as the decision maker of
Bitcoin. On the other hand, Chinese miners repeatedly mentioned that
they want several concrete proposals from devs which they could choose.
I see no contradiction between these 2 viewpoints.
Below are some of my personal views:
5. Are we going to have a "Fee Event" / "Economic Change Event" in 2-6
months as Jeff mentioned? Frankly speaking I don't know. As the fee
starts to increase, spammers will first get squeezed --- which could be
a good thing. However, I have no idea how many txs on the blockchain are
spam. We also need to consider the effect of halving in July, which may
lead to speculation bubble and huge legitimate tx volume.
6. I believe we should avoid a radical "Economic Change Event" at least
in the next halving cycle, as Bitcoin was designed to bootstrap the
adoption by high mining reward in the beginning. For this reason, I
support an early and conservative increase, such as BIP102 or 2-4-8. 2MB
is accepted by most people and it's better than nothing for BIP101
proponents. By "early" I mean to be effective by May, at least 2 months
before the halving.
7. Segregated witness must be done. However, it can't replace a
short-term block size hardfork for the following reasons:
(a) SW softfork does not allow higher volume if users are not upgrading.
In order to bootstrap the new tx type, we may need the help of
altruistic miners to provide a fee discount for SW tx.
(b) In terms of block space saving, SW softfork is most efficient for
multisig tx, which is still very uncommon
(c) My most optimistic guess is SW will be ready in 6 months, which will
be very close to halving and potential tx volume burst. And it may not
be done in 2016, as it does not only involve consensus code, but also
change in the p2p protocol and wallet design
8. Duplex payment channel / Lightning Network may be viable solutions.
However, they won't be fully functional until SW is done so they are
irrelevant in this discussion
9. No matter what is going to be done / not done, I believe we should
now have a clear road map and schedule for the community: a short-term
hardfork or not? The timeline of SW? It is bad to leave everything
uncertain and people can't well prepared for any potential radical
changes
10. Finally, I hope this discussion remains educated and evidence-based,
and no circling
next prev parent reply other threads:[~2015-12-16 18:36 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 14:53 Jeff Garzik
2015-12-16 18:34 ` Pieter Wuille
2015-12-16 21:08 ` Jeff Garzik
2015-12-16 21:11 ` Pieter Wuille
2015-12-17 2:06 ` Jameson Lopp
2015-12-17 16:58 ` Tier Nolan
2015-12-17 19:44 ` Peter Todd
2015-12-18 5:23 ` Jorge Timón
2015-12-18 9:44 ` Tier Nolan
2015-12-16 21:24 ` Jorge Timón
2015-12-16 21:36 ` Jeff Garzik
2015-12-18 5:11 ` Jeff Garzik
2015-12-18 7:56 ` Pieter Wuille
2015-12-18 10:13 ` sickpig
2015-12-18 15:48 ` Pieter Wuille
2015-12-19 19:04 ` Dave Scotese
[not found] ` <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com>
2015-12-26 16:44 ` Pieter Wuille
2015-12-26 17:20 ` Jorge Timón
2015-12-26 22:55 ` Jonathan Toomim
2015-12-26 23:01 ` Pieter Wuille
2015-12-26 23:07 ` Jonathan Toomim
2015-12-26 23:16 ` Pieter Wuille
2015-12-27 0:03 ` Jonathan Toomim
2015-12-26 23:15 ` Justus Ranvier
2015-12-27 0:13 ` Bryan Bishop
2015-12-27 0:33 ` Justus Ranvier
2015-12-18 13:56 ` Jeff Garzik
2015-12-23 6:26 ` Aaron Voisine
2015-12-16 18:36 ` jl2012 [this message]
2015-12-16 22:27 ` Jeff Garzik
2015-12-17 6:12 ` Dave Scotese
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=9a02d94fbc78afaa3e9668e0294eef64@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jgarzik@gmail$(echo .)com \
/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