path: root/96/50cfdb65574cbc0f9a373e2ef97988a704853f

Return-Path: <nickodell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7FDE39FA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Mar 2017 17:29:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f65.google.com (mail-pg0-f65.google.com [74.125.83.65])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 72F6A138
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Mar 2017 17:29:55 +0000 (UTC)
Received: by mail-pg0-f65.google.com with SMTP id w20so1634911pgc.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Mar 2017 10:29:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=osWoPfXikBbv2ebvsecwznjSL19HGZTlvoK9kNeKKI0=;
	b=gECTTUYERn/udj+Y6WN0OcaydCiAYOCLXLx5hep6rrhs7vmZV4rpdv1CHQUv2VaRAz
	+/tb+maRBys6+xBDnWsglhzVF1F/3uaDhwObF4Dyr+Pm0RK3H2j5EiT0mOjNvovWf4OB
	2LVACAAxlQCRbhTmEuw9UN3gAdLxk5/O+edz8orcLnIiKReZals0eUzao2OrH9NJMY3w
	Ij+BFPOwsYBuOqngoBmE886wJNees+RUi8IIyT2pKlBPog65v/zBRbuUZ75144k0E2a0
	KZePn0vk37zDKc8uSVgR5DcFOsbmy30CkL4L4Jx5dKiYduGvCed6m9eoMxJOhV3Uz3zV
	d5nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=osWoPfXikBbv2ebvsecwznjSL19HGZTlvoK9kNeKKI0=;
	b=o8yzXsrStL7oX/o1SBBwuIXrXz2lh33+92hkIZqmnWu7YrrATcVTOm1PtBueFD2WLV
	CeyGgdq1wyrsidzoavP0mhPkKyTWOyMe+XAjf/RzHIZMJNf7iXXZIr/YdFMNExG3pOVj
	2BThnM79u8CsT2qN6PjuuU6u8uOxA8QHSdMWLJNoH+oqOcZERXJLmbXHP22nOL+CU+wT
	KeSFbcaFTfOakWgZGfBDmtIOtsbYW2xq4AuoSwRBWvINhke4EwI4Zn24QuBLYaNXbHIu
	Hjeuzy66BPLmGjmxgM/4+TEQVXQigUC9J+1KEtGD0FxcWo13PD/c0KQK5/T8TOLYr0M0
	+5qA==
X-Gm-Message-State: AFeK/H3ekqcF9yw9haKQkOcF9+PEFD9iOueCI6DIUF5nwqionmKeQuJf3fvk3yTdbejZpo/QaaNjLf41n7AYcA==
X-Received: by 10.84.128.75 with SMTP id 69mr12191274pla.111.1490376594971;
	Fri, 24 Mar 2017 10:29:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.162.208 with HTTP; Fri, 24 Mar 2017 10:29:54 -0700 (PDT)
In-Reply-To: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info>
References: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info>
From: Nick ODell <nickodell@gmail.com>
Date: Fri, 24 Mar 2017 11:29:54 -0600
Message-ID: <CANN4kmcoffWnwE3jCSSNE8xFp4JAUTJim9TsBVtx0QuBbN03FQ@mail.gmail.com>
To: CANNON <cannon@cannon-ciota.info>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c12f93a866697054b7d5709
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	HTML_OBFUSCATE_05_10, 
	RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 24 Mar 2017 17:31:36 +0000
Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from
 malicious miner takeover?
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: Fri, 24 Mar 2017 17:29:56 -0000

--94eb2c12f93a866697054b7d5709
Content-Type: text/plain; charset=UTF-8

Two concerns:

1) This makes block validity depend on things that aren't in the
blockchain. If you and I have different minrelaytxfee's, we will have
different mempool sizes. Your node will discard a block, but my node will
think it is valid, and our nodes will not come to consensus.

2) This is trivially bypassed. A miner can take some coins they own
already, and create a zero-value transaction that has a scriptPubKey of
OP_1. (i.e. anyone-can-spend.) Then, they create another transaction
spending the first transaction, with an empty scriptSig, and the same
scriptPubKey. They do this over and over until they fill up the block.

The last OP_1 output can be left for the next miner. Since the above
algorithm is deterministic, a merkle tree containing every transaction
except the coinbase can be precomputed. The 'malicious' miners do not need
to store this fake block.

On Fri, Mar 24, 2017 at 10:03 AM, CANNON via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> When the original white paper was written the idea was that nodes
> would be miners at same time. That the distribution of mining power
> being mostly on par with the distribution of nodes if I understand
> correctly. The problem we face now I fear, is the mining power
> becoming centralized. Even if every bitcoin node invested a $1000
> into mining power and mined at a loss, it still would not even
> make a dent in hash distribution. Currently there are around 6000
> known nodes. If each node invested $1000 for say 10 ths of hashing
> power. At current hashrate of around 3,674,473,142 GH/s this would
> only make up %16 of hash power. This is out of balance as while
> nodes are distributed mining power is becoming very centralized
> due to the creation of monopolization of ASICs. The problem we
> are facing is a small group of a couple people whom control a
> large amount and growing of hash power. At time of this writing
> it has quickly risen to 39% and at current rate will soon become
> 50% of hashing power that is controlled by a small group of a few
> people. Their intentions are too hijack the bitcoin network to a
> cryptocurrency that suits their dangerous agenda. Dangerous because
> their plan would centralize power of consensus as I understand it,
> to themselves the miners. Dangerous also because the code base of
> the attempting subverters is buggy, insecure, and reckless from a
> technological standpoint. Even though they only have very minute
> amount of nodes compared to legitimate bitcion nodes, the danger
> is that they are very quickly taking over in mining power. While
> it is true that nodes will not accept invalid blocks that would be
> attempted to be pushed by the conspirators, they are threatening to
> attack the valid (or in their words, "minority chain") by dedicating
> some mining power soley to attacking the valid chain by mining empty
> blocks and orphaning the valid chain. So even though the majority
> of nodes would be enforcing what blocks are valid and as a result
> block the non-compliant longer chain, the conspiring miner can simply
> (as they are currently threatening to) make the valid chain unuseable
> by mining empty blocks.
>
> If a malicious miner with half or majority control passes invalid
> blocks, the worst case scenario is a hardfork coin split in which
> the non-compliant chain becomes an alt. However the problem is that
> this malicious miner is very recently threatening to not just simply
> fork, but to kill the valid chain to force economic activity to the
> adversary controlled chain. If we can simply defend against attacks
> to the valid chain, we can prevent the valid chain from dying.
>
> While empty or near empty blocks would generally be protected by
> the incentive of miners to make money. The threat is there if the
> malicious miner with majority control is willing to lose out on
> these transaction fees and block reward if their intention is to
> suppress it to force the majority onto their chain.
>
> Proposal for potential solution Update nodes to ignore empty blocks,
> so this way mined empty blocks cannot be used to DOS attack the
> blockchain. But what about defense from say, blocks that are
> not empty but intentionally only have a couple transactions
> in it? Possible to have nodes not only ignore empty blocks,
> but also blocks that are abnormally small compared to number of
> valid transactions in mempool?
>
> For example would be something like this:
> If block = (empty OR  <%75 of mempool) THEN discard
> This threshold just an example.
>
> What would be any potentials risks
> and attacks resulting from both having such new rulesets and not
> doing anything?
>
> Lets assume that the first problem of blocking empty or near empty
> blocks has been mitigated with the above proposed solution. How
> likely and possible would it be for a malicious miner with lots of
> mining power to orphan the chain after so many blocks even with
> non empty blocks? Is there a need to mitigate this?
> If so is it possible?
>
> Time is running short I fear. There needs to be discussion on various
> attacks and how they can be guarded against along with various
> other contingency plans.
>
> - --
> Cannon
> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> Email: cannon@cannon-ciota.info
>
> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
> If this matters to you, use PGP.
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJY1UH/AAoJEAYDai9lH2mw2QYQALDLBxjdO5WTG7VXfuAE476p
> D3o1MMGw23tb+DFUO5WV6aFqfy3VSxbVXz6UuWbj6kHgp3ys6qxg5TX0Dy8tKSZM
> V28kovuS/pfen4gTxw1FCNff7YVW1R8QX+cSYxSD5EoEaTbpIPgi8zMusDxUVZk2
> WG3ItoyvkLvoNIYGDcU3gR3UkjDS5lOPiHu5BKSj1dEiibOXhr8JEBCznfUSyxCG
> TjVRJaUPlwCU06nad8jAZiDrsW3l866iNkBKaMzMavYuMLvCGIdRkbf54B2ZlIT/
> S/owusxqeIdQpydi/3ydnrqyeWo3znMnn+oOvdvfYEHKLts6gar3Zv8cZ40yYSIE
> z7C7GQFIo5TYDUNOk+2VE7NNtdX39Wj3gJql/305miaIt0qMsf1D30ODjePwyxUQ
> LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/tFm3kx0PunptJaZT8d9EgMeHREjCF4di04A
> 6Dp3Qeug41X/zdIc2AM387QnPwmGB1TpfrY9qgvcrIe26T6An2V5LHwVmslCX3ui
> DYAl0o5ODQqnnakF1FIrr1blMVqm7FqDPQc1I5TfzQuxX2+x+5zdrciPC2HUMCMQ
> jMujge5IdGL3kjEwjt+M6kqLu0/T0fhdUetb2DWrRJUcEVoIaiUL7qLJC+4KMR3d
> Gu3oWoE1ld+BC6At28AD
> =SSuj
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Two concerns:<div><br></div><div>1) This makes block valid=
ity depend on things that aren&#39;t in the blockchain. If you and I have d=
ifferent minrelaytxfee&#39;s, we will have different mempool sizes. Your no=
de will discard a block, but my node will think it is valid, and our nodes =
will not come to consensus.</div><div><br></div><div>2) This is trivially b=
ypassed. A miner can take some coins they own already, and create a zero-va=
lue transaction that has a scriptPubKey of OP_1. (i.e. anyone-can-spend.) T=
hen, they create another transaction spending the first transaction, with a=
n empty scriptSig, and the same scriptPubKey. They do this over and over un=
til they fill up the block.</div><div><br></div><div>The last OP_1 output c=
an be left for the next miner. Since the above algorithm is deterministic, =
a merkle tree containing every transaction except the coinbase can be preco=
mputed. The &#39;malicious&#39; miners do not need to store this fake block=
.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On F=
ri, Mar 24, 2017 at 10:03 AM, CANNON via bitcoin-dev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
When the original white paper was written the idea was that nodes<br>
would be miners at same time. That the distribution of mining power<br>
being mostly on par with the distribution of nodes if I understand<br>
correctly. The problem we face now I fear, is the mining power<br>
becoming centralized. Even if every bitcoin node invested a $1000<br>
into mining power and mined at a loss, it still would not even<br>
make a dent in hash distribution. Currently there are around 6000<br>
known nodes. If each node invested $1000 for say 10 ths of hashing<br>
power. At current hashrate of around 3,674,473,142 GH/s this would<br>
only make up %16 of hash power. This is out of balance as while<br>
nodes are distributed mining power is becoming very centralized<br>
due to the creation of monopolization of ASICs. The problem we<br>
are facing is a small group of a couple people whom control a<br>
large amount and growing of hash power. At time of this writing<br>
it has quickly risen to 39% and at current rate will soon become<br>
50% of hashing power that is controlled by a small group of a few<br>
people. Their intentions are too hijack the bitcoin network to a<br>
cryptocurrency that suits their dangerous agenda. Dangerous because<br>
their plan would centralize power of consensus as I understand it,<br>
to themselves the miners. Dangerous also because the code base of<br>
the attempting subverters is buggy, insecure, and reckless from a<br>
technological standpoint. Even though they only have very minute<br>
amount of nodes compared to legitimate bitcion nodes, the danger<br>
is that they are very quickly taking over in mining power. While<br>
it is true that nodes will not accept invalid blocks that would be<br>
attempted to be pushed by the conspirators, they are threatening to<br>
attack the valid (or in their words, &quot;minority chain&quot;) by dedicat=
ing<br>
some mining power soley to attacking the valid chain by mining empty<br>
blocks and orphaning the valid chain. So even though the majority<br>
of nodes would be enforcing what blocks are valid and as a result<br>
block the non-compliant longer chain, the conspiring miner can simply<br>
(as they are currently threatening to) make the valid chain unuseable<br>
by mining empty blocks.<br>
<br>
If a malicious miner with half or majority control passes invalid<br>
blocks, the worst case scenario is a hardfork coin split in which<br>
the non-compliant chain becomes an alt. However the problem is that<br>
this malicious miner is very recently threatening to not just simply<br>
fork, but to kill the valid chain to force economic activity to the<br>
adversary controlled chain. If we can simply defend against attacks<br>
to the valid chain, we can prevent the valid chain from dying.<br>
<br>
While empty or near empty blocks would generally be protected by<br>
the incentive of miners to make money. The threat is there if the<br>
malicious miner with majority control is willing to lose out on<br>
these transaction fees and block reward if their intention is to<br>
suppress it to force the majority onto their chain.<br>
<br>
Proposal for potential solution Update nodes to ignore empty blocks,<br>
so this way mined empty blocks cannot be used to DOS attack the<br>
blockchain. But what about defense from say, blocks that are<br>
not empty but intentionally only have a couple transactions<br>
in it? Possible to have nodes not only ignore empty blocks,<br>
but also blocks that are abnormally small compared to number of<br>
valid transactions in mempool?<br>
<br>
For example would be something like this:<br>
If block =3D (empty OR=C2=A0 &lt;%75 of mempool) THEN discard<br>
This threshold just an example.<br>
<br>
What would be any potentials risks<br>
and attacks resulting from both having such new rulesets and not<br>
doing anything?<br>
<br>
Lets assume that the first problem of blocking empty or near empty<br>
blocks has been mitigated with the above proposed solution. How<br>
likely and possible would it be for a malicious miner with lots of<br>
mining power to orphan the chain after so many blocks even with<br>
non empty blocks? Is there a need to mitigate this?<br>
If so is it possible?<br>
<br>
Time is running short I fear. There needs to be discussion on various<br>
attacks and how they can be guarded against along with various<br>
other contingency plans.<br>
<br>
- --<br>
Cannon<br>
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832<br>
Email: <a href=3D"mailto:cannon@cannon-ciota.info">cannon@cannon-ciota.info=
</a><br>
<br>
NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD<br>
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.<br>
If this matters to you, use PGP.<br>
-----BEGIN PGP SIGNATURE-----<br>
<br>
iQIcBAEBCgAGBQJY1UH/<wbr>AAoJEAYDai9lH2mw2QYQALDLBxjdO5<wbr>WTG7VXfuAE476p<=
br>
D3o1MMGw23tb+<wbr>DFUO5WV6aFqfy3VSxbVXz6UuWbj6kH<wbr>gp3ys6qxg5TX0Dy8tKSZM<=
br>
V28kovuS/<wbr>pfen4gTxw1FCNff7YVW1R8QX+<wbr>cSYxSD5EoEaTbpIPgi8zMusDxUVZk2<=
br>
WG3ItoyvkLvoNIYGDcU3gR3UkjDS5l<wbr>OPiHu5BKSj1dEiibOXhr8JEBCznfUS<wbr>yxCG<=
br>
TjVRJaUPlwCU06nad8jAZiDrsW3l86<wbr>6iNkBKaMzMavYuMLvCGIdRkbf54B2Z<wbr>lIT/<=
br>
S/owusxqeIdQpydi/<wbr>3ydnrqyeWo3znMnn+<wbr>oOvdvfYEHKLts6gar3Zv8cZ40yYSIE<=
br>
z7C7GQFIo5TYDUNOk+<wbr>2VE7NNtdX39Wj3gJql/<wbr>305miaIt0qMsf1D30ODjePwyxUQ<=
br>
LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/<wbr>tFm3kx0PunptJaZT8d9EgMeHREjCF4<wbr>di04A<=
br>
6Dp3Qeug41X/<wbr>zdIc2AM387QnPwmGB1TpfrY9qgvcrI<wbr>e26T6An2V5LHwVmslCX3ui<=
br>
DYAl0o5ODQqnnakF1FIrr1blMVqm7F<wbr>qDPQc1I5TfzQuxX2+x+<wbr>5zdrciPC2HUMCMQ<=
br>
jMujge5IdGL3kjEwjt+M6kqLu0/<wbr>T0fhdUetb2DWrRJUcEVoIaiUL7qLJC<wbr>+4KMR3d<=
br>
Gu3oWoE1ld+BC6At28AD<br>
=3DSSuj<br>
-----END PGP SIGNATURE-----<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div><br></div>

--94eb2c12f93a866697054b7d5709--