[bitcoin-dev] Drivechain RfD -- Follow Up

[Tao Effect]

In Drivechain, 51% of miners have total control and ownership over all of the sidechain coins. The vision of Drivechain is to have many blockchains "plugged in" to the main chain.

Today, well over 51% of miners are under the jurisdiction of a single government.

Thus the effect of Drivechain appears to be the creation of a new kind of digital border imposed onto the network where everyone hands over ownership of their Bitcoins to a /single/ mining cartel when they wish to interact with /any/ sidechain.

Drivechain would be a reasonable idea if that weren't the case, but since it is, Drivechain now introduces a very real possible future where Bitcoins can be confiscated by the Chinese government in exactly the same manner that the Chinese government today confiscates financial assets in other financial networks within China.

One argument is that the psuedo-anonymity granted by Bitcoin addresses could theoretically make this less likely to happen, and while that is true, it is also true that every day Bitcoin becomes less and less psuedo-anonymous as governments invest in blockchain analysis tech [1].

How many high-profile confiscations — now via the Bitcoin-blockchain itself (no longer being able to blame a 3rd-party exchange) — is Bitcoin willing to tolerate and open itself up to?

In a world before Drivechain: the worst that a 51% coalition can do is prevent you from spending your coins (censorship).

In a world with Drivechain three things become true:

1. The Bitcoin network centralizes more, because more power (both financial power and power in terms of capability/control) is granted to miners. This is likely to have secondary consequences on the main-chain network as well (in terms of its price and ability to evolve).

2. A 51% coalition — and/or the government behind it — is now able to financially profit by confiscating coins. No longer is it just censorship, "asset forfeiture" — theft — becomes a real possibility for day-to-day Bitcoin users.

3. Drivechain limits user's existing choice when it comes to who is acting as custodian of their Bitcoins, from any trustworthy exchange, down to a single mining cartel under the control of a single set of laws.

The argument given to this is that a UASF could be initiated to wrest control away from this cartel. I do not believe this addresses the concern at all.

A UASF is a very big deal and extremely difficult to pull off correctly. Even when you have users behind you, it *requires* significant support from the miners themselves [2]. Therefore, I do not believe a UASF is a realistic possibility for recovery.

I would only support Drivechain if all of these issue were addressed.

Kind regards,
Greg Slepak

[1] EU Commits €5 Million to Fund Blockchain Surveillance Research — http://www.coindesk.com/eu-commits-e5-million-fund-blockchain-surveillance-research/ <http://www.coindesk.com/eu-commits-e5-million-fund-blockchain-surveillance-research/>

[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014497.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014497.html>

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

> On Jun 10, 2017, at 10:04 AM, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> 
> Hi everyone,
> 
> It has been 3 weeks -- responses so far have been really helpful. People
> jumped right in, and identified unfinished or missing parts much faster
> than I thought they would (ie, ~two days). Very impressive.
> 
> Currently, we are working on the sidechain side of blind merged mining.
> As you know, most of the Bitcoin cryptosystem is about finding the
> longest chain, and displaying information about this chain. CryptAxe is
> editing the sidechain code to handle reorganizations in a new way (an
> even bigger departure than Namecoin's, imho).
> 
> I believe that I have responded to all the on-list objections that were
> raised. I will 1st summarize the on-list objections, and 2nd summarize
> the off-list discussion (focusing on three key themes).
> 
> 
> On-List Objection Summary
> ---------------------------
> 
> In general, they were:
> 
> * Peter complained about the resources required for the BMM 'crisis
> audit', I pointed out that it is actually optional (and, therefore,
> free), and that it doesn't affect miners relative to each other, and
> that it can be done in an ultra-cheap semi-trusted way with high
> reliability.
> * Peter also asked about miner incentives, I replied that it is profit
> maximizing to BMM sidechains, because the equation (Tx Fees - Zero Cost)
> is always positive.
> * ZmnSCPxj asked a long series of clarifying questions, and I responded.
> * Tier Nolan complained about my equivocation of the "Bitcoin: no block
> subsidy" case and the "sidechain" case. He cites the asymmetry I point
> out below (in #2). I replied, and I give an answer below.
> * ZmnSCPxj pointed out an error in our OP Code (that we will fix).
> * ZmnSCPxj also asked a number of new questions, I responded. Then he
> responded again, in general he seemed to raise many of the points
> addressed in #1 (below).
> * ZmnSCPxj wanted reorg proofs, to punish reorgers, but I pointed out
> that if 51% can reorg, they can also filter out the reorg proof. We are
> at their mercy in all cases (for better or worse).
> * ZmnSCPxj also brought up the fact that a block size limit is necessary
> for a fee market, I pointed out that this limit does not need to be
> imposed on miners by nodes...miners would be willing-and-able to
> self-impose such a limit, as it maximizes their revenues.
> * ZmnSCPxj also protested the need to soft fork in each individual
> sidechain, I pointed out my strong disagreement ("Unrestrained smart
> contract execution will be the death of most of the interesting
> applications...[could] destabilize Bitcoin itself") and introduced my
> prion metaphor.
> * ZmnSCPxj and Tier Nolan both identified the problem solved by our
> 'ratchet' concept. I explained it to ZmnSCPxj in my reply. We had not
> coded it at the time, but there is code for it now [1]. Tier proposed a
> rachet design, but I think ours is better (Tier did not find ours at
> all, because it is buried in obscure notes, because I didn't think
> anyone would make it this far so quickly).
> * Tier also advised us on how to fix the problem that ZmnSCPxj had
> identified with our NOP earlier.
> * Tier also had a number of suggestions about the real-time negotiation
> of the OP Bribe amount between nodes and miners. I'm afraid I mostly
> ignored these for now, as we aren't there yet.
> * Peter complained that ACKing the sidechain could be exploited for
> political reasons, and I responded that in such a case, miners are free
> to simply avoid ACKing, or to acquiesce to political pressure. Neither
> affect the mainchain.
> * Peter complained that sidechains might provide some miners with the
> opportunity to create a pretext to kick other miners off the network. I
> replied that it would not, and I also brought up the fact that my
> Bitcoin security model was indifferent to which people happened to be
> mining at any given time. I continue to believe that "mining
> centralization" does not have a useful definition.
> * Peter questioned whether or not sidechains would be useful. I stated
> my belief that they would be useful, and linked to my site
> (drivechain.info/projects <http://drivechain.info/projects>) which contains a number of sidechain
> use-cases, and cited my personal anecdotal experiences.
> * Peter wanted to involve miners "as little as possible", I pointed out
> that I felt that I had indeed done this minimization. My view is that
> Peter felt erroneously that it was possible to involve miners less,
> because he neglected [1] that a 51% miner group is already involved
> maximally, as they can create most messages and filter any message, and
> [2] that there are cases where we need miners to filter out harmful
> interactions among multiple chains (just as they filter out harmful
> interactions among multiple txns [ie, "double spends"]). Peter has not
> yet responded to this rebuttal.
> * Peter also suggested client-side validation as "safer", and I pointed
> out that sidechains+BMM _is_ client-side validation. I asked Peter for
> CS-V code, so that we can compare the safety and other features.
> * Sergio reminded us of his version of drivechain. Sergio and I disagree
> over the emphasis on frequency/speed of withdrawals. Also Sergio
> emphasizes a hybrid model, which does not interest me.
> 
> If I missed any objections, I hope someone will point them out.
> 
> 
> Off-List / Three Points of Ongoing Confusion
> ---------------------------------------------
> 
> Off list, I have repeated the a similar conversation perhaps 6-10 times
> over the past week. There is a cluster of remaining objections which
> centers around three topics -- speed, theft, and antifragility. I will
> reply here, and add the answers to my FAQ (drivechain.info/faq <http://drivechain.info/faq>).
> 
> 1. Speed
> 
> This objection is voiced after I point out that side-to-main transfers
> ("withdrawals") will probably take a long time, for example 5 months
> each ( these are customizable parameters, and open for debate -- but if
> withdrawals are every x=3 months, and only x=1 withdrawal can make
> forward progress [on the mainchain] at a time, and only x=1 prospective
> withdrawal can be assembled [by the sidechain] at a time, then we can
> expect total withdrawal time to average 4.5 months [(.5)*3+3] ). The
> response is something like "won't such a system be too slow, and
> therefore unusable?".
> 
> Imho, replies of this kind disregard the effect of atomic cross-chain
> swaps, which are instant.
> 
> ( In addition, while side-to-main transfers are slow, main-to-side
> transfers are quite fast, x~=10 confirmations. I would go as far as to
> say that, just as the Lightning Network is enabled by SegWit and CSV,
> Drivechain is enabled by the atomic swaps and of Counterparty-like
> embedded consensus. )
> 
> Thanks to atomic swaps, someone can act as an investment banker or
> custodian, and purchase side:BTC at a (tiny, competitive discount) and
> then transfer those side-to-main at a minimal inconvenience (comparable
> to that of someone who buys a bank CD). Through market activities, the
> _entire system_ becomes exactly as patient as its most-patient members.
> As icing on the cake, people who aren't planning on using their BTC
> anytime soon (ie "the patient") can even get a tiny investment yield, in
> return for providing this service.
> 
> 
> 2. Security
> 
> This objection usually says something like "Aren't you worried that 51%
> [hashrate] will steal the coins, given that mining is so centralized
> these days?"
> 
> The logic of drivechain is to take a known fact -- that miners do not
> steal from exchanges (by coordinating to doublespend deposits to those
> exchanges) -- and generalize it to a new situation -- that [hopefully]
> miners will not steal from sidechains (by coordinating to make 'invalid'
> withdrawals from them).
> 
> My generalization is slightly problematic, because "a large mainchain
> reorg today" would hit the entire Bitcoin system and de-confirm *all* of
> the network's transactions, whereas a sidechain-theft would hit only a
> small portion of the system. This asymmetry is a problem because of the
> 1:1 peg, which is explicitly symmetrical -- the thief makes off coins
> that are worth _just as much_ as those coins that he did _not_ attack.
> The side:BTC are therefore relatively more vulnerable to theft, which
> harms the generalization.
> 
> As I've just explained, to correct this relative deficiency, we add
> extra inconvenience for any sidechain thievery, which is in this case
> the long long withdrawal time of several months. (Which is also the main
> distinction between DC and extension blocks).
> 
> I cannot realistically imagine an erroneous withdrawal persisting for
> several weeks, let alone several months. First, over a timeframe of this
> duration, there can be no pretense of 'we made an innocent mistake', nor
> one that 'it is too inconvenient for us to fix this problem'. This
> requires the attacker to be part of an explicitly malicious conspiracy.
> Even in the conspiring case, I do not understand how miners would
> coordinate the distribution of the eventual "theft" payout, ~3 months
> from now -- if new hashrate comes online between now and then, does it
> get a portion? -- if today's hashrate closes down, does it get a reduced
> portion? -- who decides? I don't think that an algorithm can decide
> (without creating a new mechanism, which -I believe- would have to be
> powered by ongoing sustainable theft [which is impossible]), because the
> withdrawal (ie the "theft") has to be initiated, with a known
> destination, *before* it accumulates 3 months worth of acknowledgement.
> 
> Even if hashrate were controlled exclusively by one person, such a theft
> would obliterate the sidechain-tx-fee revenue from all sidechains, for a
> start. It would also greatly reduce the market price of [mainchain] BTC,
> I feel, as it ends the sidechain experiment more-or-less permanently.
> 
> And even _that_ dire situation can be defeated by UASF-style maneuvers,
> such as checkpointing. Even the threat of such maneuvers can be
> persuasive enough for them never to be needed (especially over long
> timeframes, which make these maneuvers convenient).
> 
> A slightly more realistic worst-case scenario is that a monopolist
> imposes large fees on side-to-main transfers (which he contrives so that
> only he can provide). Unless the monopoly is permanent, market forces
> (atomic swaps) will still lower the fee to ultra-competitive levels,
> making this mostly pointless.
> 
> 
> 3. Antifragility
> 
> There is an absolutely crucial distinction of "layers", which is often
> overlooked. Which is a shame, because its importance really cannot be
> understated.
> 
> Taleb's concept of antifragility is explicitly fractal -- it has layers,
> and an upper layer can only be antifragile if it is composed of
> individual members of a lower layer who are each *fragile*. In one of my
> videos I give the example of NYC food providers -- it is _because_ the
> competition is so brutal, and because each individual NYC
> restaurant/supermarket/food-truck is so likely to fail, (and because
> there is no safety net to catch them if they do fail), that the
> consumer's experience is so positive (in NYC, you can find almost any
> kind of food, at any hour of the day, at any price, despite the fact
> that a staggering ~15 million people will be eating there each day).
> 
> By this, I mean there is an absolutely crucial distinction between:
> 
> 1. A problem with a sidechain that negatively impacts its parent chain.
> 2. A problem with a sidechain that only impacts the sidechain users.
> 
> The first type of problem is unacceptable, but the second type of
> problem is actually _desirable_.
> 
> If we wanted to have the best BTC currency unit possible, we would want
> everyone to try all kinds of things out, _especially_ the things that we
> think are terrible. We'd want lots of things to be tried, and for the
> losers to "fail fast".
> 
> In practice I highly doubt the sidechain ecosystem would be anywhere
> near as dynamic as NYC or Silicon Valley. But certain questions, such as
> "What if a sidechain breaks / has DAO-like problems?"; "What if the
> sidechain has only a few nodes? Who will run them?"; "Who will maintain
> these projects?"; -- really just miss the point, I think.
> 
> Ultimately, users can vote with their feet -- if the benefits of a
> sidechain outweigh its risks, some users will send some BTC there. It is
> a strict improvement over the current situation, where users would need
> to use an Altcoin to achieve as much. Users who aren't comfortable with
> the risks of new chains / new features, can simply decline to use them.
> 
> 
> Another Objection
> ------------------
> 
> Finally, two people raised an objection which I will call the "too
> popular" objection or "too big to fail (tbtf)". Something like "what if
> a *majority* of BTC is moved to one sidechain, and then that sidechain
> has some kind of problem?".
> 
> One simple step would be to cap the quantity of BTC that can be moved to
> each sidechain, (at x=10% ? aka 210,000).
> 
> Other than that, I would point out that Bitcoin has always been the
> "money of principle", and that we survived the MtGox announcement (in
> which ~850,000/12,400,000 = 6.85% of the total BTC were assumed to be
> stolen).
> 
> I look forward to the continued feedback! Thank you all very much!
> 
> Paul
> 
> [1]
> https://github.com/drivechain-project/bitcoin/commit/c4beef5c2aa8e52d2c1e11de7c044528bbde6c60 <https://github.com/drivechain-project/bitcoin/commit/c4beef5c2aa8e52d2c1e11de7c044528bbde6c60>
> 
> 
> On 5/22/2017 2:17 AM, Paul Sztorc wrote:
>> Dear list,
>> 
>> I've been working on "drivechain", a sidechain enabling technology, for
>> some time.
>> 
>> * The technical info site is here: www.drivechain.info
>> * The changes to Bitcoin are here:
>> https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
>> * A Blank sidechain template is here:
>> https://github.com/drivechain-project/bitcoin/tree/sidechainBMM
>> 
>> As many of you know, I've been seeking feedback in person, at various
>> conferences and meetups over the past year, most prominently Scaling
>> Milan. And I intend to continue to seek feedback at Consensus2017 this
>> week, so if you are in NYC please just walk up and start talking to me!
>> 
>> But I also wanted to ask the list for feedback. Initially, I was
>> hesitant because I try not to consume reviewers' scarce time until the
>> author has put in a serious effort. However, I may have waiting too
>> long, as today it is actually quite close to a working release.
>> 
>> 
>> Scaling Implications
>> ---------------------
>> 
>> This upgrade would have significant scaling implications. Since it is
>> the case that sidechains can be added by soft fork, and since each of
>> these chains will have its own blockspace, this theoretically removes
>> the blocksize limit from "the Bitcoin system" (if one includes
>> sidechains as part of such a system). People who want a LargeBlock
>> bitcoin can just move their BTC over to such a network [1], and their
>> txns will have no longer have an impact on "Bitcoin Core". Thus, even
>> though this upgrade does not actually increase "scalability" per se, it
>> may in fact put an end to the scalability debate...forever.
>> 
>> This work includes the relatively new concept of "Blind Merged Mining"
>> [2] which I developed in January to allow SHA256^2 miners to merge-mine
>> these "drivechains", even if these miners aren't running the actual
>> sidechain software. The goal is to prevent sidechains from affecting the
>> levelness of the mining "playing field". BMM is conceptually similar to
>> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
>> required for drivechain, but it would address some of the last remaining
>> concerns.
>> 
>> 
>> Total Transaction Fees in the Far Future
>> -----------------------------------------
>> 
>> Some people feel that a maximum blocksize limit is needed to ensure that
>> future total equilibrium transaction fees are non-negligible. I
>> presented [4] on why I don't agree, 8 months ago. The reviewers I spoke
>> to over the last year have stopped bringing this complaint up, but I am
>> not sure everyone feels that way.
>> 
>> 
>> Juxtaposition with a recent "Scaling Compromise"
>> -------------------------------------------------
>> 
>> Recently, a scalability proposal began to circulate on social media. As
>> far as I could tell, it goes something like "immediately activate
>> SegWit, and then HF to double the nonwitness blockspace to 2MB within 12
>> months". But such a proposal is quite meager, compared to a "LargeBlock
>> Drivechain". The drivechain is better on both fronts, as it would not
>> require a hardfork, and could *almost immediately* add _any_ amount of
>> extra blockspace (specifically, I might expect a BIP101-like LargeBlock
>> chain that has an 8 MB maxblocksize, which doubles every two years).
>> 
>> In other words, I don't know why anyone would support that proposal over
>> mine. The only reasons would be either ignorance (ie, unfamiliarity with
>> drivechain) or because there are still nagging unspoken complaints about
>> drivechain which I apparently need to hear and address.
>> 
>> 
>> Other Thoughts
>> ---------------
>> 
>> Unfortunately, anyone who worked on the "first generation" of sidechain
>> technology (the skiplist) or the "second generation" (federated /
>> Liquid), will find that this is very different.
>> 
>> I will admit that I am very pessimistic about any conversation that
>> involves scalability. It is often said that "talking politics lowers
>> your IQ by 25 points". Bitcoin scalability conversations seem to drain
>> 50 points. (Instead of conversing, I think people should quietly work on
>> whatever they are passionate about until their problem either is solved,
>> or it goes away for some other reason, or until we all agree to just
>> stop talking about it.)
>> 
>> Cheers,
>> Paul
>> 
>> [1] http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling
>> [2] http://www.truthcoin.info/blog/blind-merged-mining/
>> [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
>> [4]
>> https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4
>> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170618/afbca0d1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170618/afbca0d1/attachment-0001.sig>