From: Tom <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org,
	Moral Agent <ethan.scruples@gmail.com>
Date: Tue, 26 Jul 2016 15:51:56 +0200
Message-ID: <1659997.Te2m0CHHuS@garp>
In-Reply-To: <CACiOHGxpTEOzUBovuJstNEVQOpD+Yv0JivuyeOFsba_jhdyydw@mail.gmail.com>
References: <CACiOHGxpTEOzUBovuJstNEVQOpD+Yv0JivuyeOFsba_jhdyydw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin
Precedence: list

> #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 :)