path: root/d6/441900c1054e2bd71287b70ca3b2815fdd9e10

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--