To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<01194110-04f0-82f5-cd5e-0101822fa2b1@gmail.com>
	<CAPWm=eVZQ5FM7AohEMocUobj4jhFvdb-Uc+DhAmSSFZ3_funrw@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <f2711e5e-0ea3-d368-e3da-9673b8801b92@gmail.com>
Date: Mon, 17 Jul 2017 16:13:38 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
	Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAPWm=eVZQ5FM7AohEMocUobj4jhFvdb-Uc+DhAmSSFZ3_funrw@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------C5BEA4364EAB2444C6DF1E03"
Content-Language: en-US
Subject: Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]
Precedence: list

This is a multi-part message in MIME format.
--------------C5BEA4364EAB2444C6DF1E03
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 7/17/2017 2:49 PM, Alex Morcos wrote:
> I felt like this whole conversation was putting the cart before the
> horse.
> You might very well have some good ideas in your roadmap update, to
> tell you the truth, I didn't even read it.

Fine, but, before the roadmap itself, I wrote exactly about why I
thought we should update it. Evidently you disagree with the horse, but
it is in front of the cart where it belongs.


> But I don't think we should be taking relatively new/untested ideas
> such as Drivechain and sticking them on a roadmap.

It isn't a "roadmap" anymore -- I changed it to a "forecast".

And I edited the drivechain part to emphasize only that mainchain space
would likely be freed as defectors leave for an alt-chain. The departing
individuals (ir hardcore LargeBlockers) will leave, despite a
security-model NACK from anyone here (in fact, it would probably only
encourage them). That leaves more space for those who remain.


> There is a tendency in this community to hear about the latest and
> greatest idea and immediately fixate on it as our salvation. ... But
> please, lets be conservative and flexible with how we evolve Bitcoin.=20
> We don't even know if or when we'll get segwit yet.

Drivechain  (c. bitcointalk Feb 2014, blog Nov 2015) is actually much
older than "the" SegWit to which you refer.  As for being "conservative"
and "flexible", I have tried to do everything I know -- Scaling
conferences, in-person discussions, papers, posts, and presentations,
adding BMM, and posting here for additional peer review. I'm sure you
have lots of ideas about how it could be more conservative and/or
flexible, which I would love to hear.

But again I think people are getting hung up on the drivechain part --
it can be easily taken out, I just thought that, if the plan included
more overall flexibility for industry, then it would help deter network
splits and scaling drama.

Paul



> On Mon, Jul 17, 2017 at 1:13 PM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     Hello,
>
>     Last week I posted about updating the Core Scalability Roadmap.
>
>     I'm not sure what the future of it is, given that it was concept
>     NACK'ed
>     by Greg Maxwell the author of the original roadmap, who said that h=
e
>     regretted writing the first one.
>
>     Nonetheless, it was ACKed by everyone else that I heard from,
>     except for
>     Tom Zander (who objected that it should be a specific project
>     document,
>     not a "Bitcoin" document -- I sortof agree and decided to label it =
a
>     "Core" document -- whether or not anything happens with that label
>     is up
>     to the community).
>
>     I therefore decided to:
>     1. Put the draft on GitHub [1]
>     2. Update it based on all of the week 1 feedback [2]
>     3. Add some spaces at the bottom for comments / expressions of
>     interest [2]
>
>     However, without interest from the maintainers of bitcoincore.org
>     <http://bitcoincore.org>
>     (specifically these [3, 4] pages and similar) the document will
>     probably
>     be unable to gain traction.
>
>     Cheers,
>     Paul
>
>     [1]
>     https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.tx=
t
>     <https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.t=
xt>
>     [2]
>     https://github.com/psztorc/btc-core-capacity-2/commit/2b4f0ecc9015e=
e398ce0486ca5c3613e3b929c00
>     <https://github.com/psztorc/btc-core-capacity-2/commit/2b4f0ecc9015=
ee398ce0486ca5c3613e3b929c00>
>     [3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
>     <https://bitcoincore.org/en/2015/12/21/capacity-increase/>
>     [4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
>     <https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/>
>
>
>     On 7/10/2017 12:50 PM, Paul Sztorc wrote:
>     > 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 ne=
w
>     > 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 scalin=
g
>     > 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 individua=
l
>     > 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.
>     >
>     >  =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 Networ=
k,
>     > 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 with=
out
>     > broadcasting to the network, is complete [5, 6] and awaits the
>     > activation of SegWit. For those users who are able to make a sing=
le
>     > on-chain transaction, it is estimated to increase both capacity a=
nd
>     > 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), th=
is
>     > 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 aggregati=
on
>     > would result in storage and bandwidth savings of at least 25%, wh=
ich
>     > 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-Decemb=
er/011865.html
>     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decem=
ber/011865.html>
>     > [2]
>     https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
>     <https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/=
>
>     > [3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
>     <http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/>
>     > [4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
>     <https://bitcoincore.org/en/2016/01/26/segwit-benefits/>
>     > [5]
>     >
>     http://lightning.community/release/software/lnd/lightning/2017/05/0=
3/litening/
>     <http://lightning.community/release/software/lnd/lightning/2017/05/=
03/litening/>
>     > [6] https://github.com/ACINQ/eclair
>     <https://github.com/ACINQ/eclair>
>     > [7] https://people.xiph.org/~greg/compacted_txn.txt
>     <https://people.xiph.org/%7Egreg/compacted_txn.txt>
>     > [8]
>     >
>     https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d=
9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
>     <https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3=
d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594>
>     > [9]
>     https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation=
/
>     <https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregatio=
n/>
>     > [10] http://www.drivechain.info/
>     > [11] https://bitcoinhardforkresearch.github.io/
>     <https://bitcoinhardforkresearch.github.io/>
>     > [12]
>     >
>     https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Februa=
ry/013542.html
>     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Febru=
ary/013542.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 H=
ard
>     > Fork date).
>     >
>     > Google Doc (if you're into that kind of thing):
>     >
>     https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmC=
q-jjBOQSVH-A/edit?usp=3Dsharing
>     <https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocm=
Cq-jjBOQSVH-A/edit?usp=3Dsharing>
>     >
>     > Cheers,
>     > Paul
>     >
>
>
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>


--------------C5BEA4364EAB2444C6DF1E03
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 7/17/2017 2:49 PM, Alex Morcos
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPWm=eVZQ5FM7AohEMocUobj4jhFvdb-Uc+DhAmSSFZ3_funrw@mail.gmail.com">
      <div dir="ltr">I felt like this whole conversation was putting the
        cart before the horse.
        <div>You might very well have some good ideas in your roadmap
          update, to tell you the truth, I didn't even read it.</div>
      </div>
    </blockquote>
    <br>
    Fine, but, before the roadmap itself, I wrote exactly about why I
    thought we should update it. Evidently you disagree with the horse,
    but it is in front of the cart where it belongs.<br>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:CAPWm=eVZQ5FM7AohEMocUobj4jhFvdb-Uc+DhAmSSFZ3_funrw@mail.gmail.com">
      <div dir="ltr">
        <div>But I don't think we should be taking relatively
          new/untested ideas such as Drivechain and sticking them on a
          roadmap.</div>
      </div>
    </blockquote>
    <br>
    It isn't a "roadmap" anymore -- I changed it to a "forecast".<br>
    <br>
    And I edited the drivechain part to emphasize only that mainchain
    space would likely be freed as defectors leave for an alt-chain. The
    departing individuals (ir hardcore LargeBlockers) will leave,
    despite a security-model NACK from anyone here (in fact, it would
    probably only encourage them). That leaves more space for those who
    remain.<br>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:CAPWm=eVZQ5FM7AohEMocUobj4jhFvdb-Uc+DhAmSSFZ3_funrw@mail.gmail.com">
      <div dir="ltr">
        <div> There is a tendency in this community to hear about the
          latest and greatest idea and immediately fixate on it as our
          salvation. ... But please, lets be conservative and flexible
          with how we evolve Bitcoin.  We don't even know if or when
          we'll get segwit yet. <br>
        </div>
      </div>
    </blockquote>
    <br>
    Drivechain  (c. bitcointalk Feb 2014, blog Nov 2015) is actually
    much older than "the" SegWit to which you refer.  As for being
    "conservative" and "flexible", I have tried to do everything I know
    -- Scaling conferences, in-person discussions, papers, posts, and
    presentations, adding BMM, and posting here for additional peer
    review. I'm sure you have lots of ideas about how it could be more
    conservative and/or flexible, which I would love to hear.<br>
    <br>
    But again I think people are getting hung up on the drivechain part
    -- it can be easily taken out, I just thought that, if the plan
    included more overall flexibility for industry, then it would help
    deter network splits and scaling drama.<br>
    <br>
    Paul<br>
    <br>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:CAPWm=eVZQ5FM7AohEMocUobj4jhFvdb-Uc+DhAmSSFZ3_funrw@mail.gmail.com">
      <div dir="ltr">
        <div>
          <div class="gmail_extra">
            <div class="gmail_quote">On Mon, Jul 17, 2017 at 1:13 PM,
              Paul Sztorc via bitcoin-dev <span dir="ltr">&lt;<a
                  href="mailto:bitcoin-dev@lists.linuxfoundation.org"
                  target="_blank" moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span>
              wrote:<br>
              <blockquote class="gmail_quote" style="margin:0px 0px 0px
                0.8ex;border-left:1px solid
                rgb(204,204,204);padding-left:1ex">Hello,<br>
                <br>
                Last week I posted about updating the Core Scalability
                Roadmap.<br>
                <br>
                I'm not sure what the future of it is, given that it was
                concept NACK'ed<br>
                by Greg Maxwell the author of the original roadmap, who
                said that he<br>
                regretted writing the first one.<br>
                <br>
                Nonetheless, it was ACKed by everyone else that I heard
                from, except for<br>
                Tom Zander (who objected that it should be a specific
                project document,<br>
                not a "Bitcoin" document -- I sortof agree and decided
                to label it a<br>
                "Core" document -- whether or not anything happens with
                that label is up<br>
                to the community).<br>
                <br>
                I therefore decided to:<br>
                1. Put the draft on GitHub [1]<br>
                2. Update it based on all of the week 1 feedback [2]<br>
                3. Add some spaces at the bottom for comments /
                expressions of interest [2]<br>
                <br>
                However, without interest from the maintainers of <a
                  href="http://bitcoincore.org" rel="noreferrer"
                  target="_blank" moz-do-not-send="true">bitcoincore.org</a><br>
                (specifically these [3, 4] pages and similar) the
                document will probably<br>
                be unable to gain traction.<br>
                <br>
                Cheers,<br>
                Paul<br>
                <br>
                [1] <a
href="https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.txt"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/psztorc/<wbr>btc-core-capacity-2/blob/<wbr>master/draft.txt</a><br>
                [2]<br>
                <a
href="https://github.com/psztorc/btc-core-capacity-2/commit/2b4f0ecc9015ee398ce0486ca5c3613e3b929c00"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/psztorc/<wbr>btc-core-capacity-2/commit/<wbr>2b4f0ecc9015ee398ce0486ca5c361<wbr>3e3b929c00</a><br>
                [3] <a
                  href="https://bitcoincore.org/en/2015/12/21/capacity-increase/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://bitcoincore.org/en/<wbr>2015/12/21/capacity-increase/</a><br>
                [4] <a
                  href="https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://bitcoincore.org/en/<wbr>2015/12/23/capacity-increases-<wbr>faq/</a><br>
                <br>
                <br>
                On 7/10/2017 12:50 PM, Paul Sztorc wrote:<br>
                &gt; Summary<br>
                &gt; =========<br>
                &gt;<br>
                &gt; In my opinion, Greg Maxwell's scaling roadmap [1]
                succeeded in a few<br>
                &gt; crucial ways. One success was that it synchronized
                the entire Bitcoin<br>
                &gt; community, helping to bring finality to the
                (endless) conversations of<br>
                &gt; that time, and get everyone back to work. However,
                I feel that the Dec<br>
                &gt; 7, 2015 roadmap is simply too old to serve this
                function any longer. We<br>
                &gt; should revise it: remove what has been
                accomplished, introduce new<br>
                &gt; innovations and approaches, and update deadlines
                and projections.<br>
                &gt;<br>
                &gt;<br>
                &gt; Why We Should Update the Roadmap<br>
                &gt; ==============================<wbr>===<br>
                &gt;<br>
                &gt; In a P2P system like Bitcoin, we lack authoritative
                info-sources (for<br>
                &gt; example, a "textbook" or academic journal), and as
                a result<br>
                &gt; conversations tend to have a problematic lack of
                progress. They do not<br>
                &gt; "accumulate", as everyone must start over.
                Ironically, the scaling<br>
                &gt; conversation _itself_ has a fatal O(n^2) scaling
                problem.<br>
                &gt;<br>
                &gt; The roadmap helped solve these problems by being
                constant in size, and<br>
                &gt; subjecting itself to publication, endorsement,
                criticism, and so forth.<br>
                &gt; Despite the (unavoidable) nuance and complexity of
                each individual<br>
                &gt; opinion, it was at least globally known that X
                participants endorsed Y<br>
                &gt; set of claims.<br>
                &gt;<br>
                &gt; Unfortunately, the Dec 2015 roadmap is now 19
                months old -- it is quite<br>
                &gt; obsolete and replacing it is long overdue. For
                example, it highlights<br>
                &gt; older items (CSV, compact blocks, versionbits) as
                being _future_<br>
                &gt; improvements, and makes no mention of new
                high-likelihood improvements<br>
                &gt; (Schnorr) or mis-emphasizes them (LN). It even
                contains mistakes (SegWit<br>
                &gt; fraud proofs). To read the old roadmap properly,
                one must already be a<br>
                &gt; technical expert. For me, this defeats the entire
                point of having one in<br>
                &gt; the first place.<br>
                &gt;<br>
                &gt; A new roadmap would be worth your attention, even
                if you didn't sign it,<br>
                &gt; because a refusal to sign would still be
                informative (and, therefore,<br>
                &gt; helpful)!<br>
                &gt;<br>
                &gt; So, with that in mind, let me present a first
                draft. Obviously, I am<br>
                &gt; strongly open to edits and feedback, because I have
                no way of knowing<br>
                &gt; everyone's opinions. I admit that I am partially
                campaigning for my<br>
                &gt; Drivechain project, and also for this
                "scalability"/"capacity"<br>
                &gt; distinction...that's because I believe in both and
                think they are<br>
                &gt; helpful. But please feel free to suggest edits.<br>
                &gt;<br>
                &gt; I emphasized concrete numbers, and concrete dates.<br>
                &gt;<br>
                &gt; And I did NOT necessarily write it from my own
                point of view, I tried<br>
                &gt; earnestly to capture a (useful) community view. So,
                let me know how I did.<br>
                &gt;<br>
                &gt;  ==== Beginning of New ("July 2017") Roadmap Draft
                ====<br>
                &gt;<br>
                &gt; This document updates the previous roadmap [1] of
                Dec 2015. The older<br>
                &gt; statement endorsed a belief that "the community is
                ready to deliver on<br>
                &gt; its shared vision that addresses the needs of the
                system while upholding<br>
                &gt; its values".<br>
                &gt;<br>
                &gt; That belief has not changed, but the shared vision
                has certainly grown<br>
                &gt; sharper over the last 18 months. Below is a list of
                technologies which<br>
                &gt; either increase Bitcoin's maximum tps rate
                ("capacity"), or which make<br>
                &gt; it easier to process a higher volume of
                transactions ("scalability").<br>
                &gt;<br>
                &gt; First, over the past 18 months, the technical
                community has completed a<br>
                &gt; number of items [2] on the Dec 2015 roadmap.
                VersonBits (BIP 9) enables<br>
                &gt; Bitcoin to handle multiple soft fork upgrades at
                once. Compact Blocks<br>
                &gt; (BIP 152) allows for much faster block propagation,
                as does the FIBRE<br>
                &gt; Network [3]. Check Sequence Verify (BIP 112) allows
                trading partners to<br>
                &gt; mutually update an active transaction without
                writing it to the<br>
                &gt; blockchain (this helps to enable the Lightning
                Network).<br>
                &gt;<br>
                &gt; Second, Segregated Witness (BIP 141), which
                reorganizes data in blocks<br>
                &gt; to handle signatures separately, has been completed
                and awaits<br>
                &gt; activation (multiple BIPS). It is estimated to
                increase capacity by a<br>
                &gt; factor of 2.2. It also improves scalability in many
                ways. First, SW<br>
                &gt; includes a fee-policy which encourages users to
                minimize their impact on<br>
                &gt; the UTXO set. Second, SW achieves linear scaling of
                sighash operations,<br>
                &gt; which prevents the network from crashing when large
                transactions are<br>
                &gt; broadcast. Third, SW provides an efficiency gain
                for everyone who is not<br>
                &gt; verifying signatures, as these no longer need to be
                downloaded or<br>
                &gt; stored. SegWit is an enabling technology for the
                Lightning Network,<br>
                &gt; script versioning (specifically Schnorr
                signatures), and has a number of<br>
                &gt; benefits which<br>
                &gt; are unrelated to capacity [4].<br>
                &gt;<br>
                &gt; Third, the Lightning Network, which allows users to
                transact without<br>
                &gt; broadcasting to the network, is complete [5, 6] and
                awaits the<br>
                &gt; activation of SegWit. For those users who are able
                to make a single<br>
                &gt; on-chain transaction, it is estimated to increase
                both capacity and<br>
                &gt; scalability by a factor of ~1000 (although these
                capacity increases will<br>
                &gt; vary with usage patterns). LN also greatly improves
                transaction speed<br>
                &gt; and transaction privacy.<br>
                &gt;<br>
                &gt; Fourth, Transaction Compression [7], observes that
                Bitcoin transaction<br>
                &gt; serialization is not optimized for storage or
                network communication. If<br>
                &gt; transactions were optimally compressed (as is
                possible today), this<br>
                &gt; would improve scalability, but not capacity, by
                roughly 20%, and in some<br>
                &gt; cases over 30%.<br>
                &gt;<br>
                &gt; Fifth, Schnorr Signature Aggregation, which shrinks
                transactions by<br>
                &gt; allowing many transactions to have a single shared
                signature, has been<br>
                &gt; implemented [8] in draft form in libsecp256k1, and
                will likely be ready<br>
                &gt; by Q4 of 2016. One analysis [9] suggests that
                signature aggregation<br>
                &gt; would result in storage and bandwidth savings of at
                least 25%, which<br>
                &gt; would therefore increase scalability and capacity
                by a factor of 1.33.<br>
                &gt; The relative savings are even greater for
                multisignature transactions.<br>
                &gt;<br>
                &gt; Sixth, drivechain [10], which allows bitcoins to be
                temporarily<br>
                &gt; offloaded to 'alternative' blockchain networks
                ("sidechains"), is<br>
                &gt; currently under peer review and may be usable by
                end of 2017. Although<br>
                &gt; it has no impact on scalability, it does allow
                users to opt-in to<br>
                &gt; greater capacity, by moving their BTC to a new
                network (although, they<br>
                &gt; will achieve less decentralization as a result).
                Individual drivechains<br>
                &gt; may have different security tradeoffs (for example,
                a greater reliance<br>
                &gt; on UTXO commitments, or MimbleWimble's shrinking
                block history) which<br>
                &gt; may give them individually greater scalability than
                mainchain Bitcoin.<br>
                &gt;<br>
                &gt; Finally, the capacity improvements outlined above
                may not be sufficient.<br>
                &gt; If so, it may be necessary to use a hard fork to
                increase the blocksize<br>
                &gt; (and blockweight, sigops, etc) by a moderate
                amount. Such an increase<br>
                &gt; should take advantage of the existing research on
                hard forks, which is<br>
                &gt; substantial [11]. Specifically, there is some
                consensus that Spoonnet<br>
                &gt; [12] is the most attractive option for such a
                hardfork. There is<br>
                &gt; currently no consensus on a hard fork date, but
                there is a rough<br>
                &gt; consensus that one would require at least 6 months
                to coordinate<br>
                &gt; effectively, which would place it in the year 2018
                at earliest.<br>
                &gt;<br>
                &gt; The above are only a small sample of current
                scaling technologies. And<br>
                &gt; even an exhaustive list of scaling technologies,
                would itself only be a<br>
                &gt; small sample of total Bitcoin innovation (which is
                proceeding at<br>
                &gt; breakneck speed).<br>
                &gt;<br>
                &gt; Signed,<br>
                &gt; &lt;Names Here&gt;<br>
                &gt;<br>
                &gt; [1]<br>
                &gt; <a
href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://lists.linuxfoundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2015-December/011865.html</a><br>
                &gt; [2] <a
href="https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://bitcoincore.org/en/<wbr>2017/03/13/performance-<wbr>optimizations-1/</a><br>
                &gt; [3] <a
                  href="http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://bluematt.bitcoin.ninja/<wbr>2016/07/07/relay-networks/</a><br>
                &gt; [4] <a
                  href="https://bitcoincore.org/en/2016/01/26/segwit-benefits/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://bitcoincore.org/en/<wbr>2016/01/26/segwit-benefits/</a><br>
                &gt; [5]<br>
                &gt; <a
href="http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://lightning.community/<wbr>release/software/lnd/<wbr>lightning/2017/05/03/litening/</a><br>
                &gt; [6] <a href="https://github.com/ACINQ/eclair"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/ACINQ/<wbr>eclair</a><br>
                &gt; [7] <a
                  href="https://people.xiph.org/%7Egreg/compacted_txn.txt"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://people.xiph.org/~greg/<wbr>compacted_txn.txt</a><br>
                &gt; [8]<br>
                &gt; <a
href="https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://github.com/<wbr>ElementsProject/secp256k1-zkp/<wbr>blob/<wbr>d78f12b04ec3d9f5744cd4c51f2095<wbr>1106b9c41a/src/secp256k1.c#<wbr>L592-L594</a><br>
                &gt; [9] <a
href="https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://bitcoincore.org/en/<wbr>2017/03/23/schnorr-signature-<wbr>aggregation/</a><br>
                &gt; [10] <a href="http://www.drivechain.info/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://www.drivechain.info/</a><br>
                &gt; [11] <a
                  href="https://bitcoinhardforkresearch.github.io/"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://<wbr>bitcoinhardforkresearch.<wbr>github.io/</a><br>
                &gt; [12]<br>
                &gt; <a
href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://lists.linuxfoundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2017-February/013542.html</a><br>
                &gt;<br>
                &gt;  ==== End of Roadmap Draft ====<br>
                &gt;<br>
                &gt; In short, please let me know:<br>
                &gt;<br>
                &gt; 1. If you agree that it would be helpful if the
                roadmap were updated.<br>
                &gt; 2. To what extent, if any, you like this draft.<br>
                &gt; 3. Edits you would make (specifically, I wonder
                about Drivechain<br>
                &gt; thoughts and Hard Fork thoughts, particularly how
                to phrase the Hard<br>
                &gt; Fork date).<br>
                &gt;<br>
                &gt; Google Doc (if you're into that kind of thing):<br>
                &gt; <a
href="https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://docs.google.com/<wbr>document/d/<wbr>1gxcUnmYl7yM0oKR9NY9zCPbBbPNoc<wbr>mCq-jjBOQSVH-A/edit?usp=<wbr>sharing</a><br>
                &gt;<br>
                &gt; Cheers,<br>
                &gt; Paul<br>
                &gt;<br>
                <br>
                <br>
                ______________________________<wbr>_________________<br>
                bitcoin-dev mailing list<br>
                <a href="mailto:bitcoin-dev@lists.linuxfoundation.org"
                  moz-do-not-send="true">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
                <a
                  href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
              </blockquote>
            </div>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>

--------------C5BEA4364EAB2444C6DF1E03--