Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Sergio Demian Lerner <sergio.d.lerner@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 11534 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 14824 bytes --]