diff options
author | Ilya Eriklintsev <erik.lite@gmail.com> | 2017-06-21 12:55:22 +0300 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-06-21 09:55:25 +0000 |
commit | a6c4d4dffbc9bab2f5067dfa6b013658c90f37f0 (patch) | |
tree | 5afa007832bc9079d39fba5b533398cd8b745fd3 | |
parent | 916b15437baaf239a3abf6068de562a8514545aa (diff) | |
download | pi-bitcoindev-a6c4d4dffbc9bab2f5067dfa6b013658c90f37f0.tar.gz pi-bitcoindev-a6c4d4dffbc9bab2f5067dfa6b013658c90f37f0.zip |
[bitcoin-dev] BIP Idea : DDoS resistance via decentrilized proof-of-work
-rw-r--r-- | d6/441900c1054e2bd71287b70ca3b2815fdd9e10 | 263 |
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 "mined" 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" 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's a= + major drawback because the cost of such attack doesn'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) < 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 ) ) < 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 ) ) < 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'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-- + |