Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 81D35486 for ; Sun, 2 Jul 2017 21:32:52 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f196.google.com (mail-qk0-f196.google.com [209.85.220.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0E16DCE for ; Sun, 2 Jul 2017 21:32:51 +0000 (UTC) Received: by mail-qk0-f196.google.com with SMTP id 91so21926105qkq.1 for ; Sun, 02 Jul 2017 14:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=vU2gIoHXtaF6LHPm61nLr9LxBVP1X34vOderABjzHWM=; b=eSTl6VKUBVBnUGX73Oo78HOYoakzHqsrMCP7Jny4PyUVbEwX9OBoLjZXAinaab21Fw EBuj4gpWwxmRaxCZBrZke6oT19TG4FMopwHdcyzVqpZv3pQ2xKQtGvSwvZaKtnDvNzm4 Pup7zaG4NziJtzSzfHvJzcq9SFIcYXce8/zRdB220bzzn/vV8OYS1GDIjTyHKE1NZl/H JYQxvT2aV2OWO3ThhVPP0MV5+Zne3piy/Cqe+VUXwlJ76Er/pAfPVwZ5sNekT3MkZf+A vjT3qDI5NYFWtBrn/rykgtY70dmzM5nOyKrhHLJji0RZz4UaiYKBYOOdTTwSckDFZT0b P6rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=vU2gIoHXtaF6LHPm61nLr9LxBVP1X34vOderABjzHWM=; b=st5ZfNqnNJa0qodkbPscOkS+RehZfS4pIn+HUZsMo9cI1GCNNTxhow2QuYdzm2IT2Z sIJKKbcvN0EeEJQHsfgsZ2NrVxn8AyeHDFixRJ1LiSab1nbqOwclgI4MagRhdEO0CwiP dH6pxyb7octcfFQf/B7aP+h494qIHTJ3S2ao9wEIzwjHIjVws2LBqxw86/ORj52Sj06C APBWKWbk5+u/GlUiMNeCMOjqrG9AVLd2p1e9fyzHYJdQqv1rm0O3//6zBTSCMjdfawSl HTULBCkk+9+9YWGPXmPzMPLXCJARq9ILwCvBa6Odxx+BFjJ9ZlNohMPH+iyu/ZV32kFV pqfA== X-Gm-Message-State: AKS2vOydtu+0HoHN7g2NEBpG+/JvmQ1LDMMQFhRoFjw7MQw7EizN4TuU KN0720gsp4z+6C/I X-Received: by 10.55.11.134 with SMTP id 128mr36871397qkl.6.1499031170894; Sun, 02 Jul 2017 14:32:50 -0700 (PDT) Received: from [192.168.1.101] (ool-45726efb.dyn.optonline.net. [69.114.110.251]) by smtp.googlemail.com with ESMTPSA id n11sm357561qtf.45.2017.07.02.14.32.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Jul 2017 14:32:49 -0700 (PDT) To: ZmnSCPxj References: <2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com> From: Paul Sztorc Message-ID: <98d35291-5948-cb06-c46a-9d209276cee2@gmail.com> Date: Sun, 2 Jul 2017 17:32:50 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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 Protocol Discussion Subject: Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains 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: Sun, 02 Jul 2017 21:32:52 -0000 Hi, Sorry for the delay, I overlooked this email until now. I see that Chris and CryptAxe both answered but I will also answer, because the message was addressed to me. On 6/30/2017 12:00 AM, ZmnSCPxj wrote: > >Your way is actually very similar to mine. Mine _forces_ the bribe to = be > >in the earliest txn (the coinbase) and to only occur once. Yours doesn= "t > >do anything to refund the briber, if the sidechain (but not the > >mainchain) reorganizes (as it can easily do, if an older sidechain > >parent is extended while the mainchain proceeds normally). This create= s > >additional risk. > > I don't understand this part. In my scheme, a sidechain cannot > reorganize unless the mainchain reorganizes, since the consensus loop > only cares about matching the current block; it ignores splits and > does not consider them valid. If I've understood you correctly, you have said that each OP Return links the (ex)-latest block to a brand new block, and that whichever message of this kind comes first (in the mainchain) wins and the rest are discarded. So what if I had a sidechain represented by a jumble of capital letters, discarded entries as lowercase letters. Mainchain Block #200001: [0 --> Q], [0 -->v], [0 -->s], [0 -->b], Mainchain Block #200002: [Q --> H], [Q --> z], Mainchain Block #200003: [H --> F] Mainchain Block #200004: [F --> J], [F -->w] Mainchain Block #200005: [H --> P], [J -->x] Mainchain Block #200006: [P --> D] Isn't the chain {{ Q --> H --> F --> J }} now starting to reorg, with a competing chain {{ Q --> H --> P --> D }} ? > But I suppose you are considering something like the Ethereum > mutability feature, which I do not think is something you would want > in a sidechain. What I do want to do, is retain the existing model to some extent. Specifically, to the degree where sidechains could salvage some bad situations (eg value overflow incident, or March 2013 incident). > >I think mine is also much more space-efficient. Even if ours each had > >exactly one h* per sidechain per block, it seems that I only require o= ne > >hash to be communicated (plus an indicator byte, and a ~2 byte counter= > >for the ratchet), whereas you require two. Since its overhead per > >sidechain per block, it actually might really add up. > > Do you not provide a single sidechain's h* twice in the block? Once > in the coinbase and once in the briber's separate transaction? That is a good point. Technically, we do include it twice, but the second instance (briber-transaction) can be "shuffled" out if the counterparties are part of the same Lightning Network (which I expect to the be the case, in equilibrium). > > In my scheme at least there is no indicator byte -- the "previous > block" hash is the indicator of which sidechain it is extending. From > your other emails on this list, it seems the ratchet is for > withdrawals from sidechain to mainchain? If so, should it not only > appear in only some of the sidechains (the ones which are currently > doing some withdrawal?)? No, sorry. There are many tangled issues (Drivechain (total system); side-to-main withdrawals (OP CountACKs); individual Drivechains themselves; Blind Merged Mining (OP BribeVerify)). The ratchet is not about withdrawals, it is exclusively about Blind Merged Mining, and making a better OP BribeVerify that offers better guarantees to both side= s. Paul