Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id ACF83C002A for ; Mon, 22 May 2023 01:27:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 72E8682213 for ; Mon, 22 May 2023 01:27:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 72E8682213 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=F9SxzMvS X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.612 X-Spam-Level: * X-Spam-Status: No, score=1.612 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_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 smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66dvuvZ7FGsc for ; Mon, 22 May 2023 01:27:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org EA6C682212 Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) by smtp1.osuosl.org (Postfix) with ESMTPS id EA6C682212 for ; Mon, 22 May 2023 01:27:53 +0000 (UTC) Received: by mail-io1-xd2e.google.com with SMTP id ca18e2360f4ac-76c4e1fe1d7so55778139f.3 for ; Sun, 21 May 2023 18:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684718873; x=1687310873; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=ZJQtElzu+UD5ph8V4em11PgQpTFGHc0+htp6yYua+aY=; b=F9SxzMvSJ+XliUr2rYHhQEJdE5gx7omag6kC6iXqDp20knZwgY5c3N4ipS4iHyjat6 8R8rdmC6TGtJFyaV+8kKFmJE1g5he0vNfa2UEXgyMfDKLvJahkqaItBQQJ2j59FM3uuq sA+BhRXbXWOlc83FKOKRzoGPAkB0tl7yodGrd3zY7h+RjJZa3E9XMyH7p5nrxxGjDxPc CiCOX1cwCE13ZcrIsvioOcE2YJ8WUEaiWWVtBEEvmm71qbxd4AWQd8QuJTbTXSRL1s0a ApnGmOlpzuD+y3qd6vR+LTf0Inc37y/LaRpCsocQ2bZ+YG7GON5FKuxqoHZYEAx7rtyC bnHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684718873; x=1687310873; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZJQtElzu+UD5ph8V4em11PgQpTFGHc0+htp6yYua+aY=; b=lP+hd0BYlbT7E1I6FEBxr9vT6pEgHsBeqodaPNNsfQcexmzopfJ9+o/A0mBQQxTWIw ORtysr4pvhkwzjmdIsFsCyaVm9Q21ZuRg3loB4lDkZgmc3fCTR3KCBNwlSdwB/KkIEU3 wC0/lSlq/CjpDgC7F2r2QkO7fvg9JCApbEtiqDbQA9o3q186quYAjMHgj7KUMyRLbCXd zfTBEXVTVQC6EykHvF5TsXcOG04dNhNuw8VcIze7oUqf/b3JLH6CbbfiYghDwCCEEVRb HHzbk3VZ4gJOvaEtca9OSZ4XVysRbBZQqwe6YQqtDEbFxU6+hAVql4mWJMg8T231xJFZ pjuw== X-Gm-Message-State: AC+VfDzC6BtN6E/qqiPkSosM4OpgSfyN4ZKWdic9Gk2+lbzYJocb7Hb2 FC2CubKIcom8FQL5OAEBeVwjIEYISa7OaGKHAL+8wJR7iLY= X-Google-Smtp-Source: ACHHUZ4H6vH9ubpSEJ/wt6Wx+Vo949yrpEky26ku89j4U/oiAlvsmQMGT8hTyU9OHixZOqZClisSXf/ta9ZjyNtLhJI= X-Received: by 2002:a6b:910:0:b0:76c:570f:ac84 with SMTP id t16-20020a6b0910000000b0076c570fac84mr5363628ioi.15.1684718872502; Sun, 21 May 2023 18:27:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Mon, 22 May 2023 02:27:41 +0100 Message-ID: To: F M , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000f1277505fc3e2da2" X-Mailman-Approved-At: Mon, 22 May 2023 09:33:28 +0000 Subject: Re: [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: Mon, 22 May 2023 01:27:55 -0000 --000000000000f1277505fc3e2da2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Lorban, The RFC is very clear and consistent on presenting payments pools in the context of non-custodial mining pools, congrats to the authoring team. Few feedbacks, on the technical definition of a payment pool, the common idea between all payment pools ideas presented so far (Joinpool, Radixpool, Coinpool) is the pool tree (what you're calling the payment tree) enabling a compact withdrawal from the pool, with more or less conservation of the pooling after a withdrawal. In 2., for the observation of the group of properties, there is one more which matters a lot if you would like to have off-chain novation of the pool tree, it's replay security, where a pool participant cannot replay its withdrawal, partially or in whole, after withdrawing all its balances. In 2.1, "as, for an integer n, the n! rapidly grows in size, it follows that the number of pre-signed transactions that has to be computed rapidly becomes too large"."This problem seems to not have been considered in [14]". The factorial complexity of the number of states (transactions/balances) in function of the number pool participants is mentioned in a footnote of the paper: "These restrictions could be also achieved by pre-signing all possible sequences of state transitions (producing, storing and exchanging all these signatures), which scales poorly (factorial) with the number of participants." and in the original mail post about Coinpool: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.ht= ml :) In 2.7, in the rational about using ANYPREVOUT, I think if you're using the ANYPREVOUT variant, the spent output amount is committed by the signature digest and I think this is introducing an interdependency between the validity of the payment tree and the block template of transactions, as in function of this latter the coinbase reward fluctuates ? I believe ANYPREVOUTANYSCRIPT is better as there is no such commitment to the spent amount/scriptPubkey iirc. About the attacks, effectively the lack of cooperation of pool participants to enable cooperative withdrawal is a huge DoS factor, it can be fought by fees to enter in the pool. Another deterrence is the timelocking of the balance in case of non-cooperative closure. Past force-closure of pools can be consumed as a proof of good-conduct by future co-participants in a payment pool. Best, Antoine Le mer. 3 mai 2023 =C3=A0 17:05, F M via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > > https://docs.google.com/document/d/1qiOOSOT7epX658_nhjz-jj0DlnSRvytemOv_u= _OtMcc/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 ther= e > 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= order 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 paymen= t > 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 R= FC > because it is not intended to be a comprehensive work. > > [0] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.= html > > [1] > https://docs.google.com/document/d/1qiOOSOT7epX658_nhjz-jj0DlnSRvytemOv_u= _OtMcc/edit?usp=3Dsharing > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000f1277505fc3e2da2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Hi Lorban,

The RFC is very clear and consistent on presenting payments pools in the co=
ntext of non-custodial mining pools, congrats to the authoring team.

Few feedbacks, on the technical definition of a payment pool, the common id=
ea between all payment pools ideas presented so far (Joinpool, Radixpool, C=
oinpool) is the pool tree (what you're calling the payment tree) enabli=
ng a compact withdrawal from the pool, with more or less conservation of th=
e pooling after a withdrawal.

In 2., for the observation of the group of properties, there is one more wh=
ich matters a lot if you would like to have off-chain novation of the pool =
tree, it's replay security, where a pool participant cannot replay its =
withdrawal, partially or in whole, after withdrawing all its balances.

In 2.1, "as, for an integer n, the n! rapidly grows in size, it follow=
s that the number of pre-signed transactions that has to be computed rapidl=
y becomes too large"."This problem seems to not have been conside=
red in [14]". The factorial complexity of the number of states (transa=
ctions/balances) in function of the number pool participants is mentioned i=
n a footnote of the paper: "These restrictions could be also achieved =
by pre-signing all possible sequences of state transitions (producing, stor=
ing and exchanging all these signatures), which scales poorly (factorial) w=
ith the number of participants." and in the original mail post about C=
oinpool: https://lists.linuxfoundation.org/pipermail/bitcoin=
-dev/2020-June/017964.html :)

In 2.7, in the rational about using ANYPREVOUT, I think if you're using=
 the ANYPREVOUT variant, the spent output amount is committed by the signat=
ure digest and I think this is introducing an interdependency between the v=
alidity of the payment tree and the block template of transactions, as in f=
unction of this latter the coinbase reward fluctuates ? I believe ANYPREVOU=
TANYSCRIPT is better as there is no such
commitment to the spent amount/scriptPubkey iirc.

About the attacks, effectively the lack of cooperation of pool participants=
 to enable cooperative withdrawal is a huge DoS factor, it can be fought by=
 fees to enter in the pool. Another deterrence is the timelocking of the ba=
lance in case of non-cooperative closure. Past force-closure of pools can b=
e consumed as a proof of good-conduct by future co-participants in a paymen=
t pool.

Best,
Antoine

Le=C2=A0mer. 3 mai 2023 =C3=A0=C2=A017:05, F M via bitc= oin-dev <bitcoi= n-dev@lists.linuxfoundation.org> a =C3=A9crit=C2=A0:

https://docs.google.com/document/d/1qiOOSOT7epX658_nhjz-jj0DlnSRvytemOv_= u_OtMcc/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 agreem= ent 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 approac= h to study 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

payment poo= ls, 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 reward [1]. This would make th= e pool non-custodial.

The main pools now are custodial, in the sense that they colle= ct 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 rule= d.

This i= s why we generally want non-custodial pools.

The only non-custodial payment pool tha= t 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. Th= is implies a very

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

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

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

several of= f-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 f= unds 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

fo= r future payment pools, in which the input=E2=80=99s references of the tran= sactions are left empty and the

signatures are ANYPREVOUT.

This makes it possible to safely c= reate 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 transac= tions for allowing safe

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

if the payment pool is set for the co-o= wnership of the mining reward, there must be a set of precompiled

transactions for e= very extranonce tried by every miner, that may not be feasible.

<= 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-ligatures:= normal;font-variant-caps:normal;font-variant-east-asian:normal;text-decorat= ion:none;vertical-align:baseline;white-space:pre-wrap">The use of ANYPREVOU= T allow the miners to collectively construct a payment tree that =E2=80=9Cw= aits=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 com= pared the average space occupied on the blockchain and compared with the

one of P2Po= ol. 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 i= s enclosed and labeled as an RFC. So, every

remark or comment may be very appreciat= ed.


Authors:

PS
Pl= ease note that although the linked document bears some resemblance to a res= earch paper, it is presented as an RFC. We chose to publish it as an RFC be= cause it is not intended to be a comprehensive work.


[0] https://lists.linuxfoundation.org/pipermail/b= itcoin-dev/2022-July/020763.html

[1]https://docs.google.com/document/d/1q= iOOSOT7epX658_nhjz-jj0DlnSRvytemOv_u_OtMcc/edit?usp=3Dsharing


<= /a>




=

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000f1277505fc3e2da2--