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 C15E614BB for ; Wed, 23 Sep 2015 16:07:52 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D8E4F1B0 for ; Wed, 23 Sep 2015 16:07:51 +0000 (UTC) Received: by qkdw123 with SMTP id w123so19092875qkd.0 for ; Wed, 23 Sep 2015 09:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GA/Z/s8vPfgZh3B7VhutQvuklQQnMHMpNMb9U4FwB3Y=; b=vATieeB0f7zk/L+/87FhQgfEYk831oz6eNqLtDo3RfG1MQ8uTeFLFYX2MGLpwKuIqz WpSQE3BfT4/GrzlQOLinpD7lt6wCp0fu/RFc/sERWHdJvPFg0gApkFxdS3y11ff4VT9w J215YW4eIqtAmGhEqNVG3LddqNm7YLoH10sKRaqOafs0U99r4UNNX7NuwL4HQLXmgYxw TY/rtgu9e4cq8lOAku7fN0J4Kyz6eWwGqfVzqch/+my6SEOVhU/9IGw7ufIWfpmJYvUT 5usFyG6fRRn+Ly9unO0G7Tsl7mMKoRkF624EhLWxNLvryIPC3qli271WWMt3TjCcRnq/ 81uA== X-Received: by 10.55.214.217 with SMTP id p86mr37278077qkl.75.1443024471111; Wed, 23 Sep 2015 09:07:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.154.132 with HTTP; Wed, 23 Sep 2015 09:07:31 -0700 (PDT) In-Reply-To: References: From: Btc Drak Date: Wed, 23 Sep 2015 17:07:31 +0100 Message-ID: To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a1149af1a00d65a05206c5180 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HTML_MESSAGE, 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 16:07:52 -0000 --001a1149af1a00d65a05206c5180 Content-Type: text/plain; charset=UTF-8 For anyone who missed the discussions of weak blocks, here are the Scaling Bitcoin's transcripts: http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/ http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/ (under Network Propagation). On Wed, Sep 23, 2015 at 4:43 PM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I've been thinking about 'weak blocks' and SPV mining, and it seems to me > weak blocks will make things better, not worse, if we improve the mining > code a little bit. > > First: the idea of 'weak blocks' (hat tip to Rusty for the term) is for > miners to pre-announce blocks that they're working on, before they've > solved the proof-of-work puzzle. To prevent DoS attacks, assume that some > amount of proof-of-work is done (hence the term 'weak block') to rate-limit > how many 'weak block' messages are relayed across the network. > > > Today, miners are incentivized to start mining an empty block as soon as > they see a block with valid proof-of-work, because they want to spend as > little time as possible mining a not-best chain. > > 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-- basically, as fast as a single packet can be relayed across > the network the whole network could be mining on the new block. > > I don't see any barrier to making accepting the full-difficulty block and > CreateNewBlock() insanely fast, and if those operations take just a > microsecond or three, miners will have an incentive to create blocks with > fee-paying transactions that weren't in the last block, rather than mining > empty blocks. > > ................. > > 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 validating miners, though, because they WOULD have to mine empty > blocks between the time a full block is found and a fully-validating miner > announced their next weak block. > > ................. > > Weak block announcements are great for the network; they give transaction > creators a pretty good idea of whether or not their transactions are likely > to be confirmed in the next block. And if we're smart about implementing > them, they shouldn't increase bandwidth or CPU usage significantly, because > all the weak blocks at a given point in time are likely to contain the same > transactions. > > -- > -- > Gavin Andresen > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a1149af1a00d65a05206c5180 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For anyone who missed the discussions of weak blocks, here= are the Scaling Bitcoin's transcripts:


On Wed, Sep 23, 2015 at 4:43 PM, Gavin Andresen via= bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
I= 9;ve been thinking about 'weak blocks' and SPV mining, and it seems= to me weak blocks will make things better, not worse, if we improve the mi= ning code a little bit.

First: =C2=A0the idea of 'we= ak blocks' (hat tip to Rusty for the term) is for miners to pre-announc= e blocks that they're working on, before they've solved the proof-o= f-work puzzle. To prevent DoS attacks, assume that some amount of proof-of-= work is done (hence the term 'weak block') to rate-limit how many &= #39;weak block' messages are relayed across the network.

=

Today, miners are incentivized to start mining an empty= block as soon as they see a block with valid proof-of-work, because they w= ant to spend as little time as possible mining a not-best chain.
=
Imagine miners always pre-announce the blocks they're wo= rking 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-- basically= , as fast as a single packet can be relayed across the network the whole ne= twork could be mining on the new block.

I don'= t see any barrier to making accepting the full-difficulty block and CreateN= ewBlock() insanely fast, and if those operations take just a microsecond or= three, miners will have an incentive to create blocks with fee-paying tran= sactions that weren't in the last block, rather than mining empty block= s.

.................

A mi= ner could try to avoid validation work by just taking a weak block announce= d by somebody else, replacing the coinbase and re-computing the merkle root= , and then mining. They will be at a slight disadvantage to fully validatin= g miners, though, because they WOULD have to mine empty blocks between the = time a full block is found and a fully-validating miner announced their nex= t weak block.

.................

Weak block announcements are great for the network; they give transa= ction creators a pretty good idea of whether or not their transactions are = likely to be confirmed in the next block. And if we're smart about impl= ementing them, they shouldn't increase bandwidth or CPU usage significa= ntly, because all the weak blocks at a given point in time are likely to co= ntain the same transactions.

--
--
Gavin Andresen

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a1149af1a00d65a05206c5180--