public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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


  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 [bitcoin-dev] Block size: It's economics & user preparation & moral hazard 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.hk \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jgarzik@gmail.com \
    /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