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

[Peter Todd via bitcoin-dev]

On Mon, Jul 17, 2017 at 02:49:22PM -0400, Alex Morcos via bitcoin-dev wrote:
> "it was ACKed by everyone else that I heard from"  - I don't think you
> should read into that much.
> 
> I felt like this whole conversation was putting the cart before the horse.
> You might very well have some good ideas in your roadmap update, to tell
> you the truth, I didn't even read it.
> But I don't think we should be taking relatively new/untested ideas such as
> Drivechain and sticking them on a roadmap.  There is a tendency in this
> community to hear about the latest and greatest idea and immediately fixate
> on it as our salvation. I'm very happy that you are doing this work and
> that others are researching a wide variety of ideas.  But please, lets be
> conservative and flexible with how we evolve Bitcoin.  We don't even know
> if or when we'll get segwit yet.

Agreed!

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

Drivechains is definitely in that situation right now.

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

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


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Paul Sztorc via bitcoin-dev]

On 7/17/2017 5:47 PM, David A. Harding wrote:
> On Mon, Jul 17, 2017 at 01:13:30PM -0400, Paul Sztorc via bitcoin-dev wrote:
>> However, without interest from the maintainers of bitcoincore.org
>> (specifically these [3, 4] pages and similar) the document will probably
>> be unable to gain traction.
>> [...]
>> [3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
>> [4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
> The BitcoinCore.org maintainers are not psychic.  If you want your
> document to appear on the website, please open a PR.  If you would like
> help formatting your document for the website, please feel free to send
> me an email off list or open an issue[1] regarding the inadequacy of
> the site's readme.
I meant only to convey that the document would appear on bitcoincore.org
iff the PR were ultimately accepted. In other words, while it is up to
"the community of Core Contributors" in a philosophical sense, it is up
to the maintainers of BitcoinCore.org in a practical sense, because they
are the ones who ultimately decide if the standard has been met.

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

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

-Paul


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



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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


On Mon, Jul 17, 2017 at 1:13 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello,
>
> Last week I posted about updating the Core Scalability Roadmap.
>
> I'm not sure what the future of it is, given that it was concept NACK'ed
> by Greg Maxwell the author of the original roadmap, who said that he
> regretted writing the first one.
>
> Nonetheless, it was ACKed by everyone else that I heard from, except for
> Tom Zander (who objected that it should be a specific project document,
> not a "Bitcoin" document -- I sortof agree and decided to label it a
> "Core" document -- whether or not anything happens with that label is up
> to the community).
>
> I therefore decided to:
> 1. Put the draft on GitHub [1]
> 2. Update it based on all of the week 1 feedback [2]
> 3. Add some spaces at the bottom for comments / expressions of interest [2]
>
> However, without interest from the maintainers of bitcoincore.org
> (specifically these [3, 4] pages and similar) the document will probably
> be unable to gain traction.
>
> Cheers,
> Paul
>
> [1] https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.txt
> [2]
> https://github.com/psztorc/btc-core-capacity-2/commit/
> 2b4f0ecc9015ee398ce0486ca5c3613e3b929c00
> [3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
> [4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
>
>
> On 7/10/2017 12:50 PM, Paul Sztorc wrote:
> > Summary
> > =
> >
> > In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
> > crucial ways. One success was that it synchronized the entire Bitcoin
> > community, helping to bring finality to the (endless) conversations of
> > that time, and get everyone back to work. However, I feel that the Dec
> > 7, 2015 roadmap is simply too old to serve this function any longer. We
> > should revise it: remove what has been accomplished, introduce new
> > innovations and approaches, and update deadlines and projections.
> >
> >
> > Why We Should Update the Roadmap
> > =
> >
> > In a P2P system like Bitcoin, we lack authoritative info-sources (for
> > example, a "textbook" or academic journal), and as a result
> > conversations tend to have a problematic lack of progress. They do not
> > "accumulate", as everyone must start over. Ironically, the scaling
> > conversation _itself_ has a fatal O(n^2) scaling problem.
> >
> > The roadmap helped solve these problems by being constant in size, and
> > subjecting itself to publication, endorsement, criticism, and so forth.
> > Despite the (unavoidable) nuance and complexity of each individual
> > opinion, it was at least globally known that X participants endorsed Y
> > set of claims.
> >
> > Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
> > obsolete and replacing it is long overdue. For example, it highlights
> > older items (CSV, compact blocks, versionbits) as being _future_
> > improvements, and makes no mention of new high-likelihood improvements
> > (Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
> > fraud proofs). To read the old roadmap properly, one must already be a
> > technical expert. For me, this defeats the entire point of having one in
> > the first place.
> >
> > A new roadmap would be worth your attention, even if you didn't sign it,
> > because a refusal to sign would still be informative (and, therefore,
> > helpful)!
> >
> > So, with that in mind, let me present a first draft. Obviously, I am
> > strongly open to edits and feedback, because I have no way of knowing
> > everyone's opinions. I admit that I am partially campaigning for my
> > Drivechain project, and also for this "scalability"/"capacity"
> > distinction...that's because I believe in both and think they are
> > helpful. But please feel free to suggest edits.
> >
> > I emphasized concrete numbers, and concrete dates.
> >
> > And I did NOT necessarily write it from my own point of view, I tried
> > earnestly to capture a (useful) community view. So, let me know how I
> did.
> >
> >   Beginning of New ("July 2017") Roadmap Draft 
> >
> > This document updates the previous roadmap [1] of Dec 2015. The older
> > 

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

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

I therefore decided to:
1. Put the draft on GitHub [1]
2. Update it based on all of the week 1 feedback [2]
3. Add some spaces at the bottom for comments / expressions of interest [2]

However, without interest from the maintainers of bitcoincore.org
(specifically these [3, 4] pages and similar) the document will probably
be unable to gain traction.

Cheers,
Paul

[1] https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.txt
[2]
https://github.com/psztorc/btc-core-capacity-2/commit/2b4f0ecc9015ee398ce0486ca5c3613e3b929c00
[3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
[4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/


On 7/10/2017 12:50 PM, Paul Sztorc wrote:
> Summary
> =
>
> In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
> crucial ways. One success was that it synchronized the entire Bitcoin
> community, helping to bring finality to the (endless) conversations of
> that time, and get everyone back to work. However, I feel that the Dec
> 7, 2015 roadmap is simply too old to serve this function any longer. We
> should revise it: remove what has been accomplished, introduce new
> innovations and approaches, and update deadlines and projections.
>
>
> Why We Should Update the Roadmap
> =
>
> In a P2P system like Bitcoin, we lack authoritative info-sources (for
> example, a "textbook" or academic journal), and as a result
> conversations tend to have a problematic lack of progress. They do not
> "accumulate", as everyone must start over. Ironically, the scaling
> conversation _itself_ has a fatal O(n^2) scaling problem.
>
> The roadmap helped solve these problems by being constant in size, and
> subjecting itself to publication, endorsement, criticism, and so forth.
> Despite the (unavoidable) nuance and complexity of each individual
> opinion, it was at least globally known that X participants endorsed Y
> set of claims.
>
> Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
> obsolete and replacing it is long overdue. For example, it highlights
> older items (CSV, compact blocks, versionbits) as being _future_
> improvements, and makes no mention of new high-likelihood improvements
> (Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
> fraud proofs). To read the old roadmap properly, one must already be a
> technical expert. For me, this defeats the entire point of having one in
> the first place.
>
> A new roadmap would be worth your attention, even if you didn't sign it,
> because a refusal to sign would still be informative (and, therefore,
> helpful)!
>
> So, with that in mind, let me present a first draft. Obviously, I am
> strongly open to edits and feedback, because I have no way of knowing
> everyone's opinions. I admit that I am partially campaigning for my
> Drivechain project, and also for this "scalability"/"capacity"
> distinction...that's because I believe in both and think they are
> helpful. But please feel free to suggest edits.
>
> I emphasized concrete numbers, and concrete dates.
>
> And I did NOT necessarily write it from my own point of view, I tried
> earnestly to capture a (useful) community view. So, let me know how I did.
>
>   Beginning of New ("July 2017") Roadmap Draft 
>
> This document updates the previous roadmap [1] of Dec 2015. The older
> statement endorsed a belief that "the community is ready to deliver on
> its shared vision that addresses the needs of the system while upholding
> its values".
>
> That belief has not changed, but the shared vision has certainly grown
> sharper over the last 18 months. Below is a list of technologies which
> either increase Bitcoin's maximum tps rate ("capacity"), or which make
> it easier to process a higher volume of transactions ("scalability").
>
> First, over the past 18 months, the technical community has completed a
> number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables
> Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks
> (BIP 152) allows for much faster block propagation, as does the FIBRE
> Network [3]. Check Sequence Verify (BIP 112) allows trading partners to
> mutually update an active transaction without writing it to the
> blockchain (this helps to enable the Lightning Network).
>
> Second, Segregated Witness (BIP 141), which reorganizes data in blocks
> to handle signatures separately, 

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect via bitcoin-dev]

That's a fair point, I confused anyone-can-spend with anyone-can-pay [1].

Isn't it different in the case of P2SH and SegWit, don't full nodes validate 
the script?

In other words, miners don't have complete control over the coins, full nodes 
keep a check on them.

At least that was my understanding, and if that's not the case then it doesn't 
make sense to me why Pieter would earlier in this thread object to Drivechain 
on the grounds that it's a different security model.

- Greg

[1] 
https://steemit.com/bitcoin/@jl777/bitcoin-spinoff-fork-how-to-make-a-clean-fork-without-any-replay-attack-and-no-blockchain-visible-changes
 


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

> On Jul 12, 2017, at 12:54 PM, CryptAxe via bitcoin-dev 
>  > wrote:
> 
> Are we just pulling numbers out of thin air now? https://p2sh.info/ 
>  BIP16 for example is widely used. It would be difficult 
> to find a single wallet that doesn't support BIP16 I have no idea what you 
> are talking about.
> 
> On 07/12/2017 12:42 PM, Tao Effect via bitcoin-dev wrote:
>> ...
>> In the present situation, anyone-can-spend outputs are used by probably less 
>> than 0.1% of users, and most software doesn't even allow for the possibility.
>> 
>> In Drivechain it's *encouraged-by-design*!
>> 
>> - Greg
>> 
>> --
>> Please do not email me anything that you are not comfortable also sharing 
>> with the NSA.
>> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org 
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[CryptAxe via bitcoin-dev]

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

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

Sorry for being a bit heated in my last response.


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

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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect via bitcoin-dev]

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

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

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

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

That is completely different.

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

In the present situation, anyone-can-spend outputs are used by probably less 
than 0.1% of users, and most software doesn't even allow for the possibility.

In Drivechain it's *encouraged-by-design*!

- Greg

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

> On Jul 12, 2017, at 12:34 PM, Chris Stewart  > wrote:
> 
> Hi Greg,
> 
> The safest way to ensure everyone's protection to make sure *no one can do 
> anything*. Then we will ALL be safe ;).
> 
> >If so, please leave, you are compromising Bitcoin's security.
> 
> Ok, let's calm down.
> 
> >If I design a car that has a button that randomly causes the brakes to give 
> >out if pressed, is that a good idea? Can I justify pushing for such a 
> >"feature" just because it's "opt-in"?
> 
> It would be more like "should we allow a car on the road if we know 
> statistically that our brakes give out in every 1/100,000,000 cars"? There is 
> security risks with everything in life -- we need to quantify the risk to see 
> if it is worth taking. I think Paul has been pretty upfront about the risks 
> of his model. I think you did a good job of demonstrating it in the email I 
> cited too.
> 
> >It is how *insecure* systems are designed.
> 
> By your account bitcoin is already insecure then -- it allows anyone can 
> spend outputs that can be claimed by miners.
> 
> >Sure, happy to, as soon as I have it written up in detail.
> 
> I look forward to this!
> 
> -Chris
> 
> On Wed, Jul 12, 2017 at 2:24 PM, Tao Effect  > wrote:
> Dear Chris,
> 
>> I think this is an unfair characterization. You have to opt into using 
>> drivechains.
> 
> I have heard this nonsense repeated countless times in order to justify 
> adopting Drivechain.
> 
> This is not how security works.
> 
> A child can "opt-in" to using a loaded gun, but is it a good idea to make it 
> easy for them to do that?
> 
> No.
> 
> This is effectively the same thing Drivechains is doing.
> 
> It is a request to modify the Bitcoin protocol to make it easy for Bitcoin 
> users to give their Bitcoins to miners.
> 
> Does that sound like a good idea to anyone?
> 
> If so, please leave, you are compromising Bitcoin's security.
> 
> Security is about making it difficult to shoot yourself in the face.
> 
> If I design a car that has a button that randomly causes the brakes to give 
> out if pressed, is that a good idea? Can I justify pushing for such a 
> "feature" just because it's "opt-in"?
> 
> No. That is fallacy.
> 
> It is not how secure systems are designed.
> 
> It is how *insecure* systems are designed.
> 
>> Care to share? I'm unaware if there is.
> 
> 
> Sure, happy to, as soon as I have it written up in detail.
> 
> Kind regards,
> Greg Slepak
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
>> On Jul 12, 2017, at 12:19 PM, Chris Stewart > > wrote:
>> 
>> Hi Greg,
>> 
>> >Here, you admit that the security of the sidechains allows miners to steal 
>> >bitcoins, something they cannot do currently.
>> 
>> If I put my coins in an anyone can spend output, a miner will take them. 
>> They can do this today. I suggest you try it if you don't believe me :-). 
>> You have to be more specific with contract types instead of generically 
>> talking about 'all contracts ever'.
>> 
>> > Drivechain is an unmistakeable weakening of Bitcoin's security guarantees. 
>> > This you have not denied.
>> 
>> I think this is an unfair characterization. You have to opt into using 
>> drivechains. Other outputs such as P2PKH/Multisig etc are unaffected by a 
>> drivechain output. As Pieter Wuille stated earlier in this thread (and Paul 
>> has stated all along), drivechain outputs have a different security model 
>> than other contracts. Namely they are controlled by miners. I think we can 
>> all agree this is unfortunate, but it is the current reality we live in. I 
>> look forward to the day we can solve the 'ownership' problem so we can have 
>> trustless interoperable blockchains, but that day is not today.
>> 
>> As a reminder, most users will not have to go through the drivechain 
>> withdrawal process. Most withdrawals will be done via atomic swaps.
>> 
>> >There is no reason to weaken Bitcoin's security in such a 

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Chris Stewart via bitcoin-dev]

Hi Greg,

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

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

Ok, let's calm down.

>If I design a car that has a button that randomly causes the brakes to
give out if pressed, is that a good idea? Can I justify pushing for such a
"feature" just because it's "opt-in"?

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

>It is how *insecure* systems are designed.

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

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

I look forward to this!

-Chris

On Wed, Jul 12, 2017 at 2:24 PM, Tao Effect  wrote:

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

> On Jul 12, 2017, at 12:19 PM, Chris Stewart  > wrote:
> 
> Hi Greg,
> 
> >Here, you admit that the security of the sidechains allows miners to steal 
> >bitcoins, something they cannot do currently.
> 
> If I put my coins in an anyone can spend output, a miner will take them. They 
> can do this today. I suggest you try it if you don't believe me :-). You have 
> to be more specific with contract types instead of generically talking about 
> 'all contracts ever'.
> 
> > Drivechain is an unmistakeable weakening of Bitcoin's security guarantees. 
> > This you have not denied.
> 
> I think this is an unfair characterization. You have to opt into using 
> drivechains. Other outputs such as P2PKH/Multisig etc are unaffected by a 
> drivechain output. As Pieter Wuille stated earlier in this thread (and Paul 
> has stated all along), drivechain outputs have a different security model 
> than other contracts. Namely they are controlled by miners. I think we can 
> all agree this is unfortunate, but it is the current reality we live in. I 
> look forward to the day we can solve the 'ownership' problem so we can have 
> trustless interoperable blockchains, but that day is not today.
> 
> As a reminder, most users will not have to go through the drivechain 
> withdrawal process. Most withdrawals will be done via atomic swaps.
> 
> >There is no reason to weaken Bitcoin's security in such a dramatic fashion. 
> >Better options are being worked on, they just take time.
> 
> Care to share? I'm unaware if there is.
> 
> >https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html
> > 
> >
> 
> Everyone should re-read this email though, this is something that could 
> happen. Paul's design makes it so that if this occurs it is *VERY* obvious. I 
> guess we can argue if there is any difference between an obvious robbery vs a 
> hidden robbery, but I think if we have to pick one or the other the choice is 
> clear to me. Other designs (that I'm aware of) for sidechains had attack 
> vectors that weren't so obvious.
> 
> -Chris
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Chris Stewart 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

Everyone should re-read this email though, this is something that could
happen. Paul's design makes it so that if this occurs it is *VERY* obvious.
I guess we can argue if there is any difference between an obvious robbery
vs a hidden robbery, but I think if we have to pick one or the other the
choice is clear to me. Other designs (that I'm aware of) for sidechains had
attack vectors that weren't so obvious.

-Chris



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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tom Zander via bitcoin-dev]

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

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

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

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

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

Individual groups can have solutions that they believe is the best. And then 
we can let the market decide which one is to be actually activated.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Jacob Eliosoff via bitcoin-dev]

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

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

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

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


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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Here's an example:

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

Here, you admit that the security of the sidechains allows miners to steal 
bitcoins, something they cannot do currently.

You next tried to equate three different types of theft, what you called 
"Classic Theft", "Channel Theft", and "Drivechain Theft", saying:

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

To anyone who understands bitcoin, there is a very clear, unmistakeable 
difference between double-spending ("Classic Theft"), and *ownership* of the 
private key controlling the bitcoins.

Similarly, to anyone who understands bitcoin, there is also a very clear, 
unmistakeable difference between censorship ("Channel Theft"), and *ownership* 
of the private key controlling the bitcoins.

The entire email was a very long-form way of admitting to all of the issues 
that were raised in the previous email, while making it sound like you had 
addressed the issues.

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

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

There is no reason to weaken Bitcoin's security in such a dramatic fashion. 
Better options are being worked on, they just take time.

Kind regards,
Greg Slepak

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

> On Jul 11, 2017, at 3:57 PM, Paul Sztorc  > wrote:
> 
> On 7/11/2017 6:41 PM, Tao Effect wrote:
>> Dear Paul,
>> 
>> Drivechain has several issues that you've acknowledged but have not,
>> IMO, adequately (at all really) addressed [1].
> 
> I replied to your email at length, at [2]. You should read that email,
> and then reply to it with your outstanding objections, if you still have
> them (per the usual customs of a mailing list).
> 
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014609.html 
> 
> 
>> Adopting DC would be an irreversible course of action,
> 
> This is false -- it is easily reversible with a second soft fork.
> 
> Also, I would say to everyone that, (in my opinion as the OP) this
> conversation will go off-topic if it veers exclusively into 'drivechain
> review'.
> 
> Paul
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Gregory Maxwell via bitcoin-dev]

On Wed, Jul 12, 2017 at 1:40 AM, Paul Sztorc  wrote:
> Separately, and very important to me, is that you feel that there are
> unresolved objections to drivechain's security model, which you decline
> to share with me and/or the list. So I would hope that you instead
> choose to share your thoughts (as is, presumably, the purpose of this list).

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

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

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

But, strategically it seems a little ill-advised.

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

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

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

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

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

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

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

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

Cheers,
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Bryan Bishop via bitcoin-dev]

On Tue, Jul 11, 2017 at 8:40 PM, Paul Sztorc via bitcoin-dev
 wrote:
> it, etc. But I am not willing to press the issue. Some of your other
> comments I also find confusing but there is little to be gained in
> clarifying them. )

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

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

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

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

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

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

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

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

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

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc via bitcoin-dev]

Greg,

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

( That's pretty surprising to me, and I would expect others to find it
surprising as well. And I wonder whether you think we should take the
old one *down*, and why you would allow (?) so many other people to sign
it, etc. But I am not willing to press the issue. Some of your other
comments I also find confusing but there is little to be gained in
clarifying them. )

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

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

I will also respond to this:

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

Let me try to explain my point of view. I did speak to several people,
in addition to the two names that I privately volunteered to you when
you asked me in a personal email earlier today. From my point of view
you had done no research (you failed to uncover any additional names),
used the information I volunteered to you against me (in the form of
false characterizations of negligent email writing!), and you also
suggested that, other than yourself and a few others, no one is
qualified even to write a first draft of a summary of present day
activities. This response is typical of the hostile review environment
which has existed in Bitcoin for years (I am more than used to it). If
instead of writing the first draft, I had written nothing, I would be
accused of being the ideas guy and/or "not contributing". You also
(rather rudely), put me in an awkward position, as the people who I
*did* ask now almost certainly prefer that I not reveal their names
(yet, a low name count is held as a strike against my competence).

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

Paul




On 7/11/2017 8:07 PM, Gregory Maxwell wrote:
> On Tue, Jul 11, 2017 at 10:17 PM, Paul Sztorc  wrote:
>> I don't understand this at all. This document attempts to do exactly
>> what its predecessor did -- nothing more or less.
> That might be your impression, then you've misunderstood what I
> intended-- What I wrote was carefully constructed as a personal view
> of how things might work out. It never claimed to be a a project
> roadmap. Though as usual, I work hard to propose things that I believe
> will be successful... and people are free to adopt what they want.
>
> And to the extent that it got taken that way I think it was an error
> and that it has harmed progress in our community; and created more
> confusion about control vs collaboration.
>
> With perfect hindsight I wouldn't have posted it; especially since
> we've learned that the demand for increased capacity from many people
> was potentially less than completely earnest. (The whole, can't double
> capacity until we quadruple it thing...)
>
>> As to your specific complaints, I have addressed both the security model
> and the concept of mining centralization on this list in the recent
> past.
>
> I don't agree that you have; but for the purpose of this thread
> doesn't really matter if I (specifically) do or don't agree.  It's an
> objective truth that many people do not yet believe these concerns
> have been addressed.
>
>> I really don't understand what you are disclosing. That Adam asked you
>> for feedback on the draft? And then, in the next sentence, that not
> That Adam asked me to write publish a new "roadmap" for Bitcoin as
> you've done here, with particular features and descriptions, 

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Karl Johan Alm via bitcoin-dev]

On Wed, Jul 12, 2017 at 6:11 AM, Gregory Maxwell via bitcoin-dev
 wrote:
> IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
> and release process once the basic technology is done; because it's
> only past that point that guarantees can really start being made.

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

Having *something* like a roadmap that gives the average user some
insights into what exactly is being planned for Bitcoin is very
desirable, arguably even necessary, in particular for the scaling
solutions. Putting deadlines and dates in would of course be highly
irresponsible, as no one can predict how much of their free time
volunteer developers will put into the project in advance (or whether
they will stick around for the next X months or stop being
contributors).

I think there is necessity for a document that describes the project
intentions for scaling solutions, but I don't think adding dates and
deadlines is appropriate. That may or may not be a roadmap. I imagine
such a document would be updated regularly as appropriate, which means
it may be less of a roadmap than the traditional kind.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc via bitcoin-dev]

On 7/11/2017 5:31 PM, Gregory Maxwell wrote:
> On Tue, Jul 11, 2017 at 8:18 PM, Paul Sztorc via bitcoin-dev
>  wrote:
>> I wrote the roadmap to try to be representative of a Core / developer
>> position.
> A fine intention, but I've checked with many of the top contributors
> and it sounds like the only regular developer you spoke with was
> Luke-Jr.  Next time you seek to represent someone you might want to
> try talking to them!
That is false. I could provide a list of names but I'm really not sure
what would be gained as result. You yourself admit that it is an
excellent list of research, almost all which you support directly.

So I think your only real objection is that I didn't talk to you
specifically.

>> I am philosophically against hard forks, but HFs were in the end
>> of the previous roadmap so I felt it should stay. And, I felt that if I
> I think the project is not philosophically against hardforks, at least
> not in an absolute sense.
That is why I included them despite being personally against them.
> But if you were instead to talk about things like fixing timewarp,
> recovering header bits, etc. It would clearly be the other way.
It links to bitcoinhardforkresearch.github.io , which I assumed would
contain the hard fork wishlist somewhere, but perhaps it does not.

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

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


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Gregory Maxwell via bitcoin-dev]

On Tue, Jul 11, 2017 at 10:17 PM, Paul Sztorc  wrote:
> I don't understand this at all. This document attempts to do exactly
> what its predecessor did -- nothing more or less.

That might be your impression, then you've misunderstood what I
intended-- What I wrote was carefully constructed as a personal view
of how things might work out. It never claimed to be a a project
roadmap. Though as usual, I work hard to propose things that I believe
will be successful... and people are free to adopt what they want.

And to the extent that it got taken that way I think it was an error
and that it has harmed progress in our community; and created more
confusion about control vs collaboration.

With perfect hindsight I wouldn't have posted it; especially since
we've learned that the demand for increased capacity from many people
was potentially less than completely earnest. (The whole, can't double
capacity until we quadruple it thing...)

> As to your specific complaints, I have addressed both the security model
and the concept of mining centralization on this list in the recent
past.

I don't agree that you have; but for the purpose of this thread
doesn't really matter if I (specifically) do or don't agree.  It's an
objective truth that many people do not yet believe these concerns
have been addressed.

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

That Adam asked me to write publish a new "roadmap" for Bitcoin as
you've done here, with particular features and descriptions, which I
declined; and explained why I didn't believe that was the right
approach.  And Adam worked with you on the document, and provided
content for it (which I then recognized in the post).

Set aside what you know to be true for a moment and consider how this
might look to an outsider who found out about it.  It could look a
like Blockstream was trying to influence the direction of Bitcoin by
laundering proposals through an apparently unaffiliated third party.
Doubly so considering who participated in your drafting and who didn't
(more below).

I don't think in actuality you did anything remotely improper
(ill-advised, perhaps, since your goal to speak for developers but you
didn't speak to them, IMO--) but I think transparency is essential to
avoid any appearance of misconduct.

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

I did--

As Bryan pointed out... with the exception of the intro and end and a
couple sentences in the middle my entire response to your post, with
the position on "roadmaps" was written a long time ago, specifically
to complain about and argue against that particular approach.

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

I think you may be mistaking a roadmap with "communications"-- people
taking about research they are exploring is great! and we should have
more of it.  But like with RedHat and kernel features, we can't really
roadmap things that are unresourced and currently just unimplemented
exploration or test code-- without seeing things which are more or
less done the community can't rightfully decide if they'd want to
support something or not.  Perhaps they'll be good things perhaps
awful-- the devil is in the details, and until an effort is fairly
mature, you cannot see the details.

There have, for example, been signature aggregation proposals in the
past that required address reuse (could only aggregate if they're
reused).  I would strongly oppose such a proposal, and I hope everyone
else here would too.  So if I were a third party looking at your
message, rather than the person who initially proposed the agg sig
thing you're talking about, I wouldn't know if I could love it or hate
it yet; and probably couldn't be expected to have much of an opinion
on it until there is a BIP and/or example implementation.

To the extent that a roadmap differs from communications in general,
it is in that it also implies things that none of us can promise
except for our own efforts; Completion of implementations, success of
experiments, adoption-- basically assuming a level of top down control
that doesn't exist in a wide public collaboration.

One of the great challenges in our industry is that we don't have
rings of communication: We don't have 

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Anthony Towns via bitcoin-dev]

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

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

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

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

That could have happened: the proposals in 

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

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

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

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

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

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

 - Awaiting consensus:
 * segregated witness

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

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

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

> There is
> currently no consensus on a hard fork date, but there is a rough
> consensus that one would require at least 6 months to coordinate
> effectively, which would place it in the year 2018 at earliest.

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

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

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

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

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

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

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

Instead of a "roadmap" (with the 

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Bryan Bishop via bitcoin-dev]

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
 wrote:
> On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
>> [  Note 1: I think it is important to disclose that several of the
>> items in this list appear to be more or less quoted out of my own
>> blockstream-internal descriptions of things we've been working on in
>> Bitcoin.
>> A while back Adam Back asked me to publish something which contained
>> significant chunks of this document more or less verbatim,
[ snip ]
> I am not exactly sure what you are insinuating but I encourage you to
> clarify it.

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

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

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

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

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc via bitcoin-dev]

On 7/11/2017 6:41 PM, Tao Effect wrote:
> Dear Paul,
>
> Drivechain has several issues that you've acknowledged but have not,
> IMO, adequately (at all really) addressed [1].

I replied to your email at length, at [2]. You should read that email,
and then reply to it with your outstanding objections, if you still have
them (per the usual customs of a mailing list).

[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014609.html

> Adopting DC would be an irreversible course of action,

This is false -- it is easily reversible with a second soft fork.

Also, I would say to everyone that, (in my opinion as the OP) this
conversation will go off-topic if it veers exclusively into 'drivechain
review'.

Paul



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc via bitcoin-dev]

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

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

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

> Regardless, people are free experiment and adopt such an approach. The
> nice thing about it not being a hardfork is that it does not require
> network-wide consensus to deploy. However, I don't think they offer a
> security model that should be encouraged, and thus doesn't have a
> place on a roadmap.
I think this is reasonable. It is true that, if no one used drivechains
ever for anything, there would be no transactions offloaded to those
chain, and then no capacity freed up on the original mainchain.

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


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

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

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

--Paul


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

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


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

> On Jul 11, 2017, at 3:17 PM, Paul Sztorc via bitcoin-dev 
>  > wrote:
> 
> Hi Greg,
> 
> 
> On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
>> I think it's great that people want to experiment with things like
>> drivechains/sidechains and what not, but their security model is very
>> distinct from Bitcoin's and, given the current highly centralized
>> mining ecosystem, arguably not very good.  So positioning them as a
>> major solution for the Bitcoin project is the wrong way to go. Instead
>> we should support people trying cool stuff, at their own risk.
>> 
>> So, given that although the vast majority of the things in the document
>> are things I've been supporting for months (Please see Note 1 way down
>> at the bottom) I cannot support your document.
> Is this the only reason you do not support the document? If so I would
> be happy to take out the section, if enough people share such a view.
> 
> As to your specific complaints, I have addressed both the security model
> and the concept of mining centralization on this list in the recent
> past. I would like to hear your responses to my claims, if you are
> willing to share them. As for positioning DC as a major solution, it is
> a little confusing because Luke-Jr and Adam back seem to feel it is at
> least worth discussing on those terms (and I know of no reason why it
> would not be discussed on those terms). The peer review here on
> [bitcoin-dev] seemed to be moving forward without any serious
> objections. And it seems unsportsmanlike for you to object, for reasons
> which you keep only to yourself.
> 
> 
>> On a more meta-subject, I think grandly stated "top down" roadmaps
>> in highly collaborative development are of minimal utility at best
> I'm aiming for minimal utility.
> 
>> IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
>> and release process once the basic technology is done; because it's
>> only past that point that guarantees can really start being made.
>> 
>> But that isn't what your document does-- it names a lot of things which
>> are still various shades of research at this point
> I don't understand this at all. This document attempts to do exactly
> what its predecessor did -- nothing more or less.
> 
>> This was an incredible benefit to our customers, but the only way it was
>> possible was because _features_ were not guaranteed in a release.
> No one is suggesting that features be guaranteed, either ever or in
> releases.
> 
> 
>> One of the big screwups with segwit handling was people sticking
>> some random unrealistic date on it it which was done AFAIK,
>> by well meaning folks who took some random numbers from people
>> working on it for when they'd be done with the development-- not the
>> testing, not the integration, and certainly not deployment and published
>> it as The Date.  Then even though the development was actually done
>> by them, segwit was portrayed as massively delayed, because what
>> matters to the users is deployment-- which we can't control.
> I really don't think they are related. For a start, software is almost
> always delayed. An obvious second is that this entire scaling
> conversation is polarized to the hilt and everyone that can be blamed
> for something has been blamed for something.
> 
> No one likes to be held to a certain deadline, but this roadmap is just
> about producing some clarity for people who do not do this 24/7.
> 
>> I see you've done this yourself with signature aggregation, sticking Q4 2016
>> right on it, which as far as I can tell is a figure that comes from mars.
> I asked Adam Back for it.
> 
>> It's also not really appropriate to ask people to sign onto stuff when they
>> can't even review it.  Perhaps the signature aggregation stuff is insecure,
>> patent encumbered, or practically useless... (It won't be but no one could
>> tell that from your post; because it doesn't even exist as a concrete 
>> proposal)
> Again, 

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc via bitcoin-dev]

Hi Greg,


On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
> I think it's great that people want to experiment with things like
> drivechains/sidechains and what not, but their security model is very
> distinct from Bitcoin's and, given the current highly centralized
> mining ecosystem, arguably not very good.  So positioning them as a
> major solution for the Bitcoin project is the wrong way to go. Instead
> we should support people trying cool stuff, at their own risk.
>
> So, given that although the vast majority of the things in the document
> are things I've been supporting for months (Please see Note 1 way down
> at the bottom) I cannot support your document.
Is this the only reason you do not support the document? If so I would
be happy to take out the section, if enough people share such a view.

As to your specific complaints, I have addressed both the security model
and the concept of mining centralization on this list in the recent
past. I would like to hear your responses to my claims, if you are
willing to share them. As for positioning DC as a major solution, it is
a little confusing because Luke-Jr and Adam back seem to feel it is at
least worth discussing on those terms (and I know of no reason why it
would not be discussed on those terms). The peer review here on
[bitcoin-dev] seemed to be moving forward without any serious
objections. And it seems unsportsmanlike for you to object, for reasons
which you keep only to yourself.


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

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

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


> One of the big screwups with segwit handling was people sticking
> some random unrealistic date on it it which was done AFAIK,
> by well meaning folks who took some random numbers from people
> working on it for when they'd be done with the development-- not the
> testing, not the integration, and certainly not deployment and published
> it as The Date.  Then even though the development was actually done
> by them, segwit was portrayed as massively delayed, because what
> matters to the users is deployment-- which we can't control.
I really don't think they are related. For a start, software is almost
always delayed. An obvious second is that this entire scaling
conversation is polarized to the hilt and everyone that can be blamed
for something has been blamed for something.

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

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

> It's also not really appropriate to ask people to sign onto stuff when they
> can't even review it.  Perhaps the signature aggregation stuff is insecure,
> patent encumbered, or practically useless... (It won't be but no one could
> tell that from your post; because it doesn't even exist as a concrete 
> proposal)
Again, I think you're missing the point. If there is a problem with SA,
you can just suggest it be removed from the document.


> I think people would rightly protest about a number of these things-- 
> especially
> things like the the agg sigs and tx compaction, "wtf, I've not heard
> of this. Who
> are you to insist this goes into Bitcoin?"
This is a very strange argument. I would consider it a benefit if people
learned from the document, and discovered things that they had not heard
of before.

There is no "insisting" of any kind.


> [  Note 1: I think it is important to disclose that several of the
> items in this list appear to be more or less quoted out of my own
> blockstream-internal descriptions of things we've been working on in
> Bitcoin.
> A while back Adam Back asked me to publish something which contained
> significant chunks of this document more or less verbatim, 
He probably showed you an earlier draft. But I wrote almost all of this
myself, and I can only recall 2 or 3 phrases (not even complete
sentences) included from Adam Back. And most of the phrases are
themselves just boring descriptions that I'm sure anyone could write.
Some phrases may have simply been taken from bitcoincore.org or
somewhere similar.

I 

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Steve Davis 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Pieter Wuille via bitcoin-dev]

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

I apologize here; I didn't mean to misrepresent his viewpoint.

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

If you're talking about the extreme case where every full node in the
increased capacity single chain model corresponds to a node that
validates both chains and all transfers between them in the
drivechains, I agree. At that point they become nearly equivalent in
terms of ease of adoption, resource costs, and capacity.

However, I don't think that is a realistic expectation. When
considering drivechains as a capacity increase, I believe most people
think about a situation where there are many chains that give an
increased capacity combined, but not everyone verifies all of them.
This is what I meant with uninteresting security model, as it requires
increased miner trust for preventing the other chains' coins from
being illegally transferred to the chain you're operating on.

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

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

Am I right in summarizing your point here as "This approach cannot
hurt, because if it were insecure, people can choose to not use it."?
I'm not sure I agree with that, as network effects or misinformation
may push users beyond what is reasonable.

Cheers,

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Gregory Maxwell via bitcoin-dev]

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

To make it clear, since I munged the English on this: Most of my post
is just copied straight out of a private thread where I explained my
perspective on 'roadmaps' as they apply to projects like Bitcoin.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Adam Back via bitcoin-dev]

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
 wrote:
> Concept ACK.
>
> I think you are overstating the readiness of drivechains though. I think the
> optimistic estimate for drivechains to be ready for bitcoin core is a year
> out from today. More likely the date should be early 2018. Still a lot of
> work to be done! :-)
>
> Also I don't know if I would put a hard fork suggestion in the scaling map.
> If drivechains are successful they should be viewed as the way we scale --
> not hard forking the protocol. Do you still have capacity concerns if
> drivechains are successful?
>
> -Chris
>
> On Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev
>  wrote:
>>
>>
>> Summary
>> =
>>
>> In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
>> crucial ways. One success was that it synchronized the entire Bitcoin
>> community, helping to bring finality to the (endless) conversations of
>> that time, and get everyone back to work. However, I feel that the Dec
>> 7, 2015 roadmap is simply too old to serve this function any longer. We
>> should revise it: remove what has been accomplished, introduce new
>> innovations and approaches, and update deadlines and projections.
>>
>>
>> Why We Should Update the Roadmap
>> =
>>
>> In a P2P system like Bitcoin, we lack authoritative info-sources (for
>> example, a "textbook" or academic journal), and as a result
>> conversations tend to have a problematic lack of progress. They do not
>> "accumulate", as everyone must start over. Ironically, the scaling
>> conversation _itself_ has a fatal O(n^2) scaling problem.
>>
>> The roadmap helped solve these problems by being constant in size, and
>> subjecting itself to publication, endorsement, criticism, and so forth.
>> Despite the (unavoidable) nuance and complexity of each individual
>> opinion, it was at least globally known that X participants endorsed Y
>> set of claims.
>>
>> Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
>> obsolete and replacing it is long overdue. For example, it highlights
>> older items (CSV, compact blocks, versionbits) as being _future_
>> improvements, and makes no mention of new high-likelihood improvements
>> (Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
>> fraud proofs). To read the old roadmap properly, one must already be a
>> technical expert. For me, this defeats the entire point of having one in
>> the first place.
>>
>> A new roadmap would be worth your attention, even if you didn't sign it,
>> because a refusal to sign would still be informative (and, therefore,
>> helpful)!
>>
>> So, with that in mind, let me present a first draft. Obviously, I am
>> strongly open to edits and feedback, because I have no way of knowing
>> everyone's opinions. I admit that I am partially campaigning for my
>> Drivechain project, and also for this "scalability"/"capacity"
>> distinction...that's because I believe in both and think they are
>> helpful. But please feel free to suggest edits.
>>
>> I emphasized concrete numbers, and concrete dates.
>>
>> And I did NOT necessarily write it from my own point of view, I tried
>> earnestly to capture a (useful) community view. So, let me know how I did.
>>
>>   Beginning of New ("July 2017") Roadmap Draft 
>>
>> This document updates the previous roadmap [1] of Dec 2015. The older
>> statement endorsed a belief that "the community is ready to deliver on
>> its shared vision that addresses the needs of the system while upholding
>> its values".
>>
>> That belief has not changed, but the shared vision has certainly grown
>> sharper over the last 18 months. Below is a list of technologies which
>> either increase Bitcoin's maximum tps rate ("capacity"), or which make
>> it easier to process a higher volume of transactions ("scalability").
>>
>> First, over the past 18 months, the technical community has completed a
>> number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables
>> Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks
>> (BIP 152) allows for much faster block propagation, as does the FIBRE
>> Network [3]. Check Sequence Verify (BIP 112) allows trading partners to
>> mutually update an active transaction without writing it to the
>> blockchain (this helps to 

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

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

The only true difference is the "extra risk of miners being able to vote
to steal your money", but as I have pointed out on this mailing list
several times, I do not actually believe that there is any marginal risk
-- miners can already "vote to steal your money" in the double-spend and
ln-channel-theft contexts. I have also argued that the "risk" is
actually desirable in an opt-in context, because it puts the burden of
proof on miners/developers (to convince users that they should move over
to the sidechain). Since their sidechain coins cannot appreciate in
value relative to the mainchain coins, users would only opt-in if they
felt that they were sufficiently compensated for any and all risks.
Hence, it is difficult to list this item as a drawback when, to the
user, it is a strict improvement (at least, by any epistemological
standard that I can think of). If you have new objections to these
claims, I'm sure we would all benefit from hearing them, myself most of all.

Paul


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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc via bitcoin-dev]

Hi Chris,

On 7/11/2017 12:03 PM, Chris Stewart wrote:
> Concept ACK.
>
> I think you are overstating the readiness of drivechains though. I
> think the optimistic estimate for drivechains to be ready for bitcoin
> core is a year out from today. More likely the date should be early
> 2018. Still a lot of work to be done! :-)
It depends on interest, I think. What remains to be done is more easily
parallelized, and in some cases (eg smartphone wallets) there are
incentives for private individuals and businesses to hustle their part
out (merely for reasons of competitiveness).

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

I wrote the roadmap to try to be representative of a Core / developer
position. I am philosophically against hard forks, but HFs were in the
end of the previous roadmap so I felt it should stay. And, I felt that
if I decided to unilaterally remove it, it would be perceived as
excessive campaigning for Drivechain. And I also felt that to remove it,
when so many industry members recently put their weight behind a fast
hard fork, would be perceived as a reaction to that attempt, and would
then overwhelm the document with political polarization, for really no
benefit.

Paul

>
> -Chris
>
> On Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev
>  > wrote:
>
>
> Summary
> =
>
> In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
> crucial ways. One success was that it synchronized the entire Bitcoin
> community, helping to bring finality to the (endless) conversations of
> that time, and get everyone back to work. However, I feel that the Dec
> 7, 2015 roadmap is simply too old to serve this function any
> longer. We
> should revise it: remove what has been accomplished, introduce new
>

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Pieter Wuille via bitcoin-dev]

On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

Concept ACK.

If drivechains are successful they should be viewed as the way we scale


I strongly disagree with that statement.

Drivechains, and several earlier sidechains ideas, are not a scalability
improvement, but merely enabling users to opt-in for another security model.

While obviously any future with wider adoption will need different
technologies that have different trade-offs, and anyone is free to choose
their security model, I don't think this particular one is interesting. In
terms of validation cost to auditors, it is as bad as just a capacity
increase on chain, while simultaneously adding the extra risk of miners
being able to vote to steal your money.

Cheers,

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[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 <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Summary
> =
>
> In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
> crucial ways. One success was that it synchronized the entire Bitcoin
> community, helping to bring finality to the (endless) conversations of
> that time, and get everyone back to work. However, I feel that the Dec
> 7, 2015 roadmap is simply too old to serve this function any longer. We
> should revise it: remove what has been accomplished, introduce new
> innovations and approaches, and update deadlines and projections.
>
>
> Why We Should Update the Roadmap
> =
>
> In a P2P system like Bitcoin, we lack authoritative info-sources (for
> example, a "textbook" or academic journal), and as a result
> conversations tend to have a problematic lack of progress. They do not
> "accumulate", as everyone must start over. Ironically, the scaling
> conversation _itself_ has a fatal O(n^2) scaling problem.
>
> The roadmap helped solve these problems by being constant in size, and
> subjecting itself to publication, endorsement, criticism, and so forth.
> Despite the (unavoidable) nuance and complexity of each individual
> opinion, it was at least globally known that X participants endorsed Y
> set of claims.
>
> Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
> obsolete and replacing it is long overdue. For example, it highlights
> older items (CSV, compact blocks, versionbits) as being _future_
> improvements, and makes no mention of new high-likelihood improvements
> (Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
> fraud proofs). To read the old roadmap properly, one must already be a
> technical expert. For me, this defeats the entire point of having one in
> the first place.
>
> A new roadmap would be worth your attention, even if you didn't sign it,
> because a refusal to sign would still be informative (and, therefore,
> helpful)!
>
> So, with that in mind, let me present a first draft. Obviously, I am
> strongly open to edits and feedback, because I have no way of knowing
> everyone's opinions. I admit that I am partially campaigning for my
> Drivechain project, and also for this "scalability"/"capacity"
> distinction...that's because I believe in both and think they are
> helpful. But please feel free to suggest edits.
>
> I emphasized concrete numbers, and concrete dates.
>
> And I did NOT necessarily write it from my own point of view, I tried
> earnestly to capture a (useful) community view. So, let me know how I did.
>
>   Beginning of New ("July 2017") Roadmap Draft 
>
> This document updates the previous roadmap [1] of Dec 2015. The older
> statement endorsed a belief that "the community is ready to deliver on
> its shared vision that addresses the needs of the system while upholding
> its values".
>
> That belief has not changed, but the shared vision has certainly grown
> sharper over the last 18 months. Below is a list of technologies which
> either increase Bitcoin's maximum tps rate ("capacity"), or which make
> it easier to process a higher volume of transactions ("scalability").
>
> First, over the past 18 months, the technical community has completed a
> number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables
> Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks
> (BIP 152) allows for much faster block propagation, as does the FIBRE
> Network [3]. Check Sequence Verify (BIP 112) allows trading partners to
> mutually update an active transaction without writing it to the
> blockchain (this helps to enable the Lightning Network).
>
> Second, Segregated Witness (BIP 141), which reorganizes data in blocks
> to handle signatures separately, has been completed and awaits
> activation (multiple BIPS). It is estimated to increase capacity by a
> factor of 2.2. It also improves scalability in many ways. First, SW
> includes a fee-policy which encourages users to minimize their impact on
> the UTXO set. Second, SW achieves linear scaling of sighash operations,
> which prevents the network from crashing when large transactions are
> broadcast. Third, SW provides an efficiency gain for everyone who is not
> verifying signatures, as these no longer need to be downloaded or
> stored. SegWit is an enabling technology for the Lightning Network,
> script versioning