References: <H7RPmZGfkVC8opGMMCW7Orav6yD05-AVB9bNtNU8C0hKYokiXL32VSmn0wkjn77qh4MvacPOePdVQ5gQZuAMF6q2oEuvKDSu6crNcEoXx_0=@protonmail.com>
	<CAGL6+mG-jD6L5b0LepyotDd2+POjkrgV98c2fLFGM0ZokD4afA@mail.gmail.com>
	<wkUkYK_kYwSQx7JKzvgrfUiZYPLPrORMT_zBL5Tg-Spnr8tOyC_o4nZT4yFOD-FE86FvshRhWTfPblYqVmaZHi-VnMbKwpDDkAOjI8b9ap8=@protonmail.com>
	<CAGL6+mGy7nTK1yA8YZcG59r9GZmVb+XWgQ1HjuPD4_pD7ZWThw@mail.gmail.com>
	<6S1lfiXnljmQiZLorMOenBXGeve0K_LHKiCIZ75Gfc8LZieB7sq_bV_UWV-kJ197FYWywzDaQE7kOEqguYxlDFWZnLdzONhFZ7OAaWFgn64=@protonmail.com>
	<CAGL6+mHqKXbm5nAHq+ghaTihCQQe0Rs1sd82ff2NiFKSq6Be+A@mail.gmail.com>
	<yDICafWAbOJEbNvT9o8fltfCuJry5ZOLGwjQ-Ji6xfLjTP3XI_DXb8UbFJ6tA8jclqIEudFABAVEbXuLN9HLnN2nv-WTDE7q9vyjcALtufc=@protonmail.com>
	<CAGL6+mGrN1m_zWs0KM4sfPHCdYUjuJ+E6hjVCFOtz2RoBDZyoQ@mail.gmail.com>
	<E-mvls0CjntrzO4fWx84mYQtc0agV4KdP5QvX3ie3fLXC_YaB58OFvRYTRZhwo7vOn5OPQnlITFwOwyFgDAAZpQ2rvtCgsi-FCy95dBEP0s=@protonmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <1e3f1e8d-c5c9-9ee5-7069-6db47bec5879@gmail.com>
Date: Sat, 9 Sep 2017 11:33:28 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
	Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <E-mvls0CjntrzO4fWx84mYQtc0agV4KdP5QvX3ie3fLXC_YaB58OFvRYTRZhwo7vOn5OPQnlITFwOwyFgDAAZpQ2rvtCgsi-FCy95dBEP0s=@protonmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] Fwd: Sidechain headers on mainchain (unification
 of drivechains and spv proofs)
Precedence: list


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