Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: Fwd: [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs) > Local Time: September 9, 2017 3:33 PM > UTC Time: September 9, 2017 3:33 PM > From: truthcoin@gmail.com > To: Bitcoin Dev , ZmnSCPxj > > Hi everyone, > > I have some agreements and disagreements. > > I agree with Zmn: > > 1. That the sidechain"s header is fully defined by the bits of data > included in mainchain headers. These bits include "h*" (some hash that > is either of the header itself or side:hashMerkleRoot), something that > forces these hashes into a DAG-like structure (in Zmn"s case, it is a > full hashPrevBlock, whereas for us it is just a tiny integer). > 2. That "miner-voting" (for lack of better phrase) accomplishes the same > task as any SPV Proof of any kind. > 3. That sidechains basically need to be merged-mined; to do otherwise, > there are marginal costs but really no marginal benefits. > > However: > > On 9/8/2017 12:19 AM, ZmnSCPxj wrote: >> Good morning. >> >> The obvious reply to all this is: what does >> sidechain-headers-on-mainchain do that drivechain cannot do cheaper? >> >> 1. Unifies merge mining (h* commitment) and WT^ validity voting. >> Merge-mined headers increase the vote on a WT^, by increasing the depth >> of the WT^. > > 1. I think it is a mistake for SHOM ("Sidechain Headers on Mainchain") > to "unify merged-mining and the WT^ validity voting". This causes the > SHOM to regress to mere extension blocks, and they therefore take on > many of the negative properties of extension blocks. > > See: http://www.drivechain.info/faq/index.html#usefulness > >> 2. Through OP_BRIBEVERIFY, the power to decide the validity of a >> sidechain lies in the economic majority rather than in the miners. > > I don"t think that this is true. 51% miner-group can pay bribes to > themselves, and orphan any block or txn that disagrees with them. > > I also don"t think that there is any meaningful difference between "what > the economic majority wants" and "what the miners do". To me it is a > blindingly obvious fact: miners are paid more, only if they increase the > value of { exchange_rate * ([x>=0] + txn_fees) }. This only increases if > Bitcoin is expected to be more objectively useful, and if its users > treasure its use sufficiently to warrant the payment of high tx fees. > > When miners disagree with, for example, the bitcoin-dev mailing list, > this is because miners are attempting to guess what the economic > majority wants, and, in making this earnest attempt, miners believe that > the bitcoin-dev interest is different from the economic majority interest. > > Obviously, I don"t expect to change any minds on this list. After all, > (since no one dares oppose the economic majority), it is a smart > strategy to pretend that the economic majority always agrees with you. > And it is extra smart to avoid examining that belief too carefully. > > 2.2.1. This seems to imply that sidechains where unified merge-mining >> and WT^ voting are paid for by economic majority, effectively work as >> proof-of-stake. The difference here is that the proof does not have to >> cover itself (i.e. the stake being used to prove is outside the system >> which the proof is proving) and it is really more of a >> proof-of-sacrifice-of-stake, since the economic majority needs to pay >> (and thus lose) the stake for continued operation of the sidechain. One >> can argue that proof-of-work is just an instance of >> proof-of-sacrifice-of-stake anyway. > > I agree with most of this, but I think in proof of work and proof of > stake the security guarantee is more reasonable.. In SHOM, there is no > reason to believe that the the quantity "total amount of money available > for withdrawal in a given time" will always be smaller than "sum of 288 > bribes". > >> 2.2.2. Miner behavior on Bcash and Bitcoin suggests to me that a good >> portion of the miners are interested more in short-term profits than >> long-term. > > As long as some critical mass of investors exist, there is no difference > between short and long term profits. It is impossible for an investor to > act in a way that affects the long term, but does not immediately also > affect the short term. > >> I have not seen a good explanation of how drivechain WT^ validity voting >> works in detail; my understanding is that a WT^ is presented on the >> mainchain, then a voting period is established during which miners >> somehow vote for whether the WT^ is valid or not, then the voting ends >> and a UTXO is somehow created. If it is in some Sztorc video, I >> apologize, I am unable to usefully view them. > Some documentation is here: > https://github.com/drivechain-project/docs/blob/master/bip1-hashrate-escrow.md > >> -- >> >> I think lockboxes should have fixed value. The value should be big >> enough that the cost of OP_WITHDRAWPROOFVERIFY is low. Particularly for >> privacy-oriented sidechains, all lockboxes having the same value will >> help tremendously in continuing obscurity after side-to-main transfers. >> However, I am uncertain whether sidechain or mainchain should enforce >> this fixed value. This parameter is something to be endlessly debated. >> Perhaps it should be sidechain that enforces this, but then mistakes >> could occur on the mainchain where some lockbox on the mainchain is >> deemed invalid on the sidechain, and cannot be unlocked validly except >> by destroying the sidechain. > I don"t think this makes any sense, because it implies that the value of > 288 block"s worth of mainchain BTC transaction fees should always be > worth more than the entire market capitalization of Bitcoin. > > Specifically, in this case, the error it introduces is that someone > could get around the fixed value by just using multiple sidechains. Then > the miners would just attack all the sidechains simultaneously. (And > these smaller sidechains would themselves have much smaller fees.) > >> >> Sidechains may first be deployed as federated peg, then at some >> sidechain height the federation may announce a move to >> drivechain/sidechain-headers-on-mainchain. The move from federated to >> economic-majority-controlled would involve the federation moving its >> controlled lockboxes to OP_WITHDRAWPROOFVERIFY lockboxes. > Sergio likes this idea, but I think that this attitude represents a lack > of faith in the design. Either the design works or it does not. Either > the federation works or it does not. >> >> Sidechain hardforks would be very contentious, with only one clear >> winner that can unlock lockboxes. I think, part of sidechain design >> must be the understanding that sidechains must never be hardforked, and >> only softforked. Indeed, I am very much convinced that it is impossible >> to safely hardfork mainchain at all, and any block size increase must by >> necessity be softforked in. > This is already the case in what we have done...the only way to > guarantee that all clients report the same WT^ is if they are all > running softforks of the first version. > >> The mechanism that supports sidechains supports any financial system, >> including centralized, non blockchain ones. The h* commitments can be >> made into commitments to the financial system"s state. Basically, it is >> an implementation of CoinWitness, without using zk-SNARKs and instead >> using some mainchain-voted proof, where validity is judged by how much >> maincoin was sacrified to advance that proof. The supported financial >> system might even allow arbitrary execution of Turing-complete code for >> more vulnerabilities. > This is why I do not want ultra-easy, completely-permissionless creation > of sidechains. Miners (and therefore, users) may NOT desire the EXPECTED > behavior of the sidechain. >> Is there some spec for WT^ layout? > Yes, see above. > > Thanks, > Paul