Updating the Scaling Roadmap

>
> 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
>
>

> 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/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing
>>
>> Cheers,
>> Paul
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> 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
> <mailto: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
>

> On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev"
> <bitcoin-dev@lists•linuxfoundation•org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     Concept ACK.
>
>     If drivechains are successful they should be viewed as the way we
>     scale
>
>
> I strongly disagree with that statement.
>
> Drivechains, and several earlier sidechains ideas, are not a
> scalability improvement, but merely enabling users to opt-in for
> another security model.
>
> While obviously any future with wider adoption will need different
> technologies that have different trade-offs, and anyone is free to
> choose their security model, I don't think this particular one is
> interesting. In terms of validation cost to auditors, it is as bad as
> just a capacity increase on chain, while simultaneously adding the
> extra risk of miners being able to vote to steal your money.
>
> Cheers,
>
> --
> Pieter
>

> On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev"
> <bitcoin-dev@lists•linuxfoundation•org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     Concept ACK.
>
>     If drivechains are successful they should be viewed as the way we
>     scale
>
>
> I strongly disagree with that statement.
>
> Drivechains, and several earlier sidechains ideas, are not a
> scalability improvement, but merely enabling users to opt-in for
> another security model.
>
> While obviously any future with wider adoption will need different
> technologies that have different trade-offs, and anyone is free to
> choose their security model, I don't think this particular one is
> interesting. In terms of validation cost to auditors, it is as bad as
> just a capacity increase on chain, while simultaneously adding the
> extra risk of miners being able to vote to steal your money.
>
> Cheers,
>
> --
> Pieter
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> I wrote the roadmap to try to be representative of a Core / developer
> position.

> I am philosophically against hard forks, but HFs were in the end
> of the previous roadmap so I felt it should stay. And, I felt that if I

> which I have included here a private email
> thread on the subject

> Pieter,
>
> I think that you have misrepresented Chris' view by taking it out of
> context. His complete quote reads "If drivechains are successful they should
> be viewed as the way we scale -- not hard forking the protocol." Chris is
> comparing Drivechains/sidechains to a hard fork.

> You went on to "disagree", but every point of contention you introduced was
> something that would apply to both drivechain-sourced capacity and
> hardfork-sourced capacity. Neither improves scalability, and both allow
> users only the opportunity to select a different security model. If I
> understand you, the point at which a security model does not become
> "interesting" to you, would be the exact same point in the drivechain and
> hardfork worlds. Both, at any rate, have the same effect on "validation cost
> to auditors".

> Since their sidechain coins cannot appreciate in value relative
> to the mainchain coins, users would only opt-in if they felt that they were
> sufficiently compensated for any and all risks. Hence, it is difficult to
> list this item as a drawback when, to the user, it is a strict improvement
> (at least, by any epistemological standard that I can think of). If you have
> new objections to these claims, I'm sure we would all benefit from hearing
> them, myself most of all.

> I think it's great that people want to experiment with things like
> drivechains/sidechains and what not, but their security model is very
> distinct from Bitcoin's and, given the current highly centralized
> mining ecosystem, arguably not very good.  So positioning them as a
> major solution for the Bitcoin project is the wrong way to go. Instead
> we should support people trying cool stuff, at their own risk.
>
> So, given that although the vast majority of the things in the document
> are things I've been supporting for months (Please see Note 1 way down
> at the bottom) I cannot support your document.

> On a more meta-subject, I think grandly stated "top down" roadmaps
> in highly collaborative development are of minimal utility at best

> IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
> and release process once the basic technology is done; because it's
> only past that point that guarantees can really start being made.
>
> But that isn't what your document does-- it names a lot of things which
> are still various shades of research at this point

> This was an incredible benefit to our customers, but the only way it was
> possible was because _features_ were not guaranteed in a release.

> One of the big screwups with segwit handling was people sticking
> some random unrealistic date on it it which was done AFAIK,
> by well meaning folks who took some random numbers from people
> working on it for when they'd be done with the development-- not the
> testing, not the integration, and certainly not deployment and published
> it as The Date.  Then even though the development was actually done
> by them, segwit was portrayed as massively delayed, because what
> matters to the users is deployment-- which we can't control.

> I see you've done this yourself with signature aggregation, sticking Q4 2016
> right on it, which as far as I can tell is a figure that comes from mars.

> It's also not really appropriate to ask people to sign onto stuff when they
> can't even review it.  Perhaps the signature aggregation stuff is insecure,
> patent encumbered, or practically useless... (It won't be but no one could
> tell that from your post; because it doesn't even exist as a concrete proposal)

> I think people would rightly protest about a number of these things-- especially
> things like the the agg sigs and tx compaction, "wtf, I've not heard
> of this. Who
> are you to insist this goes into Bitcoin?"

> [  Note 1: I think it is important to disclose that several of the
> items in this list appear to be more or less quoted out of my own
> blockstream-internal descriptions of things we've been working on in
> Bitcoin.
> A while back Adam Back asked me to publish something which contained
> significant chunks of this document more or less verbatim,

> and I
> declined saying that I personally disagree with some of his points and
> didn't think that Blockstream attempting to redirect the Bitcoin
> project (esp towards drivechains) was appropriate-- along with my
> (above) views on roadmaps (which I have included here a private email
> thread on the subject). I feel it's important to disclose this, and
> that the document was not otherwise created with the input of project
> contributors (except Luke-Jr, apparently). I wasn't previously aware
> that Adam had been working with Paul on this, had I been I would have
> also encouraged people to be a little more transparent about it. ]

> I think it's great that people want to experiment with things like
> drivechains/sidechains and what not, but their security model is very
> distinct from Bitcoin’s

> On Tue, Jul 11, 2017 at 8:18 PM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>> I wrote the roadmap to try to be representative of a Core / developer
>> position.
> A fine intention, but I've checked with many of the top contributors
> and it sounds like the only regular developer you spoke with was
> Luke-Jr.  Next time you seek to represent someone you might want to
> try talking to them!

>> I am philosophically against hard forks, but HFs were in the end
>> of the previous roadmap so I felt it should stay. And, I felt that if I
> I think the project is not philosophically against hardforks, at least
> not in an absolute sense.

> But if you were instead to talk about things like fixing timewarp,
> recovering header bits, etc. It would clearly be the other way.

> In any case, I think it's safe to say that people's opinions on
> hardforks are complicated. And all the smoke right now with unusually
> poorly executed proposals probably clouds clear thinking.

> On Tue, Jul 11, 2017 at 1:36 PM, Paul Sztorc <truthcoin@gmail•com> wrote:
>> Pieter,
>>
>> I think that you have misrepresented Chris' view by taking it out of
>> context. His complete quote reads "If drivechains are successful they should
>> be viewed as the way we scale -- not hard forking the protocol." Chris is
>> comparing Drivechains/sidechains to a hard fork.
> I apologize here; I didn't mean to misrepresent his viewpoint.

>> You went on to "disagree", but every point of contention you introduced was
>> something that would apply to both drivechain-sourced capacity and
>> hardfork-sourced capacity. Neither improves scalability, and both allow
>> users only the opportunity to select a different security model. If I
>> understand you, the point at which a security model does not become
>> "interesting" to you, would be the exact same point in the drivechain and
>> hardfork worlds. Both, at any rate, have the same effect on "validation cost
>> to auditors".
> If you're talking about the extreme case where every full node in the
> increased capacity single chain model corresponds to a node that
> validates both chains and all transfers between them in the
> drivechains, I agree. At that point they become nearly equivalent in
> terms of ease of adoption, resource costs, and capacity.
>
> However, I don't think that is a realistic expectation. When
> considering drivechains as a capacity increase, I believe most people
> think about a situation where there are many chains that give an
> increased capacity combined, but not everyone verifies all of them.
> This is what I meant with uninteresting security model, as it requires
> increased miner trust for preventing the other chains' coins from
> being illegally transferred to the chain you're operating on.

> Regardless, people are free experiment and adopt such an approach. The
> nice thing about it not being a hardfork is that it does not require
> network-wide consensus to deploy. However, I don't think they offer a
> security model that should be encouraged, and thus doesn't have a
> place on a roadmap.

>> Since their sidechain coins cannot appreciate in value relative
>> to the mainchain coins, users would only opt-in if they felt that they were
>> sufficiently compensated for any and all risks. Hence, it is difficult to
>> list this item as a drawback when, to the user, it is a strict improvement
>> (at least, by any epistemological standard that I can think of). If you have
>> new objections to these claims, I'm sure we would all benefit from hearing
>> them, myself most of all.
> Am I right in summarizing your point here as "This approach cannot
> hurt, because if it were insecure, people can choose to not use it."?
> I'm not sure I agree with that, as network effects or misinformation
> may push users beyond what is reasonable.

> Dear Paul,
>
> Drivechain has several issues that you've acknowledged but have not,
> IMO, adequately (at all really) addressed [1].

> Adopting DC would be an irreversible course of action,

> It would not be accurate to say that miners have "total" control. Miners
> do control the destination of withdrawals, but they do not control the
> withdrawal-duration nor the withdrawal-frequency.
>
> So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
> theft, but they can not change the fact that their malfeasance will be
> [a] obvious, and [b] on display for a long period of time.

> I do not think that any of the three stands out as being categorically
> worse than the others

> We should revise [the roadmap]: remove what has been accomplished,
> introduce new innovations and approaches, and update deadlines
> and projections.

>  ==== Beginning of New ("July 2017") Roadmap Draft ====

> 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.

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

> On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
>> [  Note 1: I think it is important to disclose that several of the
>> items in this list appear to be more or less quoted out of my own
>> blockstream-internal descriptions of things we've been working on in
>> Bitcoin.
>> A while back Adam Back asked me to publish something which contained
>> significant chunks of this document more or less verbatim,

> I am not exactly sure what you are insinuating but I encourage you to
> clarify it.

>> and I
>> declined saying that I personally disagree with some of his points and
>> didn't think that Blockstream attempting to redirect the Bitcoin
>> project (esp towards drivechains) was appropriate-- along with my
>> (above) views on roadmaps (which I have included here a private email
>> thread on the subject). I feel it's important to disclose this, and
>> that the document was not otherwise created with the input of project
>> contributors (except Luke-Jr, apparently). I wasn't previously aware
>> that Adam had been working with Paul on this, had I been I would have
>> also encouraged people to be a little more transparent about it. ]
> I really don't understand what you are disclosing. That Adam asked you
> for feedback on the draft? And then, in the next sentence, that not
> enough experts were asked for feedback on the draft? I'm legitimately
> confused by this part.
>
> As I stated, we can remove the drivechain section. But surely you can
> appreciate how bizarre your position on roadmaps is. What exactly, did
> you intended to create at [1]? Since it is described explicitly as "the
> roadmap in Capacity increases for the Bitcoin system", have you been
> disagreeing with it's characterization as a 'roadmap' this entire time?
> One wonders why you haven't said anything until now.
>
> [1] https://bitcoincore.org/en/2015/12/21/capacity-increase/

> I don't understand this at all. This document attempts to do exactly
> what its predecessor did -- nothing more or less.

> As to your specific complaints, I have addressed both the security model

> I really don't understand what you are disclosing. That Adam asked you
> for feedback on the draft? And then, in the next sentence, that not

> But surely you can
> appreciate how bizarre your position on roadmaps is. What exactly, did
> you intended to create at [1]? Since it is described explicitly as "the
> roadmap in Capacity increases for the Bitcoin system", have you been
> disagreeing with it's characterization as a 'roadmap' this entire time?
> One wonders why you haven't said anything until now.

> In my first email I list the benefits of having a roadmap. One benefit
> is that, without one, it is likely that a large majority of outsiders
> have almost no idea at all what is being worked on, what effect it will
> have, or when it might be ready, or to whom/what they should turn to for
> advice on such matters. Do you have a different way of addressing this
> communication problem?

>> A fine intention, but I've checked with many of the top contributors
>> and it sounds like the only regular developer you spoke with was
>> Luke-Jr.  Next time you seek to represent someone you might want to
>> try talking to them!
>
> That is false. I could provide a list of names but I'm really not sure
> what would be gained as result. You yourself admit that it is an
> excellent list of research, almost all which you support directly.
>
> So I think your only real objection is that I didn't talk to you
> specifically.

> Paul,
>
> There is a difference between replying to an email, and addressing the
> issues that were brought up in it.
>
> I did read your reply, and I chose not to respond to it because it did
> not address anything I said.

>
> Here's an example:
>
>> It would not be accurate to say that miners have "total" control. Miners
>> do control the destination of withdrawals, but they do not control the
>> withdrawal-duration nor the withdrawal-frequency.
>>
>> So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
>> theft, but they can not change the fact that their malfeasance will be
>> [a] obvious, and [b] on display for a long period of time.
>
> Here, you admit that the security of the sidechains allows miners to
> steal bitcoins, something they cannot do currently.

>
> You next tried to equate three different types of theft, what you
> called "Classic Theft", "Channel Theft", and "Drivechain Theft", saying:
>
>> I do not think that any of the three stands out as being categorically
>> worse than the others
>
> To anyone who understands bitcoin, there is a very clear,
> unmistakeable difference between double-spending ("Classic Theft"),
> and *ownership* of the private key controlling the bitcoins.
>
> Similarly, to anyone who understands bitcoin, there is also a very
> clear, unmistakeable difference between censorship ("Channel Theft"),
> and *ownership* of the private key controlling the bitcoins.

>
> I am not sure how else to respond to that email, given that none of
> the issues were really addressed.

> Drivechain is an unmistakeable weakening of Bitcoin's security
> guarantees. This you have not denied.

> IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
> and release process once the basic technology is done; because it's
> only past that point that guarantees can really start being made.

>>> A fine intention, but I've checked with many of the top contributors
>>> and it sounds like the only regular developer you spoke with was
>>> Luke-Jr.  Next time you seek to represent someone you might want to
>>> try talking to them!
>> That is false. I could provide a list of names but I'm really not sure
>> what would be gained as result. You yourself admit that it is an
>> excellent list of research, almost all which you support directly.
>>
>> So I think your only real objection is that I didn't talk to you
>> specifically.
> Come now, this is needlessly insulting. I would have made the same
> comment if you had talked to me because you didn't talk to most/all of
> Matt Corallo, Wladimir, Pieter Wuille, Alex Morcos, etc.... e.g. the
> people doing most of the work of actually building the system.  Before
> making that comment I went and checked with people to find out if only
> I was left out.  Talking to Adam (who isn't involved in the project)
> and Luke-jr (who is but is well known for frustratingly extreme
> minority positions and also contracts for Blockstream sometimes) isn't

> On Tue, Jul 11, 2017 at 10:17 PM, Paul Sztorc <truthcoin@gmail•com> wrote:
>> I don't understand this at all. This document attempts to do exactly
>> what its predecessor did -- nothing more or less.
> That might be your impression, then you've misunderstood what I
> intended-- What I wrote was carefully constructed as a personal view
> of how things might work out. It never claimed to be a a project
> roadmap. Though as usual, I work hard to propose things that I believe
> will be successful... and people are free to adopt what they want.
>
> And to the extent that it got taken that way I think it was an error
> and that it has harmed progress in our community; and created more
> confusion about control vs collaboration.
>
> With perfect hindsight I wouldn't have posted it; especially since
> we've learned that the demand for increased capacity from many people
> was potentially less than completely earnest. (The whole, can't double
> capacity until we quadruple it thing...)
>
>> As to your specific complaints, I have addressed both the security model
> and the concept of mining centralization on this list in the recent
> past.
>
> I don't agree that you have; but for the purpose of this thread
> doesn't really matter if I (specifically) do or don't agree.  It's an
> objective truth that many people do not yet believe these concerns
> have been addressed.
>
>> I really don't understand what you are disclosing. That Adam asked you
>> for feedback on the draft? And then, in the next sentence, that not
> That Adam asked me to write publish a new "roadmap" for Bitcoin as
> you've done here, with particular features and descriptions, which I
> declined; and explained why I didn't believe that was the right
> approach.  And Adam worked with you on the document, and provided
> content for it (which I then recognized in the post).
>
> Set aside what you know to be true for a moment and consider how this
> might look to an outsider who found out about it.  It could look a
> like Blockstream was trying to influence the direction of Bitcoin by
> laundering proposals through an apparently unaffiliated third party.
> Doubly so considering who participated in your drafting and who didn't
> (more below).
>
> I don't think in actuality you did anything remotely improper
> (ill-advised, perhaps, since your goal to speak for developers but you
> didn't speak to them, IMO--) but I think transparency is essential to
> avoid any appearance of misconduct.
>
>> But surely you can
>> appreciate how bizarre your position on roadmaps is. What exactly, did
>> you intended to create at [1]? Since it is described explicitly as "the
>> roadmap in Capacity increases for the Bitcoin system", have you been
>> disagreeing with it's characterization as a 'roadmap' this entire time?
>> One wonders why you haven't said anything until now.
> I did--
>
> As Bryan pointed out... with the exception of the intro and end and a
> couple sentences in the middle my entire response to your post, with
> the position on "roadmaps" was written a long time ago, specifically
> to complain about and argue against that particular approach.
>
>> In my first email I list the benefits of having a roadmap. One benefit
>> is that, without one, it is likely that a large majority of outsiders
>> have almost no idea at all what is being worked on, what effect it will
>> have, or when it might be ready, or to whom/what they should turn to for
>> advice on such matters. Do you have a different way of addressing this
>> communication problem?
> I think you may be mistaking a roadmap with "communications"-- people
> taking about research they are exploring is great! and we should have
> more of it.  But like with RedHat and kernel features, we can't really
> roadmap things that are unresourced and currently just unimplemented
> exploration or test code-- without seeing things which are more or
> less done the community can't rightfully decide if they'd want to
> support something or not.  Perhaps they'll be good things perhaps
> awful-- the devil is in the details, and until an effort is fairly
> mature, you cannot see the details.
>
> There have, for example, been signature aggregation proposals in the
> past that required address reuse (could only aggregate if they're
> reused).  I would strongly oppose such a proposal, and I hope everyone
> else here would too.  So if I were a third party looking at your
> message, rather than the person who initially proposed the agg sig
> thing you're talking about, I wouldn't know if I could love it or hate
> it yet; and probably couldn't be expected to have much of an opinion
> on it until there is a BIP and/or example implementation.
>
> To the extent that a roadmap differs from communications in general,
> it is in that it also implies things that none of us can promise
> except for our own efforts; Completion of implementations, success of
> experiments, adoption-- basically assuming a level of top down control
> that doesn't exist in a wide public collaboration.
>
> One of the great challenges in our industry is that we don't have
> rings of communication: We don't have much in the way of semi-experts
> to communicate to semi-semi-experts to communicate to media pundits to
> communicate to the unwashed masses-- at each level closing the
> inferential gap and explaining things in terms the audience
> understands. We don't have things like LWN.   We'll get there, but it
> it took the Linux world decades to build to what it has now. I think
> various forces in the industry work against us-- e.g. we lose a mot of
> mid tier technical people to the allure of striking it rich printing
> money in their own altcoins.
>
> It might be attractive to try to end-run the slow development
> appropriate web of reliable communications by deploying high authority
> edicts, but it ultimately can't work because it doesn't map to how
> things are accomplished, not in true collaborative open source, and
> certainly not in an effort whos value comes substantially from
> decentralization. Doing so, I fear, creates a false understanding of
> authority.
>
> (It's a common misunderstanding, for example, that people do what I
> want (for example); but in reality, I just try to avoid wasting my
> time advocating things that I don't think other people are already
> going to do; :) otherwise, if _I_ want something done I've got to do
> it myself or horse trade for it, just like anyone else.)
>
> One of the great things about general communications is anyone can do
> it.  Of course, unless they're talking about their own work, they
> can't promise any of it will be completely-- but that is always true.
>  If someone wants some guarantee about work, they have to be willing
> to get it done themselves (and, of course, if it's a consensus
> feature-- that much is necessary, but still not sufficient to get a
> guarantee).
>
> [from your other reply]
>>> A fine intention, but I've checked with many of the top contributors
>>> and it sounds like the only regular developer you spoke with was
>>> Luke-Jr.  Next time you seek to represent someone you might want to
>>> try talking to them!
>> That is false. I could provide a list of names but I'm really not sure
>> what would be gained as result. You yourself admit that it is an
>> excellent list of research, almost all which you support directly.
>>
>> So I think your only real objection is that I didn't talk to you
>> specifically.
> Come now, this is needlessly insulting. I would have made the same
> comment if you had talked to me because you didn't talk to most/all of
> Matt Corallo, Wladimir, Pieter Wuille, Alex Morcos, etc.... e.g. the
> people doing most of the work of actually building the system.  Before
> making that comment I went and checked with people to find out if only
> I was left out.  Talking to Adam (who isn't involved in the project)
> and Luke-jr (who is but is well known for frustratingly extreme
> minority positions and also contracts for Blockstream sometimes) isn't
> a great approach for the stated goal of speaking for developers!

> it, etc. But I am not willing to press the issue. Some of your other
> comments I also find confusing but there is little to be gained in
> clarifying them. )

> Generally, I still think that the roadmap was a helpful communication
> device, which did more good than harm. And I am interested in hearing
> what other people think.

>> Come now, this is needlessly insulting. I would have made the same
>> comment if you had talked to me because you didn't talk to most/all of
>> Matt Corallo, Wladimir, Pieter Wuille, Alex Morcos, etc.... e.g. the
>> people doing most of the work of actually building the system.  Before
>> making that comment I went and checked with people to find out if only
>> I was left out.  Talking to Adam (who isn't involved in the project)
>> and Luke-jr (who is but is well known for frustratingly extreme
>> minority positions and also contracts for Blockstream sometimes) isn't
>
> Let me try to explain my point of view. I did speak to several people,
> in addition to the two names that I privately volunteered to you when
> you had done no research (you failed to uncover any additional names),

> suggested that, other than yourself and a few others, no one is
> qualified even to write a first draft of a summary of present day

> activities. This response is typical of the hostile review environment
> which has existed in Bitcoin for years (I am more than used to it). If

> Separately, and very important to me, is that you feel that there are
> unresolved objections to drivechain's security model, which you decline
> to share with me and/or the list. So I would hope that you instead
> choose to share your thoughts (as is, presumably, the purpose of this list).

> Let me try to explain my point of view. I did speak to several people,

> used the information I volunteered to you against me (in the form of
> false characterizations of negligent email writing!), and you also

> And please try to avoid going off-topic -- this is supposed to be about
> the idea of a new roadmap.
>
> Paul
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> I think it's great that people want to experiment with things like
> drivechains/sidechains and what not, but their security model is very
> distinct from Bitcoin's and, given the current highly centralized
> mining ecosystem, arguably not very good.  So positioning them as a
> major solution for the Bitcoin project is the wrong way to go. Instead
> we should support people trying cool stuff, at their own risk.
>
> So, given that although the vast majority of the things in the document
> are things I've been supporting for months (Please see Note 1 way down
> at the bottom) I cannot support your document.

> Bitcoin development differs from Linux kernel development in a number
> of obvious ways, such as the fact Bitcoin is being "patched in
> flight".

> Having *something* like a roadmap that gives the average user some
> insights into what exactly is being planned for Bitcoin is very
> desirable, arguably even necessary,

>Here, you admit that the security of the sidechains allows miners to steal

> Drivechain is an unmistakeable weakening of Bitcoin's security

>There is no reason to weaken Bitcoin's security in such a dramatic

>

> Paul,
>
> There is a difference between replying to an email, and addressing the
> issues that were brought up in it.
>
> I did read your reply, and I chose not to respond to it because it did not
> address anything I said.
>
> Here's an example:
>
> It would not be accurate to say that miners have "total" control. Miners
> do control the destination of withdrawals, but they do not control the
> withdrawal-duration nor the withdrawal-frequency.
>
> So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
> theft, but they can not change the fact that their malfeasance will be
> [a] obvious, and [b] on display for a long period of time.
>
>
> Here, you admit that the security of the sidechains allows miners to steal
> bitcoins, something they cannot do currently.
>
> You next tried to equate three different types of theft, what you called
> "Classic Theft", "Channel Theft", and "Drivechain Theft", saying:
>
> I do not think that any of the three stands out as being categorically
> worse than the others
>
>
> To anyone who understands bitcoin, there is a very clear, unmistakeable
> difference between double-spending ("Classic Theft"), and *ownership* of
> the private key controlling the bitcoins.
>
> Similarly, to anyone who understands bitcoin, there is also a very clear,
> unmistakeable difference between censorship ("Channel Theft"), and
> *ownership* of the private key controlling the bitcoins.
>
> The entire email was a very long-form way of admitting to all of the
> issues that were raised in the previous email, while making it sound like
> you had addressed the issues.
>
> I am not sure how else to respond to that email, given that none of the
> issues were really addressed.
>
> Drivechain is an unmistakeable weakening of Bitcoin's security guarantees.
> This you have not denied.
>
> There is no reason to weaken Bitcoin's security in such a dramatic
> fashion. Better options are being worked on, they just take time.
>
> Kind regards,
> Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Jul 11, 2017, at 3:57 PM, Paul Sztorc <truthcoin@gmail•com> wrote:
>
> On 7/11/2017 6:41 PM, Tao Effect wrote:
>
> Dear Paul,
>
> Drivechain has several issues that you've acknowledged but have not,
> IMO, adequately (at all really) addressed [1].
>
>
> I replied to your email at length, at [2]. You should read that email,
> and then reply to it with your outstanding objections, if you still have
> them (per the usual customs of a mailing list).
>
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-June/014609.html
>
> Adopting DC would be an irreversible course of action,
>
>
> This is false -- it is easily reversible with a second soft fork.
>
> Also, I would say to everyone that, (in my opinion as the OP) this
> conversation will go off-topic if it veers exclusively into 'drivechain
> review'.
>
> Paul
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

> I think this is an unfair characterization. You have to opt into using drivechains.

> Care to share? I'm unaware if there is.

>If so, please leave, you are compromising Bitcoin's security.

>If I design a car that has a button that randomly causes the brakes to

>It is how *insecure* systems are designed.

>Sure, happy to, as soon as I have it written up in detail.

> Dear Chris,
>
> I think this is an unfair characterization. You have to opt into using
> drivechains.
>
>
> I have heard this nonsense repeated countless times in order to justify
> adopting Drivechain.
>
> This is not how security works.
>
> A child can "opt-in" to using a loaded gun, but is it a good idea to make
> it easy for them to do that?
>
> No.
>
> This is effectively the same thing Drivechains is doing.
>
> It is a request to modify the Bitcoin protocol to make it easy for Bitcoin
> users to give their Bitcoins to miners.
>
> Does that sound like a good idea to anyone?
>
> If so, please leave, you are compromising Bitcoin's security.
>
> Security is about making it difficult to shoot yourself in the face.
>
> If I design a car that has a button that randomly causes the brakes to
> give out if pressed, is that a good idea? Can I justify pushing for such a
> "feature" just because it's "opt-in"?
>
> No. That is fallacy.
>
> It is not how secure systems are designed.
>
> It is how *insecure* systems are designed.
>
> Care to share? I'm unaware if there is.
>
>
> Sure, happy to, as soon as I have it written up in detail.
>
> Kind regards,
> Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Jul 12, 2017, at 12:19 PM, Chris Stewart <chris@suredbits•com> wrote:
>
> Hi Greg,
>
> >Here, you admit that the security of the sidechains allows miners to
> steal bitcoins, something they cannot do currently.
>
> If I put my coins in an anyone can spend output, a miner will take them.
> They can do this today. I suggest you try it if you don't believe me :-).
> You have to be more specific with contract types instead of generically
> talking about 'all contracts ever'.
>
> > Drivechain is an unmistakeable weakening of Bitcoin's security
> guarantees. This you have not denied.
>
> I think this is an unfair characterization. You have to opt into using
> drivechains. Other outputs such as P2PKH/Multisig etc are unaffected by a
> drivechain output. As Pieter Wuille stated earlier in this thread (and Paul
> has stated all along), drivechain outputs have a different security model
> than other contracts. Namely they are controlled by miners. I think we can
> all agree this is unfortunate, but it is the current reality we live in. I
> look forward to the day we can solve the 'ownership' problem so we can have
> trustless interoperable blockchains, but that day is not today.
>
> As a reminder, most users will not have to go through the drivechain
> withdrawal process. Most withdrawals will be done via atomic swaps.
>
> >There is no reason to weaken Bitcoin's security in such a dramatic
> fashion. Better options are being worked on, they just take time.
>
> Care to share? I'm unaware if there is.
>
> >https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.
> html
>
> Everyone should re-read this email though, this is something that could
> happen. Paul's design makes it so that if this occurs it is *VERY* obvious.
> I guess we can argue if there is any difference between an obvious robbery
> vs a hidden robbery, but I think if we have to pick one or the other the
> choice is clear to me. Other designs (that I'm aware of) for sidechains had
> attack vectors that weren't so obvious.
>
> -Chris
>
>
>
>
>

> I think Paul has been pretty upfront about the risks of his model.

> By your account bitcoin is already insecure then -- it allows anyone can spend outputs that can be claimed by miners.

> ...
> In the present situation, anyone-can-spend outputs are used by
> probably less than 0.1% of users, and most software doesn't even allow
> for the possibility.
>
> In Drivechain it's *encouraged-by-design*!
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
>

> That's a fair point, I confused anyone-can-spend with anyone-can-pay [1].
>
> Isn't it different in the case of P2SH and SegWit, don't full nodes
> validate the script?
>
> In other words, miners don't have complete control over the coins,
> full nodes keep a check on them.
>
> At least that was my understanding, and if that's not the case then it
> doesn't make sense to me why Pieter would earlier in this thread
> object to Drivechain on the grounds that it's a different security model.
>
> - Greg
>
> [1] https://steemit.com/bitcoin/@jl777/bitcoin-spinoff-fork-how-to-make-a-clean-fork-without-any-replay-attack-and-no-blockchain-visible-changes
>
>
> --
> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
>
>> On Jul 12, 2017, at 12:54 PM, CryptAxe via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation•org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>
>> Are we just pulling numbers out of thin air now? https://p2sh.info/
>> BIP16 for example is widely used. It would be difficult to find a
>> single wallet that doesn't support BIP16 I have no idea what you are
>> talking about.
>>
>>
>> On 07/12/2017 12:42 PM, Tao Effect via bitcoin-dev wrote:
>>> ...
>>> In the present situation, anyone-can-spend outputs are used by
>>> probably less than 0.1% of users, and most software doesn't even
>>> allow for the possibility.
>>>
>>> In Drivechain it's *encouraged-by-design*!
>>>
>>> - Greg
>>>
>>> --
>>> Please do not email me anything that you are not comfortable also
>>> sharing with the NSA.
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> Hi!
>
> Up to now, I have purposefully been running bitcoin releases prior to
> 0.13.1 as a way to avoid the (possible) segwit activation, at least
> until such time as I personally am comfortable with it.

> At this time, I would like to have some of the more recent features, but
> without the possibility that my node will activate segwit, until I
> choose to.

> I'm not looking for reasons NOT to do it, only HOW to do it without
> unwanted side-effects.

>
> Can you explain why you wish to do this?  It should have absolutely no
> adverse impact on you-- if you don't use segwit, you don't use it-- it
> may be the case that there is some confusion about the implications
> that I could clear up for you... or suggest alternatives that might
> achieve your goals.
>

> I believe that a good reason not to wish your node to be segwit compliant

> On 13 July 2017 at 03:04, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>>
>> Can you explain why you wish to do this?  It should have absolutely no
>> adverse impact on you-- if you don't use segwit, you don't use it-- it
>> may be the case that there is some confusion about the implications
>> that I could clear up for you... or suggest alternatives that might
>> achieve your goals.
>>
>
> I believe that a good reason not to wish your node to be segwit compliant
> is to avoid having to deal with the extra bandwidth that segwit could
> require.   Running a 0.14.2 node means being ok with >1MB blocks, in case
> segwit is activated and widely used. Users not interested in segwit
> transactions may prefer to keep the cost of their node lower.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

> On Wed, Jul 12, 2017 at 6:17 AM, Dan Libby via bitcoin-dev

> It is not simple to do so correctly, I couldn't tell you off the top
> of my head; a number of things must be changed it isn't as simple as
> disabling the activiation because of the segwit P2P changes.  Nor is
> it a supported configuration. Even if it were now, it wouldn't be one
> we'd continue to support in the future after segwit is active, as
> we're likely to drop deployment/compat code.

> Can you explain why you wish to do this?  It should have absolutely no
> adverse impact on you-- if you don't use segwit, you don't use it-- it
> may be the case that there is some confusion about the implications
> that I could clear up for you... or suggest alternatives that might
> achieve your goals.

> Effectively the only reason I'm aware of to intentionally not run with
> segwit support beyond just not having upgraded yet, is a desire to try
> to temporarily have as your tip block a block that was actively
> stealing the segwit transactions of a third party. Which doesn't seem
> either personally or publicly desirable; but I fully admit I may be
> missing some good reason which I am not aware of.

> I think that terminology isn't quite precise. I think your options are:
>
>  - if you're a miner or run a mining pool, you can *signal* (or not
>    signal) support for segwit activation; you do this by controlling
>    the block version

>  - if you're running a node, you can choose to *enforce* (or not
>    enforce) the additional consensus rules associated with segwit

>
> I think it's the latter you're talking about. "Activation" is different:
> it's the collective action of the bitcoin ecosystem to start enforcing
> the segwit consensus rules after a sufficient majority of miners are
> signalling support. That's not something you as an individual can control.

> If you want to disable enforcement of segwit rules, even if a majority of
> mining power signal activation, you can change the code and recompile to
> do so, for example by changing the nTimeout setting for DEPLOYMENT_SEGWIT
> from 1510704000 (Nov 15 2017) to 1493596800 (May 1 2017, already expired).
> This is probably a bad idea, in that it will cause you to risk accepting
> blocks that nobody else in the network will accept, opening you up
> to higher risk of double spends, and may cause you to be unable to
> peer with segwit enabled nodes after segwit is activated if your node
> is rejecting blocks with witness data because you think segwit is not
> enabled while they think it is enabled. To avoid that you would also need
> to stop setting the NODE_WITNESS p2p bit, which you might be able to do
> by setting the nTimeout above to 0 instead of just a date in the past? I
> believe a timeout of 0 gets treated as automatically FAILED. There might
> be other complexities too though.

>
>> I'm not looking for reasons NOT to do it, only HOW to do it without
>> unwanted side-effects.
>
> The unwanted side-effects are precisely the reasons not to do it. If you
> don't understand what they are, you won't be able to avoid them. :)

>> I believe that a good reason not to wish your node to be segwit
> compliant is to avoid having to deal with the extra bandwidth that
> segwit could require.   Running a 0.14.2 node means being ok with >1MB
> blocks, in case segwit is activated and widely used. Users not
> interested in segwit transactions may prefer to keep the cost of their
> node lower.
>
> If the majority of the network decides to deploy SegWit, it would be in
> your best interest to validate the SegWit transactions, because you
> might will be downgraded to near-SPV node validation.
> It would be okay to still run a "non-SegWit" node if there's no SegWit
> transactions in the chain of transactions for your bitcoins, otherwise
> you cannot fully verify the the ownership of your bitcoins.
> I'm not sure the practicality of this in the long run, but it makes a
> case for having an up-to-date non-SegWit node, although I think it's a
> bit of a stretch.

> On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote:
> >> I believe that a good reason not to wish your node to be segwit
> > compliant is to avoid having to deal with the extra bandwidth that
> > segwit could require.   Running a 0.14.2 node means being ok with >1MB
> > blocks, in case segwit is activated and widely used. Users not
> > interested in segwit transactions may prefer to keep the cost of their
> > node lower.
> >
> > If the majority of the network decides to deploy SegWit, it would be in
> > your best interest to validate the SegWit transactions, because you
> > might will be downgraded to near-SPV node validation.
> > It would be okay to still run a "non-SegWit" node if there's no SegWit
> > transactions in the chain of transactions for your bitcoins, otherwise
> > you cannot fully verify the the ownership of your bitcoins.
> > I'm not sure the practicality of this in the long run, but it makes a
> > case for having an up-to-date non-SegWit node, although I think it's a
> > bit of a stretch.
>
> Right.  Well, if I never upgrade to segwit, then there seems little
> (zero?) risk of having any segwit tx in my tx chain.
>
>

> Thus this would be a way I could continue with a lower bandwidth cap and
> also keep my coins "untainted", so to speak.
>
> I'm not sure about it for the long run either.  more just something of
> an experiment.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

>
>
> On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote:
>     >> I believe that a good reason not to wish your node to be segwit
>     > compliant is to avoid having to deal with the extra bandwidth that
>     > segwit could require.   Running a 0.14.2 node means being ok with >1MB
>     > blocks, in case segwit is activated and widely used. Users not
>     > interested in segwit transactions may prefer to keep the cost of their
>     > node lower.
>     >
>     > If the majority of the network decides to deploy SegWit, it would be in
>     > your best interest to validate the SegWit transactions, because you
>     > might will be downgraded to near-SPV node validation.
>     > It would be okay to still run a "non-SegWit" node if there's no SegWit
>     > transactions in the chain of transactions for your bitcoins, otherwise
>     > you cannot fully verify the the ownership of your bitcoins.
>     > I'm not sure the practicality of this in the long run, but it makes a
>     > case for having an up-to-date non-SegWit node, although I think it's a
>     > bit of a stretch.
>
>     Right.  Well, if I never upgrade to segwit, then there seems little
>     (zero?) risk of having any segwit tx in my tx chain.
>
>
> If you mean you wish to avoid receiving UTXOs that have value that was
> at one point previously encumbered by a SegWit output then no, you can't
> avoid that. No more than you can currently avoid receiving BTC that were
> at one point in time encumbered by a P2SH output.

> I would like to understand it a bit better, as I think it applies

> If I understand correctly, my node will accept the incoming tx inputs

> I don't yet understand how my node

> so if

> On 07/13/2017 09:35 AM, Jameson Lopp wrote:
> >
> >
> > On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev
> > <bitcoin-dev@lists•linuxfoundation•org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> >     On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote:
> >     >> I believe that a good reason not to wish your node to be segwit
> >     > compliant is to avoid having to deal with the extra bandwidth that
> >     > segwit could require.   Running a 0.14.2 node means being ok with
> >1MB
> >     > blocks, in case segwit is activated and widely used. Users not
> >     > interested in segwit transactions may prefer to keep the cost of
> their
> >     > node lower.
> >     >
> >     > If the majority of the network decides to deploy SegWit, it would
> be in
> >     > your best interest to validate the SegWit transactions, because you
> >     > might will be downgraded to near-SPV node validation.
> >     > It would be okay to still run a "non-SegWit" node if there's no
> SegWit
> >     > transactions in the chain of transactions for your bitcoins,
> otherwise
> >     > you cannot fully verify the the ownership of your bitcoins.
> >     > I'm not sure the practicality of this in the long run, but it
> makes a
> >     > case for having an up-to-date non-SegWit node, although I think
> it's a
> >     > bit of a stretch.
> >
> >     Right.  Well, if I never upgrade to segwit, then there seems little
> >     (zero?) risk of having any segwit tx in my tx chain.
> >
> >
> > If you mean you wish to avoid receiving UTXOs that have value that was
> > at one point previously encumbered by a SegWit output then no, you can't
> > avoid that. No more than you can currently avoid receiving BTC that were
> > at one point in time encumbered by a P2SH output.
>
> fair enough.  This actually wasn't an area I'd considered much before
> Hampus brought it up.
>
> I would like to understand it a bit better, as I think it applies
> equally to any pre-segwit node, yes?   So let's say I am running 0.13.0
> and someone sends me bitcoins to a P2PKH address, but that person
> previously received them to a P2WPKH address.
>
> If I understand correctly, my node will accept the incoming tx inputs
> but obviously will not perform any segwit related validation, thus those
> inputs are not fully validated.  I don't yet understand how my node
> thinks they are valid at all given that it does not understand P2WPKH
> address format, so either it doesn't need to, or P2WPKH is somehow
> already valid.  I know this has all been discussed in the past, so if
> someone can point me towards a document that explains it I'd be happy to
> read that.
>
> thanks!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> If I understand correctly, my node will accept the incoming tx inputs
> but obviously will not perform any segwit related validation, thus those
> inputs are not fully validated.  I don't yet understand how my node
> thinks they are valid at all given that it does not understand P2WPKH
> address format, so either it doesn't need to, or P2WPKH is somehow
> already valid.  I know this has all been discussed in the past, so if
> someone can point me towards a document that explains it I'd be happy to
> read that.
>

> Yes.
> So you have two choices to be fully secure:
> 1. Validate using the new rules of the network (in other words, run a
> SegWit node)
> 2. Avoid any chain of transaction that contains a SegWit transaction

> See
> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_compatibility
> So the witness program is encoded in a new format that old nodes do not
> understand.
> This means that for old nodes, a number >0 will be put on the stack.
> When the script is done, it will be evaluated to true (because of >0)
> and be counted as a valid spend.
>
> https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki also
> explains the new witness program more in detail (I left out some details
> in my explanation).

> sounds good, though I'm unclear on how exactly to achieve (2) given that

> Another thing that could be done is to modify my own node so that it

> I suppose that it would be possible without modifying any rule to

> Hampus, thanks for the explanation!

> Hampus, thanks for the explanation!
>
> On 07/13/2017 03:50 PM, Hampus Sjöberg wrote:
>
> > Yes.
> > So you have two choices to be fully secure:
> > 1. Validate using the new rules of the network (in other words, run a
> > SegWit node)
> > 2. Avoid any chain of transaction that contains a SegWit transaction
>
> sounds good, though I'm unclear on how exactly to achieve (2) given that
> any party I have ever transacted with (or otherwise knows an address of
> mine) can send me coins at any time.  So it seems the only possible way
> to be certain is to run a node that has never published an address to a
> 3rd party.  Is that accurate?
>
> Another thing that could be done is to modify my own node so that it
> actually rejects such tx, but then I have modified consensus rules
> myself, thus defeating the goal of remaining with status-quo rules, and
> anyway the rest of the network would accept the tx.  I guess the benefit
> is that I could be certain of the remaining funds I have.
>
> I suppose that it would be possible without modifying any rule to
> construct a "certain balance" and an "uncertain balance".
>
> I don't intend to do such modifications! just grasping for understanding.
>
>
> > See
> > https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_
> compatibility
> > So the witness program is encoded in a new format that old nodes do not
> > understand.
> > This means that for old nodes, a number >0 will be put on the stack.
> > When the script is done, it will be evaluated to true (because of >0)
> > and be counted as a valid spend.
> >
> > https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki also
> > explains the new witness program more in detail (I left out some details
> > in my explanation).
>
> I read the relevant parts, thanks!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> On 07/13/2017 03:50 PM, Hampus Sjöberg wrote:
> > 2. Avoid any chain of transaction that contains a SegWit transaction
>
> sounds good, though I'm unclear on how exactly to achieve (2) given that
> any party I have ever transacted with (or otherwise knows an address of
> mine) can send me coins at any time.  So it seems the only possible way
> to be certain is to run a node that has never published an address to a
> 3rd party.  Is that accurate?
>

> Another thing that could be done is to modify my own node so that it
> actually rejects such tx, but then I have modified consensus rules
> myself, thus defeating the goal of remaining with status-quo rules, and
> anyway the rest of the network would accept the tx.  I guess the benefit
> is that I could be certain of the remaining funds I have.
>

> construct a "certain balance" and an "uncertain balance".
>

> On Wed, Jul 12, 2017 at 6:17 AM, Dan Libby via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
> > Hi!
> >
> > Up to now, I have purposefully been running bitcoin releases prior to
> > 0.13.1 as a way to avoid the (possible) segwit activation, at least
> > until such time as I personally am comfortable with it.
>
> It is not simple to do so correctly, I couldn't tell you off the top
> of my head; a number of things must be changed it isn't as simple as
> disabling the activiation because of the segwit P2P changes.  Nor is
> it a supported configuration. Even if it were now, it wouldn't be one
> we'd continue to support in the future after segwit is active, as
> we're likely to drop deployment/compat code.

> Can you explain why you wish to do this?  It should have absolutely no
> adverse impact on you-- if you don't use segwit, you don't use it-- it
> may be the case that there is some confusion about the implications
> that I could clear up for you... or suggest alternatives that might
> achieve your goals.

> 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/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing
>
> Cheers,
> Paul
>

> 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 he
> 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
> (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.txt
> [2]
> https://github.com/psztorc/btc-core-capacity-2/commit/
> 2b4f0ecc9015ee398ce0486ca5c3613e3b929c00
> [3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
> [4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
>
>
> On 7/10/2017 12:50 PM, Paul Sztorc 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
>

> 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.

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

> 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.

> 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 he
>     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.txt
>     <https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.txt>
>     [2]
>     https://github.com/psztorc/btc-core-capacity-2/commit/2b4f0ecc9015ee398ce0486ca5c3613e3b929c00
>     <https://github.com/psztorc/btc-core-capacity-2/commit/2b4f0ecc9015ee398ce0486ca5c3613e3b929c00>
>     [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
>     > =========
>     >
>     > 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
>     <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/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/03/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/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
>     <https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/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-aggregation/>
>     > [10] http://www.drivechain.info/
>     > [11] https://bitcoinhardforkresearch.github.io/
>     <https://bitcoinhardforkresearch.github.io/>
>     > [12]
>     >
>     https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html
>     <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/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing
>     <https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing>
>     >
>     > 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>
>
>

> "it was ACKed by everyone else that I heard from"  - I don't think you
> should read into that much.
>
> 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.
> But I don't think we should be taking relatively new/untested ideas such as
> Drivechain and sticking them on a roadmap.  There is a tendency in this
> community to hear about the latest and greatest idea and immediately fixate
> on it as our salvation. I'm very happy that you are doing this work and
> that others are researching a wide variety of ideas.  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.

> On Mon, Jul 17, 2017 at 01:13:30PM -0400, Paul Sztorc via bitcoin-dev wrote:
>> However, without interest from the maintainers of bitcoincore.org
>> (specifically these [3, 4] pages and similar) the document will probably
>> be unable to gain traction.
>> [...]
>> [3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
>> [4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
> The BitcoinCore.org maintainers are not psychic.  If you want your
> document to appear on the website, please open a PR.  If you would like
> help formatting your document for the website, please feel free to send
> me an email off list or open an issue[1] regarding the inadequacy of
> the site's readme.

> [1] https://github.com/bitcoin-core/bitcoincore.org/issues/new
>
> Speaking as the instigator of [3] and the primary author of [4] (both
> originally published on Bitcoin.org), I'll point out that Maxwell's
> reply to you was a slightly rewritten version of a reply to me sent on 4
> November 2016 (as noted elsewhere in the thread and confirmed in my
> mailbox).  I include below my signature a complete copy of my reply to
> him (and CC'd to others).
>
> If I had followed through on my earlier plan to post a copy of Maxwell's
> reply on BitcoinCore.org (assuming Bitcoin Core contributors supported
> publishing it), you probably would've known that some Bitcoin Core
> contributors were resistant to roadmaps prior to you writing your
> proposed roadmap.  For that failure, and the time you may have wasted
> because of it, I offer you my apologies.

> I will make opening a PR to BitcoinCore.org with his statement a priority
> so that hopefully future confusion can be avoided.
>
> Sincerely,
>
> -Dave
>
> On Fri, Nov 04, 2016 at 07:17:11PM +0000, Gregory Maxwell wrote:
>> [...]
> I just wanted to say that I thought this was an amazing reply.  I was
> hoping that if I waited long enough to respond I might find something
> meaningful to add, but nothing has come to mind and I didn't want to
> leave the impression that your reply didn't merit a response.
>
> Maybe we can find a place on the website to post something like this so
> that we can link to it when other people ask for roadmaps and other
> commitments to future plans.
>
> Thanks!,
>
> -Dave