From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 26EA6C0012 for ; Mon, 13 Dec 2021 01:31:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 1539660EE1 for ; Mon, 13 Dec 2021 01:31:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT_VdiViRVI0 for ; Mon, 13 Dec 2021 01:31:56 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp3.osuosl.org (Postfix) with ESMTPS id B301360E36 for ; Mon, 13 Dec 2021 01:31:56 +0000 (UTC) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BD1VrW3018019 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 12 Dec 2021 20:31:54 -0500 Received: by mail-lf1-f48.google.com with SMTP id z7so28032183lfi.11 for ; Sun, 12 Dec 2021 17:31:54 -0800 (PST) X-Gm-Message-State: AOAM533zfZ5mAT2aN5/k2Am1h5y7LWSV0uAKnzzo2LqcDSoeTBVnc3Eg thDMm3b9SQbEayaUk0HVVLH5nI0MYwJs6FQHzo8= X-Google-Smtp-Source: ABdhPJzHxUn5tzpE5gfLCXEEVxiw4XEJ1IWZZByPgvvpAW9GyhpIxnwGbSI9sEx4kgFc064/798SQIktudvAqLBuuRk= X-Received: by 2002:a19:f242:: with SMTP id d2mr26059351lfk.516.1639359113257; Sun, 12 Dec 2021 17:31:53 -0800 (PST) MIME-Version: 1.0 References: <57315643-a4c33a2ff7196be1070725cf1903435e@pmq6v.m5r2.onet> In-Reply-To: <57315643-a4c33a2ff7196be1070725cf1903435e@pmq6v.m5r2.onet> From: Jeremy Date: Sun, 12 Dec 2021 17:31:42 -0800 X-Gmail-Original-Message-ID: Message-ID: To: vjudeu@gazeta.pl Content-Type: multipart/alternative; boundary="0000000000009ae87905d2fd093a" Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2021 01:31:58 -0000 --0000000000009ae87905d2fd093a Content-Type: text/plain; charset="UTF-8" Hey there! Thanks for your response! One of the reasons to pick a longer window of, say, a couple difficulty periods would be that you can make participation in the pool hedge you against hashrate changes. You're absolutely spot on to think about the impact of pooling w.r.t. variance when fees > subsidy. That's not really in the analysis I had in the (old) post, but when the block revenues swing, dcfmp over longer periods can really smooth out the revenues for miners in a great way. This can also help with the "mind the gap" problem when there isn't a backlog of transactions, since producing an empty block still has some value (in order to incentivize mining transaction at all and not cheating, we need to reward txn inclusion as I think you're trying to point out. Sadly, I've read the rest of your email a couple times and I don't really get what you're proposing at all. It jumps right into "things you could compute". Can you maybe try stating the goals of your payout function, and then demonstrate how what you're proposing meets that? E.g., we want to pay more to miners that do x? --0000000000009ae87905d2fd093a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey t= here!

Thanks for your response!

One of the reasons to pick a longer= window of, say, a couple difficulty periods would be that you can make par= ticipation in the pool hedge you against hashrate changes.

You're absolutely spot on to thi= nk about the impact of pooling w.r.t. variance when fees > subsidy. That= 's not really in the analysis I had in the (old) post, but when the blo= ck revenues swing, dcfmp over longer periods can really smooth out the reve= nues for miners in a great way. This=C2=A0<= span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri= f;font-size:small;color:rgb(0,0,0)">can also help with the "mind the g= ap" problem when there isn't a backlog of transactions, since prod= ucing an empty block still has some value (in order to incentivize mining t= ransaction at all and not cheating, we need to reward txn inclusion as I th= ink you're trying to point out.

Sadly, I've read the = rest of your email a couple times and I don't really get what you'r= e proposing at all. It jumps right into "things you could compute"= ;. Can you maybe try stating the goals of your payout function, and then de= monstrate how what you're proposing meets that? E.g., we want to pay mo= re to miners that do x?

=

--0000000000009ae87905d2fd093a--