path: root/5b/0dc622af9ce4585b968369993d49bb3252572a

Return-Path: <vitteaymeric@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DD993B50
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Mar 2017 19:00:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com
	[209.85.128.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 58EAD343
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Mar 2017 19:00:42 +0000 (UTC)
Received: by mail-wr0-f169.google.com with SMTP id u108so7505401wrb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Mar 2017 12:00:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=subject:to:references:from:message-id:date:user-agent:mime-version
	:in-reply-to; bh=2I+TUR7XYOIpSHvoDkUiaMczlMCWmv2+Lxo/hOHskRE=;
	b=O0TecT6hpzvxLLbFYK3xLPJMKzg85C8viNI7YCga6IbLOs4BsEswgzASubBmp5U9IT
	3FXa+l6uX6bx6wvbGLMiDeXYEG5E8IdJ5HmydW9RhKMU66W5LTJkHqO/3vU6oqA3MxES
	yPeIepBwgc/tdegCG8KYGbWjriTNCsibCmICjwpgnKhK485pVNjhE5K2JNc7OnVqLlqr
	7Um+L6WlAHaYb6Ia/APuhFyDFg7MqKN55Y2075R/bDnhW23+3Z2JP4PY+jefTFwJYTWt
	xWfPK7eyGvEsW6QTDwvCMD759idIqnj/VN7XEDbYrut3EbQK56Ah90QUin2hZ12cEFkA
	up2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:to:references:from:message-id:date
	:user-agent:mime-version:in-reply-to;
	bh=2I+TUR7XYOIpSHvoDkUiaMczlMCWmv2+Lxo/hOHskRE=;
	b=UFyJD63+c72dqsBRDOk6bLeb9fHBNVFXqWE0TDESzRqlJ4OlbYt6Qw6M6DkaDd6con
	48kfbMyFnD0CzIii0YnuCkMhP6wR/OMUSmAMgH5MqQGv9XZO8yRMKkEvhJxf9TT4sZ7Q
	opKNGdc707m1WURzyjbEk0BzDZZ8X5vf9EaETszNv78Q6NhIvbi8wVlRhYRBQtF3mLiG
	+zIrkCXF3CfWwmZ6zlJkeWx/gotVqr6gduN8CP/SiKf8yQHPQmkQmXDCRRmX05Z6U+w9
	cLpuVQ+p/Nxhj7X0Il5zD87CalYgoi6PoXxyNFJ4C8McvkksxLrVYFDilROZbUKAoAu/
	UHGg==
X-Gm-Message-State: AFeK/H2qZStvMmxZRdr0Fjzl6DoNwA+5kYvBPTEcmmEdnRuUlyJ5ho8S1Ug2wUxYDzja9w==
X-Received: by 10.223.162.155 with SMTP id s27mr8769131wra.159.1490382040638; 
	Fri, 24 Mar 2017 12:00:40 -0700 (PDT)
Received: from [192.168.1.10] (ANice-654-1-69-156.w83-201.abo.wanadoo.fr.
	[83.201.96.156]) by smtp.googlemail.com with ESMTPSA id
	g13sm3475165wmd.28.2017.03.24.12.00.39
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 24 Mar 2017 12:00:40 -0700 (PDT)
To: CANNON <cannon@cannon-ciota.info>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <c8e6fd76-efaf-5e98-8048-869d886dbe55@gmail.com>
Date: Fri, 24 Mar 2017 20:00:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101
	Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info>
Content-Type: multipart/alternative;
	boundary="------------060019E14E6E5DB902FD6C43"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
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 19:00:44 -0000

This is a multi-part message in MIME format.
--------------060019E14E6E5DB902FD6C43
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Since I have been working on crypto currencies/bitcoin, I kept
repeating: btc should make a priority to significantly increase the
ridiculous number of full nodes we have today, design an incentive for
people to run full nodes and design a system for people to setup full
nodes in an acceptable timeframe

Unfortunately, this was not a priority at all, maybe because of some
historical consensus between miners and devs, so here we are today, some
miners became crazy, the situation would be much more different if more
full nodes were there

Because, how comes everybody perfectly knows the plans of the conspiring
miners? They were stupid enough to explain very precisely how they will
perform the attack?

If I were them I would in addition setup quite a lot of nodes (which
probably they are planning to do, because anyway they need them for the
new sw), not difficult, not so expensive

Defending against abnormal blocks looks to be a non issue, I suppose
that the btc devs perfectly know how to create a pattern based on
history to detect abnormal blocks (including some strange transactions)
and reject them, but this further depends on the ability of current full
nodes to upgrade, which apparently is not what they do the best

I don't know what "Time is running short I fear" stands for and when 50%
is supposed to be reached

Given that it looks difficult to quickly increase the number of full
nodes, that increasing the mining power by standard means looks too
expensive, useless and not profitable, that a counter attack based on a
new proof of something does not look to be ready, then maybe the btc
folks should ask Bram Cohen (who by some luck is participating to this
list) to resurrect the bitcoin miner Epic Scale which Bittorrent Inc (in
an umpteenth dubious attempt to make money) tried some time ago to
include quietly in utorrent forgetting to ask the authorization of the
selected users, then utorrent users might upgrade (potentially 150 M),
and the resulting mining power might be sufficient, depending on the
incentive for this, which is TBD

Or activate by anticipation proof of space... unlike bitcoin-qt,
utorrent sw is quite good to be intrusive, run in background when you
think you have closed it, run things you don't know, etc, so quite
efficient in this situation

Then if btc folks wants to promote full nodes too, it would not be a bad
idea to put the bitcoin-qt blockchain + chain state in a torrent making
sure it is seeded correctly (there are plenty of academics here, they
can do it and run full nodes too) so people can download it and setup
full nodes (incentive TBD too) assuming they know about upnp/port forward=
ing


Le 24/03/2017 =E0 17:03, CANNON via bitcoin-dev a =E9crit :
> 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 =3D (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.
>
> _______________________________________________ > bitcoin-dev mailing l=
ist > bitcoin-dev@lists.linuxfoundation.org >
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--=20
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.o=
rg
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms


--------------060019E14E6E5DB902FD6C43
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Since I have been working on crypto currencies/bitcoin, I kept
    repeating: btc should make a priority to significantly increase the
    ridiculous number of full nodes we have today, design an incentive
    for people to run full nodes and design a system for people to setup
    full nodes in an acceptable timeframe<br>
    <br>
    Unfortunately, this was not a priority at all, maybe because of some
    historical consensus between miners and devs, so here we are today,
    some miners became crazy, the situation would be much more different
    if more full nodes were there<br>
    <br>
    Because, how comes everybody perfectly knows the plans of the
    conspiring miners? They were stupid enough to explain very precisely
    how they will perform the attack?<br>
    <br>
    If I were them I would in addition setup quite a lot of nodes (which
    probably they are planning to do, because anyway they need them for
    the new sw), not difficult, not so expensive<br>
    <br>
    Defending against abnormal blocks looks to be a non issue, I suppose
    that the btc devs perfectly know how to create a pattern based on
    history to detect abnormal blocks (including some strange
    transactions) and reject them, but this further depends on the
    ability of current full nodes to upgrade, which apparently is not
    what they do the best<br>
    <br>
    I don't know what "Time is running short I fear" stands for and when
    50% is supposed to be reached<br>
    <br>
    Given that it looks difficult to quickly increase the number of full
    nodes, that increasing the mining power by standard means looks too
    expensive, useless and not profitable, that a counter attack based
    on a new proof of something does not look to be ready, then maybe
    the btc folks should ask Bram Cohen (who by some luck is
    participating to this list) to resurrect the bitcoin miner Epic
    Scale which Bittorrent Inc (in an umpteenth dubious attempt to make
    money) tried some time ago to include quietly in utorrent forgetting
    to ask the authorization of the selected users, then utorrent users
    might upgrade (potentially 150 M), and the resulting mining power
    might be sufficient, depending on the incentive for this, which is
    TBD<br>
    <br>
    Or activate by anticipation proof of space... unlike bitcoin-qt,
    utorrent sw is quite good to be intrusive, run in background when
    you think you have closed it, run things you don't know, etc, so
    quite efficient in this situation<br>
    <br>
    Then if btc folks wants to promote full nodes too, it would not be a
    bad idea to put the bitcoin-qt blockchain + chain state in a torrent
    making sure it is seeded correctly (there are plenty of academics
    here, they can do it and run full nodes too) so people can download
    it and setup full nodes (incentive TBD too) assuming they know about
    upnp/port forwarding<br>
    <br>
    <br>
    Le 24/03/2017 à 17:03, CANNON via bitcoin-dev a écrit :<br>
    <blockquote type="cite">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, "minority chain") by
      dedicating<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 = (empty OR  &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>
    </blockquote>
    <span style="white-space: pre;">&gt; _______________________________________________
&gt; bitcoin-dev mailing list
&gt; <a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
&gt; <a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></span><br>
    <br>
    -- <br>
    Zcash wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets">https://github.com/Ayms/zcash-wallets</a><br>
    Bitcoin wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets">https://github.com/Ayms/bitcoin-wallets</a><br>
    Get the torrent dynamic blocklist: <a class="moz-txt-link-freetext" href="http://peersm.com/getblocklist">http://peersm.com/getblocklist</a><br>
    Check the 10 M passwords list: <a class="moz-txt-link-freetext" href="http://peersm.com/findmyass">http://peersm.com/findmyass</a><br>
    Anti-spies and private torrents, dynamic blocklist:
    <a class="moz-txt-link-freetext" href="http://torrent-live.org">http://torrent-live.org</a><br>
    Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a><br>
    torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a><br>
    node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a><br>
    GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a><br>
    <br>
  </body>
</html>

--------------060019E14E6E5DB902FD6C43--