Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CF2FAABC for ; Thu, 13 Jul 2017 15:39:00 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f196.google.com (mail-qt0-f196.google.com [209.85.216.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9106A175 for ; Thu, 13 Jul 2017 15:38:59 +0000 (UTC) Received: by mail-qt0-f196.google.com with SMTP id v31so6505408qtb.3 for ; Thu, 13 Jul 2017 08:38:59 -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=bdCvzET0jrvIfD+N5rMV0re4wdZU0xtUlpR0HUhWFtY=; b=I1G31OJtWNatv6MNCrK2rP6a6hSpPnkNCRlxbdg59sjwFGsdQ1gsfkcCgAvwjPRPqt IWYHSqhZ7IULvTcl+u5iOyh81FzSR4GYyYNSrbwWToJ8TI9S3t2QvNvOMgspGCM8wJ6T AVAu1kG8/LHRU+WoyoCb71BlDuPMp+gXyONiXrAM+C7mK3dNyWD91/zTmrgzsfhFEWIG 6hZGuYYztbX5T/DjioKgch9JIj5115eRSWhgWgqegQaDBhQ8vQtVRwxEvQYYv/9X4ap/ K8n5jvOmBy17uRIpJPrWYAwG2TYuoa+pJyi8x5mNMLkT37wJB/60tp5vyy4G4DPZAISU IQ7g== 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=bdCvzET0jrvIfD+N5rMV0re4wdZU0xtUlpR0HUhWFtY=; b=nCZtcAN8idgX0ya+9vWqTw1IdPiHbLYT0UeqsBvQrop4g5P1+zIjYXDsnN5xwjAy7v +njDH44QOulOF/S0BCaPJzi4f577sc5enU2VeUqtMOBs12D0NAy3RiurZEPUDfhjgX0M Fc7yiWnqauX0FU5/PpphWw3B0YvT2jd/gtfc9RciZhMZG4hoin1WbE5WoFmVugoGvTyy H4dc0Gn1VCtdepra+irS7C71lsFfQu49d76S7TLywBKObsiZykP179m3LIkniq/UVsFl IaTVDcNHJ3THdJ7tN22hHMrpMjUuSdxLMT222m4y5lP9AnIqv/b/dcQljTiFYLpp7rb+ FklQ== X-Gm-Message-State: AIVw112gNiWhvBqEf6MJod+LoHy9HvheVJaink0IVX8491A4Jb5OE9pU 84/c/B9pjsoxYs/z X-Received: by 10.200.52.242 with SMTP id x47mr5889099qtb.70.1499960338208; Thu, 13 Jul 2017 08:38:58 -0700 (PDT) Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net. [69.114.110.251]) by smtp.googlemail.com with ESMTPSA id z5sm4203981qkz.53.2017.07.13.08.38.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jul 2017 08:38:56 -0700 (PDT) To: Bitcoin Protocol Discussion 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> <3F1802B5-FDD5-4E4F-9A5D-238C5F83116F@taoeffect.com> From: Paul Sztorc Message-ID: <02d9700e-e597-9c70-a007-e9c9e7504227@gmail.com> Date: Thu, 13 Jul 2017 11:39:00 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <3F1802B5-FDD5-4E4F-9A5D-238C5F83116F@taoeffect.com> Content-Type: multipart/alternative; boundary="------------7DF9E3F51FFFAC9B2E0B892B" Content-Language: en-US X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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: Thu, 13 Jul 2017 15:51:47 +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 15:39:00 -0000 This is a multi-part message in MIME format. --------------7DF9E3F51FFFAC9B2E0B892B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greg is still conflating two different usages of the word "theft": 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. In his message he claims to uniquely adopt definition #2, saying (emphasis added): > 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. =2E..however, he revokes that commitment below when it suits his purposes= =2E Since Greg's message is probably too confusing to be helpful, I will first clarify both cases: Case 1 -- soft fork rules -- all "invalid_1" txns are regarded as "theft_1" and are rejected. Case 2 -- sidechain's unique consensus rules -- all WT^ are accepted (if these WT^ are valid_1 under the Case 1 rules), whether they match the sidechain's reported WT^ or not (in other words, whether they are valid_2 or not). In Case 2, the mainchain accepts all WT^ transactions as "valid", in that they can be included in a block, whether or not they are "valid_2". By design, sidechains make no effort to validate the rules specific to each sidechain, just as they make no effort to validate the rules of Altcoins. In this way, a WT^ transaction is comparable to someone who is selling an Altcoin to purchase some Bitcoin -- Bitcoin doesn't care how they got the Altcoin. On 7/12/2017 11:24 PM, Tao Effect wrote: > 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 To be clear: yes, Greg did get it confused. And it is very important, because a neglect of the node-enforced rules is a neglect of **both** theft_1 and theft_2 simultaneously, making it easier to conflate the both of them as Greg is still doing. >> 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. This is the instance I mentioned above -- despite committing to only discussing theft_2, Greg has secretly switched back to theft_1, when he talks about a "P2SH script...used for the purpose of facilitating theft".= Under theft_2, there is no way to infer the theft-ness of the transaction from the script itself. For example, if someone made a 2-of-3 multisig with a third party escrow , and these funds were "stolen", this would be an example of funds "stolen" from a P2SH under "theft_2". At which point Greg would angrily say that whoever wrote P2SH was reckless and...allowed Bitcoins to be "stolen". Or perhaps he would switch definitions yet again, and say that "that doesn't count as theft". blah blah blah yada yada yada It is true that moving from pre-P2SH to post-P2SH has not --yet-- enabled any theft_2 as a result. But P2SH has also failed to enable sidechains. Sidechains logically must open the door to theft_2, else they will regress to the undesirable cases of hard/evil fork (as I explain in the spec). Empirically, we do not know how much theft_2 will be enabled by drivechain. Theoretically, it is possible that there will never be a theft_2 on drivechain. >> 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. I do not affirm the latter. The SPV proofs in DC are very important, as they are what allow nodes to enforce the delayed withdrawal upon miners. In fact, this is exactly what Greg admits to being confused about above. He is correct that he is confused. Experts including Adam Back (co-author of original sidechains paper, CEO of Blockstream which started the sidechains conversation) have publicly stated that they share my belief that this delayed withdrawal technique is likely to mitigate the threat of theft_2. Greg S is free to hold a different opinion. >>> 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. Greg did not specify which theft so I had to guess in the above case.=20 Above, I refer to "theft_1", the [DC#0] style theft. As always, no one can "steal_1" funds in that case. The reason I assumed Greg was talking about theft_1 and not theft_2, is because he mentioned P2SH and the fact that full nodes automatically enforce the network's rules. Drivechain's rules impose a new format, like P2SH, and have new rules which are automatically enforced by nodes. Greg's style is basically to confuse two things, ask unclear questions about them, and then try to discover "contradictions" in the mess that follows. But it is all a function of his conflation of terminology and nothing else. > I've finally collected all my thoughts / concerns and have also > summarized them in this document: > > https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9 Given how little Greg understands, even after being hand-fed by me for days and weeks, I admit a totally nonexistent interest in reading it. Paul --------------7DF9E3F51FFFAC9B2E0B892B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Greg is still conflating two different usages of the word "theft":
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.

In his message he claims to uniquely adopt definition #2, saying (emphasis added):
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.

...however, he revokes that commitment below when it suits his purposes.

Since Greg's message is probably too confusing to be helpful, I will first clarify both cases:

Case 1 -- soft fork rules -- all "invalid_1" txns are regarded as "theft_1" and are rejected.
Case 2 -- sidechain's unique consensus rules -- all WT^ are accepted (if these WT^ are valid_1 under the Case 1 rules), whether they match the sidechain's reported WT^ or not (in other words, whether they are valid_2 or not).

In Case 2, the mainchain accepts all WT^ transactions as "valid", in that they can be included in a block, whether or not they are "valid_2".  By design, sidechains make no effort to validate the rules specific to each sidechain, just as they make no effort to validate the rules of Altcoins. In this way, a WT^ transaction is comparable to someone who is selling an Altcoin to purchase some Bitcoin -- Bitcoin doesn't care how they got the Altcoin.


On 7/12/2017 11:24 PM, Tao Effect wrote:
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

To be clear: yes, Greg did get it confused.

And it is very important, because a neglect of the node-enforced rules is a neglect of **both** theft_1 and theft_2 simultaneously, making it easier to conflate the both of them as Greg is still doing.


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.


This is the instance I mentioned above -- despite committing to only discussing theft_2, Greg has secretly switched back to theft_1, when he talks about a "P2SH script...used for the purpose of facilitating theft".

Under theft_2, there is no way to infer the theft-ness of the transaction from the script itself. For example, if someone made a 2-of-3 multisig with a third party escrow , and these funds were "stolen", this would be an example of funds "stolen" from a P2SH under "theft_2".

At which point Greg would angrily say that whoever wrote P2SH was reckless and...allowed Bitcoins to be "stolen". Or perhaps he would switch definitions yet again, and say that "that doesn't count as theft". blah blah blah yada yada yada

It is true that moving from pre-P2SH to post-P2SH has not --yet-- enabled any theft_2 as a result. But P2SH has also failed to enable sidechains. Sidechains logically must open the door to theft_2, else they will regress to the undesirable cases of hard/evil fork (as I explain in the spec). Empirically, we do not know how much theft_2 will be enabled by drivechain. Theoretically, it is possible that there will never be a theft_2 on drivechain.


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.

I do not affirm the latter. The SPV proofs in DC are very important, as they are what allow nodes to enforce the delayed withdrawal upon miners. In fact, this is exactly what Greg admits to being confused about above. He is correct that he is confused.

Experts including Adam Back (co-author of original sidechains paper, CEO of Blockstream which started the sidechains conversation) have publicly stated that they share my belief that this delayed withdrawal technique is likely to mitigate the threat of theft_2. Greg S is free to hold a different opinion.


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.

Greg did not specify which theft so I had to guess in the above case.  Above, I refer to "theft_1", the [DC#0] style theft. As always, no one can "steal_1" funds in that case.

The reason I assumed Greg was talking about theft_1 and not theft_2, is because he mentioned P2SH and the fact that full nodes automatically enforce the network's rules. Drivechain's rules impose a new format, like P2SH, and have new rules which are automatically enforced by nodes.

Greg's style is basically to confuse two things, ask unclear questions about them, and then try to discover "contradictions" in the mess that follows. But it is all a function of his conflation of terminology and nothing else.


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


Given how little Greg understands, even after being hand-fed by me for days and weeks, I admit a totally nonexistent interest in reading it.

Paul
--------------7DF9E3F51FFFAC9B2E0B892B--