path: root/ee/424c49a665a7261caf6df34958c0754146c862

Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2C420258
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  9 Jun 2017 21:54:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f172.google.com (mail-qt0-f172.google.com
	[209.85.216.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A98E3240
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  9 Jun 2017 21:54:41 +0000 (UTC)
Received: by mail-qt0-f172.google.com with SMTP id u19so90677332qta.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 09 Jun 2017 14:54:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=ht6N0aAH/wt4JCEhnLE7RySCpUM+nR+fBeabUKmmizA=;
	b=E8NtMVd5feOXV/E89PulGvcCk+xcHLJP019T45vmZVJYQYDVFcKnGwatkNRMkhIQgc
	I9WvKt67nawx+w7Ibe2MDWMwHo2FWIF+cw26juqTgtSy68nESWAHkca4Q8nGgNm8tPc9
	lmIY6CMZQDnM2o85KrSOrs7P9QmtsGvEdGZnqu0vmY3wb0WrTlPXWcdiKhdiz3FU71lK
	2rQAnP/WszHqJhr8IhZI/OB6QtZzFzmMla3/gqcUfne+3FwoNd5jcsY9au1mR21/cLdS
	3yylldYs0gf5Nv3f+AaLbxcxMuQ5nBN/8/JXxV87594MAU7V8W9hQ5k+rYqt8fDZZ1jV
	uYkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=ht6N0aAH/wt4JCEhnLE7RySCpUM+nR+fBeabUKmmizA=;
	b=f5GMyJ5Xw3Fw07curauH1eynJGPoVeA6oMdmhC6BNI4js3wxWHcps3Ed9RaeDkfB2S
	4wyhh839mNJb/qi6BEilCW7cABMXG9ENASslpJjjxHZJoUuFGep19mP5kbTGQo5KDIuR
	vXmlngzre0clYFol9qgwRRY7kkC8MxO4w1zixVwCPSnzUKI24vVoFRR6McM/AoMoQlbD
	fJDMS3OPQ9XNzE9i7nuSQRDqz2sUHby76wJxc4gXiOEFGhhCI753WTEzK5F5uNwGYffa
	JSMUYEeVXj5hatpGSpzAfyV19sXRrXdirAO99kQe9VfMKa5Vr9TlDNJab4OcZ7PcCdb3
	BYaw==
X-Gm-Message-State: AKS2vOz1Q9i3OxZXlRaLU5lh+ZZVf1zwkW6J3X9oe/5326UWuub6+TdE
	CRo6Z2A2Ho4cAMV7hyQi3vXiEz2PXQ==
X-Received: by 10.55.140.193 with SMTP id o184mr36747487qkd.127.1497045280753; 
	Fri, 09 Jun 2017 14:54:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.175.58 with HTTP; Fri, 9 Jun 2017 14:54:00 -0700 (PDT)
In-Reply-To: <b04f8c13-9358-303d-2335-f509cafb90a5@gmail.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
	<20170522133335.GA17194@fedora-23-dvm>
	<CA+XQW1h22jmwq+qN69UgOhE0LZqmUDpnrmF0ZM-+2ZpoPsTrwQ@mail.gmail.com>
	<20170528210757.GA19450@fedora-23-dvm>
	<b04f8c13-9358-303d-2335-f509cafb90a5@gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Fri, 9 Jun 2017 18:54:00 -0300
Message-ID: <CAKzdR-qdk-qw+dy1D0d7rK+4zKDCVf4LA1eQUqgwcTXqL8fp0g@mail.gmail.com>
To: Paul Sztorc <truthcoin@gmail.com>
Content-Type: multipart/alternative; boundary="001a114f0ce82c10eb05518e041d"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain -- Request for Discussion
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: Fri, 09 Jun 2017 21:54:46 -0000

--001a114f0ce82c10eb05518e041d
Content-Type: text/plain; charset="UTF-8"

I'm a bit late to this party. I just want to add that there exists an
hybrid model where both a federation and the miners provide acknowledges
(sometimes known as "votes" in drivechain terms and "multi-signatures" in a
federation) of the sidechain state.

My Drivechain proposal (Feb 2016) was tailored to enable this particular
use-case, which I'm not sure Paul's proposal enable.


The proposal is on this list under the following subject: Drivechain
proposal using OP_COUNT_ACKS

BIP (draft):
https://github.com/rootstock/bips/blob/master/BIP-R10.md

Code & Test cases:
https://github.com/rootstock/bitcoin/tree/op-count-acks_devel

In this proposal, the "poll" time is sidechain-configurable, and I proposed
a few days delay was enough.
Some have said that a longer times are needed, such as 2 months.
So if you want to have a 2 month dalay for sidechain->mainchain transfers
in this code, you still can. However a better dynamic cache of acks/nacks
would be needed. However, for the hybrid use-case, one day is more than
enough.

Regards




On Tue, May 30, 2017 at 2:11 AM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Peter,
>
> Responses below.
>
> On 5/28/2017 5:07 PM, Peter Todd wrote:
> > 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.
>
> Miners can abstain from 'voting', which is politically neutral. Or, if
> they wish, smaller miners could acquiesce to the coercion and just copy
> the votes of the attacking 51% group. For users who are only running
> Bitcoin Core, there is nothing bad about that.
>
> As you say, a 51% group can arbitrarily start orphaning the blocks that
> are mined by non-member rivals. This _may_ be a problem, or it may not,
> but it is not exacerbated by drivechain.
>
> So, what exactly is "not at all true"?
>
>
> >
> > 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.
>
> I don't see what you mean here. You can't stop Coinbase from donating
> BTC to a subset of miners. That will always be possible, and it has
> nothing to do with drivechain (as I see it).
>
>
> >
> >> 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?
>
> Could we not say the same thing about the code behind CLTV?
>
> The nature of a contract, is that people are happier to be bound by some
> rules that they themselves construct (for example, a nuclear
> non-proliferation treaty).
>
> In this case, miners prefer sidechains to exist (as existence makes the
> BTC they mine more valuable, and provides additional tx fee revenues),
> and so they would like to run code which makes them possible.
>
>
> >
> > 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.
>
> As I explained above, miners can abstain from voting, which is
> politically neutral, or else they can delegate their vote to an
> aggressive miner. The "51% can orphan" concern could be raised, even in
> a world without drivechain. All that is required, is for the miners to
> be anonymous, or in private 'dark' pools (and to thereby escape censure).
>
> But there is a much bigger issue here, which is that our threat models
> are different.
>
> As you may know, my threat model [1] does not include miners "pushing
> each other off". It only cares about the miner-experience, to the extent
> that it impacts the user-experience.
>
> Moreover, I reject [2] the premise that we can even measure "miner
> centralization", or even that such a concept exists. If someone has a
> definition of this concept, which is both measurable and useful, I would
> be interested to read it.
>
> ( For what it's worth, Satoshi did not care about this, either. For
> example: "If a greedy attacker is able to assemble more CPU power than
> all the honest nodes, he...ought to find it more profitable to play by
> the rules." which implies robustness to 51% owned by one entity. )
>
> [1] http://www.truthcoin.info/blog/mining-threat-equilibrium/
> [2] http://www.truthcoin.info/blog/mirage-miner-centralization/
>
>
> >
> >> 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 part of the spec. These timing parameters must be agreed upon when
> the sidechain is added, ie _before_ users deposit to the sidechain. Once
> the sidechain is created, the timing is enforced by nodes, the same as
> with any other protocol rules. Miner-validation-ability has no effect on
> the frequency.
>
>
> >
> >> 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 don't see how. Users are free to ignore the sidechain, so it can only
> benefit them.
>
> Fortunately for you, if that is actually what miners believe, then there
> will be no problem, as miners will just filter out drivechains (so that
> Bitcoin will be "much *more* valuable"), which they can easily do.
>
>
> >                                      I would also argue that users
> should do
> > user-activated-soft-forks to ensure they fail.
>
> Again, I don't think that kind of UASF can succeed, because one option
> strictly dominates the other. But the users get the final say, of course.
>
> Empirically, I have observed overwhelming support for sidechains among
> users, business, and other developers. The btc-investors I spoke to were
> all very excited about the prospect of sidechains, even more so than
> they were excited about SegWit.
>
>
> >
> > 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 agree that miners should have as little influence as possible (and
> they probably agree, as well). But a 51% group can filter any message
> they like from the blockchain. For sidechains, there will need to be two
> public networks, so concealment is not an option.
>
> And, I repeat, for regular users of Bitcoin Core, drivechain does not
> make a 51% group more dangerous than they already are.
>
> Moreover, there are cases [1] where miner-involvement can make a big
> _positive_ impact. Just as it can be beneficial (essential, in fact) for
> Bitcoin to filter out harmful interactions among txns (in other words,
> good for miners to filter out double spends), I have discovered
> situations where it is beneficial and essential for miners to filter out
> harmful interactions among multiple chains.
>
> So I think I am actually hitting the "as little as possible" target.
>
> [1] http://www.truthcoin.info/blog/wise-contracts/#wise-contracts
>
>
> >
> > I have to ask: What use-cases do you actually see for drivechains? Why
> can't
>
> Here is a tentative project list:
> http://www.drivechain.info/projects/index.html
>
> And, as I say on the FAQ, "If each individual user is free to sell
> his/her BTC in exchange for an Altcoin (or for fiat), we can hardly deny
> users the opportunity to move their money between two sidechains."
>
> So, in a strong way, the entire altcoin market makes the case for a
> usefulness of sidechains. Bitcoin is a form of money, and only one form
> of money can exist per currency area. So, if Bitcoin is not the winner,
> it will eventually cease to exist altogether. Altcoin-competition is an
> existential threat to Bitcoin, one which is far more relevant than
> anything you've presented so far.
>
> Secondly, one important value of permissionless innovation is that one
> doesn't really know, today, what cool ideas other people are going to
> come up with tomorrow. If you did, they'd be today's ideas.
>
> Third, Core's review process has two opposite problems: on one hand it
> is slow and grueling, and on the other it is fraught with the
> possibility of catastrophic error. It would be better, for everyone, to
> allow people to try their own (non-aggressive) experiments, and to make
> their own mistakes. Already, I have seen the review process abused to
> create/maintain fiefdoms of expertise, so that the abusers can extract
> money from clients/employers/VCs.
>
> Just think of all of the free time you would have, Peter, if you didn't
> have to spend it all reviewing these projects!
>
>
> > those use-cases be done in the much safer client-side validation fashion?
>
> ? How is drivechain _not_ within the category of client-side validation?
> With BMM, validation is only performed by those users ("clients") who
> opt-in to the new features. The economic model of BMM is directly
> comparable to that of Bitcoin's PoW -- the highest-bid chain should be
> the healthiest one.
>
> Can you post the Github link for your most up-to-date client-side
> validation work so that we can compare the safety and other features?
>
> Thanks,
> Paul
>
> >
> > 1) https://petertodd.org/2016/closed-seal-sets-and-truth-
> lists-for-privacy
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a114f0ce82c10eb05518e041d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I&#39;m a bit late to this party. I just want to add =
that there exists an hybrid model where both a federation and the miners pr=
ovide acknowledges (sometimes known as &quot;votes&quot; in drivechain term=
s and &quot;multi-signatures&quot; in a federation) of the sidechain state.=
<br></div><div><br></div><div>My Drivechain proposal (Feb 2016)=C2=A0was ta=
ilored to enable this particular use-case, which I&#39;m not sure Paul&#39;=
s proposal enable.</div><div><br></div><div><br></div><div><div>The proposa=
l is on this list under the following subject: Drivechain proposal using OP=
_COUNT_ACKS</div><div><br></div><div>BIP (draft):<br></div><div><a href=3D"=
https://github.com/rootstock/bips/blob/master/BIP-R10.md" target=3D"_blank"=
>https://github.com/rootstock/<wbr>bips/blob/master/BIP-R10.md</a></div><di=
v><br></div><div>Code &amp; Test cases:</div><div><a href=3D"https://github=
.com/rootstock/bitcoin/tree/op-count-acks_devel" target=3D"_blank">https://=
github.com/rootstock/<wbr>bitcoin/tree/op-count-acks_<wbr>devel</a></div></=
div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">In this=
 proposal, the &quot;poll&quot; time is sidechain-configurable, and I propo=
sed a few days delay was enough.=C2=A0</div><div class=3D"gmail_extra">Some=
 have said that a longer times are needed, such as 2 months. =C2=A0</div><d=
iv class=3D"gmail_extra">So if you want to have a 2 month dalay for sidecha=
in-&gt;mainchain transfers in this code, you still can. However a better dy=
namic cache of acks/nacks would be needed. However, for the hybrid use-case=
, one day is more than enough.</div><div class=3D"gmail_extra"><br></div><d=
iv class=3D"gmail_extra">Regards</div><div class=3D"gmail_extra"><br></div>=
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, May 30, 20=
17 at 2:11 AM, Paul Sztorc via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">Hi Peter,<br>
<br>
Responses below.<br>
<span class=3D"gmail-"><br>
On 5/28/2017 5:07 PM, Peter Todd wrote:<br>
&gt; On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:<br>
&gt;&gt; Surprisingly, this requirement (or, more precisely, this incentive=
) does<br>
&gt;&gt; not effect miners relative to each other. The incentive to upgrade=
 is only<br>
&gt;&gt; for the purpose of preventing a &quot;theft&quot; -- defined as: a=
n improper<br>
&gt;&gt; withdrawal from a sidechain. It is not about miner revenues or the=
 ability<br>
&gt;&gt; to mine generally (or conduct BMM specifically). The costs of such=
 a theft<br>
&gt;&gt; (decrease in market price, decrease in future transaction fee leve=
ls) would<br>
&gt;&gt; be shared collectively by all future miners. Therefore, it would h=
ave no<br>
&gt;&gt; effect on miners relative to each other.<br>
&gt;<br>
&gt; That&#39;s not at all true. If I&#39;m a miner with a better capabilit=
y than another<br>
&gt; miner to prevent that theft, I have reasons to induce it to happen to =
give me<br>
&gt; political cover to pushing that other miner off the network.<br>
<br>
</span>Miners can abstain from &#39;voting&#39;, which is politically neutr=
al. Or, if<br>
they wish, smaller miners could acquiesce to the coercion and just copy<br>
the votes of the attacking 51% group. For users who are only running<br>
Bitcoin Core, there is nothing bad about that.<br>
<br>
As you say, a 51% group can arbitrarily start orphaning the blocks that<br>
are mined by non-member rivals. This _may_ be a problem, or it may not,<br>
but it is not exacerbated by drivechain.<br>
<br>
So, what exactly is &quot;not at all true&quot;?<br>
<span class=3D"gmail-"><br>
<br>
&gt;<br>
&gt; This is a very similar problem to what we had with zeroconf double-spe=
nding,<br>
&gt; where entities such as Coinbase tried to pay off miners to guarantee s=
omething<br>
&gt; that wasn&#39;t possible in a geninely decrentralized system: safe zer=
oconf<br>
&gt; transactions.<br>
<br>
</span>I don&#39;t see what you mean here. You can&#39;t stop Coinbase from=
 donating<br>
BTC to a subset of miners. That will always be possible, and it has<br>
nothing to do with drivechain (as I see it).<br>
<span class=3D"gmail-"><br>
<br>
&gt;<br>
&gt;&gt; Moreover, miners have other recourse if they are unable to run the=
 node.<br>
&gt;&gt; They can adopt a policy of simply rejecting (&quot;downvoting&quot=
;) any withdrawals<br>
&gt;&gt; that they don&#39;t understand. This would pause the withdraw proc=
ess until<br>
&gt;&gt; enough miners understand enough of what is going on to proceed wit=
h it.<br>
&gt;<br>
&gt; Why are you forcing miners to run this code at all?<br>
<br>
</span>Could we not say the same thing about the code behind CLTV?<br>
<br>
The nature of a contract, is that people are happier to be bound by some<br=
>
rules that they themselves construct (for example, a nuclear<br>
non-proliferation treaty).<br>
<br>
In this case, miners prefer sidechains to exist (as existence makes the<br>
BTC they mine more valuable, and provides additional tx fee revenues),<br>
and so they would like to run code which makes them possible.<br>
<span class=3D"gmail-"><br>
<br>
&gt;<br>
&gt; Equally, you&#39;re opening up miners to huge political risks, as reje=
cting all<br>
&gt; withdrawals is preventing users&#39; from getting their money, which g=
ives other<br>
&gt; miners a rational for kicking those miners off of Bitcoin entirely.<br=
>
<br>
</span>As I explained above, miners can abstain from voting, which is<br>
politically neutral, or else they can delegate their vote to an<br>
aggressive miner. The &quot;51% can orphan&quot; concern could be raised, e=
ven in<br>
a world without drivechain. All that is required, is for the miners to<br>
be anonymous, or in private &#39;dark&#39; pools (and to thereby escape cen=
sure).<br>
<br>
But there is a much bigger issue here, which is that our threat models<br>
are different.<br>
<br>
As you may know, my threat model [1] does not include miners &quot;pushing<=
br>
each other off&quot;. It only cares about the miner-experience, to the exte=
nt<br>
that it impacts the user-experience.<br>
<br>
Moreover, I reject [2] the premise that we can even measure &quot;miner<br>
centralization&quot;, or even that such a concept exists. If someone has a<=
br>
definition of this concept, which is both measurable and useful, I would<br=
>
be interested to read it.<br>
<br>
( For what it&#39;s worth, Satoshi did not care about this, either. For<br>
example: &quot;If a greedy attacker is able to assemble more CPU power than=
<br>
all the honest nodes, he...ought to find it more profitable to play by<br>
the rules.&quot; which implies robustness to 51% owned by one entity. )<br>
<br>
[1] <a href=3D"http://www.truthcoin.info/blog/mining-threat-equilibrium/" r=
el=3D"noreferrer" target=3D"_blank">http://www.truthcoin.info/<wbr>blog/min=
ing-threat-<wbr>equilibrium/</a><br>
[2] <a href=3D"http://www.truthcoin.info/blog/mirage-miner-centralization/"=
 rel=3D"noreferrer" target=3D"_blank">http://www.truthcoin.info/<wbr>blog/m=
irage-miner-<wbr>centralization/</a><br>
<span class=3D"gmail-"><br>
<br>
&gt;<br>
&gt;&gt; Finally, the point in dispute is a single, infrequent, true/false =
question.<br>
&gt;&gt; So miners may resort to semi-trusted methods to supplement their d=
ecision.<br>
&gt;&gt; In other words, they can just ask people they trust, if the withdr=
awal is<br>
&gt;&gt; correct or not. It is up to users to decide if they are comfortabl=
e with<br>
&gt;&gt; these risks, if/when they decide to deposit to a sidechain.<br>
&gt;<br>
&gt; Why do you think this will be infrequent? Miners with a better ability=
 to<br>
&gt; validate the drivechain have every reason to make these events more fr=
equent.<br>
<br>
</span>It is part of the spec. These timing parameters must be agreed upon =
when<br>
the sidechain is added, ie _before_ users deposit to the sidechain. Once<br=
>
the sidechain is created, the timing is enforced by nodes, the same as<br>
with any other protocol rules. Miner-validation-ability has no effect on<br=
>
the frequency.<br>
<span class=3D"gmail-"><br>
<br>
&gt;<br>
&gt;&gt; It is a matter of comparing the costs and benefits. Ignoring theft=
, the<br>
&gt;&gt; costs are near-zero, and the benefits are &gt;0. Specifically, the=
y are: a<br>
&gt;&gt; higher BTC price and greater transaction fees. Theft is discourage=
d by<br>
&gt;&gt; attempting to tie a theft to a loss of confidence in the miners, a=
s<br>
&gt;&gt; described in the spec/website.<br>
&gt;&gt; In general the incentives are very similar to those of Bitcoin its=
elf.<br>
&gt;<br>
&gt; This is also a very dubious security model - I would argue that Bitcoi=
n is much<br>
&gt; *more* valuable if miners do everything they can to ensure that drivec=
hains<br>
&gt; fail, given the huge risks involved.<br>
<br>
</span>I don&#39;t see how. Users are free to ignore the sidechain, so it c=
an only<br>
benefit them.<br>
<br>
Fortunately for you, if that is actually what miners believe, then there<br=
>
will be no problem, as miners will just filter out drivechains (so that<br>
Bitcoin will be &quot;much *more* valuable&quot;), which they can easily do=
.<br>
<span class=3D"gmail-"><br>
<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I would also=
 argue that users should do<br>
&gt; user-activated-soft-forks to ensure they fail.<br>
<br>
</span>Again, I don&#39;t think that kind of UASF can succeed, because one =
option<br>
strictly dominates the other. But the users get the final say, of course.<b=
r>
<br>
Empirically, I have observed overwhelming support for sidechains among<br>
users, business, and other developers. The btc-investors I spoke to were<br=
>
all very excited about the prospect of sidechains, even more so than<br>
they were excited about SegWit.<br>
<span class=3D"gmail-"><br>
<br>
&gt;<br>
&gt; By comparison, note Adam Back and my own efforts to ensure miners have=
 a<br>
&gt; smaller part in the ecosystem, with things like committed (encrypted)<=
br>
&gt; transactions and my closed-seal-set/truth-list approach(1). We want to=
 involve<br>
&gt; miners as little as possible in the consensus, not more.<br>
<br>
</span>I agree that miners should have as little influence as possible (and=
<br>
they probably agree, as well). But a 51% group can filter any message<br>
they like from the blockchain. For sidechains, there will need to be two<br=
>
public networks, so concealment is not an option.<br>
<br>
And, I repeat, for regular users of Bitcoin Core, drivechain does not<br>
make a 51% group more dangerous than they already are.<br>
<br>
Moreover, there are cases [1] where miner-involvement can make a big<br>
_positive_ impact. Just as it can be beneficial (essential, in fact) for<br=
>
Bitcoin to filter out harmful interactions among txns (in other words,<br>
good for miners to filter out double spends), I have discovered<br>
situations where it is beneficial and essential for miners to filter out<br=
>
harmful interactions among multiple chains.<br>
<br>
So I think I am actually hitting the &quot;as little as possible&quot; targ=
et.<br>
<br>
[1] <a href=3D"http://www.truthcoin.info/blog/wise-contracts/#wise-contract=
s" rel=3D"noreferrer" target=3D"_blank">http://www.truthcoin.info/<wbr>blog=
/wise-contracts/#wise-<wbr>contracts</a><br>
<span class=3D"gmail-"><br>
<br>
&gt;<br>
&gt; I have to ask: What use-cases do you actually see for drivechains? Why=
 can&#39;t<br>
<br>
</span>Here is a tentative project list:<br>
<a href=3D"http://www.drivechain.info/projects/index.html" rel=3D"noreferre=
r" target=3D"_blank">http://www.drivechain.info/<wbr>projects/index.html</a=
><br>
<br>
And, as I say on the FAQ, &quot;If each individual user is free to sell<br>
his/her BTC in exchange for an Altcoin (or for fiat), we can hardly deny<br=
>
users the opportunity to move their money between two sidechains.&quot;<br>
<br>
So, in a strong way, the entire altcoin market makes the case for a<br>
usefulness of sidechains. Bitcoin is a form of money, and only one form<br>
of money can exist per currency area. So, if Bitcoin is not the winner,<br>
it will eventually cease to exist altogether. Altcoin-competition is an<br>
existential threat to Bitcoin, one which is far more relevant than<br>
anything you&#39;ve presented so far.<br>
<br>
Secondly, one important value of permissionless innovation is that one<br>
doesn&#39;t really know, today, what cool ideas other people are going to<b=
r>
come up with tomorrow. If you did, they&#39;d be today&#39;s ideas.<br>
<br>
Third, Core&#39;s review process has two opposite problems: on one hand it<=
br>
is slow and grueling, and on the other it is fraught with the<br>
possibility of catastrophic error. It would be better, for everyone, to<br>
allow people to try their own (non-aggressive) experiments, and to make<br>
their own mistakes. Already, I have seen the review process abused to<br>
create/maintain fiefdoms of expertise, so that the abusers can extract<br>
money from clients/employers/VCs.<br>
<br>
Just think of all of the free time you would have, Peter, if you didn&#39;t=
<br>
have to spend it all reviewing these projects!<br>
<span class=3D"gmail-"><br>
<br>
&gt; those use-cases be done in the much safer client-side validation fashi=
on?<br>
<br>
</span>? How is drivechain _not_ within the category of client-side validat=
ion?<br>
With BMM, validation is only performed by those users (&quot;clients&quot;)=
 who<br>
opt-in to the new features. The economic model of BMM is directly<br>
comparable to that of Bitcoin&#39;s PoW -- the highest-bid chain should be<=
br>
the healthiest one.<br>
<br>
Can you post the Github link for your most up-to-date client-side<br>
validation work so that we can compare the safety and other features?<br>
<br>
Thanks,<br>
Paul<br>
<br>
&gt;<br>
&gt; 1) <a href=3D"https://petertodd.org/2016/closed-seal-sets-and-truth-li=
sts-for-privacy" rel=3D"noreferrer" target=3D"_blank">https://petertodd.org=
/2016/<wbr>closed-seal-sets-and-truth-<wbr>lists-for-privacy</a><br>
<div class=3D"gmail-HOEnZb"><div class=3D"gmail-h5">&gt;<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div></div>

--001a114f0ce82c10eb05518e041d--