From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Paul Sztorc <truthcoin@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fwd: Sidechain headers on mainchain (unification of drivechains and spv proofs)
Date: Sun, 10 Sep 2017 01:33:06 -0400 [thread overview]
Message-ID: <9F0W8wmZ5V5ibzeO8-_gKfVFgTsMjJMTNp2T9LwfBnJy-FBDWRcI-52fk3sQN_wjrulE04nJGsLcLRqO7zOzMztI5tleeX10iQUHJxWQqdk=@protonmail.com> (raw)
In-Reply-To: <1e3f1e8d-c5c9-9ee5-7069-6db47bec5879@gmail.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 --]
prev parent reply other threads:[~2017-09-10 5:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-05 8:21 [bitcoin-dev] " ZmnSCPxj
2017-09-05 17:06 ` Chris Stewart
2017-09-05 23:32 ` ZmnSCPxj
[not found] ` <Imrd8VOoGb1nVRp10RedyHoeJYajcvlhrwZQg9OtTk3vDMpc7DEFgw7CSQR_AiqNDwmMECV_fn53WY2i9NZcJKx2jtyd_psyQf6VNg3S7Gc=@protonmail.com>
2017-09-08 20:14 ` Chris Stewart
2017-09-15 4:34 ` [bitcoin-dev] Fw: " ZmnSCPxj
[not found] ` <CAGL6+mG-jD6L5b0LepyotDd2+POjkrgV98c2fLFGM0ZokD4afA@mail.gmail.com>
[not found] ` <wkUkYK_kYwSQx7JKzvgrfUiZYPLPrORMT_zBL5Tg-Spnr8tOyC_o4nZT4yFOD-FE86FvshRhWTfPblYqVmaZHi-VnMbKwpDDkAOjI8b9ap8=@protonmail.com>
[not found] ` <CAGL6+mGy7nTK1yA8YZcG59r9GZmVb+XWgQ1HjuPD4_pD7ZWThw@mail.gmail.com>
[not found] ` <6S1lfiXnljmQiZLorMOenBXGeve0K_LHKiCIZ75Gfc8LZieB7sq_bV_UWV-kJ197FYWywzDaQE7kOEqguYxlDFWZnLdzONhFZ7OAaWFgn64=@protonmail.com>
[not found] ` <CAGL6+mHqKXbm5nAHq+ghaTihCQQe0Rs1sd82ff2NiFKSq6Be+A@mail.gmail.com>
[not found] ` <yDICafWAbOJEbNvT9o8fltfCuJry5ZOLGwjQ-Ji6xfLjTP3XI_DXb8UbFJ6tA8jclqIEudFABAVEbXuLN9HLnN2nv-WTDE7q9vyjcALtufc=@protonmail.com>
[not found] ` <CAGL6+mGrN1m_zWs0KM4sfPHCdYUjuJ+E6hjVCFOtz2RoBDZyoQ@mail.gmail.com>
[not found] ` <E-mvls0CjntrzO4fWx84mYQtc0agV4KdP5QvX3ie3fLXC_YaB58OFvRYTRZhwo7vOn5OPQnlITFwOwyFgDAAZpQ2rvtCgsi-FCy95dBEP0s=@protonmail.com>
2017-09-09 15:33 ` [bitcoin-dev] Fwd: " Paul Sztorc
2017-09-10 5:32 ` ZmnSCPxj
2017-09-10 5:33 ` ZmnSCPxj [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='9F0W8wmZ5V5ibzeO8-_gKfVFgTsMjJMTNp2T9LwfBnJy-FBDWRcI-52fk3sQN_wjrulE04nJGsLcLRqO7zOzMztI5tleeX10iQUHJxWQqdk=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=truthcoin@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox