path: root/62/9297d615aa561dbc992413515b823b23fab05e

Return-Path: <truthcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 61A964A4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 10 Jul 2017 16:50:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com
	[209.85.216.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 39CDD3D9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 10 Jul 2017 16:50:33 +0000 (UTC)
Received: by mail-qt0-f179.google.com with SMTP id b40so77785892qtb.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 10 Jul 2017 09:50:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=to:from:subject:message-id:date:user-agent:mime-version;
	bh=Ws1BbNWzPatydEbGgYRZXkLmeQKq+/gaxt2wWQy+owE=;
	b=J/8kT73LDCziPB526CN4L3K2d/hzsQUKIT8RAYMdGAPJQeUxT3Ok/VC6rok0Jk9WRx
	89IsMJB669LC1+pWO/TeK3yALO1O1Dmnv05llq+4wfZIsttwDcUEJxlajjJaV3K2VyYu
	QUQdm6RSfFHnOX5SM5yErSyR+SwI/P66Vq+zjDvUA7CZarDQ7D5EvqitfF1YPdbbYAqH
	l4PSsb9Udx7gdGo1jaaq0uqRo/Ssyl2FT9x+Zu82GFtp0I04GmmZ8YewV/bQLJ0V+zh0
	Iw5Y0gbJEvJAVw/wSaDTvuk8qac/tQNCUg5cVuvM/zfuk4fLD7yfkSpqt1dLL/IK6RFV
	eR+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:to:from:subject:message-id:date:user-agent
	:mime-version;
	bh=Ws1BbNWzPatydEbGgYRZXkLmeQKq+/gaxt2wWQy+owE=;
	b=eUzkrF4JymHCiDV3ZmEvQxhD6ggU4t6/rOqY38Ld60PTiKqR+QVOqvR6ohss1H+119
	6FgWVhuAF1JRPqjxRGB4LDmTJzMC4xquOwQxjbINO5Fe/ezD80uMjI56he0grrTSu0qG
	kMTdWUGOXiu8YGLtZjOUPa5XOEr1GLiUFVp8IRqt65HOgiAh0CPfelvmLPz36wZMYWx2
	pFU17QArhdIZtyQ4i8hhBC2FfoJc2r51HnoXEF23AMiwTgPgoCrCELxoGtmuR6Y/w+hD
	AyjjfIDjKzLm9Ew0OLEMra3GfyXI+6hQd6k093Pl3GEWjK/8GymOBOBavIouF8BmUgU7
	osDQ==
X-Gm-Message-State: AIVw112ZYKm/QpwJnq7KrQKaFJE00O6rkNAao0F4xEzAqOlj/xgr6xV+
	nMHeQeL9tHbowoP5EZA=
X-Received: by 10.200.35.21 with SMTP id a21mr5659829qta.56.1499705431707;
	Mon, 10 Jul 2017 09:50:31 -0700 (PDT)
Received: from [192.168.1.101] (ool-45726efb.dyn.optonline.net.
	[69.114.110.251]) by smtp.googlemail.com with ESMTPSA id
	v5sm9751463qtv.38.2017.07.10.09.50.29
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 10 Jul 2017 09:50:30 -0700 (PDT)
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
Date: Mon, 10 Jul 2017 12:50:21 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
	Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="wbQGw234RsXIvlU8eneQoWkDKhdiTLGQ2"
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,
	RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 11 Jul 2017 15:32:16 +0000
Subject: [bitcoin-dev] Updating the Scaling Roadmap
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jul 2017 16:50:37 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--wbQGw234RsXIvlU8eneQoWkDKhdiTLGQ2
Content-Type: multipart/mixed; boundary="gaJfwLX4wckw8gjv9wqfMdRTBaELOOuRM";
 protected-headers="v1"
From: Paul Sztorc <truthcoin@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
Subject: Updating the Scaling Roadmap

--gaJfwLX4wckw8gjv9wqfMdRTBaELOOuRM
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable


Summary
=3D=3D=3D=3D=3D=3D=3D=3D=3D

In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
crucial ways. One success was that it synchronized the entire Bitcoin
community, helping to bring finality to the (endless) conversations of
that time, and get everyone back to work. However, I feel that the Dec
7, 2015 roadmap is simply too old to serve this function any longer. We
should revise it: remove what has been accomplished, introduce new
innovations and approaches, and update deadlines and projections.


Why We Should Update the Roadmap
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D

In a P2P system like Bitcoin, we lack authoritative info-sources (for
example, a "textbook" or academic journal), and as a result
conversations tend to have a problematic lack of progress. They do not
"accumulate", as everyone must start over. Ironically, the scaling
conversation _itself_ has a fatal O(n^2) scaling problem.

The roadmap helped solve these problems by being constant in size, and
subjecting itself to publication, endorsement, criticism, and so forth.
Despite the (unavoidable) nuance and complexity of each individual
opinion, it was at least globally known that X participants endorsed Y
set of claims.

Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
obsolete and replacing it is long overdue. For example, it highlights
older items (CSV, compact blocks, versionbits) as being _future_
improvements, and makes no mention of new high-likelihood improvements
(Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
fraud proofs). To read the old roadmap properly, one must already be a
technical expert. For me, this defeats the entire point of having one in
the first place.

A new roadmap would be worth your attention, even if you didn't sign it,
because a refusal to sign would still be informative (and, therefore,
helpful)!

So, with that in mind, let me present a first draft. Obviously, I am
strongly open to edits and feedback, because I have no way of knowing
everyone's opinions. I admit that I am partially campaigning for my
Drivechain project, and also for this "scalability"/"capacity"
distinction...that's because I believe in both and think they are
helpful. But please feel free to suggest edits.

I emphasized concrete numbers, and concrete dates.

And I did NOT necessarily write it from my own point of view, I tried
earnestly to capture a (useful) community view. So, let me know how I did=
=2E

 =3D=3D=3D=3D Beginning of New ("July 2017") Roadmap Draft =3D=3D=3D=3D

This document updates the previous roadmap [1] of Dec 2015. The older
statement endorsed a belief that "the community is ready to deliver on
its shared vision that addresses the needs of the system while upholding
its values".

That belief has not changed, but the shared vision has certainly grown
sharper over the last 18 months. Below is a list of technologies which
either increase Bitcoin's maximum tps rate ("capacity"), or which make
it easier to process a higher volume of transactions ("scalability").

First, over the past 18 months, the technical community has completed a
number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables
Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks
(BIP 152) allows for much faster block propagation, as does the FIBRE
Network [3]. Check Sequence Verify (BIP 112) allows trading partners to
mutually update an active transaction without writing it to the
blockchain (this helps to enable the Lightning Network).

Second, Segregated Witness (BIP 141), which reorganizes data in blocks
to handle signatures separately, has been completed and awaits
activation (multiple BIPS). It is estimated to increase capacity by a
factor of 2.2. It also improves scalability in many ways. First, SW
includes a fee-policy which encourages users to minimize their impact on
the UTXO set. Second, SW achieves linear scaling of sighash operations,
which prevents the network from crashing when large transactions are
broadcast. Third, SW provides an efficiency gain for everyone who is not
verifying signatures, as these no longer need to be downloaded or
stored. SegWit is an enabling technology for the Lightning Network,
script versioning (specifically Schnorr signatures), and has a number of
benefits which
are unrelated to capacity [4].

Third, the Lightning Network, which allows users to transact without
broadcasting to the network, is complete [5, 6] and awaits the
activation of SegWit. For those users who are able to make a single
on-chain transaction, it is estimated to increase both capacity and
scalability by a factor of ~1000 (although these capacity increases will
vary with usage patterns). LN also greatly improves transaction speed
and transaction privacy.

Fourth, Transaction Compression [7], observes that Bitcoin transaction
serialization is not optimized for storage or network communication. If
transactions were optimally compressed (as is possible today), this
would improve scalability, but not capacity, by roughly 20%, and in some
cases over 30%.

Fifth, Schnorr Signature Aggregation, which shrinks transactions by
allowing many transactions to have a single shared signature, has been
implemented [8] in draft form in libsecp256k1, and will likely be ready
by Q4 of 2016. One analysis [9] suggests that signature aggregation
would result in storage and bandwidth savings of at least 25%, which
would therefore increase scalability and capacity by a factor of 1.33.
The relative savings are even greater for multisignature transactions.

Sixth, drivechain [10], which allows bitcoins to be temporarily
offloaded to 'alternative' blockchain networks ("sidechains"), is
currently under peer review and may be usable by end of 2017. Although
it has no impact on scalability, it does allow users to opt-in to
greater capacity, by moving their BTC to a new network (although, they
will achieve less decentralization as a result). Individual drivechains
may have different security tradeoffs (for example, a greater reliance
on UTXO commitments, or MimbleWimble's shrinking block history) which
may give them individually greater scalability than mainchain Bitcoin.

Finally, the capacity improvements outlined above may not be sufficient.
If so, it may be necessary to use a hard fork to increase the blocksize
(and blockweight, sigops, etc) by a moderate amount. Such an increase
should take advantage of the existing research on hard forks, which is
substantial [11]. Specifically, there is some consensus that Spoonnet
[12] is the most attractive option for such a hardfork. There is
currently no consensus on a hard fork date, but there is a rough
consensus that one would require at least 6 months to coordinate
effectively, which would place it in the year 2018 at earliest.

The above are only a small sample of current scaling technologies. And
even an exhaustive list of scaling technologies, would itself only be a
small sample of total Bitcoin innovation (which is proceeding at
breakneck speed).

Signed,
<Names Here>

[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011=
865.html
[2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
[3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
[4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
[5]
http://lightning.community/release/software/lnd/lightning/2017/05/03/lite=
ning/
[6] https://github.com/ACINQ/eclair
[7] https://people.xiph.org/~greg/compacted_txn.txt
[8]
https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744=
cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
[9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
[10] http://www.drivechain.info/
[11] https://bitcoinhardforkresearch.github.io/
[12]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013=
542.html

 =3D=3D=3D=3D End of Roadmap Draft =3D=3D=3D=3D

In short, please let me know:

1. If you agree that it would be helpful if the roadmap were updated.
2. To what extent, if any, you like this draft.
3. Edits you would make (specifically, I wonder about Drivechain
thoughts and Hard Fork thoughts, particularly how to phrase the Hard
Fork date).

Google Doc (if you're into that kind of thing):
https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBO=
QSVH-A/edit?usp=3Dsharing

Cheers,
Paul


--gaJfwLX4wckw8gjv9wqfMdRTBaELOOuRM--

--wbQGw234RsXIvlU8eneQoWkDKhdiTLGQ2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZY7BYAAoJEKpLMzDxYsQQ9AAIAL2sB5zbMDRDITQ6/eD/dZvO
wTJayv8h1g6obtxipVpHmqB2+QLTgwXvrPIuO+YNCM9MSrmWqVzo0p/Knvi+KWq7
GJ8yi/ND4bKrfkyaj//+osDwTlDZ5YUVFERvxMo6/spwXIEcotHn99dnPP6eS8S+
awiYBU96IvNbLAJZ13Amymno+BVYVOPB3JH9OP+onyPkzSJRd567GVFitpey5VLj
P6Yb5se77ZQXP8jmgRm+KhOqCGvJxrXRRmlhkVrCJHuH338r33r4wugUOcKpdBK5
t2faxC/q4d0oOwgerFno56/5WY3O1MmAv7aBb8I0awq7jw4Fq9nUYvv8KBpedHs=
=xf+M
-----END PGP SIGNATURE-----

--wbQGw234RsXIvlU8eneQoWkDKhdiTLGQ2--