Re: [bitcoin-dev] Fwd: Sidechain headers on mainchain (unification of drivechains and spv proofs)

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

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

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 <bitcoin-dev@lists.linuxfoundation.org>, ZmnSCPxj <ZmnSCPxj@protonmail.com>
>
> 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

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