From: Gavin Andresen <gavinandresen@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Date: Tue, 8 Dec 2015 10:12:10 -0500 [thread overview]
Message-ID: <CABsx9T1wga3Tandoe2mVGSKdHJytHoc9Ko7HRm2SvJXABEFk9w@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDpcek=u=Rpe68EMOq6M7Bji9J=s5VvoQWKRqaQDAP5kTw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]
Thanks for laying out a road-map, Greg.
I'll need to think about it some more, but just a couple of initial
reactions:
Why segwitness as a soft fork? Stuffing the segwitness merkle tree in the
coinbase is messy and will just complicate consensus-critical code (as
opposed to making the right side of the merkle tree in block.version=5
blocks the segwitness data).
It will also make any segwitness fraud proofs significantly larger (merkle
path versus merkle path to coinbase transactions, plus ENTIRE coinbase
transaction, which might be quite large, plus merkle path up to root).
We also need to fix the O(n^2) sighash problem as an additional BIP for ANY
blocksize increase. That also argues for a hard fork-- it is much easier to
fix it correctly and simplify the consensus code than to continue to apply
band-aid fixes on top of something fundamentally broken.
Segwitness will require a hard or soft-fork rollout, then a significant
fraction of the transaction-producing wallets to upgrade and start
supporting segwitness-style transactions. I think it will be much quicker
than the P2SH rollout, because the biggest transaction producers have a
strong motivation to lower their fees, and it won't require a new type of
bitcoin address to fund wallets. But it still feels like it'll be six
months to a year at the earliest before any relief from the current
problems we're seeing from blocks filling up.
Segwitness will make the current bottleneck (block propagation) a little
worse in the short term, because of the extra fraud-proof data. Benefits
well worth the costs.
------------------
I think a barrier to quickly getting consensus might be a fundamental
difference of opinion on this:
"Even without them I believe we’ll be in an acceptable position with
respect to capacity in the near term"
The heaviest users of the Bitcoin network (businesses who generate tens of
thousands of transactions per day on behalf of their customers) would
strongly disgree; the current state of affairs is NOT acceptable to them.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 2625 bytes --]
next prev parent reply other threads:[~2015-12-08 15:12 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-07 22:02 Gregory Maxwell
2015-12-07 22:54 ` Bryan Bishop
2015-12-08 2:42 ` Anthony Towns
2015-12-08 4:58 ` Anthony Towns
2015-12-08 5:21 ` Gregory Maxwell
2015-12-08 6:54 ` Anthony Towns
2016-01-18 12:02 ` Anthony Towns
2016-01-22 9:46 ` Anthony Towns
2015-12-08 11:07 ` Wladimir J. van der Laan
2015-12-08 11:14 ` Jorge Timón
2015-12-08 15:12 ` Gavin Andresen [this message]
2015-12-08 15:55 ` Justus Ranvier
2015-12-08 17:41 ` Mark Friedenbach
2015-12-08 18:43 ` Justus Ranvier
2015-12-08 19:08 ` Tier Nolan
2015-12-08 19:31 ` Gregory Maxwell
2015-12-08 23:40 ` Jonathan Toomim
2015-12-08 23:48 ` Luke Dashjr
2015-12-09 0:54 ` Jonathan Toomim
2015-12-08 23:50 ` Jorge Timón
2015-12-09 0:56 ` Jonathan Toomim
2015-12-08 23:59 ` Gregory Maxwell
2015-12-09 0:58 ` Jorge Timón
2015-12-09 1:02 ` Jorge Timón
2015-12-09 1:09 ` Gavin Andresen
2015-12-09 1:31 ` Gregory Maxwell
2015-12-09 4:44 ` Ryan Butler
2015-12-09 6:29 ` Gregory Maxwell
2015-12-09 6:36 ` Ryan Butler
2015-12-09 6:59 ` Mark Friedenbach
2015-12-09 7:17 ` Gregory Maxwell
2015-12-09 7:54 ` Jorge Timón
2015-12-09 8:03 ` Gregory Maxwell
2015-12-09 8:46 ` Mark Friedenbach
2015-12-09 11:08 ` Jorge Timón
2015-12-09 16:40 ` Gavin Andresen
2015-12-11 16:18 ` Jorge Timón
2015-12-11 16:43 ` Gavin Andresen
2015-12-12 5:13 ` digitsu
2015-12-12 15:18 ` Mark Friedenbach
2015-12-14 11:21 ` Jonathan Toomim
2015-12-14 12:44 ` Adam Back
2015-12-09 4:51 ` Anthony Towns
2015-12-09 14:51 ` Chris
[not found] ` <CAPWm=eUomq6SBC0ky0WSs5=_G942vigm4RmgYuq0O-yJ-vqC2A@mail.gmail.com>
[not found] ` <CAPg+sBig9O5+he0PWhTkX5iin14QLz5+eCCu6KfwU=DxntKYtg@mail.gmail.com>
2015-12-21 4:33 ` Pieter Wuille
2015-12-21 4:42 ` Justus Ranvier
2015-12-21 4:44 ` Alex Morcos
2015-12-21 4:50 ` Mark Friedenbach
2015-12-21 5:29 ` Douglas Roark
2015-12-21 5:21 ` Btc Drak
2015-12-21 8:07 ` Anthony Towns
2015-12-21 9:56 ` Jorge Timón
2015-12-08 23:48 ` Jonathan Toomim
2015-12-09 0:23 ` Gregory Maxwell
[not found] ` <CAAS2fgRP8bLWZoKR9-iJS-2RKTGQQ9NG-LpAfa2BOdcR=GuB_A@mail.gmail.com>
2015-12-09 0:40 ` Jonathan Toomim
2015-12-09 12:28 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=CABsx9T1wga3Tandoe2mVGSKdHJytHoc9Ko7HRm2SvJXABEFk9w@mail.gmail.com \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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