Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 281DCB2A for ; Thu, 13 Jul 2017 03:24:13 +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 64AB510A for ; Thu, 13 Jul 2017 03:24:11 +0000 (UTC) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id C9C77284078; Wed, 12 Jul 2017 20:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h=from :content-type:mime-version:subject:message-id:date:references:to :in-reply-to; s=taoeffect.com; bh=gAXQUKynjMciZW5h6RU6m1zJB6M=; b=Qh457lAIu+YSG78IEHfM9kunAoJbwJcrB03qeZcu0pPVRPRh8Q/sCGnVxO581 Cue/RvnV68Ihfrv+qEOkH46IPEdDfdOG9HtbzlvKMwPZTmDedaVTQXdZndjH4y7s mbQJL2L8TRSz/J5Ko9kx0fTQcUmrDWC3ADcCGHc+S+0bo8= 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 96FB228406C; Wed, 12 Jul 2017 20:24:10 -0700 (PDT) From: Tao Effect Content-Type: multipart/signed; boundary="Apple-Mail=_00D64527-0324-4692-826A-5D68957184F5"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Mao-Original-Outgoing-Id: 521609049.7779-a6449991ad806af44a20e278efcee780 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <3F1802B5-FDD5-4E4F-9A5D-238C5F83116F@taoeffect.com> Date: Wed, 12 Jul 2017 20:24:10 -0700 References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com> <83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com> <6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com> <117f6a96-6d90-778a-d87a-be72592e31c5@gmail.com> <42C03DFC-C358-4F8C-A088-735910CCC60E@taoeffect.com> <3277f4ef-a250-d383-8b00-cb912eb19f8b@gmail.com> To: Paul Sztorc , Bitcoin Protocol Discussion In-Reply-To: <3277f4ef-a250-d383-8b00-cb912eb19f8b@gmail.com> 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: Thu, 13 Jul 2017 03:51:41 +0000 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: Thu, 13 Jul 2017 03:24:13 -0000 --Apple-Mail=_00D64527-0324-4692-826A-5D68957184F5 Content-Type: multipart/alternative; boundary="Apple-Mail=_8CD43468-0A58-49E7-82A4-666B949AE531" --Apple-Mail=_8CD43468-0A58-49E7-82A4-666B949AE531 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Paul, > In point of fact, he is wrong, because nodes do the counting. When = miners find a block, they can choose to move the counter up, down, or = not at all. But nodes do the counting. I may very well have confused who counts what, but for this discussion = on *theft* it's irrelevant, so I won't push further on this. Let's move on to the theft. > Again, keep in mind that Greg continually conflates two different = things: > 1. Whether the soft fork rules have been followed, and > 2. Whether the WT^ submitted by a majority hashrate matches the one = calculated by sidechain nodes. >=20 > The first case is exactly equal to P2SH. Just as old nodes accept = every P2SH transaction, so too will [DC#0] users accept every WT^ = transaction. To be crystal clear: I am entirely uninterested in the un-upgraded = nodes, what you call [DC#0]. They are irrelevant to my argument. > In the second case, it so happens that [DC#1], [DC#2], and [DC#3] = would also accept any WT^ *that followed the Drivechain rules*, even if = they did not like the outcome (because the outcome in question was = arbitrarily designated as a "theft" of funds -- again, see the second = case in the list above). In this way, it is exactly similar to P2SH = because nodes will accept *any* p2sh txn **that follows the p2sh = rules**, even if they don't "like" the specific script contained within = (for example, because it is a theft of "their" BitFinex funds, or a = donation to a political candidate they dislike, etc). This is false. For miners to steal P2SH funds, the P2SH script would have to be coded = to explicitly allow them to do it. How many P2SH scripts are you aware of that are used for the purpose of = facilitating such theft? I know of none, and I bet there are none. Whereas in DC, every single usage of DC allows miners to steal funds. >> In P2SH, all upgraded nodes will reject invalid P2SH transactions, = period. >=20 > In DC, all upgraded nodes will reject invalid DC transactions, period. It appears you are playing games with the meaning of "invalid" here, so = that sentence is invalid. I was very clear what I meant by "invalid" in my email: WT^ transactions = that represent miners stealing funds. Please stick to that and do not = play word games. > The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and = [DC#1] nodes do. This is what I mean by "every withdrawal is valid". So, here you are again re-affirming that WT^ transactions representing = stolen funds are allowed in DC, and by tying them all together you are = also affirming that the SPV proofs mentioned in DC are completely = irrelevant / pointless / unused. >> Again, in P2SH miners cannot steal funds, because all full nodes have = a fully automatic enforcement policy. >=20 > In DC, miners cannot steal funds, because all full nodes have a fully = automatic enforcement policy. >=20 > However, DC *allows* users to choose to place some of their BTC at the = relative mercy of the miners in creative ways, if they wish (as does = P2SH -- someone could write a script which donates funds to miners, and = then fund it... "paying" to that script). This is another example of = conflating [DC#1] and [DC#3]. So in the first sentence you say they "cannot steal funds", but = everything else you've said, including the following paragraph, and your = specification, indicates they can. I've finally collected all my thoughts / concerns and have also = summarized them in this document: https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9 = 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 7:58 PM, Paul Sztorc via bitcoin-dev = > wrote: >=20 > I will repeat that Drivechain can sometimes be confusing because it is = different things to different people. >=20 > Here is my attempt to break it down into different modes: >=20 > [DC#0] -- Someone who does not upgrade their Bitcoin software (and is = running, say, 0.13). However, they experience the effects of the new = rules which miners add (as per the soft fork[s] to add drivechain = functionality and individual drivechains). > [DC#1] -- Someone who always upgrades to the latest version of the = Bitcoin software, but otherwise has no interest in running/using = sidechains. > [DC#2] -- Someone who upgrades to the latest Bitcoin version, and = decides to also become a full node of one or more sidechains, but who = ever actually uses the sidechains. > [DC#3] -- Someone who upgrades their software, runs sidechain full = nodes, and actively moves money to and from these. >=20 > Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he = equivocates on the team "steal", using it to mean two different things: = [a] spending an invalid transaction, and [b] a withdrawal that would not = match the report given by a sidechain node. >=20 > The two are quite different, see my comments below: >=20 >=20 > On 7/12/2017 9:15 PM, Tao Effect wrote: >>> FYI that document is nearly two years old, and although it is still = overwhelmingly accurate, new optimizations allow us (I think) to push = the waiting period to several weeks and the total ACK counting period up = to several months. >>=20 >> What does that have to do with my question? The counting period, if I = understood correctly, is something miners do, not full nodes. >=20 > Greg quoted a passage that contained an older parameter estimate of "a = few days", and I thought it would be helpful and informative if I = clarified that the parameter estimate had been updated to a new (more = secure) value. >=20 > In point of fact, he is wrong, because nodes do the counting. When = miners find a block, they can choose to move the counter up, down, or = not at all. But nodes do the counting. >=20 >=20 >> Also, if the document is old and/or outdated, do you happen to have a = link to a more update-to-date version of the spec? It would be helpful = for review. >=20 > As I stated above, the document is mostly accurate. There is no other = more up to date version. >=20 >=20 >>> Because if a node doesn't have the sidechain's information, it will = just assume every withdrawal is valid. This is comparable to someone who = still hasn't upgraded to support P2SH, in cases [DC#0] and [#1]. >>=20 >> Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it = as "Yes" without substantiating why you did so. >=20 >=20 > Above, Greg omitted his original question. For reference, it was: >=20 >> The Drivechain spec seems to claim that its use of anyone-can-pay is = the same as P2SH >=20 > The answer is that both DC and P2SH use transactions which are 'always = valid' to some group of people (un-upgraded users) but which are = sometimes invalid to new users. So the only difference would be for = [DC#0] vs other versions, but this difference is trivial as miners will = censor invalid txns. >=20 > It is your classic soft fork situation. >=20 >=20 >>> Again, from the perspective of a mainchain user, every withdrawal is = valid. >>=20 >> And that is not how P2SH works. >=20 > Again, keep in mind that Greg continually conflates two different = things: > 1. Whether the soft fork rules have been followed, and > 2. Whether the WT^ submitted by a majority hashrate matches the one = calculated by sidechain nodes. >=20 > The first case is exactly equal to P2SH. Just as old nodes accept = every P2SH transaction, so too will [DC#0] users accept every WT^ = transaction. >=20 > In the second case, it so happens that [DC#1], [DC#2], and [DC#3] = would also accept any WT^ *that followed the Drivechain rules*, even if = they did not like the outcome (because the outcome in question was = arbitrarily designated as a "theft" of funds -- again, see the second = case in the list above). In this way, it is exactly similar to P2SH = because nodes will accept *any* p2sh txn **that follows the p2sh = rules**, even if they don't "like" the specific script contained within = (for example, because it is a theft of "their" BitFinex funds, or a = donation to a political candidate they dislike, etc). >=20 >=20 >>> [DC#2] and [DC#3] would certainly have an interest in understanding = what is going on, but that has absolutely nothing whatsoever to do with = Bitcoin Core and so is off-topic for this mailing list. >>=20 >> How is that an answer to my question? >=20 > Greg is, of course, not entitled to an answer to irrelevant questions = -- just as he would not be entitled to an answer if he asked for my = favorite color or my home address. And such answers would needlessly = consume the mailing list's scarce time. >=20 >=20 >> What does "[DC#2] and [DC#3] would certainly have an interest in = understanding what is going on" mean? >=20 > It is clear to me that, if we are not clear on the basics first, we = cannot hope to tackle anything intermediate. We will come back to this = after clearing up soft fork part. >=20 >=20 >> In P2SH, all upgraded nodes will reject invalid P2SH transactions, = period. >=20 > In DC, all upgraded nodes will reject invalid DC transactions, period. >=20 >=20 >> What exactly would [DC#2] and [DC#3] nodes do when faced with an = invalid WT^ transaction =E2=80=94 invalid in the sense that it contains = funds which miners are stealing? >=20 > The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and = [DC#1] nodes do. This is what I mean by "every withdrawal is valid". >=20 >=20 >> Again, in P2SH miners cannot steal funds, because all full nodes have = a fully automatic enforcement policy. >=20 > In DC, miners cannot steal funds, because all full nodes have a fully = automatic enforcement policy. >=20 > However, DC *allows* users to choose to place some of their BTC at the = relative mercy of the miners in creative ways, if they wish (as does = P2SH -- someone could write a script which donates funds to miners, and = then fund it... "paying" to that script). This is another example of = conflating [DC#1] and [DC#3]. >=20 > Paul --Apple-Mail=_8CD43468-0A58-49E7-82A4-666B949AE531 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Paul,

In point of fact, he is wrong, because nodes do the = counting. When miners find a block, they can choose to move the counter = up, down, or not at all. But nodes do the counting.

I may very well have confused who counts = what, but for this discussion on *theft* it's irrelevant, so I won't = push further on this.

Let's move on to the theft.

Again, keep in mind that = Greg continually conflates two different things:
1. Whether the soft fork rules have been followed, = and
2. Whether the WT^ submitted = by a majority hashrate matches the one calculated by sidechain = nodes.

The first case is exactly = equal to P2SH. Just as old nodes accept every P2SH transaction, so too = will [DC#0] users accept every WT^ transaction.

To be crystal clear: I am entirely = uninterested in the un-upgraded nodes, what you call [DC#0].

They are irrelevant to = my argument.

In the second case, it = so happens that [DC#1], [DC#2], and [DC#3] would also accept any WT^ = *that followed the Drivechain rules*, even if they did not like the = outcome (because the outcome in question was arbitrarily designated as a = "theft" of funds -- again, see the second case in the list above). In = this way, it is exactly similar to P2SH because nodes will accept *any* = p2sh txn **that follows the p2sh rules**, even if they don't "like" the = specific script contained within (for example, because it is a theft of = "their" BitFinex funds, or a donation to a political candidate they = dislike, etc).

This is false.

For miners to steal P2SH funds, the P2SH script would have to = be coded to explicitly allow them to do it.

How many P2SH scripts are you aware of = that are used for the purpose of facilitating such theft?

I know of none, and I = bet there are none.

Whereas in DC, every single usage of DC allows miners to = steal funds.

In = P2SH, all upgraded nodes will reject invalid P2SH transactions, = period.

In DC, all = upgraded nodes will reject invalid DC transactions, period.

It appears you = are playing games with the meaning of "invalid" here, so that sentence = is invalid.

I = was very clear what I meant by "invalid" in my email: WT^ transactions = that represent miners stealing funds. Please stick to that and do not = play word games.

The [DC#2] and [DC#3] nodes would do exactly what the = [DC#0] and [DC#1] nodes do. This is what I mean by "every withdrawal is = valid".

So, here = you are again re-affirming that WT^ transactions representing stolen = funds are allowed in DC, and by tying them all together you are also = affirming that the SPV proofs mentioned in DC are completely irrelevant = / pointless / unused.

Again, = in P2SH miners cannot steal funds, because all full nodes have a fully = automatic enforcement policy.

In DC, miners cannot steal funds, because all full = nodes have a fully automatic enforcement policy.

However, DC *allows* users to choose to place some = of their BTC at the relative mercy of the miners in creative ways, if = they wish (as does P2SH -- someone could write a script which donates = funds to miners, and then fund it... "paying" to that script). This is = another example of conflating [DC#1] and [DC#3].

So in the first sentence you say they = "cannot steal funds", but everything else you've said, including the = following paragraph, and your specification, indicates they = can.

I've = finally collected all my thoughts / concerns and have also summarized = them in this document:

https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e53= 4c9

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 7:58 PM, Paul Sztorc via bitcoin-dev = <bitcoin-dev@lists.linuxfoundation.org> wrote:

I = will repeat that Drivechain can sometimes be confusing because it is = different things to different people.

Here = is my attempt to break it down into different modes:

[DC#0] -- Someone who does not upgrade their Bitcoin software = (and is running, say, 0.13). However, they experience the effects of the = new rules which miners add (as per the soft fork[s] to add drivechain = functionality and individual drivechains).
[DC#1] -- = Someone who always upgrades to the latest version of the Bitcoin = software, but otherwise has no interest in running/using sidechains.
[DC#2] -- Someone who upgrades to the latest Bitcoin version, = and decides to also become a full node of one or more sidechains, but = who ever actually uses the sidechains.
[DC#3] -- Someone = who upgrades their software, runs sidechain full nodes, and actively = moves money to and from these.

Greg is = still conflating modes [DC#1] and [DC#3]. Specifically, he equivocates = on the team "steal", using it to mean two different things: [a] spending = an invalid transaction, and [b] a withdrawal that would not match the = report given by a sidechain node.

The two = are quite different, see my comments below:


On 7/12/2017 9:15 PM, Tao Effect wrote:
FYI that document is nearly two years = old, and although it is still overwhelmingly accurate, new optimizations = allow us (I think) to push the waiting period to several weeks and the = total ACK counting period up to several = months.
What does that have to = do with my question? The counting period, if I understood correctly, is = something miners do, not full nodes.

Greg quoted a passage that contained an older = parameter estimate of "a few days", and I thought it would be helpful = and informative if I clarified that the parameter estimate had been = updated to a new (more secure) value.

In point of fact, he is wrong, because nodes do the counting. = When miners find a block, they can choose to move the counter up, down, = or not at all. But nodes do the counting.


Also, = if the document is old and/or outdated, do you happen to have a link to = a more update-to-date version of the spec? It would be helpful for = review.

As I stated above, the document is mostly accurate. There is = no other more up to date version.


Because if a node doesn't have the = sidechain's information, it will just assume every withdrawal is valid. = This is comparable to someone who still hasn't upgraded to support P2SH, = in cases [DC#0] and [#1].

Right, for [DC#0] and [DC#1], but for = [DC#2] an [DC#3] you marked it as "Yes" without substantiating why you = did so.


Above, Greg omitted his original question. For reference, it = was:

 The Drivechain spec seems =
to claim that its use of anyone-can-pay is the same as =
P2SH

The answer is that = both DC and P2SH use transactions which are 'always valid' to some group = of people (un-upgraded users) but which are sometimes invalid to new = users. So the only difference would be for [DC#0] vs other versions, but = this difference is trivial as miners will censor invalid txns.

It is your classic soft fork = situation.


Again, from the perspective of a = mainchain user, every withdrawal is valid.
And that is not how P2SH works.

Again, keep in mind that Greg continually = conflates two different things:
1. Whether the soft fork rules have been followed, = and
2. Whether the WT^ = submitted by a majority hashrate matches the one calculated by sidechain = nodes.

The first case is = exactly equal to P2SH. Just as old nodes accept every P2SH transaction, = so too will [DC#0] users accept every WT^ transaction.

In the second case, it so happens that [DC#1], = [DC#2], and [DC#3] would also accept any WT^ *that followed the = Drivechain rules*, even if they did not like the outcome (because the = outcome in question was arbitrarily designated as a "theft" of funds -- = again, see the second case in the list above). In this way, it is = exactly similar to P2SH because nodes will accept *any* p2sh txn **that = follows the p2sh rules**, even if they don't "like" the specific script = contained within (for example, because it is a theft of "their" BitFinex = funds, or a donation to a political candidate they dislike, = etc).


[DC#2] and [DC#3] would certainly have an = interest in understanding what is going on, but that has absolutely = nothing whatsoever to do with Bitcoin Core and so is off-topic for this = mailing list.
How = is that an answer to my question?

Greg is, of course, not entitled to an answer to = irrelevant questions -- just as he would not be entitled to an answer if = he asked for my favorite color or my home address. And such answers = would needlessly consume the mailing list's scarce time.


What = does "[DC#2] and [DC#3] would certainly have an interest in = understanding what is going on" mean?

It is clear to me that, if we are not clear on = the basics first, we cannot hope to tackle anything intermediate. We = will come back to this after clearing up soft fork part.


In = P2SH, all upgraded nodes will reject invalid P2SH transactions, = period.

In DC, all upgraded nodes will reject invalid DC = transactions, period.


What = exactly would [DC#2] and [DC#3] nodes do when faced with an invalid WT^ = transaction =E2=80=94 invalid in the sense that it contains funds which = miners are stealing?

The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] = and [DC#1] nodes do. This is what I mean by "every withdrawal is = valid".


Again, = in P2SH miners cannot steal funds, because all full nodes have a fully = automatic enforcement policy.

In DC, miners cannot steal funds, because all full nodes have = a fully automatic enforcement policy.

However, DC *allows* users to choose to place some of their = BTC at the relative mercy of the miners in creative ways, if they wish = (as does P2SH -- someone could write a script which donates funds to = miners, and then fund it... "paying" to that script). This is another = example of conflating [DC#1] and [DC#3].

Paul

= --Apple-Mail=_8CD43468-0A58-49E7-82A4-666B949AE531-- --Apple-Mail=_00D64527-0324-4692-826A-5D68957184F5 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----- iQIcBAEBCgAGBQJZZufZAAoJEOxnICvpCVJHMVsP/3zhz0TdnxnYj3m3xQkyZwyP 3eEikrTTlbdyrqf9Az6Lfyn1G6ubDR0+E/GhfSkL1ib7viBOywAglSLQhlGQ1dk3 AyPzET+EaAa9+LMb2i9QK8GGuR7HUgeyAjOAlLENRO6hbE01s+Fxv4O9+CIph1QY K4Sb2VcN+0A0t3mLdFEWbEFUx5EIHp+ORkIxVfD4XezjoDbYP15LW68KAscgH1bz yU7zcYcFo7jjEU/edWIEgSsPcuG+nuMRlDYR+5Fy84twm5T/K4wPdKb/2btz7wQt bUid5V7HRMn6QN2ydg4ypC6tybiqnsm1HToSo8XiU8YQqzBnXxLwslb8YNTCo8rc TqMA80kau1aClQpUROJ3g4CtgPsPGxYSWWREKcpHDE/J+y+EHGBF/jpaj6Ibaozc eJHapFBMeYdnWLItEVQRM33LcJbK0E/8r31wL28efLu2w9tubJm5rjkSnT3Q1mbx mK/BqVYPgpMn5IDvHOz1h90NbZ4LB8LEuNXbXYYsx7dNxlkBD7vzr6baf1bY0UUV LXn05w+LMDhzdnSTYpuyXBDCQbdksB02BTiBfEi3XjSyJT6vwHwR8xUsnUKYAj5d wXSsnb/xcKdkjiaW5kBWbFA9tMSiBRKRc2cLVb2uF59IGs1peVlwflD+lJch7L1C DIsbj00bi+ArthSGXwNe =ClwE -----END PGP SIGNATURE----- --Apple-Mail=_00D64527-0324-4692-826A-5D68957184F5--