path: root/2e/5f415d14666a782dcd33cb7a595e261a49bfae

Return-Path: <ethan.scruples@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0F1C571
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 26 Jul 2016 12:47:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f170.google.com (mail-io0-f170.google.com
	[209.85.223.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AF2A3223
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 26 Jul 2016 12:47:26 +0000 (UTC)
Received: by mail-io0-f170.google.com with SMTP id b62so17617390iod.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 26 Jul 2016 05:47:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to;
	bh=KnlhTUacaL7Tf35nLwWhYmRU1QmvV50gJQXBaZMJ+Tg=;
	b=uZJiExi9f1sblySm9hb899l4XmzQjRqKgynVz56tRfr0Ng4by5F4EDUwfl32wMRUxg
	Hx9RaZdMlVNktvTNsBFJbPOHsSQFB7EMGkJhLYuXaWi2AD9ob/INzsjP75u74hzIiDjv
	j1QBn489ViuTfGNOQ4l2XP5L0cZjsSSAxRfRA1Io+f3E6wt5MFFkgY5fJa/3Z2/gplH5
	6eDokmDag5kzJq+TZywEQ2JAa9+YKYToY15JD9B4qemSvcOgEb0OzAx+mLR199xXkDg1
	dPWYObGcMWd/6vTZHi+cC9FSvCPEmjJsEjYdaM29gg75EdNun2w6sD/E0I3jDpgUCq9r
	hi6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
	bh=KnlhTUacaL7Tf35nLwWhYmRU1QmvV50gJQXBaZMJ+Tg=;
	b=KhhCaR+rgtoKsTKiu1xuK+4Qjc1uqb0soEF793p9zupHY6tM/mS1mj/gsdaDnz7toJ
	B2PgyvLMYAmu4SdTeB4TonmL1G4QIG23MnPcdvR3Qi1CKldWN+Ivgag4qBUThF3TM8ul
	vTi/0R/+g2+7WcGS+bUwAEggmZNlY5PobwZhX5nIy0a/3zrmWXYB75iL24wgLxHvNlv7
	Q7X+B94M2M9f+V4JxA00P94TNKgnR8yVJYLLJWhG+gPrro2xqKadTrDjr1JAuAPuWiem
	hXE+XGalg+AWwo7K5jII23wJDvIS+3HI3tfCo1oci/kS1Kq1ubjnCs93U5hXTjpQxFJ6
	lfNw==
X-Gm-Message-State: AEkoouvXyxwERL2pbcIQBzs56pVFgoZv3yN4l+Y5zirMS4fvVCBZ4xTOyIhvmNx/EEzQkNKU994ww/kq/SxnbA==
X-Received: by 10.107.15.157 with SMTP id 29mr24972907iop.123.1469537245832;
	Tue, 26 Jul 2016 05:47:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.80.15 with HTTP; Tue, 26 Jul 2016 05:47:25 -0700 (PDT)
From: Moral Agent <ethan.scruples@gmail.com>
Date: Tue, 26 Jul 2016 08:47:25 -0400
Message-ID: <CACiOHGxpTEOzUBovuJstNEVQOpD+Yv0JivuyeOFsba_jhdyydw@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a113fd39485abd80538894dd5
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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
X-Mailman-Approved-At: Tue, 26 Jul 2016 13:39:49 +0000
Subject: [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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2016 12:47:28 -0000

--001a113fd39485abd80538894dd5
Content-Type: text/plain; charset=UTF-8

I posted this to /r/bitcoin yesterday but it got minimal comments. One uses
suggested I try the mailing list so here it is:

The idea presented here could have the following benefits:

1. Improve mining decentralization
2. Reduce variance in mining profitability
3. Reduce or eliminate SPV mined blocks
4. Reduce or eliminate empty blocks, smoothing out resource usage
5. Reduce or eliminate the latency bottleneck on throughput
6. Make transaction stuffing by miners be either obvious or costly
7. Gives miners something to do while they wait for attractive transactions
to appear
8. Can be easily done with a soft fork

#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.

The sync flag should not be produced too quickly. You want to give everyone
enough time to be ready to hash the next block. Let's say that the hash of
the sync flag is a proof of work that is targeted for 2 minutes.

To fund this proof of work, the protocol is modified to demand that the
block produced 10 blocks after the sync flag must allocate 25% of the block
reward to the address published by the sync flag. In this way, sync flags
are produced in 2 minutes, and blocks are produced in 8 minutes, with 10
minutes total.


Illustration 1: https://s32.postimg.org/wzg0hs8lx/sync_flag.png)

Illustration 2: https://s32.postimg.org/vc5y9yz4l/sync_flag2.png


#Explanation of reasons:

**Improve mining decentralization**

One factor driving centralization is the imperative miners have to achieve
low latency in receiving and validating blocks. To achieve low latency, it
helps a lot if you have expensive low-latency internet connections, curated
network topologies, and large pools that have a plausible chance of finding
consecutive blocks. If miners are expected (or forced) to validate a block
prior to mining on top of it, the rational end game would be to outsource
the validation step to a trusted third party specialist who can choose
optimal locations on the globe to serve their (multiple?) mining pool
clients. These are all less decentralized than the mining situation Satoshi
and others imagined.

**Reduce variance in mining revenue**

Currently, there are about 144 opportunities per day for a pool or solo
miner to see any revenue at all. With sync flags, that number doubles to
288. Sync flags are only worth 25% of what a block is worth, but this still
represents a significant reduction in variance. This variance is one factor
causing solo miners to group into pools, and large pools to be more
attractive than small pools.

**Reduce or eliminate SPV mined blocks**

One way miners have sought to make
full-block-transmission-and-validation-latency irrelevant has been through
"SPV" mining or "Head-first" mining. There is some evidence that these
techniques may be widely used, and that badgering the miners about it is an
ineffective strategy to stop them.

In SPV mining, a miner would simply accept any block header that shows the
correct proof of work. All other validation is entrusted to other miners.
This practice is quite dangerous as the SPV miners can wander off on some
invalid chain, taking SPV nodes with them. If this occurs during a soft
fork, these blind miners can also fool unupgraded fully validating nodes
into following them.

"Head-first" mining means that miners start hashing as soon as they receive
the block header with the correct POW, but they simultaneously validate the
block, and abandon it if is not valid. I consider this to be pretty safe,
as it strictly limits the length of an invalid chain that can result from
mining without validating. However, "Head-first" mining can plausibly
generate 2 or 3 confirmations of an invalid block. It would be nice if such
confirmations did not happen.

The sync flag technique is similar to head-first mining, but rather than
hashing the next block while they wait for transmission and validation of
the prior block, they hash the sync flag. Nodes can differentiate between
sync flags and blocks, and can ignore sync flags when counting
confirmations.

**Reduce or eliminate empty blocks, smoothing out resource usage**

Empty blocks are another consequence of SPV or Headfirst mining, because
the miner cannot safely include any transactions in the block they are
hashing until they have validated the prior block. By delaying the start of
hashing the next block until after validation, miners would not have this
reason to mine empty blocks.

**Reduce or eliminate the latency bottleneck on throughput**

Centralization pressure due to latency issues has been a major
preoccupation over the last year. If latency mattered much less, it could
represent a scalability improvement that could enable higher throughput.

**Make transaction stuffing by miners be either obvious or costly**

Currently, the entire block reward goes to the miner who mines it. One
unfortunate consequence of this is that it does not cost the miner anything
to covertly stuff the block with transactions. These transactions would pay
fees and be indistinguishable from ordinary transactions, but the fees are
paid by the miner and then immediately returned to the miner.

With sync flags, the miner must share these transaction fees with the
address contained in the sync flag 10 blocks prior. This means that if the
miner gives the transactions a normal looking fee, they will incur a cost
that will be paid to the sync flag. If the miner wants to avoid this, they
must give their stuffing transactions a zero fee, which provides evidence
that they are stuffing.

Also, when miners stuff with transactions using a zero fee, they cannot
manipulate the perception of how much fee it takes to get into a block.

Note that miners could still try to covertly stuff blocks that will pay a
sync flag that they themselves created. if this is a big concern, it can be
addressed by forcing blocks to pay multiple sync flags.

**Gives miners something to do while they wait for attractive transactions
to appear**

From the Montreal scaling workshop last year, we have [this talk](
https://scalingbitcoin.org/montreal2015/presentations/Day1/13-miles-carlsten-Mind-the-Gap.pdf)
which worried that as the block subsidy reduced and transactions became a
more important fraction of miner revenue, it would be rational for miners
to turn off their mining equipment for a "gap" phase after a block is
found, to allow time to pass as more lucrative transactions entered the
mempool.

I don't know whether this will actually happen. The presence of a suitable
backlog of transactions would help prevent this dynamic from emerging. But
if such idling behavior was the optima mining strategy, it could create a
serious vulnerability. Idle hands are the devil's workshop as the saying
goes, and idle miners represent a pool of inert hashpower that is available
to rent for all kinds of destabilizing purposes. It would be better to put
those miners to profitable work mining a sync flag while they wait.

Also, this creates a more efficient price discovery mechanism for
transactions, because you allow transactions paying high fees time to
arrive to the marketplace, rather than take whatever anyone is offering
because all the "good" transactions got gobbled up in the prior block.

**Can be easily done with a soft fork**

Although a hard fork would be more efficient, sync flags could be easily
implemented using a soft fork by introducing the following rule:

Every block must include a transaction which pays 25% of the block reward
to the address given by the 10th previous sync flag, and commits to the
hash of the 1st previous sync flag.

--001a113fd39485abd80538894dd5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I posted this to /r/bitcoin yesterday but it got mini=
mal comments. One uses suggested I try the mailing list so here it is:</div=
><div><br></div><div>The idea presented here could have the following benef=
its:</div><div><br></div><div>1. Improve mining decentralization</div><div>=
2. Reduce variance in mining profitability</div><div>3. Reduce or eliminate=
 SPV mined blocks</div><div>4. Reduce or eliminate empty blocks, smoothing =
out resource usage</div><div>5. Reduce or eliminate the latency bottleneck =
on throughput</div><div>6. Make transaction stuffing by miners be either ob=
vious or costly</div><div>7. Gives miners something to do while they wait f=
or attractive transactions to appear</div><div>8. Can be easily done with a=
 soft fork</div><div><br></div><div>#Basic idea:</div><div><br></div><div>I=
deally, all miners would begin hashing the next block at exactly the same t=
ime. Miners with a head start are more profitable, and the techniques that =
help miners receive and validate blocks quickly create centralization press=
ure.</div><div><br></div><div>What if there was something that acted like t=
he starting flag at a race, which could suddenly wave and cause all of the =
miners to simultaneously begin hashing the next block?</div><div><br></div>=
<div>#Implementation:</div><div><br></div><div>Let a sync flag be a message=
 consisting of:</div><div><br></div><div>1. Hash of the previous block.</di=
v><div>2. Bitcoin address</div><div>3. Nonce</div><div><br></div><div>This =
tiny message could propagate through the network at maximum speed. If miner=
s had to include the hash of this flag in the next block, then all miners w=
ait for this flag, and when it suddenly spread through the network, all min=
ers could simultaneously begin hashing the next block.</div><div><br></div>=
<div>The sync flag should not be produced too quickly. You want to give eve=
ryone enough time to be ready to hash the next block. Let&#39;s say that th=
e hash of the sync flag is a proof of work that is targeted for 2 minutes.<=
/div><div><br></div><div>To fund this proof of work, the protocol is modifi=
ed to demand that the block produced 10 blocks after the sync flag must all=
ocate 25% of the block reward to the address published by the sync flag. In=
 this way, sync flags are produced in 2 minutes, and blocks are produced in=
 8 minutes, with 10 minutes total.</div><div><br></div><div><br></div><div>=
Illustration 1:=C2=A0<a href=3D"https://s32.postimg.org/wzg0hs8lx/sync_flag=
.png">https://s32.postimg.org/wzg0hs8lx/sync_flag.png</a>)</div><div><br></=
div><div>Illustration 2: <a href=3D"https://s32.postimg.org/vc5y9yz4l/sync_=
flag2.png">https://s32.postimg.org/vc5y9yz4l/sync_flag2.png</a></div><div><=
br></div><div><br></div><div>#Explanation of reasons:</div><div><br></div><=
div>**Improve mining decentralization**</div><div><br></div><div>One factor=
 driving centralization is the imperative miners have to achieve low latenc=
y in receiving and validating blocks. To achieve low latency, it helps a lo=
t if you have expensive low-latency internet connections, curated network t=
opologies, and large pools that have a plausible chance of finding consecut=
ive blocks. If miners are expected (or forced) to validate a block prior to=
 mining on top of it, the rational end game would be to outsource the valid=
ation step to a trusted third party specialist who can choose optimal locat=
ions on the globe to serve their (multiple?) mining pool clients. These are=
 all less decentralized than the mining situation Satoshi and others imagin=
ed.</div><div><br></div><div>**Reduce variance in mining revenue**</div><di=
v><br></div><div>Currently, there are about 144 opportunities per day for a=
 pool or solo miner to see any revenue at all. With sync flags, that number=
 doubles to 288. Sync flags are only worth 25% of what a block is worth, bu=
t this still represents a significant reduction in variance. This variance =
is one factor causing solo miners to group into pools, and large pools to b=
e more attractive than small pools.</div><div><br></div><div>**Reduce or el=
iminate SPV mined blocks**</div><div><br></div><div>One way miners have sou=
ght to make full-block-transmission-and-validation-latency irrelevant has b=
een through &quot;SPV&quot; mining or &quot;Head-first&quot; mining. There =
is some evidence that these techniques may be widely used, and that badgeri=
ng the miners about it is an ineffective strategy to stop them.</div><div><=
br></div><div>In SPV mining, a miner would simply accept any block header t=
hat shows the correct proof of work. All other validation is entrusted to o=
ther miners. This practice is quite dangerous as the SPV miners can wander =
off on some invalid chain, taking SPV nodes with them. If this occurs durin=
g a soft fork, these blind miners can also fool unupgraded fully validating=
 nodes into following them.</div><div><br></div><div>&quot;Head-first&quot;=
 mining means that miners start hashing as soon as they receive the block h=
eader with the correct POW, but they simultaneously validate the block, and=
 abandon it if is not valid. I consider this to be pretty safe, as it stric=
tly limits the length of an invalid chain that can result from mining witho=
ut validating. However, &quot;Head-first&quot; mining can plausibly generat=
e 2 or 3 confirmations of an invalid block. It would be nice if such confir=
mations did not happen.</div><div><br></div><div>The sync flag technique is=
 similar to head-first mining, but rather than hashing the next block while=
 they wait for transmission and validation of the prior block, they hash th=
e sync flag. Nodes can differentiate between sync flags and blocks, and can=
 ignore sync flags when counting confirmations.</div><div><br></div><div>**=
Reduce or eliminate empty blocks, smoothing out resource usage**</div><div>=
<br></div><div>Empty blocks are another consequence of SPV or Headfirst min=
ing, because the miner cannot safely include any transactions in the block =
they are hashing until they have validated the prior block. By delaying the=
 start of hashing the next block until after validation, miners would not h=
ave this reason to mine empty blocks.</div><div><br></div><div>**Reduce or =
eliminate the latency bottleneck on throughput**</div><div><br></div><div>C=
entralization pressure due to latency issues has been a major preoccupation=
 over the last year. If latency mattered much less, it could represent a sc=
alability improvement that could enable higher throughput.</div><div><br></=
div><div>**Make transaction stuffing by miners be either obvious or costly*=
*</div><div><br></div><div>Currently, the entire block reward goes to the m=
iner who mines it. One unfortunate consequence of this is that it does not =
cost the miner anything to covertly stuff the block with transactions. Thes=
e transactions would pay fees and be indistinguishable from ordinary transa=
ctions, but the fees are paid by the miner and then immediately returned to=
 the miner.</div><div><br></div><div>With sync flags, the miner must share =
these transaction fees with the address contained in the sync flag 10 block=
s prior. This means that if the miner gives the transactions a normal looki=
ng fee, they will incur a cost that will be paid to the sync flag. If the m=
iner wants to avoid this, they must give their stuffing transactions a zero=
 fee, which provides evidence that they are stuffing.</div><div><br></div><=
div>Also, when miners stuff with transactions using a zero fee, they cannot=
 manipulate the perception of how much fee it takes to get into a block.</d=
iv><div><br></div><div>Note that miners could still try to covertly stuff b=
locks that will pay a sync flag that they themselves created. if this is a =
big concern, it can be addressed by forcing blocks to pay multiple sync fla=
gs.</div><div><br></div><div>**Gives miners something to do while they wait=
 for attractive transactions to appear**</div><div><br></div><div>From the =
Montreal scaling workshop last year, we have [this talk](<a href=3D"https:/=
/scalingbitcoin.org/montreal2015/presentations/Day1/13-miles-carlsten-Mind-=
the-Gap.pdf">https://scalingbitcoin.org/montreal2015/presentations/Day1/13-=
miles-carlsten-Mind-the-Gap.pdf</a>) which worried that as the block subsid=
y reduced and transactions became a more important fraction of miner revenu=
e, it would be rational for miners to turn off their mining equipment for a=
 &quot;gap&quot; phase after a block is found, to allow time to pass as mor=
e lucrative transactions entered the mempool.</div><div><br></div><div>I do=
n&#39;t know whether this will actually happen. The presence of a suitable =
backlog of transactions would help prevent this dynamic from emerging. But =
if such idling behavior was the optima mining strategy, it could create a s=
erious vulnerability. Idle hands are the devil&#39;s workshop as the saying=
 goes, and idle miners represent a pool of inert hashpower that is availabl=
e to rent for all kinds of destabilizing purposes. It would be better to pu=
t those miners to profitable work mining a sync flag while they wait.</div>=
<div><br></div><div>Also, this creates a more efficient price discovery mec=
hanism for transactions, because you allow transactions paying high fees ti=
me to arrive to the marketplace, rather than take whatever anyone is offeri=
ng because all the &quot;good&quot; transactions got gobbled up in the prio=
r block.</div><div><br></div><div>**Can be easily done with a soft fork**</=
div><div><br></div><div>Although a hard fork would be more efficient, sync =
flags could be easily implemented using a soft fork by introducing the foll=
owing rule:</div><div><br></div><div>Every block must include a transaction=
 which pays 25% of the block reward to the address given by the 10th previo=
us sync flag, and commits to the hash of the 1st previous sync flag.</div><=
/div>

--001a113fd39485abd80538894dd5--