Discussion:
[bitcoin-dev] Updating the Scaling Roadmap
Paul Sztorc via bitcoin-dev
2017-07-10 16:50:21 UTC
Permalink
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
Chris Stewart via bitcoin-dev
2017-07-11 16:03:45 UTC
Permalink
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 <
Post by Paul Sztorc via bitcoin-dev
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 ====
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).
https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNoc
mCq-jjBOQSVH-A/edit?usp=sharing
Cheers,
Paul
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Pieter Wuille via bitcoin-dev
2017-07-11 20:01:10 UTC
Permalink
On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev" <
bitcoin-***@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
Paul Sztorc via bitcoin-dev
2017-07-11 20:36:36 UTC
Permalink
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
Post by Pieter Wuille via bitcoin-dev
On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev"
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
Pieter Wuille via bitcoin-dev
2017-07-11 21:40:36 UTC
Permalink
Post by Paul Sztorc via bitcoin-dev
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.
Post by Paul Sztorc via bitcoin-dev
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.
Post by Paul Sztorc via bitcoin-dev
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
Paul Sztorc via bitcoin-dev
2017-07-11 22:49:19 UTC
Permalink
Post by Pieter Wuille via bitcoin-dev
Post by Paul Sztorc via bitcoin-dev
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.
Post by Pieter Wuille via bitcoin-dev
Post by Paul Sztorc via bitcoin-dev
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).
Post by Pieter Wuille via bitcoin-dev
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.
Post by Pieter Wuille via bitcoin-dev
Post by Paul Sztorc via bitcoin-dev
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
CryptAxe via bitcoin-dev
2017-07-11 21:16:52 UTC
Permalink
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.
Post by Pieter Wuille via bitcoin-dev
On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev"
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Paul Sztorc via bitcoin-dev
2017-07-11 20:18:04 UTC
Permalink
Hi Chris,
Post by Chris Stewart via bitcoin-dev
Concept ACK.
I think you are overstating the readiness of drivechains though. I
think the optimistic estimate for drivechains to be ready for bitcoin
core is a year out from today. More likely the date should be early
2018. Still a lot of work to be done! :-)
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).
Post by Chris Stewart via bitcoin-dev
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
Post by Chris Stewart via bitcoin-dev
-Chris
On Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev
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
Gregory Maxwell via bitcoin-dev
2017-07-11 21:31:29 UTC
Permalink
On Tue, Jul 11, 2017 at 8:18 PM, Paul Sztorc via bitcoin-dev
Post by Paul Sztorc via bitcoin-dev
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!
Post by Paul Sztorc via bitcoin-dev
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.
Paul Sztorc via bitcoin-dev
2017-07-11 22:27:56 UTC
Permalink
Post by Gregory Maxwell via bitcoin-dev
On Tue, Jul 11, 2017 at 8:18 PM, Paul Sztorc via bitcoin-dev
Post by Paul Sztorc via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
Post by Paul Sztorc via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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?
Adam Back via bitcoin-dev
2017-07-11 16:49:57 UTC
Permalink
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
Post by Chris Stewart via bitcoin-dev
Concept ACK.
I think you are overstating the readiness of drivechains though. I think the
optimistic estimate for drivechains to be ready for bitcoin core is a year
out from today. More likely the date should be early 2018. Still a lot of
work to be done! :-)
Also I don't know if I would put a hard fork suggestion in the scaling map.
If drivechains are successful they should be viewed as the way we scale --
not hard forking the protocol. Do you still have capacity concerns if
drivechains are successful?
-Chris
On Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev
Post by Paul Sztorc via bitcoin-dev
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 ====
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).
https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing
Cheers,
Paul
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Gregory Maxwell via bitcoin-dev
2017-07-11 21:11:38 UTC
Permalink
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. ]
Gregory Maxwell via bitcoin-dev
2017-07-11 21:40:28 UTC
Permalink
Post by Gregory Maxwell via bitcoin-dev
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.
Paul Sztorc via bitcoin-dev
2017-07-11 22:17:19 UTC
Permalink
Hi Greg,
Post by Gregory Maxwell via bitcoin-dev
I think it's great that people want to experiment with things like
drivechains/sidechains and what not, but their security model is very
distinct from Bitcoin's and, given the current highly centralized
mining ecosystem, arguably not very good. So positioning them as a
major solution for the Bitcoin project is the wrong way to go. Instead
we should support people trying cool stuff, at their own risk.
So, given that although the vast majority of the things in the document
are things I've been supporting for months (Please see Note 1 way down
at the bottom) I cannot support your document.
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.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
[ 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.
Post by Gregory Maxwell via bitcoin-dev
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
Tao Effect via bitcoin-dev
2017-07-11 22:41:18 UTC
Permalink
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.
Post by Paul Sztorc via bitcoin-dev
Hi Greg,
Post by Gregory Maxwell via bitcoin-dev
I think it's great that people want to experiment with things like
drivechains/sidechains and what not, but their security model is very
distinct from Bitcoin's and, given the current highly centralized
mining ecosystem, arguably not very good. So positioning them as a
major solution for the Bitcoin project is the wrong way to go. Instead
we should support people trying cool stuff, at their own risk.
So, given that although the vast majority of the things in the document
are things I've been supporting for months (Please see Note 1 way down
at the bottom) I cannot support your document.
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.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
[ 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.
Post by Gregory Maxwell via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Paul Sztorc via bitcoin-dev
2017-07-11 22:57:12 UTC
Permalink
Post by Tao Effect via bitcoin-dev
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
Post by Tao Effect via bitcoin-dev
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
Paul Sztorc via bitcoin-dev
2017-07-12 00:21:09 UTC
Permalink
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.
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
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
Jacob Eliosoff via bitcoin-dev
2017-07-12 07:27:32 UTC
Permalink
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 <
Post by Paul Sztorc via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Chris Stewart via bitcoin-dev
2017-07-12 19:19:03 UTC
Permalink
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 <
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.
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
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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Tao Effect via bitcoin-dev
2017-07-12 19:24:28 UTC
Permalink
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.
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
Chris Stewart via bitcoin-dev
2017-07-12 19:34:54 UTC
Permalink
Hi Greg,

The safest way to ensure everyone's protection to make sure *no one can do
anything*. Then we will ALL be safe ;).
Post by Tao Effect via bitcoin-dev
If so, please leave, you are compromising Bitcoin's security.
Ok, let's calm down.
Post by Tao Effect via bitcoin-dev
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.
Post by Tao Effect via bitcoin-dev
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.
Post by Tao Effect via bitcoin-dev
Sure, happy to, as soon as I have it written up in detail.
I look forward to this!

-Chris
Post by Tao Effect via bitcoin-dev
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.
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
Tao Effect via bitcoin-dev
2017-07-12 19:42:49 UTC
Permalink
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.
Hi Greg,
The safest way to ensure everyone's protection to make sure *no one can do anything*. Then we will ALL be safe ;).
Post by Tao Effect via bitcoin-dev
If so, please leave, you are compromising Bitcoin's security.
Ok, let's calm down.
Post by Tao Effect via bitcoin-dev
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.
Post by Tao Effect via bitcoin-dev
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.
Post by Tao Effect via bitcoin-dev
Sure, happy to, as soon as I have it written up in detail.
I look forward to this!
-Chris
Dear Chris,
Post by Tao Effect via bitcoin-dev
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.
Post by Tao Effect via bitcoin-dev
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.
Post by Tao Effect via bitcoin-dev
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
CryptAxe via bitcoin-dev
2017-07-12 19:54:48 UTC
Permalink
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.
Post by Tao Effect via bitcoin-dev
...
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.
CryptAxe via bitcoin-dev
2017-07-12 22:07:47 UTC
Permalink
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.
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
--
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
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.
Post by Tao Effect via bitcoin-dev
...
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Bryan Bishop via bitcoin-dev
2017-07-11 23:36:12 UTC
Permalink
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
Post by Paul Sztorc via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
[ 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 ]
Post by Paul Sztorc via bitcoin-dev
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.
Post by Paul Sztorc via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
Gregory Maxwell via bitcoin-dev
2017-07-12 00:07:51 UTC
Permalink
Post by Paul Sztorc via bitcoin-dev
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...)
Post by Paul Sztorc via bitcoin-dev
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.
Post by Paul Sztorc via bitcoin-dev
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.
Post by Paul Sztorc via bitcoin-dev
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.
Post by Paul Sztorc via bitcoin-dev
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]
Post by Paul Sztorc via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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!
Paul Sztorc via bitcoin-dev
2017-07-12 01:40:32 UTC
Permalink
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).
Post by Gregory Maxwell via bitcoin-dev
Post by Paul Sztorc via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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
Post by Gregory Maxwell via bitcoin-dev
Post by Paul Sztorc via bitcoin-dev
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...)
Post by Paul Sztorc via bitcoin-dev
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.
Post by Paul Sztorc via bitcoin-dev
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.
Post by Paul Sztorc via bitcoin-dev
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.
Post by Paul Sztorc via bitcoin-dev
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]
Post by Paul Sztorc via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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!
Bryan Bishop via bitcoin-dev
2017-07-12 02:48:38 UTC
Permalink
On Tue, Jul 11, 2017 at 8:40 PM, Paul Sztorc via bitcoin-dev
Post by Paul Sztorc via bitcoin-dev
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.
Post by Paul Sztorc via bitcoin-dev
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.
Post by Paul Sztorc via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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..?
Post by Paul Sztorc via bitcoin-dev
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.
Post by Paul Sztorc via bitcoin-dev
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
Gregory Maxwell via bitcoin-dev
2017-07-12 03:33:47 UTC
Permalink
Post by Paul Sztorc via bitcoin-dev
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.
Post by Paul Sztorc via bitcoin-dev
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!
Post by Paul Sztorc via bitcoin-dev
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,
Dan Libby via bitcoin-dev
2017-07-12 06:17:24 UTC
Permalink
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.
Gregory Maxwell via bitcoin-dev
2017-07-13 01:04:19 UTC
Permalink
On Wed, Jul 12, 2017 at 6:17 AM, Dan Libby via bitcoin-dev
Post by Dan Libby via bitcoin-dev
Hi!
Up to now, I have purposefully been running bitcoin releases prior to
0.13.1 as a way to avoid the (possible) segwit activation, at least
until such time as I personally am comfortable with it.
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.
Federico Tenga via bitcoin-dev
2017-07-13 13:11:21 UTC
Permalink
On 13 July 2017 at 03:04, Gregory Maxwell via bitcoin-dev <
Post by Gregory Maxwell via bitcoin-dev
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.
Hampus Sjöberg via bitcoin-dev
2017-07-13 13:39:40 UTC
Permalink
Post by Federico Tenga via bitcoin-dev
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 <
Post by Federico Tenga via bitcoin-dev
On 13 July 2017 at 03:04, Gregory Maxwell via bitcoin-dev <
Post by Gregory Maxwell via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Dan Libby via bitcoin-dev
2017-07-13 16:19:00 UTC
Permalink
Post by Federico Tenga via bitcoin-dev
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.
Jameson Lopp via bitcoin-dev
2017-07-13 16:35:46 UTC
Permalink
On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev <
Post by Dan Libby via bitcoin-dev
Post by Federico Tenga via bitcoin-dev
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.
Post by Dan Libby via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Dan Libby via bitcoin-dev
2017-07-13 21:58:04 UTC
Permalink
Post by Jameson Lopp via bitcoin-dev
On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev
Post by Federico Tenga via bitcoin-dev
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!
Hampus Sjöberg via bitcoin-dev
2017-07-13 22:50:32 UTC
Permalink
Post by Dan Libby via bitcoin-dev
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.
Post by Dan Libby via bitcoin-dev
If I understand correctly, my node will accept the incoming tx inputs
but obviously will not perform any segwit related validation, thus those
inputs are not fully validated.

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
Post by Dan Libby via bitcoin-dev
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.
Post by Dan Libby via bitcoin-dev
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 <
Post by Dan Libby via bitcoin-dev
Post by Jameson Lopp via bitcoin-dev
On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev
Post by Federico Tenga via bitcoin-dev
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
Post by Jameson Lopp via bitcoin-dev
node lower.
If the majority of the network decides to deploy SegWit, it would
be in
Post by Jameson Lopp via bitcoin-dev
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
Post by Jameson Lopp via bitcoin-dev
transactions in the chain of transactions for your bitcoins,
otherwise
Post by Jameson Lopp via bitcoin-dev
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
Post by Jameson Lopp via bitcoin-dev
case for having an up-to-date non-SegWit node, although I think
it's a
Post by Jameson Lopp via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Dan Libby via bitcoin-dev
2017-07-13 23:20:45 UTC
Permalink
Hampus, thanks for the explanation!
Post by Hampus Sjöberg via bitcoin-dev
Yes.
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.
Post by Hampus Sjöberg via bitcoin-dev
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!
Tier Nolan via bitcoin-dev
2017-07-14 09:03:58 UTC
Permalink
On Fri, Jul 14, 2017 at 12:20 AM, Dan Libby via bitcoin-dev <
Post by Dan Libby via bitcoin-dev
Post by Hampus Sjöberg via bitcoin-dev
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.
Post by Dan Libby via bitcoin-dev
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
Post by Dan Libby via bitcoin-dev
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".
Hampus Sjöberg via bitcoin-dev
2017-07-14 08:52:42 UTC
Permalink
Post by Dan Libby via bitcoin-dev
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.
Post by Dan Libby via bitcoin-dev
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.
Post by Dan Libby via bitcoin-dev
I suppose that it would be possible without modifying any rule to
construct a "certain balance" and an "uncertain balance".

Should be possible.
Post by Dan Libby via bitcoin-dev
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 <
Post by Dan Libby via bitcoin-dev
Hampus, thanks for the explanation!
Post by Hampus Sjöberg via bitcoin-dev
Yes.
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.
Post by Hampus Sjöberg via bitcoin-dev
See
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_
compatibility
Post by Hampus Sjöberg via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Lucas Clemente Vella via bitcoin-dev
2017-07-13 23:19:12 UTC
Permalink
2017-07-13 18:58 GMT-03:00 Dan Libby via bitcoin-dev <
Post by Dan Libby via bitcoin-dev
If I understand correctly, my node will accept the incoming tx inputs
but obviously will not perform any segwit related validation, thus those
inputs are not fully validated. I don't yet understand how my node
thinks they are valid at all given that it does not understand P2WPKH
address format, so either it doesn't need to, or P2WPKH is somehow
already valid. I know this has all been discussed in the past, so if
someone can point me towards a document that explains it I'd be happy to
read that.
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
***@gmail.com
Dan Libby via bitcoin-dev
2017-07-13 16:05:01 UTC
Permalink
Post by Gregory Maxwell via bitcoin-dev
On Wed, Jul 12, 2017 at 6:17 AM, Dan Libby via bitcoin-dev
It is not simple to do so correctly, I couldn't tell you off the top
of my head; a number of things must be changed it isn't as simple as
disabling the activiation because of the segwit P2P changes. Nor is
it a supported configuration. Even if it were now, it wouldn't be one
we'd continue to support in the future after segwit is active, as
we're likely to drop deployment/compat code.
I understand it is not in any way a supported configuration.
Post by Gregory Maxwell via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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
Anthony Towns via bitcoin-dev
2017-07-13 01:48:26 UTC
Permalink
Post by Dan Libby via bitcoin-dev
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.
Post by Dan Libby via bitcoin-dev
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
Dan Libby via bitcoin-dev
2017-07-13 16:13:04 UTC
Permalink
Post by Anthony Towns via bitcoin-dev
- 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.
Post by Anthony Towns via bitcoin-dev
- 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.
Post by Anthony Towns via bitcoin-dev
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.
Post by Anthony Towns via bitcoin-dev
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...
Post by Anthony Towns via bitcoin-dev
Post by Dan Libby via bitcoin-dev
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
Karl Johan Alm via bitcoin-dev
2017-07-12 01:22:59 UTC
Permalink
On Wed, Jul 12, 2017 at 6:11 AM, Gregory Maxwell via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
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.
Tom Zander via bitcoin-dev
2017-07-12 09:37:32 UTC
Permalink
On Wednesday, 12 July 2017 03:22:59 CEST Karl Johan Alm via bitcoin-dev
Post by Karl Johan Alm via bitcoin-dev
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.
Post by Karl Johan Alm via bitcoin-dev
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
Tom Zander via bitcoin-dev
2017-07-12 09:02:51 UTC
Permalink
On Tuesday, 11 July 2017 23:11:38 CEST Gregory Maxwell via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
I think it's great that people want to experiment with things like
drivechains/sidechains and what not, but their security model is very
distinct from Bitcoin's and, given the current highly centralized
mining ecosystem, arguably not very good. So positioning them as a
major solution for the Bitcoin project is the wrong way to go. Instead
we should support people trying cool stuff, at their own risk.
So, given that although the vast majority of the things in the document
are things I've been supporting for months (Please see Note 1 way down
at the bottom) I cannot support your document.
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
Steve Davis via bitcoin-dev
2017-07-11 22:26:38 UTC
Permalink
Post by Gregory Maxwell via bitcoin-dev
I think it's great that people want to experiment with things like
drivechains/sidechains and what not, but their security model is very
distinct from Bitcoin’s
Agree that experimentation is great and that it is usually the case that the security model differs.

Isn’t it also true also that the security model for SegWit is distinct from that defined for the Bitcoin token?

It does not appear to be a "chain of digital signatures" as per the original definition? I do understand that the hash state is still respected at block level. I’m referring more to the token’s chain.

Any clarification appreciated.

Thanks,

/sd
Anthony Towns via bitcoin-dev
2017-07-11 23:28:39 UTC
Permalink
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".
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
Paul Sztorc via bitcoin-dev
2017-07-17 17:13:30 UTC
Permalink
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/
Post by Paul Sztorc via bitcoin-dev
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 ====
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).
https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing
Cheers,
Paul
Alex Morcos via bitcoin-dev
2017-07-17 18:49:22 UTC
Permalink
"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 <
Post by Paul Sztorc via bitcoin-dev
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).
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/
Post by Paul Sztorc via bitcoin-dev
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.
Post by Paul Sztorc via bitcoin-dev
==== 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
Post by Paul Sztorc via bitcoin-dev
[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/
Post by Paul Sztorc via bitcoin-dev
[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
Post by Paul Sztorc via bitcoin-dev
[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
Post by Paul Sztorc via bitcoin-dev
==== End of Roadmap Draft ====
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).
https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNoc
mCq-jjBOQSVH-A/edit?usp=sharing
Post by Paul Sztorc via bitcoin-dev
Cheers,
Paul
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Peter Todd via bitcoin-dev
2017-07-17 21:50:38 UTC
Permalink
Post by Alex Morcos via bitcoin-dev
"it was ACKed by everyone else that I heard from" - I don't think you
should read into that much.
I felt like this whole conversation was putting the cart before the horse.
You might very well have some good ideas in your roadmap update, to tell
you the truth, I didn't even read it.
But I don't think we should be taking relatively new/untested ideas such as
Drivechain and sticking them on a roadmap. There is a tendency in this
community to hear about the latest and greatest idea and immediately fixate
on it as our salvation. I'm very happy that you are doing this work and
that others are researching a wide variety of ideas. But please, lets be
conservative and flexible with how we evolve Bitcoin. We don't even know
if or when we'll get segwit yet.
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
Paul Sztorc via bitcoin-dev
2017-07-17 20:13:38 UTC
Permalink
Post by Alex Morcos via bitcoin-dev
I felt like this whole conversation was putting the cart before the horse.
You might very well have some good ideas in your roadmap update, to
tell you the truth, I didn't even read it.
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.
Post by Alex Morcos via bitcoin-dev
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.
Post by Alex Morcos via bitcoin-dev
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
Post by Alex Morcos via bitcoin-dev
On Mon, Jul 17, 2017 at 1:13 PM, Paul Sztorc via bitcoin-dev
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).
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/>
Post by Paul Sztorc via bitcoin-dev
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
Post by Paul Sztorc via bitcoin-dev
community, helping to bring finality to the (endless)
conversations of
Post by Paul Sztorc via bitcoin-dev
that time, and get everyone back to work. However, I feel that
the Dec
Post by Paul Sztorc via bitcoin-dev
7, 2015 roadmap is simply too old to serve this function any
longer. We
Post by Paul Sztorc via bitcoin-dev
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
Post by Paul Sztorc via bitcoin-dev
example, a "textbook" or academic journal), and as a result
conversations tend to have a problematic lack of progress. They
do not
Post by Paul Sztorc via bitcoin-dev
"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
Post by Paul Sztorc via bitcoin-dev
subjecting itself to publication, endorsement, criticism, and so
forth.
Post by Paul Sztorc via bitcoin-dev
Despite the (unavoidable) nuance and complexity of each individual
opinion, it was at least globally known that X participants
endorsed Y
Post by Paul Sztorc via bitcoin-dev
set of claims.
Unfortunately, the Dec 2015 roadmap is now 19 months old -- it
is quite
Post by Paul Sztorc via bitcoin-dev
obsolete and replacing it is long overdue. For example, it
highlights
Post by Paul Sztorc via bitcoin-dev
older items (CSV, compact blocks, versionbits) as being _future_
improvements, and makes no mention of new high-likelihood
improvements
Post by Paul Sztorc via bitcoin-dev
(Schnorr) or mis-emphasizes them (LN). It even contains mistakes
(SegWit
Post by Paul Sztorc via bitcoin-dev
fraud proofs). To read the old roadmap properly, one must
already be a
Post by Paul Sztorc via bitcoin-dev
technical expert. For me, this defeats the entire point of
having one in
Post by Paul Sztorc via bitcoin-dev
the first place.
A new roadmap would be worth your attention, even if you didn't
sign it,
Post by Paul Sztorc via bitcoin-dev
because a refusal to sign would still be informative (and,
therefore,
Post by Paul Sztorc via bitcoin-dev
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
Post by Paul Sztorc via bitcoin-dev
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
Post by Paul Sztorc via bitcoin-dev
earnestly to capture a (useful) community view. So, let me know
how I did.
Post by Paul Sztorc via bitcoin-dev
==== Beginning of New ("July 2017") Roadmap Draft ====
This document updates the previous roadmap [1] of Dec 2015. The
older
Post by Paul Sztorc via bitcoin-dev
statement endorsed a belief that "the community is ready to
deliver on
Post by Paul Sztorc via bitcoin-dev
its shared vision that addresses the needs of the system while
upholding
Post by Paul Sztorc via bitcoin-dev
its values".
That belief has not changed, but the shared vision has certainly
grown
Post by Paul Sztorc via bitcoin-dev
sharper over the last 18 months. Below is a list of technologies
which
Post by Paul Sztorc via bitcoin-dev
either increase Bitcoin's maximum tps rate ("capacity"), or
which make
Post by Paul Sztorc via bitcoin-dev
it easier to process a higher volume of transactions
("scalability").
Post by Paul Sztorc via bitcoin-dev
First, over the past 18 months, the technical community has
completed a
Post by Paul Sztorc via bitcoin-dev
number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9)
enables
Post by Paul Sztorc via bitcoin-dev
Bitcoin to handle multiple soft fork upgrades at once. Compact
Blocks
Post by Paul Sztorc via bitcoin-dev
(BIP 152) allows for much faster block propagation, as does the
FIBRE
Post by Paul Sztorc via bitcoin-dev
Network [3]. Check Sequence Verify (BIP 112) allows trading
partners to
Post by Paul Sztorc via bitcoin-dev
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
Post by Paul Sztorc via bitcoin-dev
to handle signatures separately, has been completed and awaits
activation (multiple BIPS). It is estimated to increase capacity
by a
Post by Paul Sztorc via bitcoin-dev
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
Post by Paul Sztorc via bitcoin-dev
the UTXO set. Second, SW achieves linear scaling of sighash
operations,
Post by Paul Sztorc via bitcoin-dev
which prevents the network from crashing when large transactions are
broadcast. Third, SW provides an efficiency gain for everyone
who is not
Post by Paul Sztorc via bitcoin-dev
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
Post by Paul Sztorc via bitcoin-dev
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
Post by Paul Sztorc via bitcoin-dev
vary with usage patterns). LN also greatly improves transaction
speed
Post by Paul Sztorc via bitcoin-dev
and transaction privacy.
Fourth, Transaction Compression [7], observes that Bitcoin
transaction
Post by Paul Sztorc via bitcoin-dev
serialization is not optimized for storage or network
communication. If
Post by Paul Sztorc via bitcoin-dev
transactions were optimally compressed (as is possible today), this
would improve scalability, but not capacity, by roughly 20%, and
in some
Post by Paul Sztorc via bitcoin-dev
cases over 30%.
Fifth, Schnorr Signature Aggregation, which shrinks transactions by
allowing many transactions to have a single shared signature,
has been
Post by Paul Sztorc via bitcoin-dev
implemented [8] in draft form in libsecp256k1, and will likely
be ready
Post by Paul Sztorc via bitcoin-dev
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.
Post by Paul Sztorc via bitcoin-dev
The relative savings are even greater for multisignature
transactions.
Post by Paul Sztorc via bitcoin-dev
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
Post by Paul Sztorc via bitcoin-dev
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
Post by Paul Sztorc via bitcoin-dev
will achieve less decentralization as a result). Individual
drivechains
Post by Paul Sztorc via bitcoin-dev
may have different security tradeoffs (for example, a greater
reliance
Post by Paul Sztorc via bitcoin-dev
on UTXO commitments, or MimbleWimble's shrinking block history)
which
Post by Paul Sztorc via bitcoin-dev
may give them individually greater scalability than mainchain
Bitcoin.
Post by Paul Sztorc via bitcoin-dev
Finally, the capacity improvements outlined above may not be
sufficient.
Post by Paul Sztorc via bitcoin-dev
If so, it may be necessary to use a hard fork to increase the
blocksize
Post by Paul Sztorc via bitcoin-dev
(and blockweight, sigops, etc) by a moderate amount. Such an
increase
Post by Paul Sztorc via bitcoin-dev
should take advantage of the existing research on hard forks,
which is
Post by Paul Sztorc via bitcoin-dev
substantial [11]. Specifically, there is some consensus that
Spoonnet
Post by Paul Sztorc via bitcoin-dev
[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
Post by Paul Sztorc via bitcoin-dev
even an exhaustive list of scaling technologies, would itself
only be a
Post by Paul Sztorc via bitcoin-dev
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>
Post by Paul Sztorc via bitcoin-dev
[2]
https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
<https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/>
Post by Paul Sztorc via bitcoin-dev
[3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
<http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/>
Post by Paul Sztorc via bitcoin-dev
[4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
<https://bitcoincore.org/en/2016/01/26/segwit-benefits/>
Post by Paul Sztorc via bitcoin-dev
[5]
http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/
<http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/>
Post by Paul Sztorc via bitcoin-dev
[6] https://github.com/ACINQ/eclair
<https://github.com/ACINQ/eclair>
Post by Paul Sztorc via bitcoin-dev
[7] https://people.xiph.org/~greg/compacted_txn.txt
<https://people.xiph.org/%7Egreg/compacted_txn.txt>
Post by Paul Sztorc via bitcoin-dev
[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>
Post by Paul Sztorc via bitcoin-dev
[9]
https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
<https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/>
Post by Paul Sztorc via bitcoin-dev
[10] http://www.drivechain.info/
[11] https://bitcoinhardforkresearch.github.io/
<https://bitcoinhardforkresearch.github.io/>
Post by Paul Sztorc via bitcoin-dev
[12]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html>
Post by Paul Sztorc via bitcoin-dev
==== End of Roadmap Draft ====
1. If you agree that it would be helpful if the roadmap were
updated.
Post by Paul Sztorc via bitcoin-dev
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).
https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing
<https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing>
Post by Paul Sztorc via bitcoin-dev
Cheers,
Paul
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
Paul Sztorc via bitcoin-dev
2017-07-17 22:04:49 UTC
Permalink
Post by Paul Sztorc via bitcoin-dev
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
Post by Paul Sztorc via bitcoin-dev
[...]
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
Loading...