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 AD5F5AB6 for ; Wed, 28 Jun 2017 16:43:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f193.google.com (mail-qt0-f193.google.com [209.85.216.193]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8FB0ED3 for ; Wed, 28 Jun 2017 16:43:26 +0000 (UTC) Received: by mail-qt0-f193.google.com with SMTP id v31so8169938qtb.3 for ; Wed, 28 Jun 2017 09:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=COELcM0HKvHesn9bw1LXdylOfsRhJTNEjhci5IJUQU8=; b=WZlf+G1xq/A7vvC21igvKGyQtu2chstISXwQeiZR1BjEli/l1H0fTt+5GOeFnw4E1e tBsyBNyn24narWI3tLZRKToEthCA9YbiMXJ0x4/hObwIT/ovy+1ALYIEn+iPz2DC1LbD lBVYSZxXCT68mKVELJh09c0ZnNrbhDvgbeJTv5mx0SxXruOJfyouYsRd3dCoLy0/dNgN e483VX6EXzMhW7/4FTJPZIZHYo+0/UfR80C0UQ0YSvmeuf3qQS6SAcTGA0EvahOIIjiB 0i+0FyhQfoSCqE38a1pYOwTBXGQach/5MTVBMD/foP/Gc3lYLzsFHCYjW9XmUjO/zjVV R4jw== 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:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=COELcM0HKvHesn9bw1LXdylOfsRhJTNEjhci5IJUQU8=; b=PDfTozFknxBZHX1WVqh9vVeTot+9MS+JvSNo0kaK/+PIXfktswufgYSkk+3MJDhItQ wztPP+kSdqBeDz2nK2cZ68vOgOk4tWMDpnQep9KppDjYSNNF/kTs9P5uqWtYg+C8Z7GD 1hIkEE11Qk03ePbr5AV75NCT4rRnkFUUgirv3oI/j35a07hkf5ID8vj6mCsUoZ4U4EGI Chu+TBq8L+MpX7yS9bGDV9huOY2X4D/g/WV7HTznmasbP6c7OblACN2SJL0OEVkAaCRw LJAhpwpz/OtFCPRtE3echxOMq8HD3xQe5tjIaNFpsM22m5Twv6jf7JrRIVgByH/+0gpT ELpA== X-Gm-Message-State: AKS2vOz95NwlQVMT9bD9TXkj7fltTWFkRPbCE0Z4uo6F8teJaf+5U03h QgLVBoSRyFTzwPVal8c= X-Received: by 10.200.55.208 with SMTP id e16mr13731045qtc.198.1498668205691; Wed, 28 Jun 2017 09:43:25 -0700 (PDT) Received: from [192.168.1.100] (ool-45726efb.dyn.optonline.net. [69.114.110.251]) by smtp.googlemail.com with ESMTPSA id 79sm2100585qky.50.2017.06.28.09.43.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 09:43:24 -0700 (PDT) To: Luke Dashjr , bitcoin-dev@lists.linuxfoundation.org, Chris Stewart References: <201706280520.29105.luke@dashjr.org> From: Paul Sztorc Message-ID: <32d0153f-0660-3261-237e-516b570bc2db@gmail.com> Date: Wed, 28 Jun 2017 12:43:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <201706280520.29105.luke@dashjr.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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_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 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: Wed, 28 Jun 2017 16:43:27 -0000 Hi Luke, On 6/28/2017 1:20 AM, Luke Dashjr via bitcoin-dev wrote: > On Wednesday 28 June 2017 12:37:13 AM Chris Stewart via bitcoin-dev wrote: >> BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given >> critical hash is included at the given vout index in the coinbase >> transaction >> the script evaluates to true. Otherwise, the script will fail. >> >> This allows sidechains to be merged mined against >> bitcoin without burdening bitcoin miners with extra resource requirements. > > I don't see how. It seems like the logical outcome from this is "whoever pays > the most gets the next sidechain block"... That's not particularly useful for > merge mining. This is one of the assumptions which BMM exploits, see #4 of: http://www.truthcoin.info/blog/blind-merged-mining/#focus The idea is that this is a safe assumption, because it is already the case today. If we assume that miners revenue-maximize, and further that the "bidder" frames his payments in tx-fees, then a willing buyer can control the next block by simply filling it with high tx-fee spam. Anyone who is willing to pay the most can already 'get' the next mainchain block (only, indirectly). > >> This enables sidechains in Bitcoin. > > There are different kinds of sidechains... > > Federated peg: this already works on Bitcoin. > SPV/SNARK peg: this isn't enabled by your BIP. > Drivechains: this isn't enabled by your BIP. > > How do you say this enables any kind of sidechain? Yes, it is unclear, but Chris' email is specific to blind merged mining (BMM), which is kind of a "sidechains +". So this does not directly enable any sidechains. Instead, it enables the "+" part. --Paul