From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 365C2891 for ; Sat, 9 Sep 2017 15:33:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 85FE6A1 for ; Sat, 9 Sep 2017 15:33:16 +0000 (UTC) Received: by mail-io0-f171.google.com with SMTP id y123so10780422iod.0 for ; Sat, 09 Sep 2017 08:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:from:to:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=L0upFmVhoZ+IfpnBwIPRBTFLhwpTA8Vmpfys521W1jE=; b=kJFJldz1jxYP2hfvYpcMZrsEsDAq/aDMhlaAGRN1QaaoJmTchMSEYl6Kkn4IAATSQ/ A0MfQenJxBUwazJMcD+u+5+LVCsMhfsl+yZKzSqYJMpLroKSP6ZCiJukTgBB7R8ZQoRY 077QysOGcdMrdpUGDQsJLo6nK62oTEGj+yl0d6j7exyobxp72lwAxFjqk7OPVF5AQ6Yz kQlCZGHGvudQCKtDFZrxaUDlKXY5xRWQ0leGSU8ZPMdXtW5+rKfGkVuWGwcXKjGDCFHm 7N8gIy6qHsJasvgkTqCV0DOExM0zbGb/jqUmX9Oo77HVRW8pC6M2yLHpPH3BTIBYSO8y /Vpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:to:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=L0upFmVhoZ+IfpnBwIPRBTFLhwpTA8Vmpfys521W1jE=; b=W+wDDKD0xLcoaGMQYEn5v+WlNLMguJsue68pe0NaYlgkF88bCVxvY7gpBi+KJVcABC FS6JyvUk67SmFRn7liVIgm4BGEcefFHfldekxBa3f8B+zsCXAXFe8AsCYyhuTA9JZooG f7WR1qQYuaLQuVvU7WqFzL+umLa6XMpGQVXvlb9pp77dVLz5Qmt9fxlhZkMeK+UmfgWR phgw3F04c9sxaE4JG3Tddx1po0465AXfvi/xuzHRKVTVlgfE1i2bsXxoPKwyQu47hQzm VoeOnd8ig1n0tU7SHF2xW5+ObeixpBhNV3v1VAzP1GkSniMrpgJ3Xj82WIPH2rk59ntr fw2g== X-Gm-Message-State: AHPjjUj2jd2TaxquBe45ePPlF8HlJCD/TRwg6ESXkCh5SVREd7SnGUv1 zH0VuLDPDeNoxA== X-Google-Smtp-Source: AOwi7QDiHf0ZDh9lKZqTVcMl+nCBzX+vlVReNsN9tD4h0yxv7/VK3gT/SXls5HkeDtiFABT46l3fGg== X-Received: by 10.107.138.77 with SMTP id m74mr8438495iod.218.1504971195629; Sat, 09 Sep 2017 08:33:15 -0700 (PDT) Received: from [192.168.43.210] ([172.58.142.199]) by smtp.googlemail.com with ESMTPSA id 12sm2308553itm.1.2017.09.09.08.33.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Sep 2017 08:33:14 -0700 (PDT) References: <6S1lfiXnljmQiZLorMOenBXGeve0K_LHKiCIZ75Gfc8LZieB7sq_bV_UWV-kJ197FYWywzDaQE7kOEqguYxlDFWZnLdzONhFZ7OAaWFgn64=@protonmail.com> From: Paul Sztorc To: Bitcoin Dev , ZmnSCPxj 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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Fwd: Sidechain headers on mainchain (unification of drivechains and spv proofs) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 15:33:17 -0000 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