From: Paul Sztorc <truthcoin@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain RfD -- Follow Up
Date: Thu, 13 Jul 2017 11:39:00 -0400 [thread overview]
Message-ID: <02d9700e-e597-9c70-a007-e9c9e7504227@gmail.com> (raw)
In-Reply-To: <3F1802B5-FDD5-4E4F-9A5D-238C5F83116F@taoeffect.com>
[-- Attachment #1: Type: text/plain, Size: 6908 bytes --]
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:
>
> 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
[-- Attachment #2: Type: text/html, Size: 11922 bytes --]
next prev parent reply other threads:[~2017-07-13 15:39 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-22 6:17 [bitcoin-dev] Drivechain -- Request for Discussion Paul Sztorc
2017-05-22 13:33 ` Peter Todd
2017-05-22 15:30 ` Paul Sztorc
2017-05-28 21:07 ` Peter Todd
[not found] ` <CAJowKgJjNaoWVc=QXfOqH3OdBPoKm3qkfUNpKV6oKLSRx_fD0g@mail.gmail.com>
[not found] ` <CAJowKgKFMXDE-yzEqYkY7c+80Mgn+iL9ZRNJbv9WhUBR32EvRg@mail.gmail.com>
2017-05-29 5:54 ` Erik Aronesty
2017-05-30 5:11 ` Paul Sztorc
2017-06-09 21:54 ` Sergio Demian Lerner
2017-06-10 16:28 ` Paul Sztorc
2017-05-22 14:39 ` ZmnSCPxj
2017-05-22 16:19 ` Paul Sztorc
2017-05-22 19:12 ` Tier Nolan
2017-05-22 20:00 ` Paul Sztorc
2017-05-23 9:51 ` Tier Nolan
2017-05-23 14:22 ` Paul Sztorc
2017-05-24 8:50 ` Tier Nolan
2017-05-24 10:05 ` Tier Nolan
2017-05-24 17:32 ` CryptAxe
2017-05-25 22:08 ` Tier Nolan
2017-06-18 14:36 ` Chris Stewart
2017-06-18 21:27 ` CryptAxe
[not found] ` <CAGL6+mGZZ=wG8P_DNj3PXVf==mLjJwA_bESh0_UdH2iVBY7GQA@mail.gmail.com>
2017-06-19 15:41 ` Chris Stewart
2017-05-23 0:13 ` ZmnSCPxj
2017-05-23 14:12 ` Paul Sztorc
2017-05-23 23:26 ` ZmnSCPxj
2017-06-10 17:04 ` [bitcoin-dev] Drivechain RfD -- Follow Up Paul Sztorc
2017-06-18 21:30 ` Tao Effect
2017-06-19 16:04 ` Paul Sztorc
[not found] ` <CAJowKgLJW=kJhcN4B7TbWXLb7U51tzYU3PFOy1m8JqKXqFsU4A@mail.gmail.com>
2017-06-20 11:54 ` Paul Sztorc
2017-06-20 13:38 ` Erik Aronesty
2017-06-22 13:27 ` Paul Sztorc
2017-06-22 13:45 ` Erik Aronesty
2017-06-22 20:30 ` Paul Sztorc
2017-06-23 14:19 ` Erik Aronesty
2017-06-23 14:51 ` Moral Agent
2017-06-23 18:11 ` Paul Sztorc
2017-07-12 22:43 ` Tao Effect
2017-07-13 0:26 ` Paul Sztorc
2017-07-13 1:15 ` Tao Effect
2017-07-13 2:58 ` Paul Sztorc
2017-07-13 3:24 ` Tao Effect
2017-07-13 15:39 ` Paul Sztorc [this message]
2017-07-13 13:17 ` Hampus Sjöberg
2017-07-13 17:04 ` Paul Sztorc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=02d9700e-e597-9c70-a007-e9c9e7504227@gmail.com \
--to=truthcoin@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox