From: Peter Todd <pete@petertodd•org>
To: Paul Sztorc <truthcoin@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain -- Request for Discussion
Date: Sun, 28 May 2017 17:07:57 -0400 [thread overview]
Message-ID: <20170528210757.GA19450@fedora-23-dvm> (raw)
In-Reply-To: <CA+XQW1h22jmwq+qN69UgOhE0LZqmUDpnrmF0ZM-+2ZpoPsTrwQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3494 bytes --]
On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
> Surprisingly, this requirement (or, more precisely, this incentive) does
> not effect miners relative to each other. The incentive to upgrade is only
> for the purpose of preventing a "theft" -- defined as: an improper
> withdrawal from a sidechain. It is not about miner revenues or the ability
> to mine generally (or conduct BMM specifically). The costs of such a theft
> (decrease in market price, decrease in future transaction fee levels) would
> be shared collectively by all future miners. Therefore, it would have no
> effect on miners relative to each other.
That's not at all true. If I'm a miner with a better capability than another
miner to prevent that theft, I have reasons to induce it to happen to give me
political cover to pushing that other miner off the network.
This is a very similar problem to what we had with zeroconf double-spending,
where entities such as Coinbase tried to pay off miners to guarantee something
that wasn't possible in a geninely decrentralized system: safe zeroconf
transactions.
> Moreover, miners have other recourse if they are unable to run the node.
> They can adopt a policy of simply rejecting ("downvoting") any withdrawals
> that they don't understand. This would pause the withdraw process until
> enough miners understand enough of what is going on to proceed with it.
Why are you forcing miners to run this code at all?
Equally, you're opening up miners to huge political risks, as rejecting all
withdrawals is preventing users' from getting their money, which gives other
miners a rational for kicking those miners off of Bitcoin entirely.
> Finally, the point in dispute is a single, infrequent, true/false question.
> So miners may resort to semi-trusted methods to supplement their decision.
> In other words, they can just ask people they trust, if the withdrawal is
> correct or not. It is up to users to decide if they are comfortable with
> these risks, if/when they decide to deposit to a sidechain.
Why do you think this will be infrequent? Miners with a better ability to
validate the drivechain have every reason to make these events more frequent.
> It is a matter of comparing the costs and benefits. Ignoring theft, the
> costs are near-zero, and the benefits are >0. Specifically, they are: a
> higher BTC price and greater transaction fees. Theft is discouraged by
> attempting to tie a theft to a loss of confidence in the miners, as
> described in the spec/website.
> In general the incentives are very similar to those of Bitcoin itself.
This is also a very dubious security model - I would argue that Bitcoin is much
*more* valuable if miners do everything they can to ensure that drivechains
fail, given the huge risks involved. I would also argue that users should do
user-activated-soft-forks to ensure they fail.
By comparison, note Adam Back and my own efforts to ensure miners have a
smaller part in the ecosystem, with things like committed (encrypted)
transactions and my closed-seal-set/truth-list approach(1). We want to involve
miners as little as possible in the consensus, not more.
I have to ask: What use-cases do you actually see for drivechains? Why can't
those use-cases be done in the much safer client-side validation fashion?
1) https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2017-05-28 21:22 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-22 6:17 Paul Sztorc
2017-05-22 13:33 ` Peter Todd
2017-05-22 15:30 ` Paul Sztorc
2017-05-28 21:07 ` Peter Todd [this message]
[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
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=20170528210757.GA19450@fedora-23-dvm \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=truthcoin@gmail$(echo .)com \
/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