+Return-Path: <willtech@live.com.au>

+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org

+ [172.17.192.35])

+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 4A1B72C

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Sat, 15 Sep 2018 05:29:25 +0000 (UTC)

+X-Greylist: whitelisted by SQLgrey-1.7.6

+Received: from APC01-HK2-obe.outbound.protection.outlook.com

+ (mail-oln040092255056.outbound.protection.outlook.com [40.92.255.56])

+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B7BB47A8

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Sat, 15 Sep 2018 05:29:23 +0000 (UTC)

+Received: from HK2APC01FT049.eop-APC01.prod.protection.outlook.com

+ (10.152.248.51) by HK2APC01HT134.eop-APC01.prod.protection.outlook.com

+ (10.152.248.198) with Microsoft SMTP Server (version=TLS1_2,

+ cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1143.11;

+ Sat, 15 Sep 2018 05:29:20 +0000

+Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.248.59) by

+ HK2APC01FT049.mail.protection.outlook.com (10.152.249.218) with

+ Microsoft SMTP Server (version=TLS1_2,

+ cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1143.11 via

+ Frontend Transport; Sat, 15 Sep 2018 05:29:20 +0000

+Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM

+ ([fe80::3d19:7b68:daee:a1fd]) by PS2P216MB0179.KORP216.PROD.OUTLOOK.COM

+ ([fe80::3d19:7b68:daee:a1fd%9]) with mapi id 15.20.1122.021;

+ Sat, 15 Sep 2018 05:29:20 +0000

+From: Damian Williamson <willtech@live.com.au>

+To: Andrew <onelineproof@gmail.com>, Bitcoin Protocol Discussion

+ <bitcoin-dev@lists.linuxfoundation.org>

+Thread-Topic: [bitcoin-dev] Selfish Mining Prevention

+Thread-Index: AQHUQ929vUuYMRqqE0yCtZaZqwUgr6Tu6L6AgAH4Q9Y=

+Date: Sat, 15 Sep 2018 05:29:20 +0000

+Message-ID: <PS2P216MB017942E0336DD337CB1EB6A89D180@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>

+References: <CAL8tG=k+kXHMbQdUXO3BXKv7fQwp5t2QuaQut7sPUtEYgwzn0A@mail.gmail.com>,

+ <CAL8tG=mui_izrob0V66QqNzSJs1Lpbm0xxUYMpzb65-JR9QhRw@mail.gmail.com>

+In-Reply-To: <CAL8tG=mui_izrob0V66QqNzSJs1Lpbm0xxUYMpzb65-JR9QhRw@mail.gmail.com>

+Accept-Language: en-AU, en-US

+Content-Language: en-AU

+X-MS-Has-Attach:

+X-MS-TNEF-Correlator:

+x-incomingtopheadermarker: OriginalChecksum:6808D9537593124ADD1B28C8AEB7A9CEFFEB7D8AD5C80AB99775BAFFBE9365D3;

+ UpperCasedChecksum:B00F664672C8D7C2ABB9C050C9ADA79D1ED60661D57C6F3C1CC99B8E7BA4B994;

+ SizeAsReceived:7184; Count:46

+x-ms-exchange-messagesentrepresentingtype: 1

+x-tmn: [p04DvQ7MLJngRqvgFSbb3dVXgfKYN/x6]

+x-ms-publictraffictype: Email

+x-microsoft-exchange-diagnostics: 1; HK2APC01HT134;

+ 6:xbDf61LywbY6LYp8oolPIkHK7wU+tbaIfRXVRkETbcjwFv9PDVLLc91TQ6UJGfixR51fRkCNis89Cz8q77IVk8tgFagOlLQjn3G/L+Fym10nMgN5rZNuuG27P+zcrFpjrsvqYCNNwd+jLxCSi9wXjXlERiLF7nyOWKKm8/A6pAmbBxH/h6zKbeqUbYvfxs8xNd667RDT8tQ2Odlb62zNWGo645gCWWLoSEHfcGdUX3aXsgfnE+Ej+8iBCTr9BI8eBxHOBPSFsJSU4HQ7Gb+AIgNOD9X1yy2FTTo3vI+ORcPHzkWvnJ5syNTEeRKSo46ijMeCb2ypaIFtVLTeO1VnpZ2K+B/xi7lO51bzmRRz4kpS/8UrgIVfpQFeNet8jZ4ImAU83Zs9iG0+Vd9htbwyfo2VEyCEyiyJ1z2XNiRa5dXkZp9Ryh7tU/lQTcGRXdNb3pSn4tkXKvPC25eC69DUwg==;

+ 5:ReHExNpgXVxHvHxBYOfhGvxNaI5sxb3imgVNbY58miUMb1ZLQVM5+VOXQcVp99gEBw/ocDT4x5WhKGjszXKwFwNQjEavi/mzYeJNsM+X4Uy8P+4ZnQVWsLABE+Y/c93VtwpuS7eMvuSGnySbGbCYYLBjic3IAhzMEKDJvFqFyY0=;

+ 7:FKjLlfIvFUzmzTQ7Q/SJTwc+vxRJ8I6m1Q1xG/u7MiXn2QUcO9eyomHkY543ltfYm0dGZAcNPSz9hMjy1fJxkusgdzbhfMPO2hUtWsQ0bpD1sXbvT38yF7zPvJqZncWP6HRdx6qSyXujqlkdax67a2KpZgmqGQAZI3j2BysYD1PaFUrqystrQo/X/rd+fJHQJD+lBPSuXdgGkXCc/yvJeCgxCpHVtkvX+4A9fRHtLzZgdDuPeeEHv2bI/6MpeofC

+x-incomingheadercount: 46

+x-eopattributedmessage: 0

+x-microsoft-antispam: BCL:0; PCL:0;

+ RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045);

+ SRVR:HK2APC01HT134;

+x-ms-traffictypediagnostic: HK2APC01HT134:

+x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058);

+ SRVR:HK2APC01HT134; BCL:0; PCL:0; RULEID:; SRVR:HK2APC01HT134;

+x-forefront-prvs: 0796EBEDE1

+x-forefront-antispam-report: SFV:NSPM;

+ SFS:(7070007)(189003)(199004)(105586002)(7696005)(6506007)(347745004)(19627405001)(53546011)(106356001)(966005)(14454004)(8676002)(76176011)(6606003)(104016004)(81156014)(6436002)(25786009)(16799955002)(99286004)(82202002)(74482002)(5660300001)(39060400002)(6246003)(74316002)(561944003)(551934003)(6306002)(33656002)(14444005)(54896002)(256004)(11346002)(446003)(229853002)(236005)(9686003)(97736004)(5250100002)(486006)(110136005)(476003)(2900100001)(55016002)(606006)(86362001)(66574006)(6346003)(68736007)(26005)(56003)(102836004)(8936002);

+ DIR:OUT; SFP:1901; SCL:1; SRVR:HK2APC01HT134;

+ H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None;

+ PTR:InfoNoRecords; MX:1; A: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: 3kh2fBRBoIoWtB9sJdVghd5FNawbj8/h3wCLAqL3QOzFj8iSAQTl4UuA1QuTYm6FyX1Uxhoi4szyA849Wx8WN3MXQE+TEh/7L0OHxQdR6Gl7FPel52BfvR9AHdg9a3axv7kNGyHg6l0UPRWi11jY/OOXmKuGIA8TP46nxxbrr3kn/JgiAPTx8tzR/srUbP1DUpczwtHMSOI1GDVyMvfJzNJ4CZovX0n0SNPIhZq40sk=

+Content-Type: multipart/alternative;

+ boundary="_000_PS2P216MB017942E0336DD337CB1EB6A89D180PS2P216MB0179KORP_"

+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: 6e84b409-7b9c-42fa-1023-08d61acc302f

+X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7

+X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2018 05:29:20.3076 (UTC)

+X-MS-Exchange-CrossTenant-fromentityheader: Internet

+X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa

+X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT134

+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: Sat, 15 Sep 2018 05:36:23 +0000

+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 <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: Sat, 15 Sep 2018 05:29:25 -0000

+

+--_000_PS2P216MB017942E0336DD337CB1EB6A89D180PS2P216MB0179KORP_

+Content-Type: text/plain; charset="us-ascii"

+Content-Transfer-Encoding: quoted-printable

+

+>This "reserve" part of the fee will be paid to miners if the hashrate rise=

+s.

+

+

+Anticipating ongoing hashrate rise shows that you have not yet thought abou=

+t moving outside of the current greed model, a model wherein mining will co=

+nsume all available resources within the colony's objective just to spread =

+as far as possible with each new miner bringing diminishing individual retu=

+rns and shortening the life of Earth for no additional gain. Greed model :=

+=3D bacteria.

+

+________________________________

+From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@li=

+sts.linuxfoundation.org> on behalf of Andrew via bitcoin-dev <bitcoin-dev@l=

+ists.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

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

+

+--_000_PS2P216MB017942E0336DD337CB1EB6A89D180PS2P216MB0179KORP_

+Content-Type: text/html; charset="us-ascii"

+Content-Transfer-Encoding: quoted-printable

+

+<html>

+<head>

+<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=

+>

+<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 style=3D"margin-top:0;margin-bottom:0">&gt;<font size=3D"2"><span style=

+=3D"font-size:11pt;">This &quot;reserve&quot; part of the fee will be paid =

+to miners if the hashrate rises.</span></font></p>

+<p style=3D"margin-top:0;margin-bottom:0"><br>

+</p>

+<p style=3D"margin-top:0;margin-bottom:0">Anticipating ongoing hashrate ris=

+e shows that you have not yet thought about moving outside of the current g=

+reed model, a model wherein mining will consume all available resources wit=

+hin the colony's objective just to

+ spread as far as possible with each new miner bringing diminishing individ=

+ual returns and shortening the life of Earth for no additional gain. Greed =

+model :=3D bacteria.<br>

+</p>

+</div>

+<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">

+<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=

+yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> bitcoin-dev-bounces@l=

+ists.linuxfoundation.org &lt;bitcoin-dev-bounces@lists.linuxfoundation.org&=

+gt; on behalf of Andrew via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundati=

+on.org&gt;<br>

+<b>Sent:</b> Friday, 14 September 2018 9:19:37 AM<br>

+<b>To:</b> Bitcoin Dev<br>

+<b>Subject:</b> Re: [bitcoin-dev] Selfish Mining Prevention</font>

+<div>&nbsp;</div>

+</div>

+<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;=

+">

+<div class=3D"PlainText">I discussed this more at bitcointalk:<br>

+<a href=3D"https://bitcointalk.org/index.php?topic=3D4998410.0">https://bit=

+cointalk.org/index.php?topic=3D4998410.0</a><br>

+<br>

+The attacks I'm interested in preventing are not only selfish mining<br>

+and collusion, but also more subtle attacks like block withholding,<br>

+and in general anything that aims to drive out the competition in<br>

+order to increase hashrate fraction. I also scrapped the idea of<br>

+changing the block subsidies, and I am only focuses on fees.<br>

+<br>

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

+&quot;reserve fees&quot;. When a user makes a transaction, for each txout<b=

+r>

+script, they can add parameters that specify the fraction of the total<br>

+fee that is held in &quot;reserve&quot; and the time it is held in &quot;re=

+serve&quot;<br>

+(can set a limit of 2016 blocks). This &quot;reserve&quot; part of the fee =

+will<br>

+be paid to miners if the hashrate rises. So if hashrate is currently h<br>

+and peak hashrate (from past year) is p, then for each period (1 day),<br>

+a new hashrate is calculated h1, and if h1 &gt; h, then the fraction<br>

+(h1-h)/p from the reserve fees created in the past 2016 blocks will be<br>

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

+rising, until the &quot;contract&quot; expires, and the leftover part can b=

+e<br>

+used by the owner of the unspent output, but it can only be used for<br>

+paying fees, not as inputs for future transactions (to save on block<br>

+space).<br>

+<br>

+This should incentivize miners to not drive out the competition, since<br>

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

+hashrate they get an unconditional subsidy that does not require<br>

+transactions, thus more space for transactions with fees.<br>

+<br>

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

+block reward, but they will get more important, and this change<br>

+wouldn't force anything (would be voluntary by each user), just miners<br>

+have to agree to it with a soft fork (so they don't spend from the<br>

+anyone-can-spend outputs used for reserve fees). Resource requirements<br>

+for validation are quite small I believe.<br>

+<br>

+On Sat, Sep 1, 2018 at 12:11 AM, Andrew &lt;onelineproof@gmail.com&gt; wrot=

+e:<br>

+&gt; As I understand, selfish mining is an attack where miners collude to<b=

+r>

+&gt; mine at a lower hashrate then with all miners working independently.<b=

+r>

+&gt; What are the current strategies used to prevent this and what are the<=

+br>

+&gt; future plans?<br>

+&gt;<br>

+&gt; One idea I have is to let the block reward get &quot;modulated&quot; a=

+ccording<br>

+&gt; to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)<=

+br>

+&gt; consisting of 144 blocks, h is the hashrate of the last 144 block (1<b=

+r>

+&gt; day) period, and r is the base subsidy (12.5 BTC currently). You can<b=

+r>

+&gt; then make the max block reward 0.5 r (1 &#43; h/p). So if hashrate is =

+at<br>

+&gt; peak you get the full reward. Otherwise you get less, down to a min of=

+<br>

+&gt; 0.5 r.<br>

+&gt;<br>

+&gt; If miners were to collude to mine at a lower than peak hashrate, then<=

+br>

+&gt; they may be able to do it profitably for 144 blocks, but after that,<b=

+r>

+&gt; the reward would get modulated and it wouldn't be so much in their<br>

+&gt; interest to continue mining at the lower hashrate.<br>

+&gt;<br>

+&gt; What flaws are there with this? I know it could be controversial due<b=

+r>

+&gt; to easier mining present for early miners, so maybe it would have to<b=

+r>

+&gt; be done in combination with a new more dynamic difficulty adjustment<b=

+r>

+&gt; algorithm. But I don't see how hashrate can continue rising<br>

+&gt; indefinitely, so a solution should be made for selfish mining.<br>

+&gt;<br>

+&gt; Also when subsidies stop and a fee market is needed, I guess a portion=

+<br>

+&gt; of the fees can be withheld for later if hashrate is not at peak.<br>

+&gt;<br>

+&gt;<br>

+&gt; --<br>

+&gt; PGP: B6AC 822C 451D 6304 6A28&nbsp; 49E9 7DB7 011C D53B 5647<br>

+<br>

+<br>

+<br>

+-- <br>

+PGP: B6AC 822C 451D 6304 6A28&nbsp; 49E9 7DB7 011C D53B 5647<br>

+_______________________________________________<br>

+bitcoin-dev mailing list<br>

+bitcoin-dev@lists.linuxfoundation.org<br>

+<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">=

+https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>

+</div>

+</span></font></div>

+</body>

+</html>

+

+--_000_PS2P216MB017942E0336DD337CB1EB6A89D180PS2P216MB0179KORP_--

+