Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EA8E5982 for ; Wed, 12 Jul 2017 22:43:34 +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 0F26116D for ; Wed, 12 Jul 2017 22:43:33 +0000 (UTC) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 70D45284078; Wed, 12 Jul 2017 15:43:33 -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=6GgsRc4UTdA58nr/9 0ZpYwVWfMs=; b=OA8rY6YYMyD5doFjlUC56qdFOcHnPMgNwCrZi2QCyc0Mr5qhk l5y5v/EqYxqYE3waQRKW33ykYAbLhA0lzIVwckpWylR4Xh3puqLCMLuqa4hdBRcv HtwgSHY+IBL6lCzIZq8MdvNDGZHxnHxKtM3mfMroDzCyfg5E+AA8HxDzSk= 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 1C3EC28406C; Wed, 12 Jul 2017 15:43:32 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D0AFBEE6-EDAD-483D-91A5-3EE89CE4FCEA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tao Effect In-Reply-To: <6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com> Date: Wed, 12 Jul 2017 15:43:31 -0700 X-Mao-Original-Outgoing-Id: 521592211.699102-97a45256e816d08fe84607c7668c5ee2 Message-Id: References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com> <83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com> <6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com> To: Paul Sztorc 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 22:45:04 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Drivechain RfD -- Follow Up 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:43:35 -0000 --Apple-Mail=_D0AFBEE6-EDAD-483D-91A5-3EE89CE4FCEA Content-Type: multipart/alternative; boundary="Apple-Mail=_B33A8C94-EFDF-4B78-9242-4CDEEF324520" --Apple-Mail=_B33A8C94-EFDF-4B78-9242-4CDEEF324520 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Paul, I'm assuming it's OK with you that I pick up from where we left off in = the "Scaling Roadmap" thread [1], so as to be on-topic per your request. = (For others reading, part of my reply to the previous email in this = thread is here [2]). For reference, I said: > Isn't it different in the case of P2SH and SegWit, don't full nodes = validate the script? >=20 > In other words, miners don't have complete control over the coins, = full nodes keep a check on them. >=20 > 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. CryptAxe's response was in part: > 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). I am now looking closer again at step number 4 in the Drivechain = specification [2]: 4. Everyone waits for a period of, say, 3 days. This gives everyone an = opportunity to make sure the same WT^ is in both the Bitcoin coinbase = and the Sidechain header. If they=E2=80=99re different, everyone has = plenty of time to contact each other, figure out what is going on, and = restart the process until its right. It seems to me that where our disagreement lies is in this point. The Drivechain spec seems to claim that its use of anyone-can-pay is the = same as P2SH (and in later emails you reference SegWit as well). Is this = really true? The following suggests to me it isn't: 1. Pieter Wuille's email suggests he disagrees [4] 2. Per the question in [1], it's my understanding that P2SH transactions = contain all of the information within themselves for full nodes to act = as a check on miners mishandling the anyone-can-spend nature of P2SH = transactions. However, that does not seem to be the case with WT^ = transactions. In P2SH txns, there is no need for anyone to, as the Drivechain spec = says, "to contact each other, figure out what is going on". Everything = just automatically works. If the security of WT^ transactions could be brought up to actually be = in line with the security of P2SH and SegWit transactions, then I would = have far less to object to. Kind regards, Greg Slepak [1] = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014763.h= tml = [2] = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014745.h= tml = [3] http://www.truthcoin.info/blog/drivechain/ = [4] = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014721.h= tml = -- Please do not email me anything that you are not comfortable also = sharing with the NSA. > On Jun 19, 2017, at 9:04 AM, Paul Sztorc > wrote: >=20 > Hi Greg, >=20 > Responses below: >=20 > On 6/18/2017 5:30 PM, Tao Effect wrote: >> In Drivechain, 51% of miners have total control and ownership over = all >> of the sidechain coins. >=20 > 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. >=20 [ ...snip.. ] --Apple-Mail=_B33A8C94-EFDF-4B78-9242-4CDEEF324520 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Paul,

I'm = assuming it's OK with you that I pick up from where we left off in the = "Scaling Roadmap" thread [1], so as to be on-topic per your request. = (For others reading, part of my reply to the previous email in this = thread is here [2]).

For reference, I said:

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.

CryptAxe's = response was in part:

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). 


I am now looking = closer again at step number 4 in the Drivechain specification = [2]:

4. Everyone waits for a period of, say, 3 = days. This gives everyone an opportunity to make sure the same WT^ is in = both the Bitcoin coinbase and the Sidechain header. If they=E2=80=99re = different, everyone has plenty of time to contact each other, figure out = what is going on, and restart the process until its = right.


It seems to me that = where our disagreement lies is in this point.

The Drivechain spec seems to claim that = its use of anyone-can-pay is the same as P2SH (and in later emails you = reference SegWit as well). Is this really true?

The following suggests to me it = isn't:

1. = Pieter Wuille's email suggests he disagrees [4]

2. Per the question in [1], it's my = understanding that P2SH transactions contain all of the information = within themselves for full nodes to act as a check on miners mishandling = the anyone-can-spend nature of P2SH transactions. However, that does not = seem to be the case with WT^ transactions.


In = P2SH txns, there is no need for anyone to, as the Drivechain spec says, = "to contact each other, figure out what is going on". Everything just = automatically works.


If the security of WT^ = transactions could be brought up to actually be in line with the = security of P2SH and SegWit transactions, then I would have far less to = object to.

Kind = regards,
Greg Slepak


[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ju= ly/014763.html
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ju= ly/014745.html
[3] http://www.truthcoin.info/blog/drivechain/
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ju= ly/014721.html

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

On Jun 19, 2017, at 9:04 AM, Paul Sztorc <truthcoin@gmail.com>= wrote:

Hi = Greg,

Responses below:

On 6/18/2017 5:30 PM, Tao Effect wrote:
In Drivechain, 51% of = miners have total control and ownership over all
of the = sidechain coins.

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.


[ ...snip.. ]

= --Apple-Mail=_B33A8C94-EFDF-4B78-9242-4CDEEF324520-- --Apple-Mail=_D0AFBEE6-EDAD-483D-91A5-3EE89CE4FCEA 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----- iQIcBAEBCgAGBQJZZqYTAAoJEOxnICvpCVJHJc0P/2/nCS3ThsRJ/wC1RjOiFkiF efkN6ufGSxVqu95i6erBOm2RHImDemV680XYCCUD6ow8l4iYqENALatR2iykeHM9 /t6SbCS8cwq/x2FSnJdAo546rJAWITsedhWoASr7nepdpEelOox5CXVe2sILSmFP FzZXgWwSQMQRA8PWIr6HZKnqoUAqzmg8d++fxBKXOPaQ357tDNQNdJclY8uL0fED q2e9zYTKqe9iYxS7LG1pDSHXeEw7Ef9iHxbi9V0m2M8iyzBPjkd87w/F2nckR5mK f5iNaDwLZ6h56MMpSectrxU/spfOcJLq9ttyT8qLMO0oe1Gh90NVY37u9bIMCYrY xWfDP/wtJ3ymBxQGf/z9psGwbpqn5EOGGamWqm2syN8zW5ouCnRXmgPbBNmz1luB vvyH8FQOZsAYea54SO9gkZmTiKyg3TZJ4dRkWw5c0KExXC6e/iQZH+y9kBVEIgi3 o0ckzFKQoCyErZbBlLbKIduqSg4Z2RFZNh2VZDJC4PM5/Aqwko3SG4iKfzxCx7Mp 3oxMHFoz/JpsEajAUDhnCKJq5I8up+75CCKQuLgfhR2Ia1If6Gq98ngYq9gFTQAN E2etRd6KMeA5U9TtGqlcWysbeJUdJiGBU87WynLIa5yS0RBJmSpRCWTkgr6kAGl/ gCaAJ2sayt0zG+ZINGKV =nOXJ -----END PGP SIGNATURE----- --Apple-Mail=_D0AFBEE6-EDAD-483D-91A5-3EE89CE4FCEA--