MIME-Version: 1.0
In-Reply-To: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info>
References: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info>
From: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= <el33th4x0r@gmail.com>
Date: Fri, 24 Mar 2017 09:27:47 -0700
Message-ID: <CAPkFh0s-ZyLN06h+EpU2rfgs5TkTEPG+3FZyWSXusp-Z9XHasQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>, 
	CANNON <cannon@cannon-ciota.info>
Content-Type: multipart/alternative; boundary=001a1143d9fe649fb0054b7c79b2
Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from
 malicious miner takeover?
Precedence: list

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

Because there's no consensus on the contents of the mempool, this approach
is unsafe and will lead to forks. It also opens a new attack vector where
people can time the flood of new transactions with the discovery of a block
by a competitor, to orphan the block and to fork the chain.

The technical defense against an attacking majority of miners is to change
the PoW, effectively moving the community off into a new altcoin where the
attackers, hopefully, don't have majority hash power.

- egs

Sent from my phone, please compensate for autocorrect errors.

On Mar 24, 2017 9:06 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
>

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

<div dir=3D"auto">Because there&#39;s no consensus on the contents of the m=
empool, this approach is unsafe and will lead to forks. It also opens a new=
 attack vector where people can time the flood of new transactions with the=
 discovery of a block by a competitor, to orphan the block and to fork the =
chain.<div dir=3D"auto"><br></div><div dir=3D"auto">The technical defense a=
gainst an attacking majority of miners is to change the PoW, effectively mo=
ving the community off into a new altcoin where the attackers, hopefully, d=
on&#39;t have majority hash power.</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">- egs</div><div dir=3D"auto"><br><div data-smartmail=3D"gmail_si=
gnature" dir=3D"auto">Sent from my phone, please compensate for autocorrect=
 errors. </div></div></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Mar 24, 2017 9:06 AM, &quot;CANNON via bitcoin-dev&quot; &lt;<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.l=
inuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-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></div>

--001a1143d9fe649fb0054b7c79b2--