path: root/bf/9bd5491d3b255f1670e76b1ecbc8b1cd5a3f29

Return-Path: <bounce+33760e.2c141-bitcoin-dev=lists.linuxfoundation.org@suredbits.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A762087A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Jul 2017 16:03:58 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from so254-16.mailgun.net (so254-16.mailgun.net [198.61.254.16])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E402F3CD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Jul 2017 16:03:54 +0000 (UTC)
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=suredbits.com;
	q=dns/txt; 
	s=mailo; t=1499789034; h=Content-Type: To: Subject: Message-ID: Date:
	From: References: In-Reply-To: MIME-Version: Sender;
	bh=vJ0EUKTdXUqt4MDUuwIC6yomTIDqRtH27cAZ5d6gTw4=;
	b=nMP7/qiBClvgv1x2xC3HvjeBRCs9FCqpQQxo8bDwwDFUV8gfNEEQ7yyjlgBvkCdS+aevN5VF
	V2mWx4ALASkK6W0bWhfb2H0qjNZ0QfvdQWOFZgjluw7D+Harl0q+SN/0gBSXfmb77iCRAWYs
	BBoeJ+Xbxiy6SsE6HXaP7NWnk94=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=suredbits.com; s=mailo;
	q=dns; h=Sender: MIME-Version: In-Reply-To: References: From: Date:
	Message-ID: Subject: To: Content-Type;
	b=iKVV6kwTidmp3dYw6y5HUdqX9yVMSnRcB3p5+ACYAoT8Q+UkMQScbikmAA8C5+rvGcDY6y
	N6toKRg0cV5ZXMDAQoQlK63cS3/0DmEus3F6x3STfeLI4CziAb5ccYXxCW7FpyIJSZr4tD1T
	k4f8wfigM/22yvI/sEcYS4Ba7VS+s=
Sender: chris@suredbits.com
X-Mailgun-Sending-Ip: 198.61.254.16
X-Mailgun-Sid: WyI5MGYzNyIsICJiaXRjb2luLWRldkBsaXN0cy5saW51eGZvdW5kYXRpb24ub3JnIiwgIjJjMTQxIl0=
Received: from mail-it0-f52.google.com (mail-it0-f52.google.com
	[209.85.214.52])
	by mxa.mailgun.org with ESMTP id 5964f6e3.7f2bd44ada70-smtp-out-n02;
	Tue, 11 Jul 2017 16:03:47 -0000 (UTC)
Received: by mail-it0-f52.google.com with SMTP id m68so67962130ith.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Jul 2017 09:03:46 -0700 (PDT)
X-Gm-Message-State: AIVw112ORmWroxarbS1dDjDLCk8GzrBOQ7EFKIhSseetsCFXu3qOL372
	rRRfDZzkJYNjySAmzSQ/OJ8Bww6YcA==
X-Received: by 10.107.134.141 with SMTP id q13mr647784ioi.191.1499789025933;
	Tue, 11 Jul 2017 09:03:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.174.131 with HTTP; Tue, 11 Jul 2017 09:03:45 -0700 (PDT)
In-Reply-To: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Tue, 11 Jul 2017 11:03:45 -0500
X-Gmail-Original-Message-ID: <CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
Message-ID: <CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
To: Paul Sztorc <truthcoin@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113eacde2207d105540cd8ff"
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no 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 16:17:40 +0000
Subject: Re: [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: Tue, 11 Jul 2017 16:03:58 -0000

--001a113eacde2207d105540cd8ff
Content-Type: text/plain; charset="UTF-8"

Concept ACK.

I think you are overstating the readiness of drivechains though. I think
the optimistic estimate for drivechains to be ready for bitcoin core is a
year out from today. More likely the date should be early 2018. Still a lot
of work to be done! :-)

Also I don't know if I would put a hard fork suggestion in the scaling map.
If drivechains are successful they should be viewed as the way we scale --
not hard forking the protocol. Do you still have capacity concerns if
drivechains are successful?

-Chris

On Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Summary
> =========
>
> 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
> =================================
>
> 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.
>
>  ==== Beginning of New ("July 2017") Roadmap Draft ====
>
> 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/011865.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/litening/
> [6] https://github.com/ACINQ/eclair
> [7] https://people.xiph.org/~greg/compacted_txn.txt
> [8]
> https://github.com/ElementsProject/secp256k1-zkp/blob/
> d78f12b04ec3d9f5744cd4c51f20951106b9c41a/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/013542.html
>
>  ==== End of Roadmap Draft ====
>
> 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/1gxcUnmYl7yM0oKR9NY9zCPbBbPNoc
> mCq-jjBOQSVH-A/edit?usp=sharing
>
> Cheers,
> Paul
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a113eacde2207d105540cd8ff
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Concept ACK.<br><br></div>I think you are o=
verstating the readiness of drivechains though. I think the optimistic esti=
mate for drivechains to be ready for bitcoin core is a year out from today.=
 More likely the date should be early 2018. Still a lot of work to be done!=
 :-)<br><br></div>Also I don&#39;t know if I would put a hard fork suggesti=
on in the scaling map. If drivechains are successful they should be viewed =
as the way we scale -- not hard forking the protocol. Do you still have cap=
acity concerns if drivechains are successful? <br><br></div>-Chris<br></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jul 10, =
2017 at 11:50 AM, Paul Sztorc via bitcoin-dev <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><br>
Summary<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
In my opinion, Greg Maxwell&#39;s scaling roadmap [1] succeeded in a few<br=
>
crucial ways. One success was that it synchronized the entire Bitcoin<br>
community, helping to bring finality to the (endless) conversations of<br>
that time, and get everyone back to work. However, I feel that the Dec<br>
7, 2015 roadmap is simply too old to serve this function any longer. We<br>
should revise it: remove what has been accomplished, introduce new<br>
innovations and approaches, and update deadlines and projections.<br>
<br>
<br>
Why We Should Update the Roadmap<br>
=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<wbr>=3D=3D=3D<br>
<br>
In a P2P system like Bitcoin, we lack authoritative info-sources (for<br>
example, a &quot;textbook&quot; or academic journal), and as a result<br>
conversations tend to have a problematic lack of progress. They do not<br>
&quot;accumulate&quot;, as everyone must start over. Ironically, the scalin=
g<br>
conversation _itself_ has a fatal O(n^2) scaling problem.<br>
<br>
The roadmap helped solve these problems by being constant in size, and<br>
subjecting itself to publication, endorsement, criticism, and so forth.<br>
Despite the (unavoidable) nuance and complexity of each individual<br>
opinion, it was at least globally known that X participants endorsed Y<br>
set of claims.<br>
<br>
Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite<br>
obsolete and replacing it is long overdue. For example, it highlights<br>
older items (CSV, compact blocks, versionbits) as being _future_<br>
improvements, and makes no mention of new high-likelihood improvements<br>
(Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit<br=
>
fraud proofs). To read the old roadmap properly, one must already be a<br>
technical expert. For me, this defeats the entire point of having one in<br=
>
the first place.<br>
<br>
A new roadmap would be worth your attention, even if you didn&#39;t sign it=
,<br>
because a refusal to sign would still be informative (and, therefore,<br>
helpful)!<br>
<br>
So, with that in mind, let me present a first draft. Obviously, I am<br>
strongly open to edits and feedback, because I have no way of knowing<br>
everyone&#39;s opinions. I admit that I am partially campaigning for my<br>
Drivechain project, and also for this &quot;scalability&quot;/&quot;capacit=
y&quot;<br>
distinction...that&#39;s because I believe in both and think they are<br>
helpful. But please feel free to suggest edits.<br>
<br>
I emphasized concrete numbers, and concrete dates.<br>
<br>
And I did NOT necessarily write it from my own point of view, I tried<br>
earnestly to capture a (useful) community view. So, let me know how I did.<=
br>
<br>
=C2=A0=3D=3D=3D=3D Beginning of New (&quot;July 2017&quot;) Roadmap Draft =
=3D=3D=3D=3D<br>
<br>
This document updates the previous roadmap [1] of Dec 2015. The older<br>
statement endorsed a belief that &quot;the community is ready to deliver on=
<br>
its shared vision that addresses the needs of the system while upholding<br=
>
its values&quot;.<br>
<br>
That belief has not changed, but the shared vision has certainly grown<br>
sharper over the last 18 months. Below is a list of technologies which<br>
either increase Bitcoin&#39;s maximum tps rate (&quot;capacity&quot;), or w=
hich make<br>
it easier to process a higher volume of transactions (&quot;scalability&quo=
t;).<br>
<br>
First, over the past 18 months, the technical community has completed a<br>
number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables<br>
Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks<br>
(BIP 152) allows for much faster block propagation, as does the FIBRE<br>
Network [3]. Check Sequence Verify (BIP 112) allows trading partners to<br>
mutually update an active transaction without writing it to the<br>
blockchain (this helps to enable the Lightning Network).<br>
<br>
Second, Segregated Witness (BIP 141), which reorganizes data in blocks<br>
to handle signatures separately, has been completed and awaits<br>
activation (multiple BIPS). It is estimated to increase capacity by a<br>
factor of 2.2. It also improves scalability in many ways. First, SW<br>
includes a fee-policy which encourages users to minimize their impact on<br=
>
the UTXO set. Second, SW achieves linear scaling of sighash operations,<br>
which prevents the network from crashing when large transactions are<br>
broadcast. Third, SW provides an efficiency gain for everyone who is not<br=
>
verifying signatures, as these no longer need to be downloaded or<br>
stored. SegWit is an enabling technology for the Lightning Network,<br>
script versioning (specifically Schnorr signatures), and has a number of<br=
>
benefits which<br>
are unrelated to capacity [4].<br>
<br>
Third, the Lightning Network, which allows users to transact without<br>
broadcasting to the network, is complete [5, 6] and awaits the<br>
activation of SegWit. For those users who are able to make a single<br>
on-chain transaction, it is estimated to increase both capacity and<br>
scalability by a factor of ~1000 (although these capacity increases will<br=
>
vary with usage patterns). LN also greatly improves transaction speed<br>
and transaction privacy.<br>
<br>
Fourth, Transaction Compression [7], observes that Bitcoin transaction<br>
serialization is not optimized for storage or network communication. If<br>
transactions were optimally compressed (as is possible today), this<br>
would improve scalability, but not capacity, by roughly 20%, and in some<br=
>
cases over 30%.<br>
<br>
Fifth, Schnorr Signature Aggregation, which shrinks transactions by<br>
allowing many transactions to have a single shared signature, has been<br>
implemented [8] in draft form in libsecp256k1, and will likely be ready<br>
by Q4 of 2016. One analysis [9] suggests that signature aggregation<br>
would result in storage and bandwidth savings of at least 25%, which<br>
would therefore increase scalability and capacity by a factor of 1.33.<br>
The relative savings are even greater for multisignature transactions.<br>
<br>
Sixth, drivechain [10], which allows bitcoins to be temporarily<br>
offloaded to &#39;alternative&#39; blockchain networks (&quot;sidechains&qu=
ot;), is<br>
currently under peer review and may be usable by end of 2017. Although<br>
it has no impact on scalability, it does allow users to opt-in to<br>
greater capacity, by moving their BTC to a new network (although, they<br>
will achieve less decentralization as a result). Individual drivechains<br>
may have different security tradeoffs (for example, a greater reliance<br>
on UTXO commitments, or MimbleWimble&#39;s shrinking block history) which<b=
r>
may give them individually greater scalability than mainchain Bitcoin.<br>
<br>
Finally, the capacity improvements outlined above may not be sufficient.<br=
>
If so, it may be necessary to use a hard fork to increase the blocksize<br>
(and blockweight, sigops, etc) by a moderate amount. Such an increase<br>
should take advantage of the existing research on hard forks, which is<br>
substantial [11]. Specifically, there is some consensus that Spoonnet<br>
[12] is the most attractive option for such a hardfork. There is<br>
currently no consensus on a hard fork date, but there is a rough<br>
consensus that one would require at least 6 months to coordinate<br>
effectively, which would place it in the year 2018 at earliest.<br>
<br>
The above are only a small sample of current scaling technologies. And<br>
even an exhaustive list of scaling technologies, would itself only be a<br>
small sample of total Bitcoin innovation (which is proceeding at<br>
breakneck speed).<br>
<br>
Signed,<br>
&lt;Names Here&gt;<br>
<br>
[1]<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Dec=
ember/011865.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2015-December/011865.html</a=
><br>
[2] <a href=3D"https://bitcoincore.org/en/2017/03/13/performance-optimizati=
ons-1/" rel=3D"noreferrer" target=3D"_blank">https://bitcoincore.org/en/<wb=
r>2017/03/13/performance-<wbr>optimizations-1/</a><br>
[3] <a href=3D"http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/" re=
l=3D"noreferrer" target=3D"_blank">http://bluematt.bitcoin.ninja/<wbr>2016/=
07/07/relay-networks/</a><br>
[4] <a href=3D"https://bitcoincore.org/en/2016/01/26/segwit-benefits/" rel=
=3D"noreferrer" target=3D"_blank">https://bitcoincore.org/en/<wbr>2016/01/2=
6/segwit-benefits/</a><br>
[5]<br>
<a href=3D"http://lightning.community/release/software/lnd/lightning/2017/0=
5/03/litening/" rel=3D"noreferrer" target=3D"_blank">http://lightning.commu=
nity/<wbr>release/software/lnd/<wbr>lightning/2017/05/03/litening/</a><br>
[6] <a href=3D"https://github.com/ACINQ/eclair" rel=3D"noreferrer" target=
=3D"_blank">https://github.com/ACINQ/<wbr>eclair</a><br>
[7] <a href=3D"https://people.xiph.org/~greg/compacted_txn.txt" rel=3D"nore=
ferrer" target=3D"_blank">https://people.xiph.org/~greg/<wbr>compacted_txn.=
txt</a><br>
[8]<br>
<a href=3D"https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04e=
c3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594" rel=3D"noreferrer=
" target=3D"_blank">https://github.com/<wbr>ElementsProject/secp256k1-zkp/<=
wbr>blob/<wbr>d78f12b04ec3d9f5744cd4c51f2095<wbr>1106b9c41a/src/secp256k1.c=
#<wbr>L592-L594</a><br>
[9] <a href=3D"https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggr=
egation/" rel=3D"noreferrer" target=3D"_blank">https://bitcoincore.org/en/<=
wbr>2017/03/23/schnorr-signature-<wbr>aggregation/</a><br>
[10] <a href=3D"http://www.drivechain.info/" rel=3D"noreferrer" target=3D"_=
blank">http://www.drivechain.info/</a><br>
[11] <a href=3D"https://bitcoinhardforkresearch.github.io/" rel=3D"noreferr=
er" target=3D"_blank">https://<wbr>bitcoinhardforkresearch.<wbr>github.io/<=
/a><br>
[12]<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Feb=
ruary/013542.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2017-February/013542.html</a=
><br>
<br>
=C2=A0=3D=3D=3D=3D End of Roadmap Draft =3D=3D=3D=3D<br>
<br>
In short, please let me know:<br>
<br>
1. If you agree that it would be helpful if the roadmap were updated.<br>
2. To what extent, if any, you like this draft.<br>
3. Edits you would make (specifically, I wonder about Drivechain<br>
thoughts and Hard Fork thoughts, particularly how to phrase the Hard<br>
Fork date).<br>
<br>
Google Doc (if you&#39;re into that kind of thing):<br>
<a href=3D"https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNo=
cmCq-jjBOQSVH-A/edit?usp=3Dsharing" rel=3D"noreferrer" target=3D"_blank">ht=
tps://docs.google.com/<wbr>document/d/<wbr>1gxcUnmYl7yM0oKR9NY9zCPbBbPNoc<w=
br>mCq-jjBOQSVH-A/edit?usp=3D<wbr>sharing</a><br>
<br>
Cheers,<br>
Paul<br>
<br>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a113eacde2207d105540cd8ff--