From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6C9956C for ; Wed, 12 Jul 2017 19:34:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from so254-16.mailgun.net (so254-16.mailgun.net [198.61.254.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A26E1F2 for ; Wed, 12 Jul 2017 19:34:57 +0000 (UTC) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=suredbits.com; q=dns/txt; s=mailo; t=1499888096; h=Content-Type: Cc: To: Subject: Message-ID: Date: From: References: In-Reply-To: MIME-Version: Sender; bh=qyfP3M9to8MOk8/vQkjK/aSRmMuJeejCyrlcvffdwq4=; b=bm0NSfzNXe0U/HsTiunYBFTOjzXg84VZleztFgALfh9o6HW/M9jzhSZR2dax8Xkxm1dHamRM fVKA+I3eawm0VTaQYLbyLIWNyeIwyblsJMHbyJjuvPiZm5nYFH1ozHCZz3NqBS9Fe5Ek1WSW r/Z6a66gFoNWxz2NBDU4IbctKQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=suredbits.com; s=mailo; q=dns; h=Sender: MIME-Version: In-Reply-To: References: From: Date: Message-ID: Subject: To: Cc: Content-Type; b=dnmwYBS7Utgtud0fMTaNfxiLXoOErXKnIIPlEUCFihJ8zeYxd+gvgtmcqsm30zCSPECuyD KzkL+wx0A2heX+tn4p9J9A+UQej6LxGdgm9QzE+bvRFC6W3cvu1j7e4zm+JBIvGINCzWkOhW 0ZpN5PIGxCspQjVdAGsuz/nsSiQGA= Sender: chris@suredbits.com X-Mailgun-Sending-Ip: 198.61.254.16 X-Mailgun-Sid: WyI5MGYzNyIsICJiaXRjb2luLWRldkBsaXN0cy5saW51eGZvdW5kYXRpb24ub3JnIiwgIjJjMTQxIl0= Received: from mail-it0-f42.google.com (mail-it0-f42.google.com [209.85.214.42]) by mxa.mailgun.org with ESMTP id 596679e0.7f4d1048d130-smtp-out-n03; Wed, 12 Jul 2017 19:34:56 -0000 (UTC) Received: by mail-it0-f42.google.com with SMTP id m84so22176563ita.0 for ; Wed, 12 Jul 2017 12:34:56 -0700 (PDT) X-Gm-Message-State: AIVw113obOlA+nVXJv2d7Id/SxTm7G87wq8a5veRDRAYvDPTMbHr/SSw INUdpuONK8Yat+njNe/2AdjmAZEm1A== X-Received: by 10.36.224.132 with SMTP id c126mr10099230ith.54.1499888095822; Wed, 12 Jul 2017 12:34:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.174.131 with HTTP; Wed, 12 Jul 2017 12:34:54 -0700 (PDT) In-Reply-To: <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> <26FE0468-7049-4BE0-948F-D5E40FE2CBAC@taoeffect.com> From: Chris Stewart Date: Wed, 12 Jul 2017 14:34:54 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Tao Effect Content-Type: multipart/alternative; boundary="94eb2c19e2b427cb46055423e93f" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no 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:36:11 +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:34:58 -0000 --94eb2c19e2b427cb46055423e93f Content-Type: text/plain; charset="UTF-8" Hi Greg, The safest way to ensure everyone's protection to make sure *no one can do anything*. Then we will ALL be safe ;). >If so, please leave, you are compromising Bitcoin's security. Ok, let's calm down. >If I design a car that has a button that randomly causes the brakes to give out if pressed, is that a good idea? Can I justify pushing for such a "feature" just because it's "opt-in"? It would be more like "should we allow a car on the road if we know statistically that our brakes give out in every 1/100,000,000 cars"? There is security risks with everything in life -- we need to quantify the risk to see if it is worth taking. I think Paul has been pretty upfront about the risks of his model. I think you did a good job of demonstrating it in the email I cited too. >It is how *insecure* systems are designed. By your account bitcoin is already insecure then -- it allows anyone can spend outputs that can be claimed by miners. >Sure, happy to, as soon as I have it written up in detail. I look forward to this! -Chris On Wed, Jul 12, 2017 at 2:24 PM, Tao Effect wrote: > Dear Chris, > > I think this is an unfair characterization. You have to opt into using > drivechains. > > > I have heard this nonsense repeated countless times in order to justify > adopting Drivechain. > > This is not how security works. > > A child can "opt-in" to using a loaded gun, but is it a good idea to make > it easy for them to do that? > > No. > > This is effectively the same thing Drivechains is doing. > > It is a request to modify the Bitcoin protocol to make it easy for Bitcoin > users to give their Bitcoins to miners. > > Does that sound like a good idea to anyone? > > If so, please leave, you are compromising Bitcoin's security. > > Security is about making it difficult to shoot yourself in the face. > > If I design a car that has a button that randomly causes the brakes to > give out if pressed, is that a good idea? Can I justify pushing for such a > "feature" just because it's "opt-in"? > > No. That is fallacy. > > It is not how secure systems are designed. > > It is how *insecure* systems are designed. > > Care to share? I'm unaware if there is. > > > Sure, happy to, as soon as I have it written up in detail. > > Kind regards, > Greg Slepak > > -- > Please do not email me anything that you are not comfortable also sharing with > the NSA. > > On Jul 12, 2017, at 12:19 PM, Chris Stewart wrote: > > Hi Greg, > > >Here, you admit that the security of the sidechains allows miners to > steal bitcoins, something they cannot do currently. > > If I put my coins in an anyone can spend output, a miner will take them. > They can do this today. I suggest you try it if you don't believe me :-). > You have to be more specific with contract types instead of generically > talking about 'all contracts ever'. > > > Drivechain is an unmistakeable weakening of Bitcoin's security > guarantees. This you have not denied. > > I think this is an unfair characterization. You have to opt into using > drivechains. Other outputs such as P2PKH/Multisig etc are unaffected by a > drivechain output. As Pieter Wuille stated earlier in this thread (and Paul > has stated all along), drivechain outputs have a different security model > than other contracts. Namely they are controlled by miners. I think we can > all agree this is unfortunate, but it is the current reality we live in. I > look forward to the day we can solve the 'ownership' problem so we can have > trustless interoperable blockchains, but that day is not today. > > As a reminder, most users will not have to go through the drivechain > withdrawal process. Most withdrawals will be done via atomic swaps. > > >There is no reason to weaken Bitcoin's security in such a dramatic > fashion. Better options are being worked on, they just take time. > > Care to share? I'm unaware if there is. > > >https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600. > html > > Everyone should re-read this email though, this is something that could > happen. Paul's design makes it so that if this occurs it is *VERY* obvious. > I guess we can argue if there is any difference between an obvious robbery > vs a hidden robbery, but I think if we have to pick one or the other the > choice is clear to me. Other designs (that I'm aware of) for sidechains had > attack vectors that weren't so obvious. > > -Chris > > > > > --94eb2c19e2b427cb46055423e93f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg,

The safest way to ensu= re 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 goo= d job of demonstrating it in the email I cited too.

>It is how *insecure* systems are designed.

By your accoun= t bitcoin is already insecure then -- it allows anyone can spend outputs th= at can be claimed by miners.

>Sure, happy to, as soon as I have i= t 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,

<= div>
I think this is an unfair ch= aracterization. You have to opt into using drivechains.
<= br>
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 effe= ctively 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.

Secur= ity is about making it difficult to shoot yourself in the face.
<= br>
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 f= or such a "feature" just because it's "opt-in"?

No. That is fallacy.

It is n= ot how secure systems are designed.

It is how *ins= ecure* systems are designed.

Care to share? I'm una= ware if there is.=C2=A0

=
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=C2=A0with 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 th= em. They can do this today. I suggest you try it if you don't believe m= e :-). You have to be more specific with contract types instead of generica= lly talking about 'all contracts ever'.

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

I think this is an unfair character= ization. You have to opt into using drivechains. Other outputs such as P2PK= H/Multisig etc are unaffected by a drivechain output. As Pieter Wuille stat= ed earlier in this thread (and Paul has stated all along), drivechain outpu= ts have a different security model than other contracts. Namely they are co= ntrolled 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 blockch= ains, 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 rea= son to weaken Bitcoin's security in such a dramatic=20 fashion. Better options are being worked on, they just take time.

Everyone sho= uld re-read this email though, this is something that could happen. Paul= 9;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 hidde= n robbery, but I think if we have to pick one or the other the choice is cl= ear to me. Other designs (that I'm aware of) for sidechains had attack = vectors that weren't so obvious.

-Chris





--94eb2c19e2b427cb46055423e93f--