Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 274436C for ; Wed, 12 Jul 2017 19:24:31 +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 63F761F2 for ; Wed, 12 Jul 2017 19:24:30 +0000 (UTC) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id D8DF3284087; Wed, 12 Jul 2017 12:24:29 -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=Tk9RN7E5UswILc9YK qryH/+dBrU=; b=SbzuAApWbWfcJQzO6eF7fQzYo8zgdL9wOAZyUWvHUyLybqI+N 4weHF324oEPH5K3NKjPVmho+m/H4XhdmxbGVMoZ6EY9cleRJXsqpDRjo2EGZuaPE qObo30zp9j863dq0G3TOi3FpbffuGCkyiucgCtj5cDhQlu82pKmv0bBXYQ= 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 85874284078; Wed, 12 Jul 2017 12:24:29 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_30B1E1D8-DC1E-4AA8-B749-A2AAA02879B5"; 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:24:28 -0700 X-Mao-Original-Outgoing-Id: 521580268.087857-b34895a95886c626c48881606dcd349d Message-Id: <26FE0468-7049-4BE0-948F-D5E40FE2CBAC@taoeffect.com> References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com> <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com> <08078429-089f-9315-2f76-a08121c5378c@gmail.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:27:04 +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:24:31 -0000 --Apple-Mail=_30B1E1D8-DC1E-4AA8-B749-A2AAA02879B5 Content-Type: multipart/alternative; boundary="Apple-Mail=_2DDDFBFD-2A3C-485A-BA09-D6BD09394C92" --Apple-Mail=_2DDDFBFD-2A3C-485A-BA09-D6BD09394C92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Chris, > I think this is an unfair characterization. You have to opt into using = drivechains. I have heard this nonsense repeated countless times in order to justify = adopting Drivechain. This is not how security works. A child can "opt-in" to using a loaded gun, but is it a good idea to = make it easy for them to do that? No. This is effectively the same thing Drivechains is doing. It is a request to modify the Bitcoin protocol to make it easy for = Bitcoin users to give their Bitcoins to miners. Does that sound like a good idea to anyone? If so, please leave, you are compromising Bitcoin's security. Security is about making it difficult to shoot yourself in the face. If I design a car that has a button that randomly causes the brakes to = give out if pressed, is that a good idea? Can I justify pushing for such = a "feature" just because it's "opt-in"? No. That is fallacy. It is not how secure systems are designed. It is how *insecure* systems are designed. > Care to share? I'm unaware if there is. Sure, happy to, as soon as I have it written up in detail. Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also = sharing with the NSA. > On Jul 12, 2017, at 12:19 PM, Chris Stewart > wrote: >=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 --Apple-Mail=_2DDDFBFD-2A3C-485A-BA09-D6BD09394C92 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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-Ju= ne/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=_2DDDFBFD-2A3C-485A-BA09-D6BD09394C92-- --Apple-Mail=_30B1E1D8-DC1E-4AA8-B749-A2AAA02879B5 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----- iQIcBAEBCgAGBQJZZndsAAoJEOxnICvpCVJHywAQAIMmljqNX4K1i/UNZu35Sm5q 2IuPkPztCIAfiNUcxc2zDf6M5tjA8jbiS4tOKyYsULselQs92zr0/yvlEiO/RZHw CoAdYEYx9BXczjAQov4QfQ5tm8mJBWgNu+jsBCurNuA85W99W9Ib2xOj9og9AByA OguQXO5VP3nsjcI+yEq3ztHn/H4TfaJ6YJsMDYUlq7M6r4vSGZMyZUw0IOmulo1l /heqoR0qoFOiiu8XWXNe9x1zD3DWDZt5QAeELgm6c8HlzpaPhZMUlJvMn6xAjkcP mp7H169lbrMwH63hbiFpUE7I3m225wxJ3lF4Hw0g9ae+6VCJtZQ1JnyP4+83Pkrj jiz2rfzz6iJ4/tNvFaXtnB3e7QNBnOtcb8aekDQKVozC1Hfl6uLtzCNw14POW3Ez sohfAuNHFJzfYvNYo3tQ263Dkzzwb7v+VkNOKCAIEehzNzqQk9ke1uH84mZikaO2 VU4IVBwLP3nqZS+G8bmJsI2nF/Z577QgB58x1S1jXjKXjxQ6KxNe88QLTOfAD+QU KZzjQi1c0AMb5npBSqJEPWihYs6VfcTUkYRCKCOSsr4vr669ZNGxAHqLM41Ss9ua ILGtRWTtxZjifQzh3zSYcq0n9dGnDMdhPdHqbdkZROoNLrrHeuNrp/A36H/yxRGy 89mEhe0xefgxPhY2GRE1 =A7CG -----END PGP SIGNATURE----- --Apple-Mail=_30B1E1D8-DC1E-4AA8-B749-A2AAA02879B5--