[bitcoin-dev] Updating the Scaling Roadmap

[bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

[-- Attachment #1.1: Type: text/plain, Size: 8501 bytes --]


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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Chris Stewart]

[-- Attachment #1: Type: text/plain, Size: 9475 bytes --]

Concept ACK.

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

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

-Chris

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

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

[-- Attachment #2: Type: text/html, Size: 12309 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Adam Back]

Separate from scale, there is utility to a hard-fork to fix wish-list
bugs that cant be reasonably fixed via soft-fork.  The spoonnet
proposal fixes a good number of interesting bugs.  Spoonnet and
several other HF research proposals can be found here
https://bitcoinhardforkresearch.github.io/  Part of the research on HF
is about safe deployment methods which is obviously the other main
consideration.  It seems to me likely that if the HF were to focus on
bug fixes, and not mix in new tradeoffs of security vs scale, it would
more easily reach consensus.

Adam

On 11 July 2017 at 17:03, Chris Stewart via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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
>

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev" <
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

[-- Attachment #2: Type: text/html, Size: 1738 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

[-- Attachment #1: Type: text/plain, Size: 2807 bytes --]

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

The only true difference is the "extra risk of miners being able to vote
to steal your money", but as I have pointed out on this mailing list
several times, I do not actually believe that there is any marginal risk
-- miners can already "vote to steal your money" in the double-spend and
ln-channel-theft contexts. I have also argued that the "risk" is
actually desirable in an opt-in context, because it puts the burden of
proof on miners/developers (to convince users that they should move over
to the sidechain). 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.

Paul


On 7/11/2017 4:01 PM, Pieter Wuille wrote:
> 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
>


[-- Attachment #2: Type: text/html, Size: 4629 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Pieter Wuille]

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.

Cheers,

-- 
Pieter

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

On 7/11/2017 5:40 PM, Pieter Wuille wrote:
> 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.
I'm sure you did not intend to do so, of course.

>> 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.
I think I understand what you are saying, but in this case "it" [your
experience] isn't a different security model *for you*. Perhaps we
disagree on the significance of this qualification.

It seems to be me that your position puts you in danger of having to go
out and protect users from investing in insecure _Altcoins_. Probably,
in a world where altcoins were magically impossible, there would be an
even greater demand for Bitcoin capacity than there is in our
Altcoin-filled world (for a few reasons).

> 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.
I think this is reasonable. It is true that, if no one used drivechains
ever for anything, there would be no transactions offloaded to those
chain, and then no capacity freed up on the original mainchain.

However, though I think your logic is correct in general, I think in
this specific instance it would be somewhat unreasonable to ignore the
fact that, today, we have clear evidence that many people *are* in fact
chomping at the bit to literally leave this blockchain for one that is
almost identical save for a larger maxblocksize.


>> 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.
Again, I think you may be right. However, users may be similarly misled
in the case of Altcoins (or in the case of investments in fiat
currency), and they may be misled in their use of all kinds of
cryptographic software, and in the clothes that they buy and all of
their other activities.

I would strongly support clear expectations, and constant reminders to
users that the security models are different. Perhaps, even, annoying
dialogue boxes that pop up when/if a user tries to move their funds to a
sidechain.

But, again, this (I think) is something that would *also* apply to a
hard fork. We cannot know if Pieter Wuille, for example, believes that a
given hard fork is "push[ing] users beyond what is reasonable" until we
ask him.

--Paul

Re: [bitcoin-dev] Updating the Scaling Roadmap

[CryptAxe]

[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]

If users can opt-in to another security model, why can't they opt-in to
another scaling model? The mainchain (Bitcoin) does not have to adopt
any of the changes made to a sidechain such as larger blocks for example.


On 07/11/2017 01:01 PM, Pieter Wuille via bitcoin-dev wrote:
> 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


[-- Attachment #2: Type: text/html, Size: 3320 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

[-- Attachment #1: Type: text/plain, Size: 2145 bytes --]

Hi Chris,

On 7/11/2017 12:03 PM, Chris Stewart wrote:
> 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! :-)
It depends on interest, I think. What remains to be done is more easily
parallelized, and in some cases (eg smartphone wallets) there are
incentives for private individuals and businesses to hustle their part
out (merely for reasons of competitiveness).

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

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 decided to unilaterally remove it, it would be perceived as
excessive campaigning for Drivechain. And I also felt that to remove it,
when so many industry members recently put their weight behind a fast
hard fork, would be perceived as a reaction to that attempt, and would
then overwhelm the document with political polarization, for really no
benefit.

Paul

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


[-- Attachment #2: Type: text/html, Size: 3728 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Gregory Maxwell]

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.

Part of the reason they were discussed in the capacity document was to
make it clear that I wasn't, and to invite other project members to
expose disagreement (though I'd mostly checked in advance...)

But these recently proposed ultra-hasty highly contentious changes,
that seem to be being suggested on shorter and shorter timeframes; I
do think the project is actually opposed to those in a very strong
sense.

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

At least at the moment computers and bandwidth are improving; I don't
think any regular developers are opposed to hardforks that change
capacity well tech improvements and protocol improvements have made it
obviously not much of a trade-off.

Personally, I wish the project had previously adopted a license that
requires derived works to not accept any block the derived-from work
wouldn't accept for at least two years, or otherwise the derivative
has to be clearly labeled not-bitcoin. :P

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.

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

On 7/11/2017 5:31 PM, Gregory Maxwell wrote:
> 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!
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.

>> 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.
That is why I included them despite being personally against them.
> But if you were instead to talk about things like fixing timewarp,
> recovering header bits, etc. It would clearly be the other way.
It links to bitcoinhardforkresearch.github.io , which I assumed would
contain the hard fork wishlist somewhere, but perhaps it does not.

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

Yes, of course. But is your position that if something is complicated we
should not try to clarify it?

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Gregory Maxwell]

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.

I think you may have have missed how much work I put into what I published
before talking with people who actually work on the project to find out
what they wouldn't object to before publishing the prior document--
and how much I left out that I would have loved to have in; and why
I specifically held back from describing it as a roadmap or prompting
people to sign onto it (though they did of their own accord).

On a more meta-subject, I think grandly stated "top down" roadmaps
in highly collaborative development are of minimal utility at best and
actively misleading at worst. Fundamentally, it misunderstands the nature
of peer collaboration. It's kind of like asking for a roadmap for the
development of fusion power; individual practitioners have their own
roadmaps, but the collaboration of science does not.

Consider an example,

The Linux kernel is one of the largest and best funded open source
projects, which produces the most widely used operating system kernel
in the world and one of the most widely used pieces of software of all
time, and it produces _no_ roadmaps.

Quoting Andrew Morton, "Instead of a roadmap, there are technical
guidelines. Instead of a central resource allocation, there are
persons and companies who all have a stake in the further development
of the Linux kernel, quite independently from one another: People like
Linus Torvalds and I don’t plan the kernel evolution. We don’t sit
there and think up the roadmap for the next two years, then assign
resources to the various new features. That's because we don’t have
any resources. The resources are all owned by the various corporations
who use and contribute to Linux, as well as by the various independent
contributors out there. It's those people who own the resources who
decide."

Linus remarked, "I look at the current release and the next one, as I
don't think planning 10 years ahead is sane."

Yet the Linux kernel still has every advantage over us:  They have far
more contributing resources from far more sources, they have a fairly
centralized model and control over their own destiny because they have
a much more functional pathway to disagreement than we have in Bitcoin
for consensus rules.

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 (much of it research
I'm working on and strongly support, in fact--)

We can also talk in a visionary sense about the sorts of things we're
exploring, but it just isn't possible to nail down when they'll be
ready until they are: If it's not something the linux kernel can do,
it's not something we can do.  These are neat and existing ideas,
but not a roadmap.

At least not as a group. Individually contributing parties have a lot
more visibility and control into their own activities, and there is
virtue in forecasting at that level. Redhat, for example, has
roadmaps. They primarily deal with stabilization and support of
already existing technology that you could get in the raw from the
various upstream sources (fedora, kernel, etc.). (see for an example,
http://www.slideshare.net/albertspijkers/red-hat-enterprise-linux-roadmap
)

Separately, what we can do stably in Core is have timely reliable
releases.  Juniper made it 10 years with regular timed releases that
did not slip by more than IIRC three days and which were _all_ production
deployable (things changed later, but thats another story).

This was an incredible benefit to our customers, but the only way it was
possible was because _features_ were not guaranteed in a release.
If a feature failed during the final testing and it needed more than the
most trivial of fixes, it was _removed_ or disabled.  As soon as there
are multiple in-flight deliverables it becomes more important to be
timely over-all even that that significantly delays single deliverables.
This is effectively at odds with hard deadlines on functionality, even
before getting into the fact that for consensus features delivery in
software is irrelevant until activation which is a public election.
(E.g. we shipped segwit almost a year ago, but it still hasn't arrived
for users).

From the perspective of Bitcoin I think what people are actually
asking for us to do is to (help) drive the Bitcoin Story-- the actual
technology and its timelines is usually not that relevant: if it were,
they'd be stepping up with resources to contribute to it. There are
many ways to do that, -- we don't have to use highly authoritarian
methods that wouldn't even work for the Linux kernel.

[And all these projects you listed, your help would be more than welcome!]

This can be done by a mixture of talking about research _as research_
not a done deal, and by moving discussions of non-research things to
where they're actually more forecastable.  98% of the public
discussion about segwit was before the pull request, -- there were
solid political reasons for this-- but it was the wrong timing.  On
the case of CSV and CLTV, the general public didn't hear about them
until they were merged -- pretty much-- and the timing then was much
more compatible with 'roadmapping' +/- activation uncertainty.

Some of this is driven by competitive pressure with things like
Ethereum or other altcoins (e.g. dash, god save us) that have a lot
lower commitment to engineering integrity or even logical consistency.
We can't compete with technobabble bullshit, and we shouldn't try and
as a side effect back ourselves into a corner where we're making
remarkable accomplishments but regarded as failures in payment
(because we either forecast it taking N years, which is the best we
could promise, or because we forecast the best we might achieve and it
was both still too long and the timeframe got missed).

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.
(Well not quite mars, see Note 1)
Probably we'll have the research and an implementation done by then, but
with so much uncertainty around segwit activation, I doubt anyone can be
about when users will be able to use it (which is what they care about!)

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

In any case; I can repeat the same story for major RFCs, FWIW.  Collaborative
innovation is _very_ hard to stick to a tight schedule.  And road-maps
of totally prospective technology that no one has the actual authority to make
happen aren't a productive thing for the industry.

In a few weeks you'll start seeing articles on the major new things
coming in Bitcoin Core 0.15,
-- now that we can do, because the work is done, and the outcome is
very predictable. There are some awesome improvements around it-- ones
we can rally around; and know will be delivered for sure.


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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Gregory Maxwell]

On Tue, Jul 11, 2017 at 9:11 PM, Gregory Maxwell <greg@xiph.org> wrote:
> which I have included here a private email
> thread on the subject

To make it clear, since I munged the English on this: Most of my post
is just copied straight out of a private thread where I explained my
perspective on 'roadmaps' as they apply to projects like Bitcoin.

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

Hi Greg,


On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
> 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.
Is this the only reason you do not support the document? If so I would
be happy to take out the section, if enough people share such a view.

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 would like to hear your responses to my claims, if you are
willing to share them. As for positioning DC as a major solution, it is
a little confusing because Luke-Jr and Adam back seem to feel it is at
least worth discussing on those terms (and I know of no reason why it
would not be discussed on those terms). The peer review here on
[bitcoin-dev] seemed to be moving forward without any serious
objections. And it seems unsportsmanlike for you to object, for reasons
which you keep only to yourself.


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

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

> This was an incredible benefit to our customers, but the only way it was
> possible was because _features_ were not guaranteed in a release.
No one is suggesting that features be guaranteed, either ever or in
releases.


> 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 really don't think they are related. For a start, software is almost
always delayed. An obvious second is that this entire scaling
conversation is polarized to the hilt and everyone that can be blamed
for something has been blamed for something.

No one likes to be held to a certain deadline, but this roadmap is just
about producing some clarity for people who do not do this 24/7.

> 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.
I asked Adam Back for it.

> 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)
Again, I think you're missing the point. If there is a problem with SA,
you can just suggest it be removed from the document.


> 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?"
This is a very strange argument. I would consider it a benefit if people
learned from the document, and discovered things that they had not heard
of before.

There is no "insisting" of any kind.


> [  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, 
He probably showed you an earlier draft. But I wrote almost all of this
myself, and I can only recall 2 or 3 phrases (not even complete
sentences) included from Adam Back. And most of the phrases are
themselves just boring descriptions that I'm sure anyone could write.
Some phrases may have simply been taken from bitcoincore.org or
somewhere similar.

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/

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?

Paul

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect]

[-- Attachment #1.1: Type: text/plain, Size: 8613 bytes --]

Dear Paul,

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

I think there are far safer solutions for scaling Bitcoin and integrating it with other chains than DC, which is again, a serious security risk to the whole network, as per [1].

Adopting DC would be an irreversible course of action, and one that in my opinion would unnecessarily damage not only other sidechains, but the main chain as well.

There is no rush, a proper solution is likely to present itself (I even have one that I'm toying with, but it's not quite ready yet for publication). I'm sure others are thinking similar thoughts too.

Kind regards,
Greg Slepak

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html>

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

> On Jul 11, 2017, at 3:17 PM, Paul Sztorc via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> Hi Greg,
> 
> 
> On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
>> 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.
> Is this the only reason you do not support the document? If so I would
> be happy to take out the section, if enough people share such a view.
> 
> 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 would like to hear your responses to my claims, if you are
> willing to share them. As for positioning DC as a major solution, it is
> a little confusing because Luke-Jr and Adam back seem to feel it is at
> least worth discussing on those terms (and I know of no reason why it
> would not be discussed on those terms). The peer review here on
> [bitcoin-dev] seemed to be moving forward without any serious
> objections. And it seems unsportsmanlike for you to object, for reasons
> which you keep only to yourself.
> 
> 
>> On a more meta-subject, I think grandly stated "top down" roadmaps
>> in highly collaborative development are of minimal utility at best
> I'm aiming for minimal utility.
> 
>> 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
> I don't understand this at all. This document attempts to do exactly
> what its predecessor did -- nothing more or less.
> 
>> This was an incredible benefit to our customers, but the only way it was
>> possible was because _features_ were not guaranteed in a release.
> No one is suggesting that features be guaranteed, either ever or in
> releases.
> 
> 
>> 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 really don't think they are related. For a start, software is almost
> always delayed. An obvious second is that this entire scaling
> conversation is polarized to the hilt and everyone that can be blamed
> for something has been blamed for something.
> 
> No one likes to be held to a certain deadline, but this roadmap is just
> about producing some clarity for people who do not do this 24/7.
> 
>> 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.
> I asked Adam Back for it.
> 
>> 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)
> Again, I think you're missing the point. If there is a problem with SA,
> you can just suggest it be removed from the document.
> 
> 
>> 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?"
> This is a very strange argument. I would consider it a benefit if people
> learned from the document, and discovered things that they had not heard
> of before.
> 
> There is no "insisting" of any kind.
> 
> 
>> [  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,
> He probably showed you an earlier draft. But I wrote almost all of this
> myself, and I can only recall 2 or 3 phrases (not even complete
> sentences) included from Adam Back. And most of the phrases are
> themselves just boring descriptions that I'm sure anyone could write.
> Some phrases may have simply been taken from bitcoincore.org <http://bitcoincore.org/> or
> somewhere similar.
> 
> 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/ <https://bitcoincore.org/en/2015/12/21/capacity-increase/>
> 
> 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?
> 
> Paul
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #1.2: Type: text/html, Size: 13429 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect]

[-- Attachment #1.1: Type: text/plain, Size: 3058 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 6983 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

[-- Attachment #1: Type: text/plain, Size: 3085 bytes --]

On 7/11/2017 7:12 PM, Tao Effect wrote:
> 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.

In that case you should clarify, which is exactly what you are doing now.

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

If that were the case, then DC would need to be a hard fork. It so
happens that it is *not* the case -- if users choose to deposit to an
anyone-can-spend output, then miners can take the Bitcoins, which *is*
something that miners can 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 what you are disagreeing with. The three thefts involve
different attacker resources and behaviors, and in that way they are
different. But in all three cases the user has lost the BTC they would
have otherwise owned, and in that way they are not different.

And users are under no obligation to use DC, just as they are under no
obligation to open a LN channel (or use P2SH, etc).

>
> I am not sure how else to respond to that email, given that none of
> the issues were really addressed.
Other than your complaint about being freely given the option to upgrade
to software which will give you the option to freely opt-in to a
different security model that you can otherwise ignore, feel free to
bring up any other issues you feel need to be addressed.

> Drivechain is an unmistakeable weakening of Bitcoin's security
> guarantees. This you have not denied.
That is false. I do deny it. Per the logic of the soft fork, the
security properties are at best unchanged (as I think almost everyone
else on this list would acknowledge). And even for those users who
opt-in, I feel the risk of theft is low, as I explain in the very
passage you've quoted above.

And please try to avoid going off-topic -- this is supposed to be about
the idea of a new roadmap.

Paul

[-- Attachment #2: Type: text/html, Size: 5518 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Jacob Eliosoff]

[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]

Just a quick note in favor of an updated roadmap (some may object to that
label, but I think it's fine).  When you and your friends are planning your
weekly movie outing, it's very helpful to have someone who knows the group,
knows what films are playing, checks people's preferences, mails around
proposals, updates with corrections, keeps a list of choices for future
weeks, etc.  (Certainly not the same as imposing an agenda, except when the
coordinator gets pushy.)

Core veterans like those on this thread are well placed to compile (not
decree) such a document - basically an informed view of what looks likely
to get rough consensus, and in what order.  *Of course* some will dispute
the priorities etc, but it's my experience that if everyone virtuously
refrains from this kind of coordination effort, often the weekend rolls by
without a film.

Agreed that specific deadlines often create more problems than they solve,
but even without dates, clarifying priorities (eg, segwit before HF) is
still useful.

All this is aside from the fact that I have many criticisms of the "movies
chosen" so far and the criteria used to choose them - another thread
(basically, I support an interpretation of "consensus" that takes more note
of non-dev constituents).  The consensus-marshaling effort is still
important, and appreciated.


On Tue, Jul 11, 2017 at 8:21 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

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

[-- Attachment #2: Type: text/html, Size: 2632 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Chris Stewart]

[-- Attachment #1: Type: text/plain, Size: 5147 bytes --]

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



On Tue, Jul 11, 2017 at 6:12 PM, Tao Effect via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

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

[-- Attachment #2: Type: text/html, Size: 8716 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect]

[-- Attachment #1.1: Type: text/plain, Size: 3406 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 7568 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Chris Stewart]

[-- Attachment #1: Type: text/plain, Size: 4453 bytes --]

Hi Greg,

The safest way to ensure everyone's protection to make sure *no one can do
anything*. Then we will ALL be safe ;).

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

Ok, let's calm down.

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

It would be more like "should we allow a car on the road if we know
statistically that our brakes give out in every 1/100,000,000 cars"? There
is security risks with everything in life -- we need to quantify the risk
to see if it is worth taking. I think Paul has been pretty upfront about
the risks of his model. I think you did a good job of demonstrating it in
the email I cited too.

>It is how *insecure* systems are designed.

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

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

I look forward to this!

-Chris

On Wed, Jul 12, 2017 at 2:24 PM, Tao Effect <contact@taoeffect.com> wrote:

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

[-- Attachment #2: Type: text/html, Size: 7769 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect]

[-- Attachment #1.1: Type: text/plain, Size: 5731 bytes --]

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

I think he has been rather misleading in his presentation of the risks.

He outlines them in a very technical manner, yes, but then goes on to promote them to lay people as if they're no big deal, which is completely misleading.

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

That is completely different.

It is disingenuous to say the two are remotely similar. The two situations have little-to-nothing in common.

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.

> On Jul 12, 2017, at 12:34 PM, Chris Stewart <chris@suredbits.com <mailto:chris@suredbits.com>> wrote:
> 
> Hi Greg,
> 
> The safest way to ensure everyone's protection to make sure *no one can do anything*. Then we will ALL be safe ;).
> 
> >If so, please leave, you are compromising Bitcoin's security.
> 
> Ok, let's calm down.
> 
> >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"?
> 
> It would be more like "should we allow a car on the road if we know statistically that our brakes give out in every 1/100,000,000 cars"? There is security risks with everything in life -- we need to quantify the risk to see if it is worth taking. I think Paul has been pretty upfront about the risks of his model. I think you did a good job of demonstrating it in the email I cited too.
> 
> >It is how *insecure* systems are designed.
> 
> By your account bitcoin is already insecure then -- it allows anyone can spend outputs that can be claimed by miners.
> 
> >Sure, happy to, as soon as I have it written up in detail.
> 
> I look forward to this!
> 
> -Chris
> 
> On Wed, Jul 12, 2017 at 2:24 PM, Tao Effect <contact@taoeffect.com <mailto:contact@taoeffect.com>> wrote:
> 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 <mailto: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 <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
>> 
>> 
>> 
> 
> 


[-- Attachment #1.2: Type: text/html, Size: 13179 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[CryptAxe]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 4294 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect]

[-- Attachment #1.1: Type: text/plain, Size: 1927 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 8095 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[CryptAxe]

[-- Attachment #1: Type: text/plain, Size: 2971 bytes --]

You guys are both right that it is a different security model, with the
important distinction that it is opt-in. What I disagree with about what
you said is only that we are encouraging more risky behavior by adding
consensus rules via softfork. There are additional risks with
drivechains, but not because of how the new consensus rules would be
added (it would be the same risk as the P2SH softfork).

What's been explained to me a few times is that the
anyone-can-spend-ness of new transaction types that depend on softforked
consensus rules are exponentially less risky to the point that it is
infeasible to steal them as blocks are added to the chain that activated
the soft fork. I believe that Luke-Jr and Lopp are both very good at
explaining this and I know that Lopp has actually done some research as
to the cost of stealing these outputs. I can't remember the link but you
might find that with a google. One of them might even chime in and
explain that I'm totally wrong again!

Sorry for being a bit heated in my last response.


On 07/12/2017 02:55 PM, Tao Effect wrote:

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


[-- Attachment #2: Type: text/html, Size: 14025 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Bryan Bishop]

I can't help but notice that I have read Greg's email before-- all the
way back in 2016. It would have been impossible for him to write a
reply to Paul's current email back then... but I also notice that Greg
did not indicate that he was copy-pasting until the very end (and even
then his aside at the end was sort of not the most clear it could have
been I think).

On Tue, Jul 11, 2017 at 5:17 PM, Paul Sztorc via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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,
[ snip ]
> I am not exactly sure what you are insinuating but I encourage you to
> clarify it.

I believe that's an artifact of a 2016 email. And the rest of it, for
that matter. See below.

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

The vast majority of Greg's email, including all the positiontext on
roadmaps was mostly text sent on 2016-11-04 to Adam Back, myself,
Wladimir, and others. Some of the other parts aren't, like the part
mentioning Blockstream.

Here is a commitment to a list of the recipients (for whatever good
such a commitment might do):
b1e575e15d86a5a5931ea0bc519701df4cc152f020f03cd7912074ce5c36260a

- Bryan
http://heybryan.org/
1 512 203 0507

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Gregory Maxwell]

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!

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

Greg,

I would summarize your email as stating that: you regret writing the
first email, and regret the fact that it became a roadmap that everyone
signed. And that therefore it is obviously a concept NACK from you.

( That's pretty surprising to me, and I would expect others to find it
surprising as well. And I wonder whether you think we should take the
old one *down*, and why you would allow (?) so many other people to sign
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.

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

I will also respond to this:

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

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 asked me in a personal email earlier today. From my point of view
you had done no research (you failed to uncover any additional names),
used the information I volunteered to you against me (in the form of
false characterizations of negligent email writing!), and you also
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
instead of writing the first draft, I had written nothing, I would be
accused of being the ideas guy and/or "not contributing". You also
(rather rudely), put me in an awkward position, as the people who I
*did* ask now almost certainly prefer that I not reveal their names
(yet, a low name count is held as a strike against my competence).

Such are the perils of posting to bitcoin-dev! Let all be warned! : )

Paul




On 7/11/2017 8:07 PM, Gregory Maxwell wrote:
> 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!

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Bryan Bishop]

On Tue, Jul 11, 2017 at 8:40 PM, Paul Sztorc via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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. )

To me it looked as if I was reading an email that was making a bunch
of points about how bitcoin development can't be coordinated and how
things would be broken if it were to be coordinated ("high authority
edicts"). There was a lot of harm caused by calling that 2015 email a
roadmap. Somehow-- and there's no way to figure out how this happened
I guess- people started putting timeline commitments to different
features. But there's really no way to guarantee any of those
timelines. And I think it's very quick to reach the point of unethical
to advocate a perspective that there's guarantee to things will happen
according to that timeline in the standard bitcoin development model.
I think there's already such a huge amount of public misunderstanding
around how bitcoin development works that giving guarantees even as a
community would further increase the misunderstandings.

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

I think generally communicating about research directions and projects
is useful and valuable, and I don't see any disagreement about that in
itself from anyone in this thread. I recommend an abundance of caution
with regards to whether to call these efforts roadmaps.

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

Well I mean he did look at some of the people putting the most effort
into bitcoin development. Why would he start at the other end of the
list as a rough check..?

> 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

Those suggestions were mixed with strong avocado that summaries are
good, coupled with recommendations that these aren't really roadmaps.
As to qualifying from where knowledge is sourced, yeah it seems like
talking with developers is a good idea, it seems everyone agrees with
that in this thread.

> 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

Well, to the extent that criticism is being misinterpreted as hostile,
I have seen people get upset from basic security review because "why
were't we more friendly and just say OK instead of pointing out the
problems".

- Bryan
http://heybryan.org/
1 512 203 0507

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Gregory Maxwell]

On Wed, Jul 12, 2017 at 1:40 AM, Paul Sztorc <truthcoin@gmail.com> wrote:
> 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).

You've complained in this thread that Tao Effects' specific criticisms
were off-topic for the thread. I agree.

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

Yes, but apparently none of the most active developers or people
working on the proposals you named.  But you're fully entitled to
write about whatever you want while talking to whomever you want or
even without talking to anyone at all.

But, strategically it seems a little ill-advised.

For example, had you spoken to me I would have advised against the
dates offered for signature agg-- which would be more realistic for
publication of a complete proposal and implementation that the
community could finally have an opinion on, not for actual deployment;
and I probably would have discouraged highlighting compaction since we
haven't worked on that much since December due to other priorities.

(I also would have forwarded you my general concern about 'roadmaps'
as a communication tool.)

Maybe this could saved a bit of time and discussion, maybe not!

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

I apologize for causing you to feel anything was used against you.  I
don't support the roadmap-approach you propose here-- but my failure
to support it is definitionally non-personal according to the laws of
time and space: I wrote that opposition to other peoples similar
proposal some nine months ago, in private-- it has nothing to do with
you in a rather profound and physical sense.

To the extent that I criticize whom you talked to, it was intended to
be merely a remark on strategy: You yourself stated that "wrote the
roadmap to try to be representative of a Core / developer position",
but you didn't talk to the major developers or the authors of the
things you put on the roadmap--  there is /nothing improper/ or bad
about that... but I don't think it was good strategy. Feel free to
disagree, it was-- perhaps-- unsolicited advice.

It seems to me that your goal is creating more communication around
the clear set of obvious shared intentions; sounds great. Dressing it
as an official "roadmap" I think works counter to that purpose, and to
really be successful with the communications goal  I think it would be
best to go around privately polling major actors to find out what
they'd add or remove then take the intersection then spare everyone
the debate.  Not that debate isn't good, but we shouldn't shouldn't be
debating over an omnibus bill that needlessly ties things together,
people can debate each initiative on its own merits in its own
threads... the purpose was to communicate, right?  I do support that
goal, even though I don't think I support the current approach.

As before-- that is more unsolicited advice, feel free to ignore it.
Just keep in mind that no one owes anyone a response. I did take the
time to read and understand your message. I'm sorry that my response
isn't more to your liking. I'm thankful that you read and responded to
my reply.

Cheers,

[bitcoin-dev] how to disable segwit in my build?

[Dan Libby]

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.

As I understand it, there is not any user setting that can disable
segwit from activating on my node.  If there was, I would use it.
Please correct me if wrong.

I am here to ask what is the simplest code change (fewest LOC changed) I
can make to 0.14.2+ code that would disable segwit from activating and
keep my node acting just like a legacy node with regards to consensus
rules, even if/when the rest of the network activates segwit.

I think, more generally, the same question applies to most any Bip9
versionbits feature.

I'm not looking for reasons NOT to do it, only HOW to do it without
unwanted side-effects.  My first untested idea is just to change the
segwit nTimeout in chainparams.cpp to a date in the past.  But I figured
I should ask the experts first.   :-)

thanks.


ps: full disclosure:  I may be the only one who wants this, but if
successful, I do plan to release my changes in case someone else wishes
to run with status-quo consensus rules.

Re: [bitcoin-dev] how to disable segwit in my build?

[Gregory Maxwell]

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.

Having a node that supports it won't make it more likely to activate,
you can mine without signaling segwit even on a node that supports it.
Your own transactions will not use segwit just because your node
supports it.

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.

Re: [bitcoin-dev] how to disable segwit in my build?

[Federico Tenga]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1148 bytes --]

Re: [bitcoin-dev] how to disable segwit in my build?

[Hampus Sjöberg]

[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]

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

Greetings
Hampus

2017-07-13 15:11 GMT+02:00 Federico Tenga via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

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

[-- Attachment #2: Type: text/html, Size: 3033 bytes --]

Re: [bitcoin-dev] how to disable segwit in my build?

[Dan Libby]

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.

Re: [bitcoin-dev] how to disable segwit in my build?

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev <
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.


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

[-- Attachment #2: Type: text/html, Size: 2854 bytes --]

Re: [bitcoin-dev] how to disable segwit in my build?

[Dan Libby]

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!

Re: [bitcoin-dev] how to disable segwit in my build?

[Hampus Sjöberg]

[-- Attachment #1: Type: text/plain, Size: 4988 bytes --]

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

Yes, this applies to all non-SegWit nodes.

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

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

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

So how softforks often work is that you make the transaction appear to be
always spendable for old nodes, regardless if it really was spendable or
not. This will make sure it is a softfork, the update is backwards
compatible.
If it would be the other way around, if new rules that the node doesn't
understand would always be invalid, it would be hardfork, which is what
we're trying to avoid in the first place.

> so if
someone can point me towards a document that explains it I'd be happy to
read that.

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

Cheers
Hampus

2017-07-13 23:58 GMT+02:00 Dan Libby via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

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

[-- Attachment #2: Type: text/html, Size: 6533 bytes --]

Re: [bitcoin-dev] how to disable segwit in my build?

[Dan Libby]

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!

Re: [bitcoin-dev] how to disable segwit in my build?

[Hampus Sjöberg]

[-- Attachment #1: Type: text/plain, Size: 3679 bytes --]

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

Yes, as soon as you receive new Bitcoins, there's a chance that they have
been in a SegWit transaction at some point.
I'm not sure if you can see the chain of transactions for an address in
bitcoin-cli, but if that is possible, you should be able to double check
the transaction types.

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

Hmm yes, if you reject a such transaction, you'll hardfork the network.
If you ignore it in your wallet, you'll be safe, but you'll lose those
bitcoins ofc.
It's a difficult situation.

> I suppose that it would be possible without modifying any rule to
construct a "certain balance" and an "uncertain balance".

Should be possible.

> Hampus, thanks for the explanation!

You're welcome!
I personally very much like and want SegWit, but I respect people that
wants to maintain the status quo, it's what will make Bitcoin strong in the
long run.

Cheers
Hampus

2017-07-14 1:20 GMT+02:00 Dan Libby via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

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

[-- Attachment #2: Type: text/html, Size: 4977 bytes --]

Re: [bitcoin-dev] how to disable segwit in my build?

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 3748 bytes --]

On Fri, Jul 14, 2017 at 12:20 AM, Dan Libby via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

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

You would also have to ensure that everyone you give your addresses to
follows the same rule.  As time passes, there would be fewer and fewer
people who have "clean" outputs.

From the perspective of old nodes, segwit looks like lots of people are
transferring money to "anyone-can-spend" outputs.  This outputs are
completely unprotected.  Literally, anyone can spend them.  (In practice,
miners would spend them, since why would they include a transaction that
sends "free money" to someone else).

If you run an old node, then someone could send you a transaction that only
spends segwit outputs and you would think it is a valid payment.

Imagine that there are only 3 UTXOs (Alice, Bob and Carl have all the
Bitcoins).

UTXO-1:  Requires signature by Alice (legacy output)

UTXO-2: Anyone can pay (but is actually a segwit output that needs to be
signed by Bob)

UTXO-3: Anyone can pay (but is actually a segwit output that needs to be
signed by Carl)

Only Bob can spend UTXO-2, since it needs his signature.

Anyone could create a transaction that spends UTXO-2 and it would look good
to all legacy nodes.  It is an "anyone can spend" output after all.

However, if they submit the transaction to the miners, then it will be
rejected, because according to the new rules, it is invalid (it needs to be
signed by Bob).

Once a soft fork goes through, then all miners will enforce the new rules.

A miner who added the transaction to one of his blocks (since it is valid
under the old rules) would find that no other miners would accept his block
and he would get no fees for that block.  This means that all miners have
an incentive to upgrade once a soft fork activates.

His block would be accepted by legacy nodes, for a short while.  However,
since 95% of the miners are on the main chain, their chain (which rejects
his block) would end up the longest.

If you are running a legacy client when a soft fork comes in, then you can
be tricked with "zero confirm" transactions.  The transaction will look
good to you, but will be invalid under the new rules.  This makes your
client think you have received (a lot of) money, but in practice, the
transaction will not be accepted by the miners.


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

If you wanted, you could mark any transaction that has a segwit looking
output as "dirty" and then all of its descendants as dirty.

However, pretty quickly, only a tiny fraction of all bitcoins would be
clean.

I suppose that it would be possible without modifying any rule to
> construct a "certain balance" and an "uncertain balance".
>

Right.

I think a reasonably compromise would be to assume that all transactions
buried more than a few hundred blocks deep are probably ok.  Only segwit
looking outputs would be marked as "uncertain".

[-- Attachment #2: Type: text/html, Size: 4837 bytes --]

Re: [bitcoin-dev] how to disable segwit in my build?

[Lucas Clemente Vella]

[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]

2017-07-13 18:58 GMT-03:00 Dan Libby via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

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

From your perspective, the P2WPKH will look like a anyone-can-spend
transaction, thus, valid no matter who is spending. So, you would be
basically leaving the security of segwit transactions to those who actually
are interested in and using them. If your fork becomes popular, it would
decrease the security of Segwit transactions to something akin to the
security model of the Drivechain currently being discussed: only those
particularly interested in that particular sidechain (and segwit witness
could be loosely categorized into a sidechain) will be responsible to
prevent others from stealing funds from the anyone-can-spend transactions.

-- 
Lucas Clemente Vella
lvella@gmail.com

[-- Attachment #2: Type: text/html, Size: 1834 bytes --]

Re: [bitcoin-dev] how to disable segwit in my build?

[Dan Libby]

On 07/12/2017 06:04 PM, Gregory Maxwell wrote:
> 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.

I understand it is not in any way a supported configuration.

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

Please lets not go into the weeds debating about my reasons.

I actually have nothing against segwit per-se, and think it is clever
tech.  I wish that it, or another malleability fix, had been baked in
from the start.  But it wasn't, and I dislike changing the consensus
rules except if critical flaws are found.


anyway, some of my reasons are:

I am content with status-quo consensus rules.

I see greatest long-term value in a fixed, unchanging set of rules
(though that is outside my control of course).

I have limited bandwidth and resources and prefer 1mb limit for that reason.

Prior to activation, I do not choose to signal for segwit in any way
shape or form.

I realize I could run a pre-segwit node forever, but would like to enjoy
more recent features and otherwise avoid bit-rot.

I am mule-headed and stubborn.  If network-wide activation should
happen, I will most likely upgrade to segwit at some point, but I intend
that point to be at my choosing, not because software defaults did it
for me.

I view it as a little bit of a personal challenge and experiment.

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

no that thought did not enter my mind.  still not sure I fully grok it
in fact, but no matter.



-- 
Dan Libby

Open Source Consulting S.A.
Santa Ana, Costa Rica
http://osc.co.cr
phone: 011 506 2204 7018
Fax: 011 506 2223 7359

Re: [bitcoin-dev] how to disable segwit in my build?

[Troy Benjegerdes]

On Thu, Jul 13, 2017 at 01:04:19AM +0000, Gregory Maxwell via bitcoin-dev wrote:
> 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.
 
And this attitude is why bitcoin-core is going to get dropped and,
hopefully, instead of just one code to rule them all, we will have
good specifications and multiple competing implementations.

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

One of the significant adverse impacts of Segwit is the following:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2861

When viewed on Github, less than one third of the consensus-critical
code is visible on-screen.

This is a maintenance and readability nightmare, in my opinion. There
are many good reasons why giving *users* the ability to firewall off
that code, maybe even with #ifdefs, as ugly as they are, would provide
some much better confidence that one is indeed, not running segwit.

I suspect it would help the community a great deal in comfort level
if this code were easier to read and used some type of coding standard
in which the default github view on the average browser shows all the
code without having a "hidden feature" that requires scrolling that
has no obvious UI indication you even need to scroll.

Re: [bitcoin-dev] how to disable segwit in my build?

[Anthony Towns]

On Tue, Jul 11, 2017 at 11:17:24PM -0700, Dan Libby via bitcoin-dev wrote:
> 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 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. :)

Cheers,
aj

Re: [bitcoin-dev] how to disable segwit in my build?

[Dan Libby]

On 07/12/2017 06:48 PM, Anthony Towns via bitcoin-dev wrote:

> 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

I wish to NOT signal for segwit if mining.

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

I wish to NOT enforce segwit consensus rules.

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

good point, thanks for clarifying.

> 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've set the nTimeout to 0 already.  I will look into the NODE_WITNESS
p2p bit.

I think that logically, if coded correctly, my node would have no more
risks than any other legacy (pre-segwit) node on the network...

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

fair enough.  But these are the same risks as running any pre-segwit
node, correct?    For example bitcoin-core 0.13.0, or any version of
btcd to date...


-- 
Dan Libby

Open Source Consulting S.A.
Santa Ana, Costa Rica
http://osc.co.cr
phone: 011 506 2204 7018
Fax: 011 506 2223 7359

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Karl Johan Alm]

On Wed, Jul 12, 2017 at 6:11 AM, Gregory Maxwell via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.

Bitcoin development differs from Linux kernel development in a number
of obvious ways, such as the fact Bitcoin is being "patched in
flight". The current political situation over Bitcoin development is
also quite different, with scalability being a major concern for a lot
of users, and conflicting views leading to risky technical gambles.

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, in particular for the scaling
solutions. Putting deadlines and dates in would of course be highly
irresponsible, as no one can predict how much of their free time
volunteer developers will put into the project in advance (or whether
they will stick around for the next X months or stop being
contributors).

I think there is necessity for a document that describes the project
intentions for scaling solutions, but I don't think adding dates and
deadlines is appropriate. That may or may not be a roadmap. I imagine
such a document would be updated regularly as appropriate, which means
it may be less of a roadmap than the traditional kind.

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tom Zander]

On Wednesday, 12 July 2017 03:22:59 CEST Karl Johan Alm via bitcoin-dev 
wrote:
> Bitcoin development differs from Linux kernel development in a number
> of obvious ways, such as the fact Bitcoin is being "patched in
> flight".

I've heard this before and it doesn't make any sense to me. Just like your 
Linux box needs a reboot to get a kernel upgrade, your node needs a restart 
to upgrade. Neither the (entire) internet will go down nor the (entire) 
Bitcoin network will go down as a result.

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

This is fine, and groups that do development should do this more structured 
than something like https://bitcoinhardforkresearch.github.io/

It just would not make any sense to have a roadmap for the *entire* industry 
as this would require you to decide what technical solution is better than 
another before either of them are fully researched.

Individual groups can have solutions that they believe is the best. And then 
we can let the market decide which one is to be actually activated.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tom Zander]

On Tuesday, 11 July 2017 23:11:38 CEST Gregory Maxwell via bitcoin-dev 
wrote:
> 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.

I”m thinking along the same lines, a industry wide roadmap makes very little 
sense.

Much like in Linux we have a lot of smaller groups doing their own thing, 
all working for the good of Linux as they see it, and implicitly, as they 
use it.
I think its safe to say that Linus would not want any say over the roadmap 
of Intel or Google or any other particpant in the Linux space.

I am in agreement with Gregory that we should reject a Bitcoin-wide scaling 
roadmap.

I do suggest that smalle groups publish their individual roadmaps, show what 
they are planning to work on in a place that people will find it (a website, 
not a mailinglist archive).

Those individual roadmaps then show what that group will work on, which 
helps their communication. It helps people talking about Bitcoin to the 
general public as well, and it helps people understand whom they would like 
to support financially or otherwise.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Anthony Towns]

On Mon, Jul 10, 2017 at 12:50:21PM -0400, Paul Sztorc via bitcoin-dev wrote:
> We should revise [the roadmap]: remove what has been accomplished, 
> introduce new innovations and approaches, and update deadlines 
> and projections.

Timelines have good and bad points (in this context, I'd generally call
projections good, deadlines bad :); people have interpreted the lack of
any clear timeline for a hardmark on the 2015 roadmap as no plan for a
hard fork at all; meanwhile the overly optimistic timeline for segwit
being "ready" in April or July last year has been interpreted as "ready
for use" and treated as a failure, when it didn't work out that way.

I think it would be helpful for the development community to have some
way of talking about timelines, for instance to be able to say "the
*minimum* timeline for a reasonable hard fork is 6 months for proposal
review, speculative analysis and initial coding, 3 months for concrete
proposal review and thorough testing, 3-6 months for consensus to develop
on whether to lock the proposed changes in as the new consensus, and
a further 6-24 months for wide scale deployment to occur before any
behavioural change to take actual effect".

Those numbers give a lead time of 18 to 38 months of engagement with the
developer community before it takes effect, as compared to the six month
timeline of the New York agreement. 18 months implies that a block size
increase would be *available* today if people wanting larger blocks had
engaged with the development community from January 2016 in the same
way that segwit was developed, rather than working in their own sandboxes.

That could have happened: the proposals in 

  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011995.html

from Dec 2015 could have been engaged with, and, optimistically, we could
have a non-controversial deployment of SpoonNet already if they had been.

It might be a good idea to actually engage with investors and businesses
on this: the point of the timelines above isn't to slow things down for
its own sake, it's that you need to take time in order to think through
the potential consequences of changes, and avoid unintended bad outcomes.
That seems like something that investors and businesses can understand,
and endorse up front -- and they could meaningfully do so simply by saying
"any hard-fork that does not go through each of the stages for at least
the minimum time will be treated as an altcoin rather than an upgrade
of bitcoin". But the process has to be "here is what it takes from a
technical POV to avoid fucking up bitcoin; does your company endorse
being responsible with other people's money despite the costs of doing
so?" If you're in a move-fast-and-break-things mode, the answer might
legitimately be "no", of course.

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

I'd suggest dividing the activities into phases more clearly; maybe:

 - Already available to users:
     * version bits
     * compact block relay
     * FIBRE
     * CSV
     * better fee estimation

 - Awaiting consensus:
     * segregated witness

 - Active development / concrete specifications:
     * lightning network
     * light client mode for bitcoin core (PR#10794)

 - Draft proposals at experimental stage:
     * transaction compression? (or is this the already deployed stuff?)
     * schnorr sig aggregation
     * drivechain
     * spoonnet
     * mimblewimble
     * block size increases

 - Ideas that aren't even experiments yet
     * asicboost prevention

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

As above, it seems to me that 18 months of engagement is likely a bare
minimum amount of time for a robustly implemented hard fork (6 months is
almost exactly segwit2x's total timeline, from proposal in late May as
the New York Agreement to the new rules being available in mid-November,
and it doesn't look at all robust to me).  

Possibly if the existing features of spoonnet are already adequate,
you could cut that down by a few months. But realistically, that says
to me early 2019 at the absolute earliest, and if engagement with the
development process doesn't start tomorrow, later than that.

FWIW, here's a longer form draft of what I think hard fork guidelines
maybe could look like:

  https://gist.github.com/ajtowns/914cf2309822bff357cda4ab3f48a966

It's obviously blatantly contradictory with support of the NYA/segwit2x,
but at this point I think that's true of any process that's not just
a rephrasing of "move fast and break things".

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

Publishing something like this as an informational BIP every year or
two seems like a good idea to me.

Instead of a "roadmap" (with the implication that there's a schedule
people might rely on and developers have to meet), maybe just have it as
a list of the current high impact scaling features being worked on --
where the purpose of publishing the list is to let people understand
how far various ideas have progressed currently, and focus attention on:

  - wider adoption of already deployed features, by users, exchanges,
    wallets, etc; eg segwit doesn't scale anything if no one uses it
  - achieving activation of implemented features
  - encouraging R&D on approaches that are currently still experimental
    in order to make them actually usable

In that case, there's no actual need for guessing at future dates;
just the current status is sufficient.

Documenting current roadblocks might also be valuable (eg, lightning and
signature aggregation and drivechains etc are kind-of stalled waiting
on segwit's activation, I think; for a brief point, segwit was stalled
waiting on compact blocks, etc). Might not be worthwhile updating the doc
regularly to keep track of what's a roadblock though.

(I think you could usefully generalise beyond scaling to just "high
impact features" really)

Cheers,
aj

Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]

[Paul Sztorc]

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

Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]

[Alex Morcos]

[-- Attachment #1: Type: text/plain, Size: 11385 bytes --]

"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 1:13 PM, Paul Sztorc via bitcoin-dev <
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
> (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
>

[-- Attachment #2: Type: text/html, Size: 15469 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]

[Paul Sztorc]

[-- Attachment #1: Type: text/plain, Size: 15572 bytes --]

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

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


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

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

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


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

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

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

Paul



> On Mon, Jul 17, 2017 at 1:13 PM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     Hello,
>
>     Last week I posted about updating the Core Scalability Roadmap.
>
>     I'm not sure what the future of it is, given that it was concept
>     NACK'ed
>     by Greg Maxwell the author of the original roadmap, who said that 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>
>
>


[-- Attachment #2: Type: text/html, Size: 23940 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

On Mon, Jul 17, 2017 at 02:49:22PM -0400, Alex Morcos via bitcoin-dev wrote:
> "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.

Agreed!

A closely related example is my own Treechains work, which got a bunch of
excitement when I first published the idea. But would I have wanted it on a
roadmap? Hell no: sure enough, as it got more peer review others (and myself!)
found that it was going to be a harder than it initially looked to actually get
into production.

Drivechains is definitely in that situation right now.

Also don't forget that proper security peer review takes a *lot* of work. I
myself have a todo list item to respond to Paul's post on Drivechains, but I
need to spend a few days to do that and just haven't had the time (not to
mention that no-one is paying me to do general Bitcoin dev work right now).

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]

[Paul Sztorc]

On 7/17/2017 5:47 PM, David A. Harding wrote:
> 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.
I meant only to convey that the document would appear on bitcoincore.org
iff the PR were ultimately accepted. In other words, while it is up to
"the community of Core Contributors" in a philosophical sense, it is up
to the maintainers of BitcoinCore.org in a practical sense, because they
are the ones who ultimately decide if the standard has been met.

I think it is perfectly reasonable to keep site-updates narrowly
organized in the GitHub PR sphere (and to ignore everything else).

> [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 appreciate you saying that. Thank you.

-Paul


> 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