Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4AF8BC50 for ; Fri, 14 Sep 2018 18:00:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 03AFF7E4 for ; Fri, 14 Sep 2018 18:00:40 +0000 (UTC) Received: by mail-ot1-f43.google.com with SMTP id a19-v6so5411516otl.12 for ; Fri, 14 Sep 2018 11:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7Vvg1lA+KdI4xsu7GOe2m/j7MkSKYXop0+kvNNATF/Y=; b=BJUqHB4rsgmM5qyq2mF+fI3WEiIc+B0GSUkCAlETXz8Yj6m2NGLGor2r0M0aryzTKZ rsqS2eciaQZJ2Fg5Ex/fDCThTQzxhtoq3cdfWl8YWToJ8AohVjbvaTouC3DqRsK5NqEy E98iNe73YCpLGcceAnoSSwPkzBEdKSJcQ947KwkhV3AzHfgZEQZNEvuXy0m7vghvjhYI 8l5NIivH4GBuxWGAaVvs22Lgmua3p3NNchnSP7A3MBSHCecOb77g3lczco/RXGa/ly9w UsYJTyXjfp5wbEqtAUZexSYJO8xZrr0R6z+Nlr48MV0aDVkex/EZj6brUrEKA+UKOIeo 9bEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7Vvg1lA+KdI4xsu7GOe2m/j7MkSKYXop0+kvNNATF/Y=; b=rIGGvJNgDyKAhJARnnOjku3HDKBnuhzgnpOGsxeGXbl95u6blN7X7VsaIhQRTuQP61 BWWaeqg09NkGmyJ4jk+I+Y/VKewgSTBuLLbh0eQx+z9AVF3js2QhNHu3ma8RMmKZz4Vt bLeCLUw70rZcNgGuYaQwshz1UJ8kXK+YaCVBNTMXT4BcQiolPVj3HHmIibYPFjylbMNv clNozlqL9nx2e+xu8Ss5YCe0ovKslzncRP7r6dbo9rZGGPNGjuQhhO81BpQk3GJpzgQt IeAUjEC0/uKOHE9t6z8eKfgeER55Vc64pt/9YxoF3xs6xN3e2KSGJTaT1q+nrrOHAgKV 14CA== X-Gm-Message-State: APzg51Bz8tlHpnC6FifGCSBffzkG9yTQsnrv9EFNrs2NwxJ1jnB2W1Ss jI3PMmDi1/LTVLE27c6R7zKfxVa3xtmd8YN7Pc0= X-Google-Smtp-Source: ANB0VdbcCbTxGgcS/JgpsfmHCKkFb8co6/wtK5IdkL6eJSejpv8C+ilDsa7omNz+aniDt7wMNK7hBk6jrZ1Yct0zgZ0= X-Received: by 2002:a9d:63d8:: with SMTP id e24-v6mr4913146otl.233.1536948040211; Fri, 14 Sep 2018 11:00:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Moral Agent Date: Fri, 14 Sep 2018 14:00:29 -0400 Message-ID: To: Andrew K Content-Type: multipart/alternative; boundary="000000000000f99f500575d89968" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE 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: Fri, 14 Sep 2018 18:36:53 +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: Fri, 14 Sep 2018 18:00:42 -0000 --000000000000f99f500575d89968 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you, and my apologies. I should have sent that link just to you and not put everyone on cc. On Fri, Sep 14, 2018 at 1:30 PM Andrew wrote: > (reposting to whole list instead of just him) @Moral Agent: > Interesting proposal though it introduces some elements > of proof of stake so it would be more controversial in my view. Also, > something needs to be explained about how this would not create an > attack where difficulty is frequently dropping by 25%, and suddenly we > find ourselves with a very low difficulty and PoW attacks can easily > happen. I need to analyse your proposal more, but I prefer to discuss > it on your blog instead of here just to limit the side topics and > focus only on my proposal. > > No one has yet given me a good reason for why not to support my proposal.= .. > > On Fri, Sep 14, 2018 at 2:49 PM, Moral Agent > wrote: > > You might be interested in an idea I wrote about that is in a similar > spirit > > here: > > > > > https://medium.com/coinmonks/taming-large-miners-with-helper-blocks-6ae67= ac242f6 > > > > From the article: > > > > When a block is solved, it randomly selects one satoshi from the utxo s= et > > and gives whomever controls that satoshi the power to generate a =E2=80= =9CHelper > > Block=E2=80=9D. The Helper Block commits to a subset of transactions fo= r > inclusion > > in the next block. A miner can accept the Helper Block by including the > > suggested transactions and giving the associated transaction fees to a > > payment address specified in the Helper Block. Miners who do not use a > > Helper Block must satisfy a 25% higher difficulty. > > > > On Fri, Sep 14, 2018 at 9:56 AM Andrew via bitcoin-dev > > wrote: > >> > >> 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 th= e > >> > 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, the= n > >> > 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 porti= on > >> > 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 > --000000000000f99f500575d89968 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you, and my apologies. I should have sent that link = just to you and not put everyone on cc.

On Fri, Sep 14, 2018 at 1:30 PM Andrew <onelineproof@gmail.com> wrote:
=
(reposting to whole list instead of just him= ) @Moral Agent:
Interesting proposal though it introduces some elements
of proof of stake so it would be more controversial in my view. Also,
something needs to be explained about how this would not create an
attack where difficulty is frequently dropping by 25%, and suddenly we
find ourselves with a very low difficulty and PoW attacks can easily
happen. I need to analyse your proposal more, but I prefer to discuss
it on your blog instead of here just to limit the side topics and
focus only on my proposal.

No one has yet given me a good reason for why not to support my proposal...=

On Fri, Sep 14, 2018 at 2:49 PM, Moral Agent <ethan.scruples@gmail.com> wrote:=
> You might be interested in an idea I wrote about that is in a similar = spirit
> here:
>
> https://medium.= com/coinmonks/taming-large-miners-with-helper-blocks-6ae67ac242f6
>
> From the article:
>
> When a block is solved, it randomly selects one satoshi from the utxo = set
> and gives whomever controls that satoshi the power to generate a =E2= =80=9CHelper
> Block=E2=80=9D. The Helper Block commits to a subset of transactions f= or inclusion
> in the next block. A miner can accept the Helper Block by including th= e
> suggested transactions and giving the associated transaction fees to a=
> payment address specified in the Helper Block. Miners who do not use a=
> Helper Block must satisfy a 25% higher difficulty.
>
> On Fri, Sep 14, 2018 at 9:56 AM Andrew via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> 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<= br> >> 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 bitcoint= alk
>> thread, but my proposal in short would be to add the concept of >> "reserve fees". When a user makes a transaction, for eac= h txout
>> script, they can add parameters that specify the fraction of the t= otal
>> 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 current= ly h
>> and peak hashrate (from past year) is p, then for each period (1 d= ay),
>> a new hashrate is calculated h1, and if h1 > h, then the fracti= on
>> (h1-h)/p from the reserve fees created in the past 2016 blocks wil= l 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 kee= ps
>> rising, until the "contract" expires, and the leftover p= art can be
>> used by the owner of the unspent output, but it can only be used f= or
>> paying fees, not as inputs for future transactions (to save on blo= ck
>> space).
>>
>> This should incentivize miners to not drive out the competition, s= ince
>> if they do, there will be less of these reserve fees given to mine= rs.
>> 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 th= ere
>> 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), jus= t 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 requirem= ents
>> 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 col= lude to
>> > mine at a lower hashrate then with all miners working indepen= dently.
>> > 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 "modulate= d" 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 b= lock (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 hashrat= e 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 hashra= te, then
>> > they may be able to do it profitably for 144 blocks, but afte= r 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 controvers= ial due
>> > to easier mining present for early miners, so maybe it would = have to
>> > be done in combination with a new more dynamic difficulty adj= ustment
>> > algorithm. But I don't see how hashrate can continue risi= ng
>> > 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 p= eak.
>> >
>> >
>> > --
>> > PGP: B6AC 822C 451D 6304 6A28=C2=A0 49E9 7DB7 011C D53B 5647<= br> >>
>>
>>
>> --
>> PGP: B6AC 822C 451D 6304 6A28=C2=A0 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=C2=A0 49E9 7DB7 011C D53B 5647
--000000000000f99f500575d89968--