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 4A15DB37 for ; Tue, 23 May 2017 14:12:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 89FF9134 for ; Tue, 23 May 2017 14:12:27 +0000 (UTC) Received: by mail-oi0-f52.google.com with SMTP id b204so202806629oii.1 for ; Tue, 23 May 2017 07:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=jn4XmWaoF6lzi+GF4JeX9MT3FulHYY0gb38sYZhOjXQ=; b=iZIXiYxepNREoirs/rWVWmE6stULiBLaPVZw+L7M7vm6WxmDtLyFecvF15pkG9fAA1 FNgt0TdqHWLjWMRUqqsryYZ0gODlhNsDAfg+83XVocoEegBoukHAay3TPgQfLwcSIdsB yLFpxyzZOZz4ZNmtyAzeG97KvReg5qRAOm1wMs4YL2s9Aj2XT2LC8PRoQfBoOrWIwMzG CmycVaxX7qfrZl5brGNK5m4JnUFfvC/dzVt0vHadSAjqL9ZdmPcXm0vwbMeMcfpt/bx4 lIo1uILVJ+WYfXo3NRbJeyx/3bgI6d8VTTIVo85KvjRG5cHiKUOt/ynDagr4DzuFAHc0 g0kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jn4XmWaoF6lzi+GF4JeX9MT3FulHYY0gb38sYZhOjXQ=; b=lZ+N27oOpPPFl4KtmLE0k5BartTQgYjoKh7N0qUTtXuMiScLEOywX0POQmbD+9yFqm ldW7sv1mUkW4s0gyFOgA4lzxlzkGxm4oYc6FauooLchFTAYgsYNfJepZEv1dsO7PhlZ4 +dZ6QfjNDVWQl/8ECrrUuuZqLLDKTWD/9ItHI6lQPbCfvb1nC619Ch+26GaBH0iyIo6t cCNbtlmO+lFA39RRW47mQw9xTNe551QO21gatiwSGHJpTuLka2wMGYO6OlDd+uIkeSvA OOL7J8hlL5TqAUMO2J23rFkN7tCVAs9GTF8y/hwnUeRUfC9uGnrPFJjai76aMJxfW5xX lO2A== X-Gm-Message-State: AODbwcDP/QGPlZzDMbAz8dVDgD6BFNc5QKwpyBCKqU8pRI6GXO3EhCca zx2fUZyFwmkh7g== X-Received: by 10.157.40.233 with SMTP id s96mr1970504ota.36.1495548746383; Tue, 23 May 2017 07:12:26 -0700 (PDT) Received: from [192.168.44.223] ([172.56.28.28]) by smtp.googlemail.com with ESMTPSA id e127sm313398oic.21.2017.05.23.07.12.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 07:12:25 -0700 (PDT) To: ZmnSCPxj References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com> From: Paul Sztorc Message-ID: <56d88784-9eb1-8883-0418-68aa98b74a6e@gmail.com> Date: Tue, 23 May 2017 10:12:24 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Drivechain -- Request for Discussion 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: Tue, 23 May 2017 14:12:28 -0000 On 5/22/2017 8:13 PM, ZmnSCPxj wrote: > Good morning, > > > >>What you read is only an introduction of BMM. You may also consult the > notes (at the bottom of the BMM post) or the code, although this is time > consuming of course. > > Looking over the code, I have a question: Is OP_BRIBE supposed to be > softforked in, or hardforked? Softforked, of course. From my understanding, the code as > published in your linked github cannot be softforked in, since it is not > a softfork-compatible replacement for OP_NOP: it replaces the stack top > value with a 0/1 value. Both CLTV and CSV do not touch the stack, only > flag an error if they fail. Your understanding may exceed my own. I don't understand the principle of your distinction, as it seems to me that one could add a new protocol rule which says that the block is invalid unless the OP Code does results in arbitrary-item-x. The intent is to mimic CLTV or CSV behavior, by causing something that would otherwise succeed, to fail, if arbitrary new conditions are met. > > (What happens if the h* to be put in the coinbase, by chance - even very > unlikely chance - is 0? Then OP_NOP4 is not the same as > OP_BRIBE scripts in result - the former will be rejected by old nodes, > the latter will be accepted by new nodes) That would indeed be a bug, if it happened as you described. I will check when I get the chance, thanks. > > Is OP_BRIBE the same as the OP_h_is_in_coinbase operation you described? Yes. Sorry if that was confusing. > > How is OP_BRIBE superior to just using a OP_RETURN script? Cannot > a sidechain scan the block for OP_RETURN attesting that the block hash > is present in the block? The sidechain software can indeed, but the mainchain software cannot (without making validation of both chains part of the mainchain, which defeats the original purpose of sidechains). The purpose of OP_BRIBE is to allow "Sam" (on the sidechain) and "Mary" (a mainchain miner) to work together. Sam would pay X BTC to Mary, if Mary could provide Sam with some guarantee that Sam's sidechain block [defined by h*] would make it into the largest chain. So, as I see it, this needs to be a mainchain consensus rule, but one which enforces the bare minimum criteria. > >>The literal answer to your question is that mainchain Bitcoin will > notice that, for the second withdrawal, the sum of the inputs is less > than the sum of the outputs and they the transaction is therefore invalid. > > You misunderstand. The first withdrawal was done by double-spending, > and exchanging your sidechain funds for mainchain funds using some > off-chain method. The second withdrawal is done on-chain. If A, B, and C are transacting, and each has an account on both chains. Then your example would be something like: 1. main:A sends 100 to side:A, then transfers 100 to side:B in exchange for B's good or service (provided on the sidechain) 2. side:B attempts to move side-to-main with the 100 BTC, using the lightning network. He swaps 100 side:BTC for 100 of C's main:BTC. 3. C attempts to move side-to-main, using the slow, settlement method. 4. C's side-to-main sidechain tx (wt) is bundled with others and becomes a withdrawal attempt (WT^) 5. The WT^ attempt is initiated on the mainchain. 6. After a waiting period, the WT^ begins to accumulate ACKs or NACKs (upvotes / downvotes), on the mainchain. 7. The transaction either succeeds or fails. I'm not sure, but your question seems to concern B, who exploits a reorg that happens just after step 2. After the reorg, the sidechain chain history will have a different side-to-main withdrawal in part 3. The time between each of these step is very long, on the order of weeks (summing to a length of time totaling months), for exactly this reason (as well as to encourage people to avoid using this 'formal' method, in favor of the cooperative LN and Atomic Swaps). I think that this principle of scale (ie, very VERY slow withdrawals) is important and actually makes the security categorically different. For extraordinary DAO-like situations, disinterested mainchain miners merely need a single bit of information (per sidechain), which is "distress=true", and indicates to them to temporarily stop ACKing withdrawals from the sidechain. This alone is enough to give the reorg an unlimited amount of time to work itself out. > > That said, I confused OP_h_is_in_coinbase as your method of getting out > of the sidechain into the mainchain. It seems, OP_h_is_in_coinbase is > only for blind mining? Correct > > > >>I feel that my proposal is more secure, as it can operate healthily and > quickly while using spv proofs which are much slower and much much > easier to audit. > > I don't quite understand how Drivechain handles sidechain reorgs, while > keeping Bitcoin miners blinded. It seems sidechains need to be known > ("seen") by the miner, so I don't see what is being blinded by blinded > merge mining. Mainchain miners do need to maintain some data about the sidechains, but this is very minimal, and certainly does not include the transaction data (or arbitrary messages) of the sidechain. > > >>>seems to me that your OP_is_h_in_coinbase should scan a series of > sidechain block headers backed by mainchain (meaning at the minimum that > sidechains should have some common header format prefix), rather than > just mainchain depth as your article seems to imply. >> >>How would security be improved as a result? In either case, 51% of > hashrate can cause a reorg. The sidechain software itself does scan > block headers, of course. > > I misunderstand the purpose of your OP_is_h_in_coinbase, sorry. > No problem. > >>>Blind merged mining seems strictly inferior ... a rich attacker can > simply reorg the sidechain outright without playing such games. >> >>In the future, when there is no block subsidy, a rich attacker can also > do that in mainchain Bitcoin. > > I see. However, block subsidies will drop far in the future, do you > mean to say, that sidechains will be used only in the far future? In one sense, I mean "you have already endorsed this 'fees only will work' premise, by endorsing Bitcoin". In another sense I mean "isn't it great that you will get a tiny preview, today, of future-Bitcoin's behavior?". > >>>How does your proposal handle multiple side block creators on the same > sidechain, with the possibility that chain splits occur? >> >>The side block is only "mined" if it is committed to in a mainchain > Bitcoin blog, and each mainchain block can only contain one block per > sidechain. In this way, drivechain sidechains are different from > classical Namecoin merged mining (where one _could_ run the entire > system, mining included, without interfacing with Bitcoin at all). > > I assume you mean "mainchain Bitcoin block" here. > > What mechanism ensures only one mainchain block can contain only one > sidechain block? It seems, this isn't implemented by OP_BRIBE yet. Can > you elaborate on this mechanism? That mechanism is enforced by drivechain itself, not OP_BRIBE. (OP Bribe is itself only ~half of BMM. I admit it is getting a little confusing.) Drivechain requires a soft fork to add each new sidechain. It requires this literally for a few good reasons...but the best is: there is an implicit requirement that the miners not steal from the sidechain anyway. In this way drivechain knows how to keep track of what it should expect. > > >>>Regarding your dig about people who dislike data centers, the main > issue with miners blindly accepting sidechain commitments is that it > violates "Don't trust, verify", not that allows datacenters to be > slightly smaller by not including side:nodes. >> >>As I explain early on, in earlier rounds of peer review, the focus was > on harms the sidechain technology might do to mainchain Bitcoin, and the > "datacenter point" was specifically the chief objection raised. So I am > afraid you are entirely incorrect. > > I see. It seems, the main problem, is that sidechains can be used to > sneak in block size increases. Of course, the advantage of sidechains, > is that when it increases block size irresponsibly, only those who > participated in the sidechain will suffer. Precisely. > >>In point of fact, the transactions *are* validated...by sidechain full > nodes, same as Bitcoin proper. > > But from blind merge mining by itself, how would the blinded merge miner > know that there exists an actual sidechain full node that actually did > validation? > > It seems, that the "blinding" in merge mining does not seem to be at all > useful without the miner actually seeing the sidechain. If you want > miners to upgrade to side:fullnode as well, what would then be the point > of blinding? Why not just ordinary merge mining? > > Perhaps the datacenter point is simply that your proposal suggests to > reduce the size of the datacenter by removing surge suppressors and > UPS's, to avoid some definition of "datacenter is a room with >$XXX of > equipment". I hope that my replies above already help with these. If not, let me know. Thanks for your attention, Paul