Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 36AB571F for ; 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 ; 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 To: Ilya Eriklintsev , "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 Date: Thu, 22 Jun 2017 13:47:14 +0000 Message-ID: References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 on behalf of Ilya Eriklintsev via bitcoin-dev 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

Hi Ilya,


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


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


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.


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.


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. Here is a link: https://lists.linuxfoundation.o= rg/pipermail/bitcoin-discuss/2017-January/000123.html


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.


Regards,

John Hardy
john@seebitcoin.com

From: bitcoin-dev-bounces@l= ists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.org&= gt; on behalf of Ilya Eriklintsev via bitcoin-dev <bitcoin-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-of-work
 
Hello everyone,

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 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 the miners to include that particular tra= nsaction. Such mechanism will effectively give a handicap to every miner wh= o includes "mined" transaction into next block, increasing probab= ility 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 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.

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.

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" transactions 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 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.

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 our transaction in a block would red= uce effort requirements for the miner produce 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= + current block metadata + current block transactions) < target=

Decentralized proof-of-work: hash(previous block hash + current block t= arget + 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 + signe= d_tx ) ) < target

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