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 7669615A3 for ; Thu, 24 Sep 2015 01:33:12 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ozlabs.org (ozlabs.org [103.22.144.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4A0AE19E for ; Thu, 24 Sep 2015 01:33:11 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 536B6140281; Thu, 24 Sep 2015 11:33:08 +1000 (AEST) From: Rusty Russell To: Gavin Andresen , Bitcoin Dev In-Reply-To: References: User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 24 Sep 2015 11:02:34 +0930 Message-ID: <87twqk38lp.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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: Thu, 24 Sep 2015 01:33:12 -0000 Gavin Andresen via bitcoin-dev writes: > 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. The bandwidth/latency argument is solid. And if a block encodes to < ~3k, then we can just spray it to (some?) peers rather than using INV. But validation is only trivially cachable if the delta to the previous weak block is zero. The "partially validated" cases need to be coded with care (eg. total opcode constraints, tx order). I was thinking as a first cut we do the opposite: don't validate weak blocks at all (other than PoW), and just use them as a bandwidth optimization. Ambition is good though! Chers, Rusty. PS. Original idea came to me from Greg Maxwell; Peter Todd called it "near blocks" and extolled their virtues 2 years ago...