From c47d07728ab8877b6dbacd78dcf5099e76f1545f Mon Sep 17 00:00:00 2001 From: Gary Krause Date: Thu, 12 Sep 2024 06:44:51 -0500 Subject: [PATCH 1/3] Introduction --- pplns-with-job-declaration.tex | 92 +++++++++++++++++----------------- 1 file changed, 46 insertions(+), 46 deletions(-) diff --git a/pplns-with-job-declaration.tex b/pplns-with-job-declaration.tex index 76fb0cf..e67244e 100644 --- a/pplns-with-job-declaration.tex +++ b/pplns-with-job-declaration.tex @@ -21,12 +21,12 @@ \section{Introduction} -Right now, payout schemes for miners account only for provided hash power. -One of the biggest bitcoin issue is the centralization of transaction selection, this issue is solved by Stratum v2 \cite{sv2}. Given that Stratum v2 let the miner select their own transaction (this feature is known as \emph{Job Declaration}), and that transactions fees might become the most important part of the mining reward, we need a system that calculate the payouts based both on selected transactions and hash power provided. We propose a new payment schema, called PPLNS-JD, that expands PPLNS (see \cite{rosenfeld} and \cite{ocean}), so that miner will get paid in a fair way given the hash power provided, and the fees in the mined job. The core idea is that a miner perfoming Job Declaration who is more capable to find the best set of transactions in terms of fee over vbytes (and consequentially in fees of the block template), should be rewarded more. PPLNS-JD can be implemented as an extension of Sv2 \cite{extension} and it is easly accountable, so that miners' trust in pool operator is minimized. +Current payout schemes for miners account only for provided hash power. +One of the biggest issues for the Bitcoin network is the centralization of transaction selection, this issue is solved by Stratum v2 \cite{sv2}. Given that Stratum v2 lets a miner select their own transaction (this feature is known as \emph{Job Declaration}), and given transactions fees will likely become the largest part of the mining reward, the network needs a system that calculates payouts based both on selected transaction fees and hash power provided. We propose a new payment schema, called PPLNS-JD (or informally Job Slicing), that expands PPLNS (see \cite{rosenfeld} and \cite{ocean}), so a miner can be paid fairly given hash power provided, and fees in the mined job. The core idea is that a miner performing Job Declaration, who is more capable of optimizing transaction selection for fee over vbytes (and consequentially in fees of the block template), should be rewarded more. PPLNS-JD can be implemented as an extension of Sv2 \cite{extension} and it is easily accountable, so that miners' trust in pool operator is minimized. -We define a fair payment schema that splits the share payout in two parts. The first comes from the coinbase and pays accordingly to the difficulty score of the share, in the same fashion as PPLNS. The second comes from the block fee and pays accordigly to share difficulty score and the share fee score in such a way that share with the highest fee in its group of shares (slice, see below) is paid at least $F_S/n$, where $F_S$ is the part of the block fee reserved to that group of shares $S$ and $n$ is the number of shares in $S$. +We define a fair payment schema that splits the share payout in two parts. The first comes from the block subsidy and pays accordingly to the difficulty score of the share, in the same fashion as PPLNS. The second comes from the block fees and pays accordingly to share difficulty score and the share fee score in such a way that the share with the highest fee in its group of shares (slice, see below) is paid at least $F_S/n$, where $F_S$ is the part of the block fee reserved to that group of shares $S$ and $n$ is the number of shares in $S$. -In the following, we will call the \emph{window} of PPLNS the shares that are paid once that a block is found by some pool's miner. So, the windows size is $N$, where $N$ is symbol used for the acronym "Pay Per Last $N$ Shares". We will call also \emph{mining round} the number of shares produced in the time between a Bitcoin block and the following one or, equivalently, all the shares \emph{with the same prev-hash}. +In the following, a \emph{window} is a group of PPLNS shares that are paid once a block is found by the pool. So, the windows size is $N$, where $N$ is symbol used for the acronym "Pay Per Last $N$ Shares". A \emph{mining round} is the number of shares produced in the time between a Bitcoin block and the following one or, equivalently, all the shares \emph{with the same prev-hash}. \section{Slices} In order to pay shares in a fair way with respect to fees, they must be scored somehow and the payout of the block fee must be redistributed accodingly to this score. Doing so, it is necessary to divide them in groups and compare scores only for shares belonging to the same group. Indeed, does not make any sense compare two shares taken randomly in the PPLNS window, because the mempool maximum extractable fees (MMEF) may change consistently. Indeed, it is difficult even to compare shares produced in a single mining round. @@ -67,34 +67,34 @@ \subsection{Fee-based score} Suppose we want to score the $i$-th share $s_i$, and suppose that this share belongs to a slice $S$ that contains all the shares from the $k_1$-th to the $k_2$-th. For the $i$-th share, call $\bar d_i = score_d(s_i)$ its score difficulty (calculated as above) and $f_i$ the fees of the share (which depends on the transactions chosen in the template). For this share, define the score relative to the fee \[ -score_f(s_i) = \frac{\bar d_if_i}{\sum_{j=k_1}^{k_2}\bar d_j f_j}. + score_f(s_i) = \frac{\bar d_if_i}{\sum_{j=k_1}^{k_2}\bar d_j f_j}. \] \begin{remark}\label{properties-diff-based-score} -\begin{enumerate} -\item As remaked earlier, the dependence on difficulty is intentional. Otherwise, if there are two shares with the same fee, the one with lower difficulty is paid the same as the other, while requiring less computational effort to be produced. -\item Suppose that the slice $S$ contains $n$ shares, all of the same difficulty score. Then, if $f_i = f_{max}$ is the max fee of every share in the slice $S$, then the payout for this share is at least $score_f(s_i) \ge 1/n$. This sentence is proven by contraddiction. So, assume that -\[score_f(s_i) < 1/n.\] -Since all the shares have the same difficulty score, we have -\[\frac{\bar d_if_{max}}{\sum_j d_j f_j} = \frac{f_{max}}{\sum_j f_j}.\]It follows that -\[ \frac{f_{max}}{\sum_j f_j} <\frac{1} {n}.\] -So, -\[ 1 = \frac{\sum_k f_k}{\sum_j f_j} = \sum_k \frac {f_k}{\sum_j f_j} \le \sum_k \frac{f_{max}}{\sum_j f_j}<\sum_k\frac{1}{n} = 1\] -which is impossible. -\item if there is $c>0$ such that $f_i = cf_j$ for some $s_i, s_j$ two shares in the slice $S$, then $payout_f(s_i) = c \cdot payout_f(s_j)$. This means that if a miner becomes $c$ times more capable of finding a more profitable template, his shares will be paid proportionally. -\item similarly, if $\bar d_i = c \bar d_j$, then $payout_f(s_i) = c \cdot payout_f(s_j)$ this similarly represents the fact that a miner is paid proportionally with respect his hashpower. -\item similarly to difficulty score, if the slice $S$ contains shares from $k_1$-th to $k_2$-th, we have \[\sum_{i=k_1}^{k_2} score_f(s_i) = 1. \] \label{addstoone} -\end{enumerate} + \begin{enumerate} + \item As remaked earlier, the dependence on difficulty is intentional. Otherwise, if there are two shares with the same fee, the one with lower difficulty is paid the same as the other, while requiring less computational effort to be produced. + \item Suppose that the slice $S$ contains $n$ shares, all of the same difficulty score. Then, if $f_i = f_{max}$ is the max fee of every share in the slice $S$, then the payout for this share is at least $score_f(s_i) \ge 1/n$. This sentence is proven by contraddiction. So, assume that + \[score_f(s_i) < 1/n.\] + Since all the shares have the same difficulty score, we have + \[\frac{\bar d_if_{max}}{\sum_j d_j f_j} = \frac{f_{max}}{\sum_j f_j}.\]It follows that + \[ \frac{f_{max}}{\sum_j f_j} <\frac{1} {n}.\] + So, + \[ 1 = \frac{\sum_k f_k}{\sum_j f_j} = \sum_k \frac {f_k}{\sum_j f_j} \le \sum_k \frac{f_{max}}{\sum_j f_j}<\sum_k\frac{1}{n} = 1\] + which is impossible. + \item if there is $c>0$ such that $f_i = cf_j$ for some $s_i, s_j$ two shares in the slice $S$, then $payout_f(s_i) = c \cdot payout_f(s_j)$. This means that if a miner becomes $c$ times more capable of finding a more profitable template, his shares will be paid proportionally. + \item similarly, if $\bar d_i = c \bar d_j$, then $payout_f(s_i) = c \cdot payout_f(s_j)$ this similarly represents the fact that a miner is paid proportionally with respect his hashpower. + \item similarly to difficulty score, if the slice $S$ contains shares from $k_1$-th to $k_2$-th, we have \[\sum_{i=k_1}^{k_2} score_f(s_i) = 1. \] \label{addstoone} + \end{enumerate} \end{remark} \subsection{Payout for each share} Suppose that we want to pay the $i$-th share. This share will belong to a slice $S$, to which is reserved a portion of block fees subsidy $F_S$. Then the payout is \[payout(s_i) = r\cdot score_d(s_i) + F_S \cdot score_f(s_i).\] - The redistribution of the coinbase reward necessarly depend only on $d_i$, because it is guaranteed even in empty blocks, so it is independent from work selection. +The redistribution of the coinbase reward necessarly depend only on $d_i$, because it is guaranteed even in empty blocks, so it is independent from work selection. We can see that the payouts of all shares add up to the right amount. Suppose that $N$ is the size of PPLNS window and that the slices are $S_1, \dots, S_t$, and suppose that there are $0=k_00$ and $c>c$ such that +\textbf{Note.} From now on we assume that the growth of fees within a slice (which we stress coincides with a mining round) is linear, namely there are $m>0$ and $c>c$ such that \[F(f) = mt+c.\] -Suppose furthermore that there are $100$ shares received by the pool in the time of the block to which belong the share $s_i$ (that coincides with the time frame of the slice $S$). It is no loss to assume that the distribution of these shares in this timeframe is uniform. For a share $s_j$ in $S$, we have that +Suppose furthermore that there are $100$ shares received by the pool in the time of the block to which belong the share $s_i$ (that coincides with the time frame of the slice $S$). It is no loss to assume that the distribution of these shares in this timeframe is uniform. For a share $s_j$ in $S$, we have that \[ f_j = m(6secs \cdot j) +c,\] so \begin{align*} - score_f(is_i) &= \frac{m(6secs\cdot i) +c}{\sum_{j=1}^{100} m(6secs\cdot j) +c}\\ - &= \frac{m(6\cdot i) +c}{m\cdot 6\cdot\frac{100\cdot101}{2} +c\cdot 100}\\ - &= \frac{m(6\cdot i) +c}{100(303\cdot m +c)} + score_f(is_i) & = \frac{m(6secs\cdot i) +c}{\sum_{j=1}^{100} m(6secs\cdot j) +c} \\ + & = \frac{m(6\cdot i) +c}{m\cdot 6\cdot\frac{100\cdot101}{2} +c\cdot 100} \\ + & = \frac{m(6\cdot i) +c}{100(303\cdot m +c)} \end{align*} -and +and \[payout_f(s_i) = \frac{F}{8} \cdot \frac{m(6\cdot i) +c}{100(303\cdot m +c)}.\] Hence, there must be a $\bar i$ such that $payout_f(s_{\bar i -1})< F/8000 Date: Thu, 12 Sep 2024 09:19:28 -0500 Subject: [PATCH 2/3] scores --- pplns-with-job-declaration.tex | 51 +++++++++++++++++++++++----------- 1 file changed, 35 insertions(+), 16 deletions(-) diff --git a/pplns-with-job-declaration.tex b/pplns-with-job-declaration.tex index e67244e..3f572fa 100644 --- a/pplns-with-job-declaration.tex +++ b/pplns-with-job-declaration.tex @@ -21,38 +21,57 @@ \section{Introduction} -Current payout schemes for miners account only for provided hash power. -One of the biggest issues for the Bitcoin network is the centralization of transaction selection, this issue is solved by Stratum v2 \cite{sv2}. Given that Stratum v2 lets a miner select their own transaction (this feature is known as \emph{Job Declaration}), and given transactions fees will likely become the largest part of the mining reward, the network needs a system that calculates payouts based both on selected transaction fees and hash power provided. We propose a new payment schema, called PPLNS-JD (or informally Job Slicing), that expands PPLNS (see \cite{rosenfeld} and \cite{ocean}), so a miner can be paid fairly given hash power provided, and fees in the mined job. The core idea is that a miner performing Job Declaration, who is more capable of optimizing transaction selection for fee over vbytes (and consequentially in fees of the block template), should be rewarded more. PPLNS-JD can be implemented as an extension of Sv2 \cite{extension} and it is easily accountable, so that miners' trust in pool operator is minimized. +Current payout schemes for mining pools account only for provided hashrate, which is not ideal for Job Declaration. -We define a fair payment schema that splits the share payout in two parts. The first comes from the block subsidy and pays accordingly to the difficulty score of the share, in the same fashion as PPLNS. The second comes from the block fees and pays accordingly to share difficulty score and the share fee score in such a way that the share with the highest fee in its group of shares (slice, see below) is paid at least $F_S/n$, where $F_S$ is the part of the block fee reserved to that group of shares $S$ and $n$ is the number of shares in $S$. +One of the biggest issues for the Bitcoin network is the centralization of transaction selection, this issue is solved by Stratum v2 \cite{sv2}. Stratum v2 enables a miner to select their own block template of transactions (this feature is known as \emph{Job Declaration}). Since transactions fees will become the largest percentage of the block reward, the network needs a system that calculates payouts based both on selected transaction fees and hashrate provided. We propose a new payment schema, called PPLNS-JD (or informally Job Slicing), that expands PPLNS (see \cite{rosenfeld} and \cite{ocean}), so a miner can be paid fairly given hashrate provided, and fees in the mined block template. The core idea is that a miner performing Job Declaration, who are more capable of optimizing transaction selection for fee over vbytes (and consequentially in fees of the block template), should be rewarded more. PPLNS-JD can be implemented as an extension of Sv2 \cite{extension} and it is easily accountable, so that miners' trust in pool operator is minimized. + +We define a fair accounting schema that splits pool payout in two parts. The first comes from the block subsidy and pays accordingly to the difficulty score of the share, in the same fashion as traditional PPLNS. The second comes from the block fees and pays accordingly to share difficulty score and the block fees in such a way that the share with the highest fee in its group of shares (slice, see below) is paid at least $F_S/n$, where $F_S$ is the part of the block fee reserved to that group of shares $S$ and $n$ is the number of shares in $S$. In the following, a \emph{window} is a group of PPLNS shares that are paid once a block is found by the pool. So, the windows size is $N$, where $N$ is symbol used for the acronym "Pay Per Last $N$ Shares". A \emph{mining round} is the number of shares produced in the time between a Bitcoin block and the following one or, equivalently, all the shares \emph{with the same prev-hash}. +\section{Terminology} + +Readers unfamiliar with bitcoin mining at a technical level may benefit from the following common terminology definitions: + +\begin{enumerate} + \item difficulty - an amount of leading zeroes in a given hash, the Bitcoin consensus rules use this when validating blocks, there is a Bitcoin wide network difficulty that is known and calculated independently by all nodes + \item share - a hash of a certain difficulty determined by the pool but insufficient to satisfy the networks difficulty, shares are submitted by miners as proof of work to a pool, pools often dynamically set the share difficulty for miners + \item job - data given to a miner to hash on, including but not limited to a block template + \item work - common term when discussing difficulty of shares, work is often the difficulty of an individual share or a the sum of multiple shares difficulty + \item block fees - a portion of every transaction paid to miners + \item block subsidy - the predetermined supply issuance of bitcoin in a block, this value halves every 210,000 blocks, the initial subsidy was 50 bitcoin per block + \item block reward - block subsidy + block fees +\end{enumerate} + \section{Slices} -In order to pay shares in a fair way with respect to fees, they must be scored somehow and the payout of the block fee must be redistributed accodingly to this score. Doing so, it is necessary to divide them in groups and compare scores only for shares belonging to the same group. Indeed, does not make any sense compare two shares taken randomly in the PPLNS window, because the mempool maximum extractable fees (MMEF) may change consistently. Indeed, it is difficult even to compare shares produced in a single mining round. +In order to pay shares fairly with Job Declaration, shares must be scored by fees earned in a block template and the payout of the block fees must be distributed accordingly. Doing so, it is necessary to divide them into groups and compare scores only for shares belonging to the same group. Comparing two shares taken randomly in a traditional PPLNS window is inaccurate, because the mempool maximum extractable fees (MMEF) may change consistently. The same is true for randomly selected shares within a mining round. -We call a group of shares whose fees can be scored (and the scores can be compared) a \emph{slice}, which is a portion of the stream of shares. As we seen in the previous paragraph, a slice must not cross two mining rounds. With other words, all shares in one slice must have the same prevhash. It is needed an introduction before giving the precise definition of a slice. +We call a group of shares whose fees can be scored (and the scores can be compared) a \emph{slice}, which is a portion of the stream of shares. A slice must not cross two mining rounds and all shares in one slice must have the same prevhash. A more precise definition of a \emph{slice} -Note that within a mining round, MMEF can not decrease. Indeed, the only way to remove high fees transactions from mempool is to have them mined. Therefore, MMEF grows monotonically within a single mining round. If a slice consists of \emph{all} the shares with the same prevhash (namely the slice consists of the shares produced between two consecutive blocks), there are some incentives for miners to performs a variation of pool hopping (see Appendix). +Note that within a mining round, MMEF can not decrease. The only way to remove high fees transactions from mempool is to have them mined, therefore, MMEF grows monotonically within a single mining round. If a slice consists of \emph{all} the shares with the same prevhash (the slice consists of the shares produced between two consecutive blocks), there are some incentives for miners to performs a variation of pool hopping (see Appendix). -To remove this incentive, slices must be shorter than the entire mining round. Intuitively, they must be short enough to be possible for the fees to be approximated as constant. Since a slice ends when starts the following one, it is enough define when a slice begins. Note that the slices are created by the pool and recall that they are used to calculate the score based on fees. To each slice is associated a reference job. Fix $f$ the fees of a particular reference job. Let $\delta>0$ chosen by the pool. Then, every share that belong to the slices relative to the reference job must have fees lower than -\[ f+\delta.\] -A new slice is created if one of the two event happen: +To remove this incentive, slices must be shorter than the entire mining round. Intuitively, they must be short enough to be possible for the fees to be approximated as constant. Since a slice ends when a new slice begins, it is enough to define when a slice begins. The slices are created by the pool and the score is calculated based on fees. Each slice has a reference job. We assign $f$ the fees of a particular reference job. Let $\delta>0$ be chosen by the pool. Then, every share that belongs to the slice for a reference job must have fees lower than \[ f+\delta.\] + +A new slice is created and the reference job for the slice is updated when the pool receives a share in which: \begin{enumerate} - \item the pool receive a share for a job that have fees bigger or equal then $f+\delta$, where $f$ the actual slice reference job fee. The new slice reference job is this job. - \item the pool receive a share for a job that have a prevhash different from the actual slice reference job. The new slice reference job is this job. + \item fees are greater than or equal to $f+\delta$ (increased MMEF) + \item have a prevhash different from the actual slice reference job (new block) \end{enumerate} -Every share received by the pool that do not have a job that meet condition 1. or 2. is put in the actual slice. The above means that we create a new slice every time that the MMEF change: 1. is when MMEF grows and 2. is when a new block have been found and MMEF is lower or equal. +Every share received by the pool that does not meet condition 1 or 2 is put in the existing slice. +%I'm not certain I articulated this correctly.% If there are $t$ slices in the window and $F$ are the collected fees of the mined block, assign to each slice $S$ an amount $F_S = F/t$. Then, all the shares will be scored basing on the fees of selected transactions and $F_S$ will be redistributed to all the shares of $S$ accordingly with its fee score. +% I wonder if this scoring paragraph should be moved below. % \section{Scores} -In PPLNS, once that some pool's miner finds a block, every share in the windows will be scored based on difficulty and the full block reward (coinbase and block fees) will be redistibuted accordingly. This is the ground idea of PPLNS and it is based on the fact that the work selection is performed by the pool, so all the miners are mining on the same job. If we add the Job Declaration feature, this type of scoring is not anymore fair. Indeed, suppose that there are two minewrs with the same hashpower, and both perform Job Declaration. The first is very effective in doing that, and the second not so much. So, the shares produced by the first will have higher fees than the second. On the other hand, the difficulty of the shares of the two miners will be equal, so the payout. This is not fair, because the first miner should be paid a bit more than the second. +In normal PPLNS, once the pool finds a block, every share in the window is scored and the full block reward (coinbase and block fees) is distributed accordingly. This scoring assumes all miners are mining on the same job provided by the pool. With the addition of Job Declaration, this type of scoring becomes unfair. + +Given two miners with the same hashrate that submit the same amount of work to the pool, but each has different block templates via Job Declaration. The first miner optimizes transaction selection for maximum fees, and the second not so much. With traditional PPLNS, these two miners are paid equally since only hashrate (work submitted via shares) is considered. This is unfair as the miner with optimized transaction fees is working toward higher block reward for the pool, and should be rewarded commensurately. -In this section we aim to solve this issue. The idea of our proposal is to split the payout of each share, and redistribute the coinbase reward and the block fee separately. Since the coinbase reward is independend on the other transactions in the block, it is also independent from Job Declaration, and therefore will be redistributed in base of the difficulty score $score_d(s_i)$ of the $i$-th share $s_i$. So, the coinbase reward will be redistributed in the same fashion as standard PPLNS. \newline -For the block difficulty, we must introduce a method to weight shares based on the fees. We must neither lose the dependency on the difficulty, because in the future miners are supposed to be paid mainly with fees. So, the block fees are supposed to be redistributed amongs miners based on a score $score_d(s_i)$ that depends both difficulty and the fees of every share. +To solve this inequity, we split the payout of each share, and score the block subsidy and the block fee differently. Since the block reward is determined independent of other transactions in the block, we also consider it independently from Job Declaration. We distribute the block reward based on traditional PPLNS share scoring: $score_d(s_i)$ of the $i$-th share $s_i$.\newline +For Job Declaration, we must introduce a new method to calculate $score_d(s_i)$ based on the fees for a submitted share, while retaining the score based on the work of submitted shares. This is desireable as the block subsidy trends to zero and fees become the predominate value of a block reward. -In the final subsection it will be given the precise definition for the payout of $s_i$. +In the final subsection precise definition for the payout of $s_i$ is given. \subsection{Difficulty-based score} If the window contains $N$ shares, then for the $i$-th share $s_i$ we define its score From e0b1a85514622c347a59d37f20a4f487cf84434e Mon Sep 17 00:00:00 2001 From: Gary Krause Date: Thu, 12 Sep 2024 14:53:17 -0400 Subject: [PATCH 3/3] edits --- pplns-with-job-declaration.tex | 82 +++++++++++++++++----------------- 1 file changed, 41 insertions(+), 41 deletions(-) diff --git a/pplns-with-job-declaration.tex b/pplns-with-job-declaration.tex index 3f572fa..4343dc6 100644 --- a/pplns-with-job-declaration.tex +++ b/pplns-with-job-declaration.tex @@ -41,6 +41,7 @@ \section{Terminology} \item block fees - a portion of every transaction paid to miners \item block subsidy - the predetermined supply issuance of bitcoin in a block, this value halves every 210,000 blocks, the initial subsidy was 50 bitcoin per block \item block reward - block subsidy + block fees + \item hashrate - the amount of hashes per second, generally calculated using shares within a time frame, certain machines have "sticker hashrate" which is a general number to indicate the machines level of efficiency for hashing. Commonly represented as Terrahash or Gigahasg per second (TH/s or GH/s) \end{enumerate} \section{Slices} @@ -50,7 +51,7 @@ \section{Slices} Note that within a mining round, MMEF can not decrease. The only way to remove high fees transactions from mempool is to have them mined, therefore, MMEF grows monotonically within a single mining round. If a slice consists of \emph{all} the shares with the same prevhash (the slice consists of the shares produced between two consecutive blocks), there are some incentives for miners to performs a variation of pool hopping (see Appendix). -To remove this incentive, slices must be shorter than the entire mining round. Intuitively, they must be short enough to be possible for the fees to be approximated as constant. Since a slice ends when a new slice begins, it is enough to define when a slice begins. The slices are created by the pool and the score is calculated based on fees. Each slice has a reference job. We assign $f$ the fees of a particular reference job. Let $\delta>0$ be chosen by the pool. Then, every share that belongs to the slice for a reference job must have fees lower than \[ f+\delta.\] +To remove this incentive, slices must be shorter than the entire mining round. Intuitively, they must be short enough to be possible for the fees to be approximated as constant. Since a slice ends when a new slice begins, it is enough to define when a slice begins. The slices are created by the pool and the score is calculated based on fees. Each slice has a \emph{reference job}. We assign $f$ the fees of a particular reference job. Let $\delta>0$ be chosen by the pool. Then, every share that belongs to the slice for a reference job must have fees lower than \[ f+\delta.\] A new slice is created and the reference job for the slice is updated when the pool receives a share in which: \begin{enumerate} @@ -76,22 +77,22 @@ \section{Scores} \subsection{Difficulty-based score} If the window contains $N$ shares, then for the $i$-th share $s_i$ we define its score \[score_d(s_i) = \frac{d_i}{\sum_{j=1}^Nd_j},\] -where $d_j$ is the difficulty of the share $s_j$ (for example, \cite{ocean} suggest to adopt $N$ such that the sum at the denominator eight times the bitcoin difficulty).\newline +where $d_j$ is the difficulty of the share $s_j$ (for example, Ocean TIDES\cite{ocean} suggest $N$ be the sum at the denominator eight times the bitcoin difficulty).\newline \begin{remark} - Note that - \[\sum_{j=1}^N score_d(s_i) = 1\] and that this score depends only on difficulty. + Note that \[\sum_{j=1}^N score_d(s_i) = 1\] depends only on difficulty. \end{remark} -\[\sum_{j=1}^N score_d(s_i) = 1\] and that this score depends only on difficulty. + \subsection{Fee-based score} Suppose we want to score the $i$-th share $s_i$, and suppose that this share belongs to a slice $S$ that contains all the shares from the $k_1$-th to the $k_2$-th. -For the $i$-th share, call $\bar d_i = score_d(s_i)$ its score difficulty (calculated as above) and $f_i$ the fees of the share (which depends on the transactions chosen in the template). For this share, define the score relative to the fee +For the $i$-th share, $\bar d_i = score_d(s_i)$ is the difficulty-based score (calculated as above) and $f_i$ the fees of the share (which depends on the transactions chosen in the template). We define the score relative to the fee \[ score_f(s_i) = \frac{\bar d_if_i}{\sum_{j=k_1}^{k_2}\bar d_j f_j}. \] \begin{remark}\label{properties-diff-based-score} \begin{enumerate} - \item As remaked earlier, the dependence on difficulty is intentional. Otherwise, if there are two shares with the same fee, the one with lower difficulty is paid the same as the other, while requiring less computational effort to be produced. - \item Suppose that the slice $S$ contains $n$ shares, all of the same difficulty score. Then, if $f_i = f_{max}$ is the max fee of every share in the slice $S$, then the payout for this share is at least $score_f(s_i) \ge 1/n$. This sentence is proven by contraddiction. So, assume that + \item The dependence on difficulty-based scoring is intentional so two shares with the same fee also account for computational work needed. + \item A slice $S$ contains $n$ shares, all of the same difficulty score. If $f_i = f_{max}$ is the max fee of every share in the slice $S$, then the payout for this share is at least $score_f(s_i) \ge 1/n$. This sentence is proven by contradiction. So, assume that + % I don't understand what "contradiction" means here \[score_f(s_i) < 1/n.\] Since all the shares have the same difficulty score, we have \[\frac{\bar d_if_{max}}{\sum_j d_j f_j} = \frac{f_{max}}{\sum_j f_j}.\]It follows that @@ -99,50 +100,48 @@ \subsection{Fee-based score} So, \[ 1 = \frac{\sum_k f_k}{\sum_j f_j} = \sum_k \frac {f_k}{\sum_j f_j} \le \sum_k \frac{f_{max}}{\sum_j f_j}<\sum_k\frac{1}{n} = 1\] which is impossible. - \item if there is $c>0$ such that $f_i = cf_j$ for some $s_i, s_j$ two shares in the slice $S$, then $payout_f(s_i) = c \cdot payout_f(s_j)$. This means that if a miner becomes $c$ times more capable of finding a more profitable template, his shares will be paid proportionally. - \item similarly, if $\bar d_i = c \bar d_j$, then $payout_f(s_i) = c \cdot payout_f(s_j)$ this similarly represents the fact that a miner is paid proportionally with respect his hashpower. + \item if there is $c>0$ such that $f_i = cf_j$ for some $s_i, s_j$ two shares in the slice $S$, then $payout_f(s_i) = c \cdot payout_f(s_j)$. This means that if a miner becomes $c$ times more capable of finding a template with higher fees, the shares will be paid proportionally. + \item similarly, if $\bar d_i = c \bar d_j$, then $payout_f(s_i) = c \cdot payout_f(s_j)$ similarly represents the fact that a miner is paid proportionally with respect his hashrate. \item similarly to difficulty score, if the slice $S$ contains shares from $k_1$-th to $k_2$-th, we have \[\sum_{i=k_1}^{k_2} score_f(s_i) = 1. \] \label{addstoone} \end{enumerate} \end{remark} \subsection{Payout for each share} -Suppose that we want to pay the $i$-th share. This share will belong to a slice $S$, to which is reserved a portion of block fees subsidy $F_S$. Then the payout is - +When accounting for the $i$-th share, the share will belong to a slice $S$, to which a portion of block fees subsidy $F_S$ is reserved. The payout is \[payout(s_i) = r\cdot score_d(s_i) + F_S \cdot score_f(s_i).\] -The redistribution of the coinbase reward necessarly depend only on $d_i$, because it is guaranteed even in empty blocks, so it is independent from work selection. -We can see that the payouts of all shares add up to the right amount. Suppose that $N$ is the size of PPLNS window and that the slices are $S_1, \dots, S_t$, and suppose that there are $0=k_00$ and $c>c$ such that +\textbf{Note.} From now on we assume that the growth of fees within a slice (which coincides within a mining round) is linear, namely there are $m>0$ and $c>c$ such that \[F(f) = mt+c.\] -Suppose furthermore that there are $100$ shares received by the pool in the time of the block to which belong the share $s_i$ (that coincides with the time frame of the slice $S$). It is no loss to assume that the distribution of these shares in this timeframe is uniform. For a share $s_j$ in $S$, we have that +Futhermore, there are $100$ shares received by the pool in the time of the block to which share belong to $s_i$ (that coincides with the time frame of the slice $S$). It is safe to assume that the distribution of these shares in this timeframe is uniform. For a share $s_j$ in $S$, we have that \[ f_j = m(6secs \cdot j) +c,\] so \begin{align*} @@ -189,8 +188,9 @@ \section{Motivation for slices} and \[payout_f(s_i) = \frac{F}{8} \cdot \frac{m(6\cdot i) +c}{100(303\cdot m +c)}.\] Hence, there must be a $\bar i$ such that $payout_f(s_{\bar i -1})< F/8000