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 C453278D for ; Tue, 26 Jul 2016 14:02:03 +0000 (UTC) X-Greylist: delayed 00:09:57 by SQLgrey-1.7.6 Received: from mx-out03.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B3437233 for ; Tue, 26 Jul 2016 14:02:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx04.mykolab.com (mx04.mykolab.com [10.20.7.102]) by mx-out03.mykolab.com (Postfix) with ESMTPS id ABCF0208D7; Tue, 26 Jul 2016 15:52:01 +0200 (CEST) From: Tom To: bitcoin-dev@lists.linuxfoundation.org, Moral Agent Date: Tue, 26 Jul 2016 15:51:56 +0200 Message-ID: <1659997.Te2m0CHHuS@garp> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 26 Jul 2016 14:03:34 +0000 Subject: Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin 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: Tue, 26 Jul 2016 14:02:03 -0000 > #Basic idea: > > Ideally, all miners would begin hashing the next block at exactly the same > time. Miners with a head start are more profitable, and the techniques that > help miners receive and validate blocks quickly create centralization > pressure. > > What if there was something that acted like the starting flag at a race, > which could suddenly wave and cause all of the miners to simultaneously > begin hashing the next block? > > #Implementation: > > Let a sync flag be a message consisting of: > > 1. Hash of the previous block. > 2. Bitcoin address > 3. Nonce > > This tiny message could propagate through the network at maximum speed. If > miners had to include the hash of this flag in the next block, then all > miners wait for this flag, and when it suddenly spread through the network, > all miners could simultaneously begin hashing the next block. What you describe in this part of your message can be done with no forks whatsoever and I think that this is enough. Don't really see the reason for any change in funding. The idea of sending out a block header is essentially what I called "optimistic mining" and has been described in more detail in my blog here; http://zander.github.io/posts/Innovation%20-%20OnlineScaling/ The video explains with graphics too... You may find this interesting :)