Re: [bitcoin-dev] Updating the Scaling Roadmap

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Steve Davis]

> 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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[CryptAxe]

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

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

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

Sorry for being a bit heated in my last response.


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

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


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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect]

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

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

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

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

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

- Greg

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

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

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


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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[CryptAxe]

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

Are we just pulling numbers out of thin air now? https://p2sh.info/
BIP16 for example is widely used. It would be difficult to find a single
wallet that doesn't support BIP16 I have no idea what you are talking about.


On 07/12/2017 12:42 PM, Tao Effect via bitcoin-dev wrote:
> ...
> In the present situation, anyone-can-spend outputs are used by
> probably less than 0.1% of users, and most software doesn't even allow
> for the possibility.
>
> In Drivechain it's *encouraged-by-design*!
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
>


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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect]

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

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

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

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

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

That is completely different.

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

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

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

- Greg

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

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


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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Chris Stewart]

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

Hi Greg,

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

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

Ok, let's calm down.

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

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

>It is how *insecure* systems are designed.

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

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

I look forward to this!

-Chris

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

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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect]

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

Dear Chris,

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

I have heard this nonsense repeated countless times in order to justify adopting Drivechain.

This is not how security works.

A child can "opt-in" to using a loaded gun, but is it a good idea to make it easy for them to do that?

No.

This is effectively the same thing Drivechains is doing.

It is a request to modify the Bitcoin protocol to make it easy for Bitcoin users to give their Bitcoins to miners.

Does that sound like a good idea to anyone?

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

Security is about making it difficult to shoot yourself in the face.

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

No. That is fallacy.

It is not how secure systems are designed.

It is how *insecure* systems are designed.

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


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

Kind regards,
Greg Slepak

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

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


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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Chris Stewart]

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

Hi Greg,

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

If I put my coins in an anyone can spend output, a miner will take them.
They can do this today. I suggest you try it if you don't believe me :-).
You have to be more specific with contract types instead of generically
talking about 'all contracts ever'.

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

I think this is an unfair characterization. You have to opt into using
drivechains. Other outputs such as P2PKH/Multisig etc are unaffected by a
drivechain output. As Pieter Wuille stated earlier in this thread (and Paul
has stated all along), drivechain outputs have a different security model
than other contracts. Namely they are controlled by miners. I think we can
all agree this is unfortunate, but it is the current reality we live in. I
look forward to the day we can solve the 'ownership' problem so we can have
trustless interoperable blockchains, but that day is not today.

As a reminder, most users will not have to go through the drivechain
withdrawal process. Most withdrawals will be done via atomic swaps.

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

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

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

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

-Chris



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

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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tom Zander]

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

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

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

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

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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tom Zander]

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

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

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

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

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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Jacob Eliosoff]

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

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

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

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

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


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

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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Gregory Maxwell]

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

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

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

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

But, strategically it seems a little ill-advised.

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

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

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

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

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

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

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

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

Cheers,

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Bryan Bishop]

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

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

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

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

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

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

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

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

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

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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

Greg,

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

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

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

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

I will also respond to this:

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

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

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

Paul




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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Karl Johan Alm]

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

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

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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

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

On 7/11/2017 7:12 PM, Tao Effect wrote:
> Paul,
>
> There is a difference between replying to an email, and addressing the
> issues that were brought up in it.
>
> I did read your reply, and I chose not to respond to it because it did
> not address anything I said.

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

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

If that were the case, then DC would need to be a hard fork. It so
happens that it is *not* the case -- if users choose to deposit to an
anyone-can-spend output, then miners can take the Bitcoins, which *is*
something that miners can do currently.

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

I am not sure what you are disagreeing with. The three thefts involve
different attacker resources and behaviors, and in that way they are
different. But in all three cases the user has lost the BTC they would
have otherwise owned, and in that way they are not different.

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

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

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

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

Paul

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Gregory Maxwell]

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

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

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

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

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

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

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

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

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

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

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

I did--

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

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

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

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

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

One of the great challenges in our industry is that we don't have
rings of communication: We don't have much in the way of semi-experts
to communicate to semi-semi-experts to communicate to media pundits to
communicate to the unwashed masses-- at each level closing the
inferential gap and explaining things in terms the audience
understands. We don't have things like LWN.   We'll get there, but it
it took the Linux world decades to build to what it has now. I think
various forces in the industry work against us-- e.g. we lose a mot of
mid tier technical people to the allure of striking it rich printing
money in their own altcoins.

It might be attractive to try to end-run the slow development
appropriate web of reliable communications by deploying high authority
edicts, but it ultimately can't work because it doesn't map to how
things are accomplished, not in true collaborative open source, and
certainly not in an effort whos value comes substantially from
decentralization. Doing so, I fear, creates a false understanding of
authority.

(It's a common misunderstanding, for example, that people do what I
want (for example); but in reality, I just try to avoid wasting my
time advocating things that I don't think other people are already
going to do; :) otherwise, if _I_ want something done I've got to do
it myself or horse trade for it, just like anyone else.)

One of the great things about general communications is anyone can do
it.  Of course, unless they're talking about their own work, they
can't promise any of it will be completely-- but that is always true.
 If someone wants some guarantee about work, they have to be willing
to get it done themselves (and, of course, if it's a consensus
feature-- that much is necessary, but still not sufficient to get a
guarantee).

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

Come now, this is needlessly insulting. I would have made the same
comment if you had talked to me because you didn't talk to most/all of
Matt Corallo, Wladimir, Pieter Wuille, Alex Morcos, etc.... e.g. the
people doing most of the work of actually building the system.  Before
making that comment I went and checked with people to find out if only
I was left out.  Talking to Adam (who isn't involved in the project)
and Luke-jr (who is but is well known for frustratingly extreme
minority positions and also contracts for Blockstream sometimes) isn't
a great approach for the stated goal of speaking for developers!

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Bryan Bishop]

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

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

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

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

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

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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Anthony Towns]

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

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

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

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

That could have happened: the proposals in 

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

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

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

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

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

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

 - Awaiting consensus:
     * segregated witness

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cheers,
aj

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect]

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

Paul,

There is a difference between replying to an email, and addressing the issues that were brought up in it.

I did read your reply, and I chose not to respond to it because it did not address anything I said.

Here's an example:

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

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

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

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

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

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

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

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

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

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

Kind regards,
Greg Slepak

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

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


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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

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

[Paul Sztorc]

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

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

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

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

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


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

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

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

--Paul

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect]

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

Dear Paul,

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

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

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

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

Kind regards,
Greg Slepak

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

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

> On Jul 11, 2017, at 3:17 PM, Paul Sztorc via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> Hi Greg,
> 
> 
> On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
>> I think it's great that people want to experiment with things like
>> drivechains/sidechains and what not, but their security model is very
>> distinct from Bitcoin's and, given the current highly centralized
>> mining ecosystem, arguably not very good.  So positioning them as a
>> major solution for the Bitcoin project is the wrong way to go. Instead
>> we should support people trying cool stuff, at their own risk.
>> 
>> So, given that although the vast majority of the things in the document
>> are things I've been supporting for months (Please see Note 1 way down
>> at the bottom) I cannot support your document.
> Is this the only reason you do not support the document? If so I would
> be happy to take out the section, if enough people share such a view.
> 
> As to your specific complaints, I have addressed both the security model
> and the concept of mining centralization on this list in the recent
> past. I would like to hear your responses to my claims, if you are
> willing to share them. As for positioning DC as a major solution, it is
> a little confusing because Luke-Jr and Adam back seem to feel it is at
> least worth discussing on those terms (and I know of no reason why it
> would not be discussed on those terms). The peer review here on
> [bitcoin-dev] seemed to be moving forward without any serious
> objections. And it seems unsportsmanlike for you to object, for reasons
> which you keep only to yourself.
> 
> 
>> On a more meta-subject, I think grandly stated "top down" roadmaps
>> in highly collaborative development are of minimal utility at best
> I'm aiming for minimal utility.
> 
>> IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
>> and release process once the basic technology is done; because it's
>> only past that point that guarantees can really start being made.
>> 
>> But that isn't what your document does-- it names a lot of things which
>> are still various shades of research at this point
> I don't understand this at all. This document attempts to do exactly
> what its predecessor did -- nothing more or less.
> 
>> This was an incredible benefit to our customers, but the only way it was
>> possible was because _features_ were not guaranteed in a release.
> No one is suggesting that features be guaranteed, either ever or in
> releases.
> 
> 
>> One of the big screwups with segwit handling was people sticking
>> some random unrealistic date on it it which was done AFAIK,
>> by well meaning folks who took some random numbers from people
>> working on it for when they'd be done with the development-- not the
>> testing, not the integration, and certainly not deployment and published
>> it as The Date.  Then even though the development was actually done
>> by them, segwit was portrayed as massively delayed, because what
>> matters to the users is deployment-- which we can't control.
> I really don't think they are related. For a start, software is almost
> always delayed. An obvious second is that this entire scaling
> conversation is polarized to the hilt and everyone that can be blamed
> for something has been blamed for something.
> 
> No one likes to be held to a certain deadline, but this roadmap is just
> about producing some clarity for people who do not do this 24/7.
> 
>> I see you've done this yourself with signature aggregation, sticking Q4 2016
>> right on it, which as far as I can tell is a figure that comes from mars.
> I asked Adam Back for it.
> 
>> It's also not really appropriate to ask people to sign onto stuff when they
>> can't even review it.  Perhaps the signature aggregation stuff is insecure,
>> patent encumbered, or practically useless... (It won't be but no one could
>> tell that from your post; because it doesn't even exist as a concrete proposal)
> Again, I think you're missing the point. If there is a problem with SA,
> you can just suggest it be removed from the document.
> 
> 
>> I think people would rightly protest about a number of these things-- especially
>> things like the the agg sigs and tx compaction, "wtf, I've not heard
>> of this. Who
>> are you to insist this goes into Bitcoin?"
> This is a very strange argument. I would consider it a benefit if people
> learned from the document, and discovered things that they had not heard
> of before.
> 
> There is no "insisting" of any kind.
> 
> 
>> [  Note 1: I think it is important to disclose that several of the
>> items in this list appear to be more or less quoted out of my own
>> blockstream-internal descriptions of things we've been working on in
>> Bitcoin.
>> A while back Adam Back asked me to publish something which contained
>> significant chunks of this document more or less verbatim,
> He probably showed you an earlier draft. But I wrote almost all of this
> myself, and I can only recall 2 or 3 phrases (not even complete
> sentences) included from Adam Back. And most of the phrases are
> themselves just boring descriptions that I'm sure anyone could write.
> Some phrases may have simply been taken from bitcoincore.org <http://bitcoincore.org/> or
> somewhere similar.
> 
> I am not exactly sure what you are insinuating but I encourage you to
> clarify it.
> 
>> and I
>> declined saying that I personally disagree with some of his points and
>> didn't think that Blockstream attempting to redirect the Bitcoin
>> project (esp towards drivechains) was appropriate-- along with my
>> (above) views on roadmaps (which I have included here a private email
>> thread on the subject). I feel it's important to disclose this, and
>> that the document was not otherwise created with the input of project
>> contributors (except Luke-Jr, apparently). I wasn't previously aware
>> that Adam had been working with Paul on this, had I been I would have
>> also encouraged people to be a little more transparent about it. ]
> I really don't understand what you are disclosing. That Adam asked you
> for feedback on the draft? And then, in the next sentence, that not
> enough experts were asked for feedback on the draft? I'm legitimately
> confused by this part.
> 
> As I stated, we can remove the drivechain section. But surely you can
> appreciate how bizarre your position on roadmaps is. What exactly, did
> you intended to create at [1]? Since it is described explicitly as "the
> roadmap in Capacity increases for the Bitcoin system", have you been
> disagreeing with it's characterization as a 'roadmap' this entire time?
> One wonders why you haven't said anything until now.
> 
> [1] https://bitcoincore.org/en/2015/12/21/capacity-increase/ <https://bitcoincore.org/en/2015/12/21/capacity-increase/>
> 
> In my first email I list the benefits of having a roadmap. One benefit
> is that, without one, it is likely that a large majority of outsiders
> have almost no idea at all what is being worked on, what effect it will
> have, or when it might be ready, or to whom/what they should turn to for
> advice on such matters. Do you have a different way of addressing this
> communication problem?
> 
> Paul
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

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

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

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

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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

Hi Greg,


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

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


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

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

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


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

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

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

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


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

There is no "insisting" of any kind.


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

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

> and I
> declined saying that I personally disagree with some of his points and
> didn't think that Blockstream attempting to redirect the Bitcoin
> project (esp towards drivechains) was appropriate-- along with my
> (above) views on roadmaps (which I have included here a private email
> thread on the subject). I feel it's important to disclose this, and
> that the document was not otherwise created with the input of project
> contributors (except Luke-Jr, apparently). I wasn't previously aware
> that Adam had been working with Paul on this, had I been I would have
> also encouraged people to be a little more transparent about it. ]
I really don't understand what you are disclosing. That Adam asked you
for feedback on the draft? And then, in the next sentence, that not
enough experts were asked for feedback on the draft? I'm legitimately
confused by this part.

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

[1] https://bitcoincore.org/en/2015/12/21/capacity-increase/

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

Paul

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Pieter Wuille]

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

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

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

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

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

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

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

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

Cheers,

-- 
Pieter

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Gregory Maxwell]

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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Gregory Maxwell]

On Tue, Jul 11, 2017 at 8:18 PM, Paul Sztorc via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I wrote the roadmap to try to be representative of a Core / developer
> position.

A fine intention, but I've checked with many of the top contributors
and it sounds like the only regular developer you spoke with was
Luke-Jr.  Next time you seek to represent someone you might want to
try talking to them!

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

I think the project is not philosophically against hardforks, at least
not in an absolute sense.

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

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

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

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

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

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[CryptAxe]

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

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


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


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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Gregory Maxwell]

I think it's great that people want to experiment with things like
drivechains/sidechains and what not, but their security model is very
distinct from Bitcoin's and, given the current highly centralized
mining ecosystem, arguably not very good.  So positioning them as a
major solution for the Bitcoin project is the wrong way to go. Instead
we should support people trying cool stuff, at their own risk.

So, given that although the vast majority of the things in the document
are things I've been supporting for months (Please see Note 1 way down
at the bottom) I cannot support your document.

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

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

Consider an example,

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

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

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

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

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

But that isn't what your document does-- it names a lot of things which
are still various shades of research at this point (much of it research
I'm working on and strongly support, in fact--)

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

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

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

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

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

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

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

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

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

I see you've done this yourself with signature aggregation, sticking Q4 2016
right on it, which as far as I can tell is a figure that comes from mars.
(Well not quite mars, see Note 1)
Probably we'll have the research and an implementation done by then, but
with so much uncertainty around segwit activation, I doubt anyone can be
about when users will be able to use it (which is what they care about!)

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

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

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

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


[  Note 1: I think it is important to disclose that several of the
items in this list appear to be more or less quoted out of my own
blockstream-internal descriptions of things we've been working on in
Bitcoin.

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

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

Pieter,

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

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

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

Paul


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


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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

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

Hi Chris,

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

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

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

Paul

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


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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Pieter Wuille]

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

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

Concept ACK.

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


I strongly disagree with that statement.

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

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

Cheers,

-- 
Pieter

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Adam Back]

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

Adam

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Chris Stewart]

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

Concept ACK.

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

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

-Chris

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

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

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

[bitcoin-dev] Updating the Scaling Roadmap

[Paul Sztorc]

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


Summary
=========

In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
crucial ways. One success was that it synchronized the entire Bitcoin
community, helping to bring finality to the (endless) conversations of
that time, and get everyone back to work. However, I feel that the Dec
7, 2015 roadmap is simply too old to serve this function any longer. We
should revise it: remove what has been accomplished, introduce new
innovations and approaches, and update deadlines and projections.


Why We Should Update the Roadmap
=================================

In a P2P system like Bitcoin, we lack authoritative info-sources (for
example, a "textbook" or academic journal), and as a result
conversations tend to have a problematic lack of progress. They do not
"accumulate", as everyone must start over. Ironically, the scaling
conversation _itself_ has a fatal O(n^2) scaling problem.

The roadmap helped solve these problems by being constant in size, and
subjecting itself to publication, endorsement, criticism, and so forth.
Despite the (unavoidable) nuance and complexity of each individual
opinion, it was at least globally known that X participants endorsed Y
set of claims.

Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
obsolete and replacing it is long overdue. For example, it highlights
older items (CSV, compact blocks, versionbits) as being _future_
improvements, and makes no mention of new high-likelihood improvements
(Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
fraud proofs). To read the old roadmap properly, one must already be a
technical expert. For me, this defeats the entire point of having one in
the first place.

A new roadmap would be worth your attention, even if you didn't sign it,
because a refusal to sign would still be informative (and, therefore,
helpful)!

So, with that in mind, let me present a first draft. Obviously, I am
strongly open to edits and feedback, because I have no way of knowing
everyone's opinions. I admit that I am partially campaigning for my
Drivechain project, and also for this "scalability"/"capacity"
distinction...that's because I believe in both and think they are
helpful. But please feel free to suggest edits.

I emphasized concrete numbers, and concrete dates.

And I did NOT necessarily write it from my own point of view, I tried
earnestly to capture a (useful) community view. So, let me know how I did.

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

This document updates the previous roadmap [1] of Dec 2015. The older
statement endorsed a belief that "the community is ready to deliver on
its shared vision that addresses the needs of the system while upholding
its values".

That belief has not changed, but the shared vision has certainly grown
sharper over the last 18 months. Below is a list of technologies which
either increase Bitcoin's maximum tps rate ("capacity"), or which make
it easier to process a higher volume of transactions ("scalability").

First, over the past 18 months, the technical community has completed a
number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables
Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks
(BIP 152) allows for much faster block propagation, as does the FIBRE
Network [3]. Check Sequence Verify (BIP 112) allows trading partners to
mutually update an active transaction without writing it to the
blockchain (this helps to enable the Lightning Network).

Second, Segregated Witness (BIP 141), which reorganizes data in blocks
to handle signatures separately, has been completed and awaits
activation (multiple BIPS). It is estimated to increase capacity by a
factor of 2.2. It also improves scalability in many ways. First, SW
includes a fee-policy which encourages users to minimize their impact on
the UTXO set. Second, SW achieves linear scaling of sighash operations,
which prevents the network from crashing when large transactions are
broadcast. Third, SW provides an efficiency gain for everyone who is not
verifying signatures, as these no longer need to be downloaded or
stored. SegWit is an enabling technology for the Lightning Network,
script versioning (specifically Schnorr signatures), and has a number of
benefits which
are unrelated to capacity [4].

Third, the Lightning Network, which allows users to transact without
broadcasting to the network, is complete [5, 6] and awaits the
activation of SegWit. For those users who are able to make a single
on-chain transaction, it is estimated to increase both capacity and
scalability by a factor of ~1000 (although these capacity increases will
vary with usage patterns). LN also greatly improves transaction speed
and transaction privacy.

Fourth, Transaction Compression [7], observes that Bitcoin transaction
serialization is not optimized for storage or network communication. If
transactions were optimally compressed (as is possible today), this
would improve scalability, but not capacity, by roughly 20%, and in some
cases over 30%.

Fifth, Schnorr Signature Aggregation, which shrinks transactions by
allowing many transactions to have a single shared signature, has been
implemented [8] in draft form in libsecp256k1, and will likely be ready
by Q4 of 2016. One analysis [9] suggests that signature aggregation
would result in storage and bandwidth savings of at least 25%, which
would therefore increase scalability and capacity by a factor of 1.33.
The relative savings are even greater for multisignature transactions.

Sixth, drivechain [10], which allows bitcoins to be temporarily
offloaded to 'alternative' blockchain networks ("sidechains"), is
currently under peer review and may be usable by end of 2017. Although
it has no impact on scalability, it does allow users to opt-in to
greater capacity, by moving their BTC to a new network (although, they
will achieve less decentralization as a result). Individual drivechains
may have different security tradeoffs (for example, a greater reliance
on UTXO commitments, or MimbleWimble's shrinking block history) which
may give them individually greater scalability than mainchain Bitcoin.

Finally, the capacity improvements outlined above may not be sufficient.
If so, it may be necessary to use a hard fork to increase the blocksize
(and blockweight, sigops, etc) by a moderate amount. Such an increase
should take advantage of the existing research on hard forks, which is
substantial [11]. Specifically, there is some consensus that Spoonnet
[12] is the most attractive option for such a hardfork. There is
currently no consensus on a hard fork date, but there is a rough
consensus that one would require at least 6 months to coordinate
effectively, which would place it in the year 2018 at earliest.

The above are only a small sample of current scaling technologies. And
even an exhaustive list of scaling technologies, would itself only be a
small sample of total Bitcoin innovation (which is proceeding at
breakneck speed).

Signed,
<Names Here>

[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
[2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
[3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
[4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
[5]
http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/
[6] https://github.com/ACINQ/eclair
[7] https://people.xiph.org/~greg/compacted_txn.txt
[8]
https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
[9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
[10] http://www.drivechain.info/
[11] https://bitcoinhardforkresearch.github.io/
[12]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html

 ==== End of Roadmap Draft ====

In short, please let me know:

1. If you agree that it would be helpful if the roadmap were updated.
2. To what extent, if any, you like this draft.
3. Edits you would make (specifically, I wonder about Drivechain
thoughts and Hard Fork thoughts, particularly how to phrase the Hard
Fork date).

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

Cheers,
Paul


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