Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id BD5CEC002A for ; Wed, 3 May 2023 15:49:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 9774A41CCA for ; Wed, 3 May 2023 15:49:01 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 9774A41CCA Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=g9B4xE9E X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.862 X-Spam-Level: * X-Spam-Status: No, score=1.862 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZrWFcmSwJUR for ; Wed, 3 May 2023 15:48:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org A752040272 Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) by smtp2.osuosl.org (Postfix) with ESMTPS id A752040272 for ; Wed, 3 May 2023 15:48:59 +0000 (UTC) Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-74de7182043so242380485a.3 for ; Wed, 03 May 2023 08:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683128938; x=1685720938; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=uG89Z24XLLdF2s7pOvgyOQEqC/tN968pJOp44SMfYBA=; b=g9B4xE9EhIouCss67fh4WZUg6IBRjWJkcs6gGALrM3zPUwy9uUxKUFIMYJuqzqRtp1 TeWO8c/lgjBptV2uvJCwcSitqju8DKO/Ln9E6YsqhbFN1XxpzvdbY02vehZDb/3/E1Gp HHrkvwxfPrevjyDDgcdZQyHFGa09tzXzucEyjKD4iYH0AIJBudunJNBUFjTr/8cbW4/y LqMXxP1yZl6XBLCI59Abz4H1fGXWONvXfO9zs+dl+tceEZ/+uv0mDD/7EoCp8Ck9xitc Vim9Tbf3xk4wnPAHkz6eAlvHMdWxfr0lJFtzchs/GbDw1rRcq9kOGzimFVVGT99i3XaX KOJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683128938; x=1685720938; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=uG89Z24XLLdF2s7pOvgyOQEqC/tN968pJOp44SMfYBA=; b=cjuiv5/hXaAkZaxjlrjWDM0/l0Yc3wdNCcVQ6twXgddZjqGyqZLQG6yE1z69qgkO/i Ua+FXKy1JGD9f3Q88pH74mzkhGFSB4ZMxOmNGQmM4BVTfQkr4H3t5zQsgXpViRFUuLke RyV1Q+/P7AOuAuabnChkqrxVlYJQetrBjUNsVyxc2kLuqdNYq6NZ2GSCB7sHtMky3yuM tAZKpRc9mjfqF4fuLTcBG/l1BY1F6zW6dWThe3gBhitba0573OAkVuZPVlkdZHXolpbC PilkCTT//3tYaPIwkGkE+ceznUipbfzUVJb4UpQshyZjA/Cv7N9oI6iQvYb+V/S8gx3z pZ4w== X-Gm-Message-State: AC+VfDzP7nGmuvidvIAJZPTC5wRXsODucbA1zmI9XO8JKu8/hpNe47+P cdg0NHvnv94RucR56HqE+CI7HWYtJeinGrfwWVFAr9bYsR0Iow== X-Google-Smtp-Source: ACHHUZ4ilUDtSpvTIEnZ3YKYaF2uDahRyz2hVYUGO1mLmL5zHmv2csl24CFfZgzm2gVmDfaF3a6wtA0dNkZ4CrbOEhA= X-Received: by 2002:ac8:5c8e:0:b0:3e6:98a5:a965 with SMTP id r14-20020ac85c8e000000b003e698a5a965mr1100769qta.22.1683128937956; Wed, 03 May 2023 08:48:57 -0700 (PDT) MIME-Version: 1.0 From: F M Date: Wed, 3 May 2023 11:48:46 -0400 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000075486905facbfe54" X-Mailman-Approved-At: Wed, 03 May 2023 16:05:31 +0000 Subject: [bitcoin-dev] A payout scheme for a non custodial mining pool 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: Wed, 03 May 2023 15:49:01 -0000 --00000000000075486905facbfe54 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://docs.google.com/document/d/1qiOOSOT7epX658_nhjz-jj0DlnSRvytemOv_u_O= tMcc/edit?usp=3Dsharing Dear community, In the last months there have been several discussions about the topic of covenants and payment pools [0]. It has been difficult to approach these topics as it seems that there is no agreement in a precise definition on what is a covenant or what is a payment pool. This is probably due to the great generality of these two concepts. Perhaps, a good approach to study them is to look at some different use-cases and see which are the properties that appear more often and enclose them in a clear definition. About payment pools, that may be considered themself as a covenant, we specialized further, studying a payment pool=E2=80=99s scheme that may be used for the miners of a mining pool in o= rder to share the ownership of the coinbase reward [1]. This would make the pool non-custodial. The main pools now are custodial, in the sense that they collect the rewards of mining, and use them subsequently to pay the miners. As there are few large pools that find almost all the blocks, custodial polls increase the level of centralization in a protocol born to be decentralized and consensus ruled. This is why we generally want non-custodial pools. The only non-custodial payment pool that appeared is P2Pool, active some years ago, that was also decentralized. In P2Pool, the miners were paid directly by an output of the coinbase transaction. This implies a very large coinbase, preventing the inclusion of more transactions in the block, and therefore collecting less fees and making the mining less profitable, compared to a custodial pool. This makes the P2Pool payout scheme inappropriate considering also that there is big effort in keeping blockchain light, with several off-chain protocols. Our scheme uses ANYPREVOUT signatures and it is based on the idea of payment trees. A payment tree is a tree of transactions that redistributes the funds to the payment pool participants, having their address to the leaves. The root contains the funds of the payment pool on n-of-n multisig. We allow payment trees for future payment pools, in which the input=E2=80=99s references of the transactions are left empty and the signatures are ANYPREVOUT. This makes it possible to safely create a payment pool, merge two payment pools and withdraw funds from a payment pool. Why do we use ANYPREVOUT? Most payment pool structures use precompiled transactions for allowing safe withdrawal. The signatures of these transactions clearly commits to the extranonce of the coinbase. So, if the payment pool is set for the co-ownership of the mining reward, there must be a set of precompiled transactions for every extranonce tried by every miner, that may not be feasible. The use of ANYPREVOUT allow the miners to collectively construct a payment tree that =E2=80=9Cwaits=E2=80=9D the rewards, in the case that some miners finds a block. This payment tree is unique for all miners. We assume the pool to be centralized, even though our payment pool scheme perhaps can be generalized to decentralized pools. We compared the average space occupied on the blockchain and compared with the one of P2Pool. The results seem to be promising in this aspect, and are even better if the Pool is KYC. Clearly, this is just a very brief summary of our work, that is enclosed and labeled as an RFC. So, every remark or comment may be very appreciated. Authors: - Lorban (HRF), https://github.com/lorbax/, lorenzo.bonax@gmail.com - Fi3, https://github.com/fi3/ - Rachel Rybarczyk (Galaxy Digital), https://github.com/rrybarczyk PS Please note that although the linked document bears some resemblance to a research paper, it is presented as an RFC. We chose to publish it as an RFC because it is not intended to be a comprehensive work. [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.ht= ml [1] https://docs.google.com/document/d/1qiOOSOT7epX658_nhjz-jj0DlnSRvytemOv_u_O= tMcc/edit?usp=3Dsharing --00000000000075486905facbfe54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

https://docs.google.com/document/d/1qi= OOSOT7epX658_nhjz-jj0DlnSRvytemOv_u_OtMcc/edit?usp=3Dsharing
=


Dear co= mmunity,

In the last months there have been several discussions about the t= opic of covenants and payment pools

[0]. It has been difficult to approach = these topics as it seems that there is no agreement in a precise

=

= definition= on what is a covenant or what is a payment pool. This is probably due to t= he great generality

of these two concepts. Perhaps, a good approach to stud= y them is to look at some different use-cases

and see which are the propert= ies that appear more often and enclose them in a clear definition. About

pa= yment pools, that may be considered themself as a covenant, we specialized = further, studying a payment

pool=E2=80=99s scheme that may be used for the = miners of a mining pool in order to share the ownership of the

coinbase rew= ard [1]. This would make the pool non-custodial.

The main pools now are cus= todial, in the sense that they collect the rewards of mining, and use them<= /span>

= subsequently to pay the miners. As there are few large pools that find almo= st all the blocks, custodial

polls increase the level of centralization in = a protocol born to be decentralized and consensus ruled.

This is why we g= enerally want non-custodial pools.

The only non-custodial payment pool that= appeared is P2Pool, active some years ago, that was also decentralized.

In= P2Pool, the miners were paid directly by an output of the coinbase transac= tion. This implies a very

large coinbase, preventing the inclusion of more = transactions in the block, and therefore collecting

less fees and making = the mining less profitable, compared to a custodial pool. This makes the P2= Pool

payout scheme inappropriate considering also that there is big effort = in keeping blockchain light, with

several off-chain protocols.

Our scheme u= ses ANYPREVOUT signatures and it is based on the idea of payment trees. A p= ayment tree is

a tree of transactions that redistributes the funds to the p= ayment pool participants, having their address

to the leaves. The root cont= ains the funds of the payment pool on n-of-n multisig. We allow payment tre= es

for future payment pools, in which the input=E2=80=99s references of the= transactions are left empty and the

signatures are ANYPREVOUT.

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;font-weight:400;font-style:normal;font-variant:normal;tex= t-decoration:none;vertical-align:baseline;white-space:pre-wrap">This makes = it possible to safely create a payment pool, merge two payment pools and wi= thdraw funds from

a payment pool.


Why do we use ANYPREVOUT? Most paymen= t pool structures use precompiled transactions for allowing safe

=

= withdrawal= . The signatures of these transactions clearly commits to the extranonce of= the coinbase. So,

if the payment pool is set for the co-ownership of the m= ining reward, there must be a set of precompiled

transactions for every ext= ranonce tried by every miner, that may not be feasible.

The use of ANYPREVO= UT allow the miners to collectively construct a payment tree that =E2=80=9C= waits=E2=80=9D the rewards,

in the case that some miners finds a block. Thi= s payment tree is unique for all miners.


We assume the pool to be centr= alized, even though our payment pool scheme perhaps can be generalized

to d= ecentralized pools. We compared the average space occupied on the blockchai= n and compared with the

one of P2Pool. The results seem to be promising in = this aspect, and are even better if the Pool is KYC.


Clearly, this is= just a very brief summary of our work, that is enclosed and labeled as an = RFC. So, every

remark or comment may be very appreciated.


Authors:=

PS
Please note that although the linked document bears so= me resemblance to a research paper, it is presented as an RFC. We chose to = publish it as an RFC because it is not intended to be a comprehensive work.=


[0] https://list= s.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html

[1]http= s://docs.google.com/document/d/1qiOOSOT7epX658_nhjz-jj0DlnSRvytemOv_u_OtMcc= /edit?usp=3Dsharing





--00000000000075486905facbfe54--