summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorIlya Eriklintsev <erik.lite@gmail.com>2017-06-21 12:55:22 +0300
committerbitcoindev <bitcoindev@gnusha.org>2017-06-21 09:55:25 +0000
commita6c4d4dffbc9bab2f5067dfa6b013658c90f37f0 (patch)
tree5afa007832bc9079d39fba5b533398cd8b745fd3
parent916b15437baaf239a3abf6068de562a8514545aa (diff)
downloadpi-bitcoindev-a6c4d4dffbc9bab2f5067dfa6b013658c90f37f0.tar.gz
pi-bitcoindev-a6c4d4dffbc9bab2f5067dfa6b013658c90f37f0.zip
[bitcoin-dev] BIP Idea : DDoS resistance via decentrilized proof-of-work
-rw-r--r--d6/441900c1054e2bd71287b70ca3b2815fdd9e10263
1 files changed, 263 insertions, 0 deletions
diff --git a/d6/441900c1054e2bd71287b70ca3b2815fdd9e10 b/d6/441900c1054e2bd71287b70ca3b2815fdd9e10
new file mode 100644
index 000000000..3592ec21e
--- /dev/null
+++ b/d6/441900c1054e2bd71287b70ca3b2815fdd9e10
@@ -0,0 +1,263 @@
+Return-Path: <erik.lite@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 62BB0728
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 21 Jun 2017 09:55:25 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-io0-f182.google.com (mail-io0-f182.google.com
+ [209.85.223.182])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7BD4D201
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 21 Jun 2017 09:55:24 +0000 (UTC)
+Received: by mail-io0-f182.google.com with SMTP id y77so152697ioe.3
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 21 Jun 2017 02:55:24 -0700 (PDT)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
+ h=mime-version:from:date:message-id:subject:to;
+ bh=O9hloG757gxF3fxfCdtEYnqWZ+0E3qs9Ievzd2r1Bug=;
+ b=rr+y4Je8VPlOY1JNBNAcql4cZHzhsoszkMn4KmxL8UJOLFbepg9JlAtp4GPd0xWBVg
+ z7dh8GXirxb7bWBGfXadWphlLX9gzLtRgzUKY1iXAGToIixx0lQVMsJvAppdzTyaxohd
+ lIh3yx89BKlNYgy1muh9K3bsbf6h5B/nGFqnvHIWKecBljDiPQSCpCiwdX78qRbFWWcn
+ GI6trigjVnLxEOO1TvH3CpK6mj0aiEc5AP9qMWUeuI5zzRRGYudDIH0ydcDMuT2QhIn3
+ cwk4i5H/xHGa13eSAHFOcaYOrHRWiBy+XrdC6wrHuHhZgcR91f4AItCk3sYFVBm024UY
+ ukiw==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20161025;
+ h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
+ bh=O9hloG757gxF3fxfCdtEYnqWZ+0E3qs9Ievzd2r1Bug=;
+ b=IAoQTG93sNHiPLwK2fimorilWpom3dIJ6Nem4uFTmbGFu2dtMPDzZy2cY0iwMIkfRP
+ S8DFFWngW37zYFZKrTu4fd+cUrg7wogA6/VxRln6hRrzPWrt7dUGy5g0mROPMkQwyutY
+ kOF4zr5T0FxjtcBOBaew5J64SHkk2AV7LhHbZWwtwcNg7toZwh4nnHENvpZpGhxq+4VT
+ TLIOFdkt3goKuutqbnROnAw6Qboz3mlGjCVhMjBMl6XT2zsyNlG7XCeBbrXha74KVifi
+ e7YKFGuxpreYt5VWhk29Rgo9m0vXNBYrJZ2h+PdEJ1gRStW4CoAeMw0mM2mqjnxkOKzT
+ K46w==
+X-Gm-Message-State: AKS2vOyu0v9tkpWLukaucMVYZtSL8cOB1ZyyYid7JIJ6CqHWWkxfUGMV
+ eGqB3U2N6UUUuUItKV/RhWPWguwvhSj2SvE=
+X-Received: by 10.107.130.150 with SMTP id m22mr33284027ioi.140.1498038923394;
+ Wed, 21 Jun 2017 02:55:23 -0700 (PDT)
+MIME-Version: 1.0
+Received: by 10.79.33.80 with HTTP; Wed, 21 Jun 2017 02:55:22 -0700 (PDT)
+From: Ilya Eriklintsev <erik.lite@gmail.com>
+Date: Wed, 21 Jun 2017 12:55:22 +0300
+Message-ID: <CA+Yhp0Uv3zrg28G7QcgXPSv4Md9j2U-=SROJqWAOqvW_tCu=bQ@mail.gmail.com>
+To: bitcoin-dev@lists.linuxfoundation.org
+Content-Type: multipart/alternative; boundary="001a113fb680e3d4bc0552755d5c"
+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
+X-Mailman-Approved-At: Wed, 21 Jun 2017 10:39:39 +0000
+Subject: [bitcoin-dev] BIP Idea : DDoS resistance via decentrilized
+ proof-of-work
+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: Wed, 21 Jun 2017 09:55:25 -0000
+
+--001a113fb680e3d4bc0552755d5c
+Content-Type: text/plain; charset="UTF-8"
+
+Hello everyone,
+
+recently I have got an idea that in my opinion will improve bitcoin
+network, making it better store-of-value for growing cyberspace and
+cryptoeconomy. Sorry for longread below and thank you for your time.
+
+*Decentralized proof-of-work and DDoS resistance for Bitcoin*
+
+*Abstract*
+
+By introducing some new block validation rules it is possible to make
+Bitcoin network more secure, decentralized and DDoS resistant. The idea is
+to modify simple proof-of-work puzzle in such a way that user transactions
+could be hardened with the same proof-of-work algorithm thus incentivising
+all the miners to include that particular transaction. Such mechanism will
+effectively give a handicap to every miner who includes "mined" transaction
+into next block, increasing probability of him getting block reward.
+
+*Problems and motivation*
+
+This document will address the issue of a continuous DDoS attack targeting
+the Bitcoin network, e.g. full nodes mempools constantly being overflowed
+with transactions carrying small value reduce system primary ability to
+transfer value (and hence making it perfect store of value). Valid
+transactions are cheap to create (in the sense of computational effort
+required) and no adequate mechanism exist to make transaction total value
+increase probably of its confirmation by the network.
+
+Currently, miners decide which transactions to include in blocks because
+it's them who are securing Bitcoin network providing proof-of-work
+certificates stored inside every block header. Miners have to store the
+whole blockchain at all times, so one of the costs is storage which grows
+linearly with the transaction size (blockchain size as well). Another cost
+is network bandwidth which depends directly on the size of data to be
+communicated over.
+
+The only incentive a person who wants to transfer his bitcoins is allowed
+to use is setting of transaction fee, that is going directly to the miner.
+This solution probably was intended to utilize free market (as implied by
+Satoshi introducing sequence numbers) to determine appropriate fees, but
+that is obviously not the case, in the current bitcoin network operating in
+full block capacity mode. This fee market deviates significantly from a
+free market premise (also attempts being made to make it closer, e.g. in
+BIP125 where Replace-By-Fee signaling is supposed to help in replacing
+"stuck" transactions with noncompetitive fee).
+
+Currently, bitcoin network is susceptible to the DDoS attack of a kind.
+Adversary creating and translating into the network a lot of transactions
+carrying small value (e.g. only miners fee), will be able to impair the
+ability to transfer value for everyone in the world, should he has enough
+money to pay the fees. Miners would continue to work providing security for
+the network and new blocks will consist of transaction transferring
+negligible value. It's a major drawback because the cost of such attack
+doesn't grow asymmetrically with the cost of BTC asset.
+
+*Proposed solution*
+
+So how do we incentivize all miners to include our transaction carrying a
+lot of value in the next block? The only thing a miner supposed to do to
+get a reward is to produce Hashcash proof-of-work, thus providing
+cryptographic security guarantees for the whole Bitcoin blockchain. What if
+including our transaction in a block would reduce effort requirements for
+the miner produce valid block?
+
+We could do so by extending the concept of proof-of-work, in such a way
+that we do not sacrifice security at all. Here are both descriptions
+proof-of-work as-is and to-be:
+
+Standart proof-of-work: hash(previous block hash + current block target +
+current block metadata + current block transactions) < target
+
+Decentralized proof-of-work: hash(previous block hash + current block
+target + current block metadata + current block transactions) - sum( FFFF -
+hash( previous block hash + raw_tx ) ) < target
+
+It is possible to imagine completely mining agnostic proof-of-work, for
+example, the following PoW would do:
+
+Distributed (mining-agnostic) proof-of-work: sum( FFFF - hash( previous
+block hash + current block target + current block metadata + signed_tx ) )
+< target
+
+Described protocol change could be implemented as user activated soft-fork
+(described in BIP148), introducing new blocks with the modified
+proof-of-work concept.
+
+*Economic reasoning*
+
+An adversary whose goal is to prevent the network from transferring value
+will have to compete with good users hash rate using same equipment good
+miners will use. And it's far more complicated than competing with others
+using the money to pay transaction fees.
+
+In order to investigate probable consequences of protocol upgrade and
+stability of implied economical equilibrium, we need an adequate game
+theoretical model. Such model and numerical simulation results should be
+obtained and studied before any protocol change could be considered by the
+community.
+
+To me it seems like a win-win solution for everyone owning BTC:
+
+Miners benefit: as the result DDoS attack will be stopped, Bitcoin becomes
+perfect store-of-value finally. Political decentralization of hash rate
+will be incentivized as mining equipment becomes relevant to every user.
+Users benefit: miners will have direct incentives to include transactions
+deemed important by their sender and supported by some amount of
+proof-of-work.
+
+Sincerely yours, Ilya Eriklintsev.
+
+--001a113fb680e3d4bc0552755d5c
+Content-Type: text/html; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr"><span style=3D"font-size:12.8px">Hello everyone,</span><di=
+v style=3D"font-size:12.8px"><br><div>recently I have got an idea that in m=
+y opinion will improve bitcoin network, making it better store-of-value for=
+ growing cyberspace and cryptoeconomy. Sorry for longread=C2=A0below and th=
+ank you for your time.<div><br></div><b>Decentralized proof-of-work and DDo=
+S resistance for Bitcoin</b><br><br><b>Abstract</b><br><br>By introducing s=
+ome new block validation rules it is possible to make Bitcoin network more =
+secure, decentralized and DDoS resistant. The idea is to modify simple proo=
+f-of-work puzzle in such a way that user transactions could be hardened wit=
+h the same proof-of-work algorithm thus incentivising all the miners to inc=
+lude that particular transaction. Such mechanism will effectively give a ha=
+ndicap to every miner who includes &quot;mined&quot; transaction into next =
+block, increasing probability of him getting block reward.<br><br><b>Proble=
+ms and motivation</b><br><br>This document will address the issue of a cont=
+inuous DDoS attack targeting the Bitcoin network, e.g. full nodes mempools =
+constantly being overflowed with transactions carrying small value reduce s=
+ystem primary ability to transfer value (and hence making it perfect store =
+of value). Valid transactions are cheap to create (in the sense of computat=
+ional effort required) and no adequate mechanism exist to make transaction =
+total value increase probably of its confirmation by the network.<br><br>Cu=
+rrently, miners decide which transactions to include in blocks because it&#=
+39;s them who are securing Bitcoin network providing proof-of-work certific=
+ates stored inside every block header. Miners have to store the whole block=
+chain at all times, so one of the costs is storage which grows linearly wit=
+h the transaction size (blockchain size as well). Another cost is network b=
+andwidth which depends directly on the size of data to be communicated over=
+.<br><br>The only incentive a person who wants to transfer his bitcoins is =
+allowed to use is setting of transaction fee, that is going directly to the=
+ miner. This solution probably was intended to utilize free market (as impl=
+ied by Satoshi introducing sequence numbers) to determine appropriate fees,=
+ but that is obviously not the case, in the current bitcoin network operati=
+ng in full block capacity mode. This fee market deviates significantly from=
+ a free market premise (also attempts being made to make it closer, e.g. in=
+ BIP125 where Replace-By-Fee signaling is supposed to help in replacing &qu=
+ot;stuck&quot; transactions with noncompetitive fee).<br><br>Currently, bit=
+coin network is susceptible to the DDoS attack of a kind. Adversary creatin=
+g and translating into the network a lot of transactions carrying small val=
+ue (e.g. only miners fee), will be able to impair the ability to transfer v=
+alue for everyone in the world, should he has enough money to pay the fees.=
+ Miners would continue to work providing security for the network and new b=
+locks will consist of transaction transferring negligible value. It&#39;s a=
+ major drawback because the cost of such attack doesn&#39;t grow asymmetric=
+ally with the cost of BTC asset.<br><br><b>Proposed solution</b><br><br>So =
+how do we incentivize all miners to include our transaction carrying a lot =
+of value in the next block? The only thing a miner supposed to do to get a =
+reward is to produce Hashcash proof-of-work, thus providing cryptographic s=
+ecurity guarantees for the whole Bitcoin blockchain. What if including our =
+transaction in a block would reduce effort requirements for the miner produ=
+ce valid block?<br><br>We could do so by extending the concept of proof-of-=
+work, in such a way that we do not sacrifice security at all. Here are both=
+ descriptions proof-of-work as-is and to-be:<br><br>Standart proof-of-work:=
+ hash(previous block hash + current block target + current block metadata +=
+ current block transactions) &lt; target<br><br>Decentralized proof-of-work=
+: hash(previous block hash + current block target + current block metadata =
++ current block transactions) - sum( FFFF - hash( previous block hash + raw=
+_tx ) ) &lt; target<br><br>It is possible to imagine completely mining agno=
+stic proof-of-work, for example, the following PoW would do:<br><br>Distrib=
+uted (mining-agnostic) proof-of-work: sum( FFFF - hash( previous block hash=
+ + current block target + current block metadata + signed_tx ) ) &lt; targe=
+t<br><br>Described protocol change could be implemented as user activated s=
+oft-fork (described in BIP148), introducing new blocks with the modified pr=
+oof-of-work concept.<br><b><br>Economic reasoning</b><br><br>An adversary w=
+hose goal is to prevent the network from transferring value will have to co=
+mpete with good users hash rate using same equipment good miners will use. =
+And it&#39;s far more complicated than competing with others using the mone=
+y to pay transaction fees.<br><br>In order to investigate probable conseque=
+nces of protocol upgrade and stability of implied economical equilibrium, w=
+e need an adequate game theoretical model. Such model and numerical simulat=
+ion results should be obtained and studied before any protocol change could=
+ be considered by the community.<br><br>To me it seems like a win-win solut=
+ion for everyone owning BTC:<br><br>Miners benefit: as the result DDoS atta=
+ck will be stopped, Bitcoin becomes perfect store-of-value finally. Politic=
+al decentralization of hash rate will be incentivized as mining equipment b=
+ecomes relevant to every user.<br>Users benefit: miners will have direct in=
+centives to include transactions deemed important by their sender and suppo=
+rted by some amount of proof-of-work.</div><div><br></div><div>Sincerely yo=
+urs, Ilya Eriklintsev.</div></div></div>
+
+--001a113fb680e3d4bc0552755d5c--
+