From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2C420258 for ; 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 ; Fri, 9 Jun 2017 21:54:41 +0000 (UTC) Received: by mail-qt0-f172.google.com with SMTP id u19so90677332qta.3 for ; 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: References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com> <20170522133335.GA17194@fedora-23-dvm> <20170528210757.GA19450@fedora-23-dvm> From: Sergio Demian Lerner Date: Fri, 9 Jun 2017 18:54:00 -0300 Message-ID: To: Paul Sztorc 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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 pr= ovide acknowledges (sometimes known as "votes" in drivechain term= s and "multi-signatures" in a federation) of the sidechain state.=

My Drivechain proposal (Feb 2016)=C2=A0was ta= ilored to enable this particular use-case, which I'm not sure Paul'= s proposal enable.


The proposa= l is on this list under the following subject: Drivechain proposal using OP= _COUNT_ACKS

BIP (draft):

Code & Test cases:

In this= proposal, the "poll" time is sidechain-configurable, and I propo= sed a few days delay was enough.=C2=A0
Some= have said that a longer times are needed, such as 2 months. =C2=A0
So if you want to have a 2 month dalay for sidecha= in->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.

Regards

=


<= div class=3D"gmail_extra">
On Tue, May 30, 20= 17 at 2:11 AM, Paul Sztorc via bitcoin-dev <bitcoin-de= v@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: a= n 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 leve= ls) would
>> be shared collectively by all future miners. Therefore, it would h= ave no
>> effect on miners relative to each other.
>
> That's not at all true. If I'm a miner with a better capabilit= y 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 neutr= al. 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-spe= nding,
> where entities such as Coinbase tried to pay off miners to guarantee s= omething
> that wasn't possible in a geninely decrentralized system: safe zer= oconf
> 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 proc= ess until
>> enough miners understand enough of what is going on to proceed wit= h 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 reje= cting all
> withdrawals is preventing users' from getting their money, which g= ives 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, e= ven 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 cen= sure).

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<= br> each other off". It only cares about the miner-experience, to the exte= nt
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<= br> 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/min= ing-threat-equilibrium/
[2] http://www.truthcoin.info/blog/m= irage-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 d= ecision.
>> In other words, they can just ask people they trust, if the withdr= awal is
>> correct or not. It is up to users to decide if they are comfortabl= e 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 fr= equent.

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, the= y are: a
>> higher BTC price and greater transaction fees. Theft is discourage= d by
>> attempting to tie a theft to a loss of confidence in the miners, a= s
>> described in the spec/website.
>> In general the incentives are very similar to those of Bitcoin its= elf.
>
> This is also a very dubious security model - I would argue that Bitcoi= n is much
> *more* valuable if miners do everything they can to ensure that drivec= hains
> fail, given the huge risks involved.

I don't see how. Users are free to ignore the sidechain, so it c= an 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= .


>=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
> 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)<= br> > 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" targ= et.

[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<= br> 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 fashi= on?

? How is drivechain _not_ within the category of client-side validat= ion?
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<= br> 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--