Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 66807901 for ; Wed, 12 Jul 2017 22:13:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com [74.125.83.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9C81486 for ; Wed, 12 Jul 2017 22:13:16 +0000 (UTC) Received: by mail-pg0-f50.google.com with SMTP id k14so19509448pgr.0 for ; Wed, 12 Jul 2017 15:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=7vujbtPMHwkQklUC5527QjH387y2wAYinBVh8Yfz2ME=; b=ZH7ao61icKpxaXFDvsThe+K8nY38/FcSpYEmq3A+vrtuMkYyX/jJfjy8HdFWMDMBpl XHS3vUfsIfb9VGXC9sr7YG5mDEjDg6Kr3wSQVXFWJPmc6DipcZ3DHw8AeDDkZfkaNLhB kfxqI/CMyETG9r/Jak+yQswalugZnblRwQTdei/3KC+ZUzPoVuPtKRA3nG/1hd1YQKtU jAfhCr3TuTDlKFBgmwFosWQkJwe8J9lqEGx7BbP4gq7rF0dfAbmDLzbbwMvNxRWUjcSw on5PZZmrJf/UMlZhSMdZVqojUTx2wjtlXkMJFiOBBRuByxe9rtQA3yfj1JMcPBHnfyDX aLAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=7vujbtPMHwkQklUC5527QjH387y2wAYinBVh8Yfz2ME=; b=C6vJ3Vb826l2VS+Y5f2Xa96JNnOOPeyp+zRvm9APVbYezWMMVJeRTjexP/Bs+bzkPA D5/6912r4lrPCr96ffRFtd/2l6+ZV7cZjaRCh7geO4vTUh5202saYxwJYZC4bBTtDze5 9GxVX486OL1N5+ouV0FnQ0W1NWVOXMPVidGXSD0PO+6MqQFgi9qy5RaLsg9xHVeVv9o4 hwCGfncbYJKfQHyGnQ00obm3W1xcLKAUBgZKcS2p36b0BNgRPkWr4r1dy7wABXZamAGt ZNU2YeKFFoa+Eup4becoOZAStT5UFSUk3l4xo0HxmJxOoDugiZvnUFcQXAa0+7f/XR/4 IcZA== X-Gm-Message-State: AIVw112Iv5FVwGpRqM7fLzjEfL/rEy4SEpVDAJbROgcVRdK7ERhDBnrR H4ErWx/XwNJ6zbHTjzz2Mw== X-Received: by 10.84.176.100 with SMTP id u91mr6337479plb.182.1499897595828; Wed, 12 Jul 2017 15:13:15 -0700 (PDT) Received: from [192.168.1.3] (c-50-188-181-7.hsd1.or.comcast.net. [50.188.181.7]) by smtp.gmail.com with ESMTPSA id s11sm6586717pgr.53.2017.07.12.15.13.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 15:13:14 -0700 (PDT) To: Tao Effect , Bitcoin Protocol Discussion 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> <18A9E11A-07B2-48B4-B4E7-66A563A97A13@taoeffect.com> <37ed4927-d13b-f34d-a13c-9aaa55ea426b@gmail.com> <2AB8B976-5E62-4B1A-9B1B-0109EA4F606F@taoeffect.com> From: CryptAxe Message-ID: Date: Wed, 12 Jul 2017 15:07:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <2AB8B976-5E62-4B1A-9B1B-0109EA4F606F@taoeffect.com> Content-Type: multipart/alternative; boundary="------------7771C38132529B7D86D943FD" Content-Language: en-US X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 22:27:57 +0000 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 22:13:17 -0000 This is a multi-part message in MIME format. --------------7771C38132529B7D86D943FD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 mode= l. > > - Greg > > [1] https://steemit.com/bitcoin/@jl777/bitcoin-spinoff-fork-how-to-make= -a-clean-fork-without-any-replay-attack-and-no-blockchain-visible-changes= > > > -- > Please do not email me anything that you are not comfortable also > sharing with the NSA. > >> On Jul 12, 2017, at 12:54 PM, CryptAxe via bitcoin-dev >> > > wrote: >> >> Are we just pulling numbers out of thin air now? https://p2sh.info/ >> BIP16 for example is widely used. It would be difficult to find a >> single wallet that doesn't support BIP16 I have no idea what you are >> talking about. >> >> >> On 07/12/2017 12:42 PM, Tao Effect via bitcoin-dev wrote: >>> ... >>> In the present situation, anyone-can-spend outputs are used by >>> probably less than 0.1% of users, and most software doesn't even >>> allow for the possibility. >>> >>> In Drivechain it's *encouraged-by-design*! >>> >>> - Greg >>> >>> -- >>> Please do not email me anything that you are not comfortable also >>> sharing with the NSA. >>> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --------------7771C38132529B7D86D943FD Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

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> wrote:

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


On 07/12/2017 12:42 PM, Tao Effect via bitcoin-dev wrote:
...
In the present situation, anyone-can-spend outputs are used by probably less than 0.1% of users, and most software doesn't even allow for the possibility.

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

- Greg

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


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


--------------7771C38132529B7D86D943FD--