Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2E8648EE for ; Wed, 12 Jul 2017 19:42:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from homiemail-a3.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0CEAF3CF for ; Wed, 12 Jul 2017 19:42:50 +0000 (UTC) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 8BB2828408C; Wed, 12 Jul 2017 12:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=auwzuZE1Bcv2ueXiy zSDxbc4UEg=; b=CEnhMsXxS3sSJy0+O1try90zKPhhFqGOxa4ZImYzauuOW+X+C 1I2RJpZpXE5bIOENOAoBF+Qa1s/pLz9281/E9k5TIfAi3jvFbhgfpY2Jqj/A5m2H Pmwwh05Ot/odaEICSoBFeRIubf7VGxCaXu6bW+WPGcUWHFy2LBGsR91dwA= Received: from [192.168.42.67] (184-23-252-118.fiber.dynamic.sonic.net [184.23.252.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id 699AA28406C; Wed, 12 Jul 2017 12:42:50 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9CC3A83C-54B5-4A51-A706-61B42BFEB002"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tao Effect In-Reply-To: Date: Wed, 12 Jul 2017 12:42:49 -0700 X-Mao-Original-Outgoing-Id: 521581369.144068-727b04fe2fc80d5e134338b5d618fb3b Message-Id: <18A9E11A-07B2-48B4-B4E7-66A563A97A13@taoeffect.com> References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com> <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com> <08078429-089f-9315-2f76-a08121c5378c@gmail.com> <26FE0468-7049-4BE0-948F-D5E40FE2CBAC@taoeffect.com> To: Chris Stewart X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 12 Jul 2017 19:44:47 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Updating the Scaling Roadmap X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 19:42:52 -0000 --Apple-Mail=_9CC3A83C-54B5-4A51-A706-61B42BFEB002 Content-Type: multipart/alternative; boundary="Apple-Mail=_535F0622-0BBD-47E9-AAB3-DBCA118AB4C4" --Apple-Mail=_535F0622-0BBD-47E9-AAB3-DBCA118AB4C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I think Paul has been pretty upfront about the risks of his model. I think he has been rather misleading in his presentation of the risks. He outlines them in a very technical manner, yes, but then goes on to = promote them to lay people as if they're no big deal, which is = completely misleading. > By your account bitcoin is already insecure then -- it allows anyone = can spend outputs that can be claimed by miners. That is completely different. It is disingenuous to say the two are remotely similar. The two = situations have little-to-nothing in common. In the present situation, anyone-can-spend outputs are used by probably = less than 0.1% of users, and most software doesn't even allow for the = possibility. In Drivechain it's *encouraged-by-design*! - Greg -- Please do not email me anything that you are not comfortable also = sharing with the NSA. > On Jul 12, 2017, at 12:34 PM, Chris Stewart > wrote: >=20 > Hi Greg, >=20 > The safest way to ensure everyone's protection to make sure *no one = can do anything*. Then we will ALL be safe ;). >=20 > >If so, please leave, you are compromising Bitcoin's security. >=20 > Ok, let's calm down. >=20 > >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"? >=20 > 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. >=20 > >It is how *insecure* systems are designed. >=20 > By your account bitcoin is already insecure then -- it allows anyone = can spend outputs that can be claimed by miners. >=20 > >Sure, happy to, as soon as I have it written up in detail. >=20 > I look forward to this! >=20 > -Chris >=20 > On Wed, Jul 12, 2017 at 2:24 PM, Tao Effect > wrote: > Dear Chris, >=20 >> I think this is an unfair characterization. You have to opt into = using drivechains. >=20 > I have heard this nonsense repeated countless times in order to = justify adopting Drivechain. >=20 > This is not how security works. >=20 > 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? >=20 > No. >=20 > This is effectively the same thing Drivechains is doing. >=20 > It is a request to modify the Bitcoin protocol to make it easy for = Bitcoin users to give their Bitcoins to miners. >=20 > Does that sound like a good idea to anyone? >=20 > If so, please leave, you are compromising Bitcoin's security. >=20 > Security is about making it difficult to shoot yourself in the face. >=20 > 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"? >=20 > No. That is fallacy. >=20 > It is not how secure systems are designed. >=20 > It is how *insecure* systems are designed. >=20 >> Care to share? I'm unaware if there is. >=20 >=20 > Sure, happy to, as soon as I have it written up in detail. >=20 > Kind regards, > Greg Slepak >=20 > -- > Please do not email me anything that you are not comfortable also = sharing with the NSA. >=20 >> On Jul 12, 2017, at 12:19 PM, Chris Stewart > wrote: >>=20 >> Hi Greg, >>=20 >> >Here, you admit that the security of the sidechains allows miners to = steal bitcoins, something they cannot do currently. >>=20 >> 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'. >>=20 >> > Drivechain is an unmistakeable weakening of Bitcoin's security = guarantees. This you have not denied. >>=20 >> 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. >>=20 >> As a reminder, most users will not have to go through the drivechain = withdrawal process. Most withdrawals will be done via atomic swaps. >>=20 >> >There is no reason to weaken Bitcoin's security in such a dramatic = fashion. Better options are being worked on, they just take time. >>=20 >> Care to share? I'm unaware if there is. >>=20 >> = >https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.= html = >>=20 >> 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. >>=20 >> -Chris >>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail=_535F0622-0BBD-47E9-AAB3-DBCA118AB4C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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>= 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=20= such a "feature" just because it's "opt-in"?

It would be more like "should we allow a car on the=20 road if we know statistically that our brakes give out in every=20 1/100,000,000 cars"? There is security risks with everything in life --=20= we need to quantify the risk to see if it is worth taking. I think Paul=20= 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=20 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






= --Apple-Mail=_535F0622-0BBD-47E9-AAB3-DBCA118AB4C4-- --Apple-Mail=_9CC3A83C-54B5-4A51-A706-61B42BFEB002 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZZnu5AAoJEOxnICvpCVJHPcoQAJyjDc3o4L1PUvFcfNqjojak hnEBZDTNCnHKNy8sVbnVQl5ZKlnvZ23LWYM9C5zQAr7M/wepaGs/2zGEidPiUT0K kMmUgBY5Pq1Xxj8HD8gVJOAa9OpBh8z97BFd6JCKNpMx50GzWo1RQLIt8MfbW4I2 3GExg5R0wcCx4iELiqDUojf+N5J75CvXCeN3YUm+N9WJJyleSCj9iYJaNi1U/tKJ MiAeH5acJizHAqJxNAsS5AuInPcR5chIEkjtpniCdZbcVH5ip6AwzzJfs8KKdPOl gCZMLkTk2gQZ3xUXq17t5XTZhtqXTde63aRHSx+5526N8hlqd4r+64yy/MGlwS3T 5ATf/o4fIBMuziOLJohzrm5+u3s0ozg1/3bmAbWe674ZYvjJbJ4DopKiNx2Ickdz EBz6dYdB6/L34HffFdUCt1XQeLraDdUl7Okr0Ojl9v0oKnAoNZkvj6TFCu4kNIEd i1VudGKF5h2ztokS1knu+20BGZBojhRxrjqqcUrL4XRlLL1SB0IT3xUP8+4rx/60 3e6cHsQkzeX85+hboUT5c6U+0KOXM8E/FojdoczNGrHPJK+KKcADmS0+TnSRaX/g myXcXYo9yD1UJkXGbZN5dWa4V0YImO097HHKkkp2xmVwGu6L3LdJEg9xF5VvGBpY LVaealV4Y+LFOPDhDdq7 =jJM4 -----END PGP SIGNATURE----- --Apple-Mail=_9CC3A83C-54B5-4A51-A706-61B42BFEB002--