path: root/1c/3e5fb0a527be214107529b20afc89356ff4b08

Return-Path: <truthcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CF2FAABC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 13 Jul 2017 15:38:59 +0000 (UTC)
Received: by mail-qt0-f196.google.com with SMTP id v31so6505408qtb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>
	(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 <bitcoin-dev@lists.linuxfoundation.org>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
	<83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
	<AAC86547-7904-4475-9966-138130019567@taoeffect.com>
	<6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com>
	<F2C3A9F4-07AB-41B9-B915-9E33EE313F9E@taoeffect.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 <truthcoin@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix"><span class="" style="background-color:
        rgb(255, 255, 255); float: none; display: inline !important;">Greg
        is still conflating two different usages of the word "theft":</span><br
        class="" style="background-color: rgb(255, 255, 255);">
      <span class="" style="background-color: rgb(255, 255, 255); float:
        none; display: inline !important;">1. Whether the soft fork
        rules have been followed, and</span><span class=""
        style="background-color: rgb(255, 255, 255); float: none;
        display: inline !important;"><br>
        2. Whether the WT^ submitted by a majority hashrate matches the
        one calculated by sidechain nodes.<br>
        <br>
        In his message he claims to uniquely adopt definition #2, saying
        (emphasis added):<br>
        <br>
      </span><span class="" style="background-color: rgb(255, 255, 255);
        float: none; display: inline !important;">
        <blockquote type="cite">
          <div class="">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.</div>
        </blockquote>
        <br>
        ...however, he revokes that commitment below when it suits his
        purposes.<br>
        <br>
        Since Greg's message is probably too confusing to be helpful, I
        will first clarify both cases:<br>
        <br>
        Case 1 -- soft fork rules -- all "invalid_1" txns are regarded
        as "theft_1" and are rejected.<br>
        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).<br>
        <br>
        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.<br>
      </span><br>
      <br>
      On 7/12/2017 11:24 PM, Tao Effect wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:3F1802B5-FDD5-4E4F-9A5D-238C5F83116F@taoeffect.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      Dear Paul,
      <div class=""><br class="">
      </div>
      <div class="">
        <blockquote type="cite" class=""><span class=""
            style="background-color: rgb(255, 255, 255); float: none;
            display: inline !important;">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.</span><br class=""
            style="background-color: rgb(255, 255, 255);">
        </blockquote>
        <div class=""><br class="">
        </div>
        I may very well have confused who counts what</div>
    </blockquote>
    <br>
    To be clear: yes, Greg did get it confused.<br>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote type="cite"
      cite="mid:3F1802B5-FDD5-4E4F-9A5D-238C5F83116F@taoeffect.com">
      <div class="">
        <div class="">
          <blockquote type="cite" class=""><span class=""
              style="background-color: rgb(255, 255, 255); display:
              inline !important;">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).</span></blockquote>
          <br class="">
        </div>
        <div class="">This is false.</div>
        <div class=""><br class="">
        </div>
        <div class="">For miners to steal P2SH funds, the P2SH script
          would have to be coded to explicitly allow them to do it.</div>
        <div class=""><br class="">
        </div>
        <div class="">How many P2SH scripts are you aware of that are
          used for the purpose of facilitating such theft?</div>
        <div class=""><br class="">
        </div>
        <div class="">I know of none, and I bet there are none.</div>
      </div>
    </blockquote>
    <br>
    <br>
    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".<br>
    <br>
    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".<br>
    <br>
    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<br>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote type="cite"
      cite="mid:3F1802B5-FDD5-4E4F-9A5D-238C5F83116F@taoeffect.com">
      <div class="">
        <div class="">
          <blockquote type="cite" class=""><span class=""
              style="background-color: rgb(255, 255, 255); display:
              inline !important;">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".</span></blockquote>
          <br class="">
        </div>
        <div class="">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.</div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote type="cite"
      cite="mid:3F1802B5-FDD5-4E4F-9A5D-238C5F83116F@taoeffect.com">
      <div class="">
        <div class="">
          <blockquote type="cite" class="">
            <blockquote type="cite"
              cite="mid:42C03DFC-C358-4F8C-A088-735910CCC60E@taoeffect.com"
              class="" style="background-color: rgb(255, 255, 255);">
              <div class="">Again, in P2SH miners cannot steal funds,
                because all full nodes have a fully automatic
                enforcement policy.</div>
            </blockquote>
            <br class="" style="background-color: rgb(255, 255, 255);">
            <span class="" style="background-color: rgb(255, 255, 255);
              float: none; display: inline !important;">In DC, miners
              cannot steal funds, because all full nodes have a fully
              automatic enforcement policy.</span><br class=""
              style="background-color: rgb(255, 255, 255);">
            <br class="" style="background-color: rgb(255, 255, 255);">
            <span class="" style="background-color: rgb(255, 255, 255);
              float: none; display: inline !important;">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].</span><br class="" style="background-color:
              rgb(255, 255, 255);">
          </blockquote>
          <br class="">
        </div>
        <div class="">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.</div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote type="cite"
      cite="mid:3F1802B5-FDD5-4E4F-9A5D-238C5F83116F@taoeffect.com">
      <div class="">
        <div class="">I've finally collected all my thoughts / concerns
          and have also summarized them in this document:</div>
        <div class=""><br class="">
        </div>
        <div class=""><a
href="https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9"
            class="" moz-do-not-send="true">https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9</a></div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    Paul<br>
  </body>
</html>

--------------7DF9E3F51FFFAC9B2E0B892B--