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 C350EC0012 for ; Mon, 13 Dec 2021 14:11:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id A212C6F2D6 for ; Mon, 13 Dec 2021 14:11:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=gazeta.pl 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 N1GQEPQLu8A2 for ; Mon, 13 Dec 2021 14:10:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from smtpo90.poczta.onet.pl (smtpo90.poczta.onet.pl [213.180.149.143]) by smtp3.osuosl.org (Postfix) with ESMTPS id B70B96059F for ; Mon, 13 Dec 2021 14:10:58 +0000 (UTC) Received: from pmq4v.m5r2.onet (pmq4v.m5r2.onet [10.174.32.70]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4JCNhV04dSz1yBc; Mon, 13 Dec 2021 15:10:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1639404650; bh=44ITudYWHoqyD3f7Ebdd6DITTLBmw2C9vc2FFs/Fa+8=; h=From:Cc:To:Date:Subject:From; b=Uoaf0N/A3/GshrcaTqMSHOsRxaVHbcvvyRWS6Vz74W/6d3W5rqGBYm8ldmkQ0carv IY1Q4lyKBtj2GXLUTb1KOMj4RMTirztFWBZxB/mGEx29l3KWbNOcub7FM6+JsCDG2g 75bqb1WdFWjab6MXaR0703ThThuQs/VQPcP+J01A= Content-Type: multipart/alternative; boundary="===============4857360730779384453==" MIME-Version: 1.0 Received: from [82.177.167.2] by pmq4v.m5r2.onet via HTTP id ; Mon, 13 Dec 2021 15:10:49 +0100 From: vjudeu@gazeta.pl X-Priority: 3 To: Jeremy Date: Mon, 13 Dec 2021 15:10:49 +0100 Message-Id: <150216403-2fc1a5b1e9f48639bccf4fa9a5ebd62e@pmq4v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;82.177.167.2;PL;2 X-Mailman-Approved-At: Mon, 13 Dec 2021 14:23:05 +0000 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 14:11:00 -0000 This is a multi-part message in MIME format. --===============4857360730779384453== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > Can you maybe try stating the goals of your payout function, and then dem= onstrate how what you're proposing meets that? =C2=A0 The goals are quite simple: if you are a solo miner, you are trying to mine= a block that meets the network difficulty. If you are using some kind of p= ool, then you are trying to mine N times easier blocks and receive N times = lower reward for doing that. If many miners work on similar transactions, t= hen each miner can validate each transaction once and assign transaction fe= e to transaction id, in this way the coinbase reward can be quickly checked= , because you have to check only those transactions, which were unknown to = you and for example included only by this miner and not broadcasted. Assumi= ng that most of the transactions will be the same and included by most of t= he miners, that verification would be quick and can be simplified only to c= hecking "what is different from what I am mining". Also, to determine the proper amount of shares received, you can assign a d= ifficulty for each miner. So, if you are connected to eight mining nodes, y= ou can assign a difficulty to each of them, just to limit how much work for= each share they can produce to have it accepted and included for payments.= It is needed to avoid spamming by producing a lot of shares at difficulty = one by bigger miners, they should find it more profitable to create bigger = shares, because by accumulating them, it is cheaper to receive one bigger p= ayment than a lot of smaller payments. On 2021-12-13 14:59:58 user Jeremy wrote: Hey there! =C2=A0 Thanks for your response! =C2=A0 One of the reasons to pick a longer window of, say, a couple difficulty per= iods would be that you can make participation in the pool hedge you against= hashrate changes. =C2=A0 You're absolutely spot on to think about the impact of pooling w.r.t. varia= nce when fees > subsidy. That's not really in the analysis I had in the (ol= d) post, but when the block revenues swing, dcfmp over longer periods can r= eally smooth out the revenues for miners in a great way. This=C2=A0can also= help with the "mind the gap" problem when there isn't a backlog of transac= tions, since producing an empty block still has some value (in order to inc= entivize mining transaction at all and not cheating, we need to reward txn = inclusion as I think you're trying to point out. =C2=A0 Sadly, I've read the rest of your email a couple times and I don't really g= et what you're proposing at all. It jumps right into "things you could comp= ute". 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 mor= e to miners that do x? =C2=A0 =C2=A0 =C2=A0 =C2=A0 --===============4857360730779384453== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
> Can you maybe try stating the goals of your payout function, and = then demonstrate how what you're proposing meets that?
 

The goals are quite simple: if you are a solo miner, you are try= ing to mine a block that meets the network difficulty. If you are using som= e kind of pool, then you are trying to mine N times easier blocks and recei= ve N times lower reward for doing that. If many miners work on similar tran= sactions, then each miner can validate each transaction once and assign tra= nsaction fee to transaction id, in this way the coinbase reward can be quic= kly checked, because you have to check only those transactions, which were = unknown to you and for example included only by this miner and not broadcas= ted. Assuming that most of the transactions will be the same and included b= y most of the miners, that verification would be quick and can be simplifie= d only to checking "what is different from what I am mining".

Also, to determine the proper amount of shares received, you can assign= a difficulty for each miner. So, if you are connected to eight mining node= s, you can assign a difficulty to each of them, just to limit how much work= for each share they can produce to have it accepted and included for payme= nts. It is needed to avoid spamming by producing a lot of shares at difficu= lty one by bigger miners, they should find it more profitable to create big= ger shares, because by accumulating them, it is cheaper to receive one bigg= er payment than a lot of smaller payments.

On 2021-12-13 14:59:58 user Jeremy <jlrubin@mit.edu> wrote:
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 c= hanges.
 
You're absolutely spot on t= o 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 bl= ock revenues swing, dcfmp over longer periods can really smooth out the rev= enues 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 v= alue (in order to incentivize mining transaction at all and not cheating, w= e 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 y= ou maybe try stating the goals of your payout function, and then demonstrat= e how what you're proposing meets that? E.g., we want to pay more to miners= that do x?
 
 
 
 
--===============4857360730779384453==--