<div dir="ltr"><div>I made a repo to be a home for sync_flags here: <a href="https://github.com/moral-agent/sync_flags">https://github.com/moral-agent/sync_flags</a></div><div><br></div><div>If you see any personally identifying information, please be a good sport and let me know. I'm a nobody, but I'd still prefer not to get doxxed.</div><div><br></div><div>Two changes to the proposal (see repo for explanations)</div><div><br></div><div>1. Sync flags now would have the same difficulty as blocks.</div><div>2. Blocks now donate to 5 sync flags instead of 1</div><div><br></div><div>I also added comments about selfish mining and invalid block spam.</div><div><br></div><div>Response to replies:</div><div><br></div><div><a href="mailto:tomz@freedommail.ch">tomz@freedommail.ch</a>: What is the advantage over optimistic mining?<br></div><div><br></div><div>1. Sync flags can be somewhat smaller than block headers.</div><div>2. Sync flags improve variance by doubling the number of chances to win</div><div>3. Sync flags can be distinguished from normal blocks, so SPV clients can ignore them as confirmations.</div><div>4. Sync flags reward all miners equally. Optimistic blocks have to be empty unless you mined the previous block, which damages decentralization.</div><div>5. Sync flags result in fewer empty blocks, smoothing out resource usage</div><div>6. Sync flags make transaction stuffing by miners either obvious or costly</div><div>7. Sync flags give miners something to do while they wait for attractive transactions to appear.</div><div><br></div><div><a href="mailto:erik@q32.com">erik@q32.com</a>: Flags will be selfish mined.</div><div><br></div><div>I agree that flags would likely be selfish mined. I have modified the proposal to say that flags have the same POW target as blocks, so the selfish mining vulnerability should be equal to the current protocol.</div><div><br></div><div><a href="mailto:martijn.meijering@mevs.nl">martijn.meijering@mevs.nl</a>: Why expect more selfish mining?</div><div><br></div><div>Because flags had small POW relative to blocks. After you find a block, why not hide it while you take a crack at the flag?</div><div><br></div><div><a href="mailto:tier.nolan@gmail.com">tier.nolan@gmail.com</a>: Effect is same as mandatory empty blocks.</div><div><br></div><div>Not quite the same:</div><div><br></div><div><div>1. Sync flags can be somewhat smaller than block headers.</div><div>2. Sync flags can be distinguished from normal blocks, so SPV clients can ignore them as confirmations.</div><div>3. Sync flags make transaction stuffing by miners either obvious or costly</div></div><div>4. No one pays for empty blocks, except for the block subsidy. Some miners may choose to only mine the non-empty blocks, resulting in hashpower-for-rent to make mischief or hashpower that oscillates, creating a situation where empty blocks take longer to mine than full blocks.</div><div><br></div><div><a href="mailto:nickodell@gmail.com">nickodell@gmail.com</a>: Payout mechanism incompatible with certain mining pools</div><div><br></div><div>Hopefully some kind of smart contract structure could be implemented as you suggested.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 26, 2016 at 6:03 PM, Nick ODell <span dir="ltr"><<a href="mailto:nickodell@gmail.com" target="_blank">nickodell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Moral,<br>
<br>
Mining the sync flag isn't compatible with the payout structure of non<br>
hot-wallet pools like Eligius or decentralized pools like p2pool.<br>
Those need the ability to split a reward among multiple parties.<br>
Instead of giving an address to send the funds to, you could include<br>
the hash of the transaction allowed to spend the sync flag output.<br>
You'd have to zero the previous outpoint of the transaction before<br>
hashing, since you don't know what the hash of the coinbase ten blocks<br>
from now will be.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Tue, Jul 26, 2016 at 6:47 AM, Moral Agent via bitcoin-dev<br>
<<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> I posted this to /r/bitcoin yesterday but it got minimal comments. One uses<br>
> suggested I try the mailing list so here it is:<br>
><br>
> The idea presented here could have the following benefits:<br>
><br>
> 1. Improve mining decentralization<br>
> 2. Reduce variance in mining profitability<br>
> 3. Reduce or eliminate SPV mined blocks<br>
> 4. Reduce or eliminate empty blocks, smoothing out resource usage<br>
> 5. Reduce or eliminate the latency bottleneck on throughput<br>
> 6. Make transaction stuffing by miners be either obvious or costly<br>
> 7. Gives miners something to do while they wait for attractive transactions<br>
> to appear<br>
> 8. Can be easily done with a soft fork<br>
><br>
> #Basic idea:<br>
><br>
> Ideally, all miners would begin hashing the next block at exactly the same<br>
> time. Miners with a head start are more profitable, and the techniques that<br>
> help miners receive and validate blocks quickly create centralization<br>
> pressure.<br>
><br>
> What if there was something that acted like the starting flag at a race,<br>
> which could suddenly wave and cause all of the miners to simultaneously<br>
> begin hashing the next block?<br>
><br>
> #Implementation:<br>
><br>
> Let a sync flag be a message consisting of:<br>
><br>
> 1. Hash of the previous block.<br>
> 2. Bitcoin address<br>
> 3. Nonce<br>
><br>
> This tiny message could propagate through the network at maximum speed. If<br>
> miners had to include the hash of this flag in the next block, then all<br>
> miners wait for this flag, and when it suddenly spread through the network,<br>
> all miners could simultaneously begin hashing the next block.<br>
><br>
> The sync flag should not be produced too quickly. You want to give everyone<br>
> enough time to be ready to hash the next block. Let's say that the hash of<br>
> the sync flag is a proof of work that is targeted for 2 minutes.<br>
><br>
> To fund this proof of work, the protocol is modified to demand that the<br>
> block produced 10 blocks after the sync flag must allocate 25% of the block<br>
> reward to the address published by the sync flag. In this way, sync flags<br>
> are produced in 2 minutes, and blocks are produced in 8 minutes, with 10<br>
> minutes total.<br>
><br>
><br>
> Illustration 1: <a href="https://s32.postimg.org/wzg0hs8lx/sync_flag.png" rel="noreferrer" target="_blank">https://s32.postimg.org/wzg0hs8lx/sync_flag.png</a>)<br>
><br>
> Illustration 2: <a href="https://s32.postimg.org/vc5y9yz4l/sync_flag2.png" rel="noreferrer" target="_blank">https://s32.postimg.org/vc5y9yz4l/sync_flag2.png</a><br>
><br>
><br>
> #Explanation of reasons:<br>
><br>
> **Improve mining decentralization**<br>
><br>
> One factor driving centralization is the imperative miners have to achieve<br>
> low latency in receiving and validating blocks. To achieve low latency, it<br>
> helps a lot if you have expensive low-latency internet connections, curated<br>
> network topologies, and large pools that have a plausible chance of finding<br>
> consecutive blocks. If miners are expected (or forced) to validate a block<br>
> prior to mining on top of it, the rational end game would be to outsource<br>
> the validation step to a trusted third party specialist who can choose<br>
> optimal locations on the globe to serve their (multiple?) mining pool<br>
> clients. These are all less decentralized than the mining situation Satoshi<br>
> and others imagined.<br>
><br>
> **Reduce variance in mining revenue**<br>
><br>
> Currently, there are about 144 opportunities per day for a pool or solo<br>
> miner to see any revenue at all. With sync flags, that number doubles to<br>
> 288. Sync flags are only worth 25% of what a block is worth, but this still<br>
> represents a significant reduction in variance. This variance is one factor<br>
> causing solo miners to group into pools, and large pools to be more<br>
> attractive than small pools.<br>
><br>
> **Reduce or eliminate SPV mined blocks**<br>
><br>
> One way miners have sought to make<br>
> full-block-transmission-and-validation-latency irrelevant has been through<br>
> "SPV" mining or "Head-first" mining. There is some evidence that these<br>
> techniques may be widely used, and that badgering the miners about it is an<br>
> ineffective strategy to stop them.<br>
><br>
> In SPV mining, a miner would simply accept any block header that shows the<br>
> correct proof of work. All other validation is entrusted to other miners.<br>
> This practice is quite dangerous as the SPV miners can wander off on some<br>
> invalid chain, taking SPV nodes with them. If this occurs during a soft<br>
> fork, these blind miners can also fool unupgraded fully validating nodes<br>
> into following them.<br>
><br>
> "Head-first" mining means that miners start hashing as soon as they receive<br>
> the block header with the correct POW, but they simultaneously validate the<br>
> block, and abandon it if is not valid. I consider this to be pretty safe, as<br>
> it strictly limits the length of an invalid chain that can result from<br>
> mining without validating. However, "Head-first" mining can plausibly<br>
> generate 2 or 3 confirmations of an invalid block. It would be nice if such<br>
> confirmations did not happen.<br>
><br>
> The sync flag technique is similar to head-first mining, but rather than<br>
> hashing the next block while they wait for transmission and validation of<br>
> the prior block, they hash the sync flag. Nodes can differentiate between<br>
> sync flags and blocks, and can ignore sync flags when counting<br>
> confirmations.<br>
><br>
> **Reduce or eliminate empty blocks, smoothing out resource usage**<br>
><br>
> Empty blocks are another consequence of SPV or Headfirst mining, because the<br>
> miner cannot safely include any transactions in the block they are hashing<br>
> until they have validated the prior block. By delaying the start of hashing<br>
> the next block until after validation, miners would not have this reason to<br>
> mine empty blocks.<br>
><br>
> **Reduce or eliminate the latency bottleneck on throughput**<br>
><br>
> Centralization pressure due to latency issues has been a major preoccupation<br>
> over the last year. If latency mattered much less, it could represent a<br>
> scalability improvement that could enable higher throughput.<br>
><br>
> **Make transaction stuffing by miners be either obvious or costly**<br>
><br>
> Currently, the entire block reward goes to the miner who mines it. One<br>
> unfortunate consequence of this is that it does not cost the miner anything<br>
> to covertly stuff the block with transactions. These transactions would pay<br>
> fees and be indistinguishable from ordinary transactions, but the fees are<br>
> paid by the miner and then immediately returned to the miner.<br>
><br>
> With sync flags, the miner must share these transaction fees with the<br>
> address contained in the sync flag 10 blocks prior. This means that if the<br>
> miner gives the transactions a normal looking fee, they will incur a cost<br>
> that will be paid to the sync flag. If the miner wants to avoid this, they<br>
> must give their stuffing transactions a zero fee, which provides evidence<br>
> that they are stuffing.<br>
><br>
> Also, when miners stuff with transactions using a zero fee, they cannot<br>
> manipulate the perception of how much fee it takes to get into a block.<br>
><br>
> Note that miners could still try to covertly stuff blocks that will pay a<br>
> sync flag that they themselves created. if this is a big concern, it can be<br>
> addressed by forcing blocks to pay multiple sync flags.<br>
><br>
> **Gives miners something to do while they wait for attractive transactions<br>
> to appear**<br>
><br>
> From the Montreal scaling workshop last year, we have [this<br>
> talk](<a href="https://scalingbitcoin.org/montreal2015/presentations/Day1/13-miles-carlsten-Mind-the-Gap.pdf" rel="noreferrer" target="_blank">https://scalingbitcoin.org/montreal2015/presentations/Day1/13-miles-carlsten-Mind-the-Gap.pdf</a>)<br>
> which worried that as the block subsidy reduced and transactions became a<br>
> more important fraction of miner revenue, it would be rational for miners to<br>
> turn off their mining equipment for a "gap" phase after a block is found, to<br>
> allow time to pass as more lucrative transactions entered the mempool.<br>
><br>
> I don't know whether this will actually happen. The presence of a suitable<br>
> backlog of transactions would help prevent this dynamic from emerging. But<br>
> if such idling behavior was the optima mining strategy, it could create a<br>
> serious vulnerability. Idle hands are the devil's workshop as the saying<br>
> goes, and idle miners represent a pool of inert hashpower that is available<br>
> to rent for all kinds of destabilizing purposes. It would be better to put<br>
> those miners to profitable work mining a sync flag while they wait.<br>
><br>
> Also, this creates a more efficient price discovery mechanism for<br>
> transactions, because you allow transactions paying high fees time to arrive<br>
> to the marketplace, rather than take whatever anyone is offering because all<br>
> the "good" transactions got gobbled up in the prior block.<br>
><br>
> **Can be easily done with a soft fork**<br>
><br>
> Although a hard fork would be more efficient, sync flags could be easily<br>
> implemented using a soft fork by introducing the following rule:<br>
><br>
> Every block must include a transaction which pays 25% of the block reward to<br>
> the address given by the 10th previous sync flag, and commits to the hash of<br>
> the 1st previous sync flag.<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
><br>
</div></div></blockquote></div><br></div>