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 2F5A1170C for ; Wed, 23 Sep 2015 19:24:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 80D83163 for ; Wed, 23 Sep 2015 19:24:07 +0000 (UTC) Received: by igbkq10 with SMTP id kq10so125862504igb.0 for ; Wed, 23 Sep 2015 12:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L7MVjlIck11OBbeb52UfmHvStu1Tg/MDdw1l0DOB1fk=; b=yfwc371O6DvxO/jvQT+3StKsEe48EsPjQse3QhmdSESXyXkzUw4kkF/GKSZm+lkR63 vrpIa9Ay7K9DJyaLHcrEhjMK4nHh8gGVAjtpr8+gYy+y50ubztOZG7cuTAZxnDDYFZ7n qHYuAOWjaECpAwoOol24Y8/W//1wxv+Qtk6F9rsv5cf92hQGXRO98VdbTN74YUeuWZlc MYxYn5aEfRDFOaEQppL918Bcs936cwlx7sWN/rMZr4hbRVDjGELx6IUAcfGDp+Ixhbll i3L9WfdimpNtqO5OAgsxyVNOc40AR4d+CfLcFSSpDPGgcKkMEHNia7PcqS0aVtEp3C/k GvAA== MIME-Version: 1.0 X-Received: by 10.50.27.5 with SMTP id p5mr25410749igg.66.1443036247004; Wed, 23 Sep 2015 12:24:07 -0700 (PDT) Received: by 10.107.19.30 with HTTP; Wed, 23 Sep 2015 12:24:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Sep 2015 19:24:06 +0000 Message-ID: From: Gregory Maxwell To: Bryan Bishop Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham 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] Weak block thoughts... X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 19:24:08 -0000 On Wed, Sep 23, 2015 at 4:07 PM, Bryan Bishop via bitcoin-dev wrote: > more recently: > http://gnusha.org/bitcoin-wizards/2015-09-20.log > http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/ > http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/ See also my response to Peter R's paper that was republished to the list at http://pastebin.com/jFgkk8M3 (See sections at "For example, imagine if miners only include transactions that were previously committed" and especially "Miners volutarily participate in a fast consensus mechenism which commits to transactions") On Wed, Sep 23, 2015 at 3:43 PM, Gavin Andresen via bitcoin-dev wrote: > Imagine miners always pre-announce the blocks they're working on to their > peers, and peers validate those 'weak blocks' as quickly as they are able. > > Because weak blocks are pre-validated, when a full-difficulty block based on > a previously announced weak block is found, block propagation should be > insanely fast-- [...] > A miner could try to avoid validation work by just taking a weak block > announced by somebody else, replacing the coinbase and re-computing the > merkle root, and then mining. They will be at a slight disadvantage to fully Take care, here-- if a scheme is used where e.g. the full solution had to be exactly identical to a prior weak block then the result would be making mining not progress free because bigger miners would have disproportionately more access to the weak/strong one/two punch. I think what you're thinking here is okay, but it wasn't clear to me if you'd caught that particular potential issue. Avoiding this is why I've always previously described this idea as merged mined block DAG (with blocks of arbitrary strength) which are always efficiently deferentially coded against prior state. A new solution (regardless of who creates it) can still be efficiently transmitted even if it differs in arbitrary ways (though the efficiency is less the more different it is). There is a cost to these schemes-- additional overhead from communicating the efficiently encoded weak blocks. But participation in this overhead is optional and doesn't impact the history. I'm unsure of what approach to take for incentive compatibility analysis. In the worst case this approach class has no better delays (and higher bandwidth); but it doesn't seem to me to give rise to any immediate incrementally strategic behavior (or at least none worse than you'd get from just privately using the same scheme). On Wed, Sep 23, 2015 at 4:28 PM, Peter R via bitcoin-dev wrote: > Shouldn't mining pools and miners be paying you guys for coding solutions > that improve their profitability? The income to miners as a whole doesn't depend on these sorts of optimizations, competitive advantages do... so better common open infrastructure helps mostly in the case of putting propagation disadvantaged miners on an equal playing field. You'll note that none of them are exactly sharing their SPV mining source code right now.... in any case, there are simple, expedient, and low risk ways to improve their equality in that respect: centralize (e.g. use bigger pools).