path: root/ae/a654eb5463af2a35231e4a974ac382cbd574cd

Return-Path: <outlook_32F81FD1D1BD8CA0@outlook.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 36AB571F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 22 Jun 2017 13:47:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from NAM03-BY2-obe.outbound.protection.outlook.com
	(mail-oln040092006021.outbound.protection.outlook.com [40.92.6.21])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C595CE5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 22 Jun 2017 13:47:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
	s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; 
	bh=UQ4Bz4ET7mW+EUaS3fV6TIL6lBFn9XBA2cmcOtmFhAg=;
	b=PkDQiEiRc21iKjzbe3iOkh1ko4bVPC6iZavnxyZQzWYZNDsVlHLq0ZYMdzRllfcXNXCN7bXwoi86st7DbKRpcchSk5STDO4zzUElHh4F0UjzPwHymCMX3MJNQRP2lHRHI/fj494PLjQ+ZnsTcSJniGmZ4n1SWyx4h6Z5wcP5+LamXnX4T6+ig4msV3+jdpLVtXOWLKK/6Wur+aWYydAsm+uMqXZlwVyDABRvo0+J58yoGXQrwp4Lx0dhMmve0d7V0EJGzAoRoCr/XDv72Zn63iYEHNdDAEfjqtPYEdJsHhD+fr4lLCCXLbSaTsAjdfLGS2069Szf5cmdvhCsVVWUpA==
Received: from CO1NAM03FT041.eop-NAM03.prod.protection.outlook.com
	(10.152.80.59) by CO1NAM03HT039.eop-NAM03.prod.protection.outlook.com
	(10.152.81.45) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1199.9;
	Thu, 22 Jun 2017 13:47:16 +0000
Received: from BLUPR0301MB2002.namprd03.prod.outlook.com (10.152.80.58) by
	CO1NAM03FT041.mail.protection.outlook.com (10.152.81.163) with
	Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id
	15.1.1199.9 via Frontend Transport; Thu, 22 Jun 2017 13:47:16 +0000
Received: from BLUPR0301MB2002.namprd03.prod.outlook.com ([10.164.22.16]) by
	BLUPR0301MB2002.namprd03.prod.outlook.com ([10.164.22.16]) with mapi id
	15.01.1199.016; Thu, 22 Jun 2017 13:47:15 +0000
From: John Hardy <john@seebitcoin.com>
To: Ilya Eriklintsev <erik.lite@gmail.com>,
	"bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] BIP Idea : DDoS resistance via decentrilized
	proof-of-work
Thread-Index: AQHS6nrKOpsmmp32IUi4svgYWRignaIw3K/I
Sender: John Hardy <outlook_32F81FD1D1BD8CA0@outlook.com>
Date: Thu, 22 Jun 2017 13:47:14 +0000
Message-ID: <BLUPR0301MB2002AAC764B140C4DE74768DEEDB0@BLUPR0301MB2002.namprd03.prod.outlook.com>
References: <CA+Yhp0Uv3zrg28G7QcgXPSv4Md9j2U-=SROJqWAOqvW_tCu=bQ@mail.gmail.com>
In-Reply-To: <CA+Yhp0Uv3zrg28G7QcgXPSv4Md9j2U-=SROJqWAOqvW_tCu=bQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed)
	header.d=none; gmail.com;
	dmarc=none action=none header.from=seebitcoin.com; 
x-incomingtopheadermarker: OriginalChecksum:7CAFD6F8E1F2278BAD1B0C648E3314AD02820B400BCE8332B3C39369FB9FB4B6;
	UpperCasedChecksum:B10C126CEDCC6CC2A8EFC70BDFDC5EA148132F3EE12FB37485C0E16D57CFEA49;
	SizeAsReceived:7436; Count:46
x-ms-exchange-messagesentrepresentingtype: 2
x-tmn: [CsSOpRqO9qEVc0OCPk8VTNsmjIVmUub1]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO1NAM03HT039;
	7:4Ili3FL3WY4EIklvvxKq3POEofijNwRMP9P0HiADS5pPwfTST2bQY7NmwVTYZNc/TieqNSuo0GsJhKoqCePmPCegLu08YYrEWqWj6Wiux54oiXaiKq7LFuYadwb+PNbYKWvZBaznDGrhBP5mVsippJfEvZVdGIMMTHPyRNlyFyDjuOOK0MRxnlHg/eC4UoeF6DegWMmpbdWjxVjNkO+3ky133ra0jKt1wMJpld41F2bwgrg4WMsrfeW+l1xAOpAIEv6Qn7zWikSkigb+e/5gAFD3FMtbJfaHKuS2wXbLoyWtyVTQ1BysMVpVqAj0bHQBeIo8n6LH0A6WxIDLYjHJZTCODeEe5NSWAaFkxFiTd7Euro53N4Yis/RO7mWjO0rx05V/WboU4ENSArmVBPGrw73b6hudWoFRcDV6aV8Kevvo4fGJU08fA4sc6/jkChJf2eT+0IJscFGzQkB6svptPt+cxCNZzVX5ISKd00XHopo3zjHo3reQz2OBqf1RYkHeYAwAIwEzTO5v2+m/a4ajCpu5Is6/4a8OsAVCMwLvc6fIclU+fLlLBYAfftnhhxN2IrjyDOwRuzw7woIF2asXX+IzDHHQ8wkU+uEp85sE/O8c2C56c/GPoqAShUBo2cGG94+ASlhGFJDDtfDsOtjr9Qhgeur3aU/3LYqIuMqmJf1GqgzVBOpqDdaOWOck3xIvCxi5/VPxqwZVQf1SozvHAMtssOf5ImpuCjm/lQcpYJRKAZohUO6gSYSKmjkNwlTl/ZNutysIWJjV7zjgSjx8Vg==
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004);
	DIR:OUT; SFP:1901; SCL:1; SRVR:CO1NAM03HT039;
	H:BLUPR0301MB2002.namprd03.prod.outlook.com; FPR:; SPF:None;
	LANG:en; 
x-ms-office365-filtering-correlation-id: 11425952-425c-46ff-9992-08d4b9753127
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(300000502055)(300135100095)(22001)(300000503055)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095);
	SRVR:CO1NAM03HT039; 
x-ms-traffictypediagnostic: CO1NAM03HT039:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
	RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031);
	SRVR:CO1NAM03HT039; BCL:0; PCL:0;
	RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);
	SRVR:CO1NAM03HT039; 
x-forefront-prvs: 03468CBA43
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BLUPR0301MB2002AAC764B140C4DE74768DEEDB0BLUPR0301MB2002_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 13:47:14.7448 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM03HT039
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 22 Jun 2017 14:22:20 +0000
Subject: Re: [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: Thu, 22 Jun 2017 13:47:19 -0000

--_000_BLUPR0301MB2002AAC764B140C4DE74768DEEDB0BLUPR0301MB2002_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Ilya,


This proposal wouldn't work because bad actors can perform PoW just as chea=
ply as any other participant.


The transaction fee already acts as a mechanism to prevent spam. It is not =
a problem to have a lot of low value transactions in the mempool as thresho=
lds can easily be set for them to be disregarded/expire - a 300MB  maxmempo=
ol size by default eliminates any real 'DDOS' risk. Spam only really become=
s an issue when it enters the blockchain. If a spammer is willing to pay th=
e tx fee to spam, they'd be willing to pay the PoW.


The only actors who can spam the blockchain at zero cost are the miners the=
mselves (beyond the opportunity cost of including genuine fee paying transa=
ctions). They can even do it without their transactions ever hitting the me=
mpool or including a fee, though this behaviour would be easy to spot.


If miners are colluding to spam the mempool or blocks in order to increase =
the average transaction cost overall there is little that can be done as th=
e network relies on 51% of hashpower being honest. A miner creating spam tr=
ansactions that enter the mempool has the risk that another miner would inc=
lude it in a block and they would incur an economic cost if this happened.


I had an idea for a dynamic blocksize that required miners to pay a percent=
age of the transaction fees to the next mined block. Here is a link: https:=
//lists.linuxfoundation.org/pipermail/bitcoin-discuss/2017-January/000123.h=
tml


If it was established that miners spamming blocks with transactions was an =
issue, this could be used as a disincentive as it means the cost for doing =
so becomes non-zero.


Regards,

John Hardy
john@seebitcoin.com

________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@li=
sts.linuxfoundation.org> on behalf of Ilya Eriklintsev via bitcoin-dev <bit=
coin-dev@lists.linuxfoundation.org>
Sent: Wednesday, June 21, 2017 9:55 AM
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] BIP Idea : DDoS resistance via decentrilized proof-o=
f-work

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 Bitco=
in network more secure, decentralized and DDoS resistant. The idea is to mo=
dify 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 t=
he miners to include that particular transaction. Such mechanism will effec=
tively 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 w=
ith transactions carrying small value reduce system primary ability to tran=
sfer 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 certificat=
es stored inside every block header. Miners have to store the whole blockch=
ain 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 ban=
dwidth 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 t=
o use is setting of transaction fee, that is going directly to the miner. T=
his solution probably was intended to utilize free market (as implied by Sa=
toshi introducing sequence numbers) to determine appropriate fees, but that=
 is obviously not the case, in the current bitcoin network operating in ful=
l block capacity mode. This fee market deviates significantly from a free m=
arket premise (also attempts being made to make it closer, e.g. in BIP125 w=
here Replace-By-Fee signaling is supposed to help in replacing "stuck" tran=
sactions with noncompetitive fee).

Currently, bitcoin network is susceptible to the DDoS attack of a kind. Adv=
ersary creating and translating into the network a lot of transactions carr=
ying 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 net=
work and new blocks will consist of transaction transferring negligible val=
ue. It's a major drawback because the cost of such attack doesn't grow asym=
metrically with the cost of BTC asset.

Proposed solution

So how do we incentivize all miners to include our transaction carrying a l=
ot 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 cryptographi=
c security guarantees for the whole Bitcoin blockchain. What if including o=
ur transaction in a block would reduce effort requirements for the miner pr=
oduce valid block?

We could do so by extending the concept of proof-of-work, in such a way tha=
t 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 + c=
urrent block metadata + current block transactions) < target

Decentralized proof-of-work: hash(previous block hash + current block targe=
t + 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 exa=
mple, the following PoW would do:

Distributed (mining-agnostic) proof-of-work: sum( FFFF - hash( previous blo=
ck hash + current block target + current block metadata + signed_tx ) ) < t=
arget

Described protocol change could be implemented as user activated soft-fork =
(described in BIP148), introducing new blocks with the modified proof-of-wo=
rk concept.

Economic reasoning

An adversary whose goal is to prevent the network from transferring value w=
ill have to compete with good users hash rate using same equipment good min=
ers will use. And it's far more complicated than competing with others usin=
g the money to pay transaction fees.

In order to investigate probable consequences of protocol upgrade and stabi=
lity of implied economical equilibrium, we need an adequate game theoretica=
l 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 wil=
l be incentivized as mining equipment becomes relevant to every user.
Users benefit: miners will have direct incentives to include transactions d=
eemed important by their sender and supported by some amount of proof-of-wo=
rk.

Sincerely yours, Ilya Eriklintsev.

--_000_BLUPR0301MB2002AAC764B140C4DE74768DEEDB0BLUPR0301MB2002_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p>Hi Ilya,</p>
<p><br>
</p>
<p>This proposal wouldn't work because bad actors can perform PoW just as c=
heaply as any other participant.</p>
<p><br>
</p>
<p>The transaction fee already acts as a mechanism to prevent spam. It is n=
ot a problem to have a lot of low value transactions in the mempool as thre=
sholds can easily be set for them to be disregarded/expire - a 300MB &nbsp;=
maxmempool size by default eliminates
 any real 'DDOS' risk. Spam only really becomes an issue when it enters the=
 blockchain. If a spammer is willing to pay the tx fee to spam, they'd be w=
illing to pay the PoW.</p>
<p><br>
</p>
<p>The only actors who can spam the blockchain at zero cost are the miners =
themselves (beyond the opportunity cost of including genuine fee paying tra=
nsactions). They can even do it without their transactions ever hitting the=
 mempool or including a fee, though
 this behaviour would be easy to spot.</p>
<p><br>
</p>
<p>If miners are colluding to spam the mempool or blocks in order to increa=
se the average transaction cost overall there is little that can be done as=
 the network relies on 51% of hashpower being honest. A miner creating spam=
 transactions that enter the mempool
 has the risk that another miner would include it in a block and they would=
 incur an economic cost if this happened.</p>
<p><br>
</p>
<p>I had an idea for a dynamic blocksize that required miners to pay a perc=
entage of the transaction fees to the next mined block.
<span style=3D"font-family: Calibri, Helvetica, sans-serif, EmojiFont, &quo=
t;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, NotoColorEmoji, &quo=
t;Segoe UI Symbol&quot;, &quot;Android Emoji&quot;, EmojiSymbols; font-size=
: 16px;">
Here is a link:&nbsp;</span><a href=3D"https://lists.linuxfoundation.org/pi=
permail/bitcoin-discuss/2017-January/000123.html" class=3D"OWAAutoLink" id=
=3D"LPlnk778968" style=3D"font-family: Calibri, Helvetica, sans-serif, Emoj=
iFont, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, NotoColor=
Emoji, &quot;Segoe UI Symbol&quot;, &quot;Android Emoji&quot;, EmojiSymbols=
; font-size: 16px;" previewremoved=3D"true">https://lists.linuxfoundation.o=
rg/pipermail/bitcoin-discuss/2017-January/000123.html</a></p>
<p><br>
</p>
<p>If it was established that miners spamming blocks with transactions was =
an issue, this could be used as a disincentive as it means the cost for doi=
ng so becomes non-zero.</p>
<p><br>
</p>
Regards,
<div><br>
</div>
<div>John Hardy</div>
<div>john@seebitcoin.com</div>
<div><br>
<div style=3D"color: rgb(0, 0, 0);">
<hr style=3D"display:inline-block; width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co=
lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> bitcoin-dev-bounces@l=
ists.linuxfoundation.org &lt;bitcoin-dev-bounces@lists.linuxfoundation.org&=
gt; on behalf of Ilya Eriklintsev via bitcoin-dev
 &lt;bitcoin-dev@lists.linuxfoundation.org&gt;<br>
<b>Sent:</b> Wednesday, June 21, 2017 9:55 AM<br>
<b>To:</b> bitcoin-dev@lists.linuxfoundation.org<br>
<b>Subject:</b> [bitcoin-dev] BIP Idea : DDoS resistance via decentrilized =
proof-of-work</font>
<div>&nbsp;</div>
</div>
<div>
<div dir=3D"ltr"><span style=3D"font-size:12.8px">Hello everyone,</span>
<div style=3D"font-size:12.8px"><br>
<div>recently I have got an idea that in my opinion will improve bitcoin ne=
twork, making it better store-of-value for growing cyberspace and cryptoeco=
nomy. Sorry for longread&nbsp;below and thank you for your time.
<div><br>
</div>
<b>Decentralized proof-of-work and DDoS resistance for Bitcoin</b><br>
<br>
<b>Abstract</b><br>
<br>
By introducing some new block validation rules it is possible to make Bitco=
in network more secure, decentralized and DDoS resistant. The idea is to mo=
dify 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 tra=
nsaction. Such mechanism will effectively give a handicap to every miner wh=
o includes &quot;mined&quot; transaction into next block, increasing probab=
ility of him getting block reward.<br>
<br>
<b>Problems and motivation</b><br>
<br>
This document will address the issue of a continuous DDoS attack targeting =
the Bitcoin network, e.g. full nodes mempools constantly being overflowed w=
ith transactions carrying small value reduce system primary ability to tran=
sfer value (and hence making it
 perfect store of value). Valid transactions are cheap to create (in the se=
nse of computational effort required) and no adequate mechanism exist to ma=
ke transaction total value increase probably of its confirmation by the net=
work.<br>
<br>
Currently, miners decide which transactions to include in blocks because it=
's them who are securing Bitcoin network providing proof-of-work certificat=
es stored inside every block header. Miners have to store the whole blockch=
ain at all times, so one of the
 costs is storage which grows linearly with the transaction size (blockchai=
n size as well). Another cost is network bandwidth which depends directly o=
n the size of data to be communicated over.<br>
<br>
The only incentive a person who wants to transfer his bitcoins is allowed t=
o use is setting of transaction fee, that is going directly to the miner. T=
his solution probably was intended to utilize free market (as implied by Sa=
toshi 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 mar=
ket 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, bitcoin network is susceptible to the DDoS attack of a kind. Adv=
ersary creating and translating into the network a lot of transactions carr=
ying 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 con=
tinue to work providing security for the network and new blocks will consis=
t of transaction transferring negligible value. It's a major drawback becau=
se the cost of such attack doesn't
 grow asymmetrically 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 l=
ot 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 cryptographi=
c security guarantees for the whole
 Bitcoin blockchain. What if including our transaction in a block would red=
uce effort requirements for the miner produce valid block?<br>
<br>
We could do so by extending the concept of proof-of-work, in such a way tha=
t 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 &#43; current block target=
 &#43; current block metadata &#43; current block transactions) &lt; target=
<br>
<br>
Decentralized proof-of-work: hash(previous block hash &#43; current block t=
arget &#43; current block metadata &#43; current block transactions) - sum(=
 FFFF - hash( previous block hash &#43; raw_tx ) ) &lt; target<br>
<br>
It is possible to imagine completely mining agnostic proof-of-work, for exa=
mple, the following PoW would do:<br>
<br>
Distributed (mining-agnostic) proof-of-work: sum( FFFF - hash( previous blo=
ck hash &#43; current block target &#43; current block metadata &#43; signe=
d_tx ) ) &lt; target<br>
<br>
Described protocol change could be implemented as user activated soft-fork =
(described in BIP148), introducing new blocks with the modified proof-of-wo=
rk concept.<br>
<b><br>
Economic reasoning</b><br>
<br>
An adversary whose goal is to prevent the network from transferring value w=
ill have to compete with good users hash rate using same equipment good min=
ers will use. And it's far more complicated than competing with others usin=
g the money to pay transaction fees.<br>
<br>
In order to investigate probable consequences of protocol upgrade and stabi=
lity of implied economical equilibrium, we need an adequate game theoretica=
l model. Such model and numerical simulation 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 solution for everyone owning BTC:<br>
<br>
Miners benefit: as the result DDoS attack will be stopped, Bitcoin becomes =
perfect store-of-value finally. Political decentralization of hash rate wil=
l be incentivized as mining equipment becomes relevant to every user.<br>
Users benefit: miners will have direct incentives to include transactions d=
eemed important by their sender and supported by some amount of proof-of-wo=
rk.</div>
<div><br>
</div>
<div>Sincerely yours, Ilya Eriklintsev.</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_BLUPR0301MB2002AAC764B140C4DE74768DEEDB0BLUPR0301MB2002_--