From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8E0259C for ; Thu, 22 Jun 2017 12:02:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 75530198 for ; Thu, 22 Jun 2017 12:02:47 +0000 (UTC) Received: by mail-it0-f52.google.com with SMTP id m47so48933376iti.1 for ; Thu, 22 Jun 2017 05:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YJMDNfkvzk8s6TXmGB/Xi5AoqLwEjMM7ig5tS52gFMc=; b=bkLK6XhxB5sKWXQvNIGhSmc5LDqjiEdroUw0U+VU2KvJ0i5X2ogQh6k6UZ9vw7cJR6 3xgAOjJyp7aRaC2ZcZsQbVMJaiv8SQS+Ml8k0jcenyLaop9Nvz8vlCsTTghH6FpfNg2O sVr7QNHij34OhIUVmb5dmoYcaln23ZDcA8WmHXRVnFLQ+8SaVO9OrlJj3/hp1yLGCdx2 1curuld3GCdhiR4nklRQsdQT4kJxEMVpFw0B5Hugv3Ml9G2Qsxr1JH/pjnbKduOGin1E zLOsNg8TSXXl1EE1GrlxQYgtnG5RkXSU0AWz44YKHJQpIc9Rd3bOo5+wKaiFWW8kxMK0 6jFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YJMDNfkvzk8s6TXmGB/Xi5AoqLwEjMM7ig5tS52gFMc=; b=i3EZPNHVHU4bOR52F74+8Ffp2y2dnR9QscQLj+vwpAWvtOyti4Gacef300fapAV7mP Tm8nacEaZlGSQRBc4TeuiEawNxR+QdCVrMukzSb9EvJh03g4WWfdxVTfS8yp8sZzClqu wLcAQIlZ4iB00REndBpAMWRLAXBbeCt2E+1OczIiyH5qd93i1KTLIECaB/ddIJTZ0f2J sz4GLiylaD7NARo2m2P7n7/JTkmT5hb2OPdFqd4cKjmHcbk5MQvUMoV+XWFjbLCJQdNk 5t1oyYuNAk27d0eAkoTIrHKRg2dySVKyMHlqWibDBSK+HyJ62l38xh5Qf7UWC7hPiAT8 2ytw== X-Gm-Message-State: AKS2vOzlk+B1Rp9W2POnE8MTMrLWN6qBAKhgPeqjZyapqcwcnt4cNPk3 +8qb6RJ45+c94AFCpExVzFOKHckEzA== X-Received: by 10.36.82.11 with SMTP id d11mr1441004itb.43.1498132966660; Thu, 22 Jun 2017 05:02:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.47.94 with HTTP; Thu, 22 Jun 2017 05:02:45 -0700 (PDT) In-Reply-To: References: From: Conrad Burchert Date: Thu, 22 Jun 2017 14:02:45 +0200 Message-ID: To: Ilya Eriklintsev Content-Type: multipart/alternative; boundary="001a11448a1a4de0ac05528b433f" 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: Thu, 22 Jun 2017 12:41:28 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org 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 12:02:48 -0000 --001a11448a1a4de0ac05528b433f Content-Type: text/plain; charset="UTF-8" As soon as there is competition for block space, people will likely outsource creating the proof of work on the transaction to "transaction miners". This would likely result in giving a fee to those transaction miners. If those are the same miners as those mining the block, we are back at the current system. Put in other words: We are already doing this, you are paying the miner for a piece of the proof of work of the block. If you want to mine instead of paying, just mine a block and use a part of the block reward to pay the fee for another transaction. This also does not work to prevent spam. Instead of paying the transaction fee you can just pay someone to mine proof-of-work on your spam transactions, resulting in roughly the same cost. There is no reason a normal user would be better in doing this than a spammer, likely it is the other way around as the spammer is a more reliable customer for a miner. 2017-06-21 11:55 GMT+02:00 Ilya Eriklintsev via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > 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. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a11448a1a4de0ac05528b433f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As soon as there is competition for block space, people wi= ll likely outsource creating the proof of work on the transaction to "= transaction miners". This would likely result in giving a fee to those= transaction miners. If those are the same miners as those mining the block= , we are back at the current system.

Put in other words:= We are already doing this, you are paying the miner for a piece of the pro= of of work of the block. If you want to mine instead of paying, just mine a= block and use a part of the block reward to pay the fee for another transa= ction.

This also does not work to prevent spam. In= stead of paying the transaction fee you can just pay someone to mine proof-= of-work on your spam transactions, resulting in roughly the same cost. Ther= e is no reason a normal user would be better in doing this than a spammer, = likely it is the other way around as the spammer is a more reliable custome= r for a miner.

2017-06-21 11:55 GMT+02:00 Ilya Eriklintsev via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>:
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 f= or longread=C2=A0below and thank you for your time.

Decent= ralized proof-of-work and DDoS resistance for Bitcoin

Abstrac= t

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 trans= actions could be hardened with the same proof-of-work algorithm thus incent= ivising all the miners to include that particular transaction. Such mechani= sm will effectively give a handicap to every miner who includes "mined= " transaction into next block, increasing probability of him getting b= lock reward.

Problems and motivation

This document wil= l address the issue of a continuous DDoS attack targeting the Bitcoin netwo= rk, e.g. full nodes mempools constantly being overflowed with transactions = carrying small value reduce system primary ability to transfer value (and h= ence making it perfect store of value). Valid transactions are cheap to cre= ate (in the sense of computational effort required) and no adequate mechani= sm exist to make transaction total value increase probably of its confirmat= ion by the network.

Currently, miners decide which transactions to i= nclude in blocks because it's them who are securing Bitcoin network pro= viding 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 sto= rage which grows linearly with the transaction size (blockchain size as wel= l). 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) t= o determine appropriate fees, but that is obviously not the case, in the cu= rrent bitcoin network operating in full block capacity mode. This fee marke= t deviates significantly from a free market premise (also attempts being ma= de to make it closer, e.g. in BIP125 where Replace-By-Fee signaling is supp= osed to help in replacing "stuck" transactions with noncompetitiv= e fee).

Currently, bitcoin network is susceptible to the DDoS attack= of a kind. Adversary creating and translating into the network a lot of tr= ansactions carrying small value (e.g. only miners fee), will be able to imp= air 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 secur= ity for the network and new blocks will consist of transaction transferring= negligible value. It's a major drawback because the cost of such attac= k doesn't grow asymmetrically with the cost of BTC asset.

Pro= posed solution

So how do we incentivize all miners to include ou= r transaction carrying a lot of value in the next block? The only thing a m= iner supposed to do to get a reward is to produce Hashcash proof-of-work, t= hus providing cryptographic security guarantees for the whole Bitcoin block= chain. What if including our transaction in a block would reduce effort req= uirements for the miner produce valid block?

We could do so by exten= ding the concept of proof-of-work, in such a way that we do not sacrifice s= ecurity at all. Here are both descriptions proof-of-work as-is and to-be:
Standart proof-of-work: hash(previous block hash + current block targ= et + current block metadata + current block transactions) < target
Decentralized proof-of-work: hash(previous block hash + current block tar= get + current block metadata + current block transactions) - sum( FFFF - ha= sh( previous block hash + raw_tx ) ) < target

It is possible to i= magine completely mining agnostic proof-of-work, for example, the following= PoW would do:

Distributed (mining-agnostic) proof-of-work: sum( FFF= F - hash( previous block hash + current block target + current block metada= ta + signed_tx ) ) < target

Described protocol change could be im= plemented as user activated soft-fork (described in BIP148), introducing ne= w blocks with the modified proof-of-work concept.

Economic reason= ing

An adversary whose goal is to prevent the network from trans= ferring value will have to compete with good users hash rate using same equ= ipment good miners will use. And it's far more complicated than competi= ng with others using the money to pay transaction fees.

In order to = investigate probable consequences of protocol upgrade and stability of impl= ied economical equilibrium, we need an adequate game theoretical model. Suc= h model and numerical simulation results should be obtained and studied bef= ore any protocol change could be considered by the community.

To me = it seems like a win-win solution for everyone owning BTC:

Miners ben= efit: as the result DDoS attack will be stopped, Bitcoin becomes perfect st= ore-of-value finally. Political decentralization of hash rate will be incen= tivized as mining equipment becomes relevant to every user.
Users benefi= t: miners will have direct incentives to include transactions deemed import= ant by their sender and supported by some amount of proof-of-work.

Sincerely yours, Ilya Eriklintsev.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--001a11448a1a4de0ac05528b433f--