Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C5BE3825 for ; Sat, 15 Sep 2018 22:46:00 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255058.outbound.protection.outlook.com [40.92.255.58]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C9288102 for ; Sat, 15 Sep 2018 22:45:58 +0000 (UTC) Received: from HK2APC01FT106.eop-APC01.prod.protection.outlook.com (10.152.248.60) by HK2APC01HT009.eop-APC01.prod.protection.outlook.com (10.152.248.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1164.13; Sat, 15 Sep 2018 22:45:55 +0000 Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.248.55) by HK2APC01FT106.mail.protection.outlook.com (10.152.249.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1164.13 via Frontend Transport; Sat, 15 Sep 2018 22:45:55 +0000 Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([fe80::3d19:7b68:daee:a1fd]) by PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([fe80::3d19:7b68:daee:a1fd%11]) with mapi id 15.20.1143.017; Sat, 15 Sep 2018 22:45:55 +0000 From: Damian Williamson To: Andrew Thread-Topic: [bitcoin-dev] Selfish Mining Prevention Thread-Index: AQHUQ929vUuYMRqqE0yCtZaZqwUgr6Tu6L6AgAH4Q9aAALHxgIAAbXCQ Date: Sat, 15 Sep 2018 22:45:55 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:7493FE2F42043C2CD11E5DDF4E8BC50873758119FE80B682829E70D69F23CB02; UpperCasedChecksum:B4CD3C3DFD58767759329B8426BDD377C6F3E32CE893E91621F73935A501ECAB; SizeAsReceived:7368; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [papEjPHlJVI+wsXKEXsgB/bX/EX/aJN6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HK2APC01HT009; 6:+vmRuP+5E02aEzYw2KUezPC8xSR7GGGJpC1ZKSdUKJtKljLGeaMGMLbDSFiXuRE4PaLXx9r7Wiwlh93gjVJvFkyO76xMOCUmZh8NmdXVhOQjk6qHh0FxsLBJWtRUbIaobwHhTz6RxBgln+qchiQ6+3SPsokOOq6qsaJgWIYHfZDw+RnAuDm9IKSpopHwKbt2qYxSKVvCivzDFGyqHJhRzMsiSUdIkG4KcKvrtPXyqBEBAVc4rzO3+KBO3ClZaeBXRSfGjI2+rvjujP3bFPtTqxNk7EcUm+Qx/X+WiC7AGi+PY2Oi4dcPXXoKhTfq7XpHA8c7gse63yPwosF/w6Ri30v18zPdwfjRip1JjWawqM0WmuuYdMq1VZaFyVc9iLxpP72FTAyV5wmKapLPFLpJB/zLKYCHIWKYYM5FN+HPVv2QwJxAjIZsBfMF0opfJJ79ht9+FX1VOjAV9WPiCec8bg==; 5:JFxfArMeoi8ORtp5IQ5XrdKZODBaQZFS4z7oXGKncgwA1CeosA25QDU9pBX7SjiI+Ni8XBtK/njZoVybUASpcqJgLmdfo+Plc8aULN1KCNgT4lZ18AoTwx0oRDzshpV7H3qLcodM3meONAcNwhshNA/dl0xgWw5JyZx6tz7qYlI=; 7:4EKmtOPiP0H2ldAD7L0TnLU7p66rm4KlDVQR2FjAErhIYfZJcsKbqI7nADafQNGfjw+2j09WMlWeYQUOg4EneJzIALNfvBDG8++3IbYHTyO1lf0UcQtF5z5oKXcDa6Shy5WDEBi4JXT0qBGCdadXw+D1eovpHL3oQtTTaCrxxZZdQsl1IVtV5J63TDYAnq80/YOf+70gP+oA634BpQzHopiWssJvwqiz5XT8icKNvGi3JDYpmMGp3VANtFaSuGkO x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:HK2APC01HT009; x-ms-traffictypediagnostic: HK2APC01HT009: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:HK2APC01HT009; BCL:0; PCL:0; RULEID:; SRVR:HK2APC01HT009; x-forefront-prvs: 0796EBEDE1 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(4326008)(86362001)(6346003)(26005)(14454004)(74482002)(606006)(6916009)(16799955002)(6606003)(1411001)(68736007)(6246003)(551934003)(74316002)(19627405001)(33656002)(561944003)(104016004)(102836004)(66574006)(56003)(82202002)(14444005)(256004)(5250100002)(97736004)(39060400002)(6506007)(53546011)(347745004)(25786009)(8676002)(106356001)(966005)(11346002)(446003)(6436002)(7696005)(99286004)(81156014)(93886005)(8936002)(2900100001)(476003)(5660300001)(105586002)(486006)(229853002)(236005)(9686003)(6306002)(76176011)(55016002)(54896002); DIR:OUT; SFP:1901; SCL:1; SRVR:HK2APC01HT009; H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: live.com.au does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=willtech@live.com.au; x-microsoft-antispam-message-info: 0RUq1J1MYwrfq7TQEcIm2whWPbE/FaEEsfreKllUeRNWzm3SgEAhWJqejIqBRByBcqZVdKGcRlFUWV9DSGbatkUcMDJCXxSAWH+EQInzF8/1TbRFqOQ02pFJk16w1gxUlwgKZn03ViqbZZ1YExAV2tMt6TrQdUfiUO1rmcB3AlqQMiqZQ8b4bpZovFYRo2PUqYO01D8cQDKedRH+16mkmwOa+ezfSrjMANpRKDo8m3M= Content-Type: multipart/alternative; boundary="_000_PS2P216MB0179A4E6401D831166E749089D180PS2P216MB0179KORP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-Network-Message-Id: 6d4f4dd6-05a4-4de7-03a4-08d61b5cff8f X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2018 22:45:55.4865 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT009 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Sun, 16 Sep 2018 22:55:03 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Selfish Mining Prevention 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: Sat, 15 Sep 2018 22:46:00 -0000 --_000_PS2P216MB0179A4E6401D831166E749089D180PS2P216MB0179KORP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see what you say, however, since the proposal as I have read it says "And= this will keep happening as long as hashrate keeps rising," - what actuall= y happens in the case hashrate stagnates or falls? I would prefer to see (not only with your proposal) greater bias toward has= hrate being exponentially more uneconomical the more it rises to stifle gre= ed. The current level of mining already greatly exceeds that necessary for = the stability of the network and far lower hashrates are completely accepti= ble provided the network is protected from large switch-ons, which I say is= achievable. I do have other thoughts to approach greed that I have not yet made formal = on this list, much unrelated to your proposal, but, I see freedom of use of= Bitcoin needing to be censorship resistant but not necessarily mining prov= ided it is protected enough or free or flexible enough to allow for, say, 5= 0k globally distributed standard mining hardware units to exist operating a= t any one time profitably. That said, I am PoW only and not PoS orientated. ________________________________ From: akaramaoun@gmail.com on behalf of Andrew Sent: Sunday, 16 September 2018 2:01:19 AM To: Damian Williamson Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Selfish Mining Prevention @Moral Agent: No problem. I did ask in the first post what the current plans are for selfish miner prevention. So if anyone has any other relevant ideas (not just for selfish mining but for making mining more decentralized and competetive), then please post it, but I just prefer to focus on my proposal more than others. @Damian: I think you are concerned that this will incentivize more global resource consumption and will be detrimental to our environment? Personally, I believe centralization of energy does more harm to the environment rather than total energy consumption. If Bitcoin helps "power" to become more decentralized, then I wouldn't be surprised if total (global) energy consumption actually decreases. The debt based economy is forcing us to continuously grow and use up more resources, and collectivism is turning individuals into super-organisms capable of doing much more harm to the environment than can be done by one or a just a few individuals working independently. In my proposal, I actually allow for changing environmental conditions by measuring only the peak hashrate of the past year, and not the full history of blocks. On Sat, Sep 15, 2018 at 5:29 AM, Damian Williamson w= rote: >>This "reserve" part of the fee will be paid to miners if the hashrate >> rises. > > > Anticipating ongoing hashrate rise shows that you have not yet thought ab= out > moving outside of the current greed model, a model wherein mining will > consume all available resources within the colony's objective just to spr= ead > as far as possible with each new miner bringing diminishing individual > returns and shortening the life of Earth for no additional gain. Greed mo= del > :=3D bacteria. > > ________________________________ > From: bitcoin-dev-bounces@lists.linuxfoundation.org > on behalf of Andrew via > bitcoin-dev > Sent: Friday, 14 September 2018 9:19:37 AM > To: Bitcoin Dev > Subject: Re: [bitcoin-dev] Selfish Mining Prevention > > I discussed this more at bitcointalk: > https://bitcointalk.org/index.php?topic=3D4998410.0 > > The attacks I'm interested in preventing are not only selfish mining > and collusion, but also more subtle attacks like block withholding, > and in general anything that aims to drive out the competition in > order to increase hashrate fraction. I also scrapped the idea of > changing the block subsidies, and I am only focuses on fees. > > You can read more about the motivation and details in the bitcointalk > thread, but my proposal in short would be to add the concept of > "reserve fees". When a user makes a transaction, for each txout > script, they can add parameters that specify the fraction of the total > fee that is held in "reserve" and the time it is held in "reserve" > (can set a limit of 2016 blocks). This "reserve" part of the fee will > be paid to miners if the hashrate rises. So if hashrate is currently h > and peak hashrate (from past year) is p, then for each period (1 day), > a new hashrate is calculated h1, and if h1 > h, then the fraction > (h1-h)/p from the reserve fees created in the past 2016 blocks will be > released to miners for that period (spread out over the 144 blocks in > that period). And this will keep happening as long as hashrate keeps > rising, until the "contract" expires, and the leftover part can be > used by the owner of the unspent output, but it can only be used for > paying fees, not as inputs for future transactions (to save on block > space). > > This should incentivize miners to not drive out the competition, since > if they do, there will be less of these reserve fees given to miners. > Yes in the end the miners will get all the fees, but with rising > hashrate they get an unconditional subsidy that does not require > transactions, thus more space for transactions with fees. > > I can make a formal BIP and pull request, but I need to know if there > is interest in this. Now fees don't play such a large part of the > block reward, but they will get more important, and this change > wouldn't force anything (would be voluntary by each user), just miners > have to agree to it with a soft fork (so they don't spend from the > anyone-can-spend outputs used for reserve fees). Resource requirements > for validation are quite small I believe. > > On Sat, Sep 1, 2018 at 12:11 AM, Andrew wrote: >> As I understand, selfish mining is an attack where miners collude to >> mine at a lower hashrate then with all miners working independently. >> What are the current strategies used to prevent this and what are the >> future plans? >> >> One idea I have is to let the block reward get "modulated" according >> to peak hashrate. Say p is the peak hashrate for 365 periods (1 year) >> consisting of 144 blocks, h is the hashrate of the last 144 block (1 >> day) period, and r is the base subsidy (12.5 BTC currently). You can >> then make the max block reward 0.5 r (1 + h/p). So if hashrate is at >> peak you get the full reward. Otherwise you get less, down to a min of >> 0.5 r. >> >> If miners were to collude to mine at a lower than peak hashrate, then >> they may be able to do it profitably for 144 blocks, but after that, >> the reward would get modulated and it wouldn't be so much in their >> interest to continue mining at the lower hashrate. >> >> What flaws are there with this? I know it could be controversial due >> to easier mining present for early miners, so maybe it would have to >> be done in combination with a new more dynamic difficulty adjustment >> algorithm. But I don't see how hashrate can continue rising >> indefinitely, so a solution should be made for selfish mining. >> >> Also when subsidies stop and a fee market is needed, I guess a portion >> of the fees can be withheld for later if hashrate is not at peak. >> >> >> -- >> PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 > > > > -- > PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 --_000_PS2P216MB0179A4E6401D831166E749089D180PS2P216MB0179KORP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I see what you say, however, sinc= e the proposal as I have read it says "And this will k= eep happening as long as hashrate keeps rising," - what actually happe= ns in the case hashrate stagnates or falls?


I would prefer to see (not only with your proposal) greater= bias toward hashrate being exponentially more uneconomical the more it ris= es to stifle greed. The current level of mining already greatly exceeds that necessary for the stability of the = network and far lower hashrates are completely acceptible provided the netw= ork is protected from large switch-ons, which I say is achievable.


I do have other thoughts to approach greed that I have n= ot yet made formal on this list, much unrelated to your proposal, but, I se= e freedom of use of Bitcoin needing to be censorship resistant but not necessarily mining provided it is protecte= d enough or free or flexible enough to allow for, say, 50k globally distrib= uted standard mining hardware units to exist operating at any one time prof= itably. That said, I am PoW only and not PoS orientated.

From: akaramaoun@gmail.com = <akaramaoun@gmail.com> on behalf of Andrew <onelineproof@gmail.com= >
Sent: Sunday, 16 September 2018 2:01:19 AM
To: Damian Williamson
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Selfish Mining Prevention
 
@Moral Agent: No problem. I did ask in the first p= ost what the current
plans are for selfish miner prevention. So if anyone has any other
relevant ideas (not just for selfish mining but for making mining more
decentralized and competetive), then please post it, but I just prefer
to focus on my proposal more than others.

@Damian: I think you are concerned that this will incentivize more
global resource consumption and will be detrimental to our
environment? Personally, I believe centralization of energy does more
harm to the environment rather than total energy consumption. If
Bitcoin helps "power" to become more decentralized, then I wouldn= 't be
surprised if total (global) energy consumption actually decreases. The
debt based economy is forcing us to continuously grow and use up more
resources, and collectivism is turning individuals into
super-organisms capable of doing much more harm to the environment
than can be done by one or a just a few individuals working
independently. In my proposal, I actually allow for changing
environmental conditions by measuring only the peak hashrate of the
past year, and not the full history of blocks.

On Sat, Sep 15, 2018 at 5:29 AM, Damian Williamson <willtech@live.com.au= > wrote:
>>This "reserve" part of the fee will be paid to miners if = the hashrate
>> rises.
>
>
> Anticipating ongoing hashrate rise shows that you have not yet thought= about
> moving outside of the current greed model, a model wherein mining will=
> consume all available resources within the colony's objective just to = spread
> as far as possible with each new miner bringing diminishing individual=
> returns and shortening the life of Earth for no additional gain. Greed= model
> :=3D bacteria.
>
> ________________________________
> From: bitcoin-dev-bounces@lists.linuxfoundation.org
> <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of And= rew via
> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> Sent: Friday, 14 September 2018 9:19:37 AM
> To: Bitcoin Dev
> Subject: Re: [bitcoin-dev] Selfish Mining Prevention
>
> I discussed this more at bitcointalk:
> https:= //bitcointalk.org/index.php?topic=3D4998410.0
>
> The attacks I'm interested in preventing are not only selfish mining > and collusion, but also more subtle attacks like block withholding, > and in general anything that aims to drive out the competition in
> order to increase hashrate fraction. I also scrapped the idea of
> changing the block subsidies, and I am only focuses on fees.
>
> You can read more about the motivation and details in the bitcointalk<= br> > thread, but my proposal in short would be to add the concept of
> "reserve fees". When a user makes a transaction, for each tx= out
> script, they can add parameters that specify the fraction of the total=
> fee that is held in "reserve" and the time it is held in &qu= ot;reserve"
> (can set a limit of 2016 blocks). This "reserve" part of the= fee will
> be paid to miners if the hashrate rises. So if hashrate is currently h=
> and peak hashrate (from past year) is p, then for each period (1 day),=
> a new hashrate is calculated h1, and if h1 > h, then the fraction > (h1-h)/p from the reserve fees created in the past 2016 blocks will be=
> released to miners for that period (spread out over the 144 blocks in<= br> > that period). And this will keep happening as long as hashrate keeps > rising, until the "contract" expires, and the leftover part = can be
> used by the owner of the unspent output, but it can only be used for > paying fees, not as inputs for future transactions (to save on block > space).
>
> This should incentivize miners to not drive out the competition, since=
> if they do, there will be less of these reserve fees given to miners.<= br> > Yes in the end the miners will get all the fees, but with rising
> hashrate they get an unconditional subsidy that does not require
> transactions, thus more space for transactions with fees.
>
> I can make a formal BIP and pull request, but I need to know if there<= br> > is interest in this. Now fees don't play such a large part of the
> block reward, but they will get more important, and this change
> wouldn't force anything (would be voluntary by each user), just miners=
> have to agree to it with a soft fork (so they don't spend from the
> anyone-can-spend outputs used for reserve fees). Resource requirements=
> for validation are quite small I believe.
>
> On Sat, Sep 1, 2018 at 12:11 AM, Andrew <onelineproof@gmail.com>= wrote:
>> As I understand, selfish mining is an attack where miners collude = to
>> mine at a lower hashrate then with all miners working independentl= y.
>> What are the current strategies used to prevent this and what are = the
>> future plans?
>>
>> One idea I have is to let the block reward get "modulated&quo= t; according
>> to peak hashrate. Say p is the peak hashrate for 365 periods (1 ye= ar)
>> consisting of 144 blocks, h is the hashrate of the last 144 block = (1
>> day) period, and r is the base subsidy (12.5 BTC currently). You c= an
>> then make the max block reward 0.5 r (1 + h/p). So if hashrate= is at
>> peak you get the full reward. Otherwise you get less, down to a mi= n of
>> 0.5 r.
>>
>> If miners were to collude to mine at a lower than peak hashrate, t= hen
>> they may be able to do it profitably for 144 blocks, but after tha= t,
>> the reward would get modulated and it wouldn't be so much in their=
>> interest to continue mining at the lower hashrate.
>>
>> What flaws are there with this? I know it could be controversial d= ue
>> to easier mining present for early miners, so maybe it would have = to
>> be done in combination with a new more dynamic difficulty adjustme= nt
>> algorithm. But I don't see how hashrate can continue rising
>> indefinitely, so a solution should be made for selfish mining.
>>
>> Also when subsidies stop and a fee market is needed, I guess a por= tion
>> of the fees can be withheld for later if hashrate is not at peak.<= br> >>
>>
>> --
>> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
>
>
>
> --
> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



--
PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
--_000_PS2P216MB0179A4E6401D831166E749089D180PS2P216MB0179KORP_--