Review/Revision #1
Conversation
|
If the fees for jobs are high but I start mining with a lesser fee, am I still included in the slice for the higher fee template? |
|
|
||
| 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$. | ||
| 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. |
There was a problem hiding this comment.
Why Job Slicing? Do you have any motivation for changing naming it like this?
JD stands for Job Declaration, so if we call it PPLNS-JD sounds strange to refer it to Job Slicing
There was a problem hiding this comment.
Couldn't think of a shorter name that was relevant. Saying "PPLNS-JD" is undesirable though. I am open to other names but thought it reasonable to add something here as an example. I'm also fine with omitting a short name in the text here.
There was a problem hiding this comment.
Share Slicing?
Because the shares are sliced into groups.
There was a problem hiding this comment.
It is a variation of Pay Per Last N Shares, so it must contain PPLNS in the name, IMO
| 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 |
There was a problem hiding this comment.
this is not true.
The difficulty is inversely related to the target. In fact, I think it should be
where
The idea is that if you call a quantity " difficulty", you expect that it increases if the work becomes more difficult, but in bitcoin harder works have a lower target, that's why we put it at the denominator.
There was a problem hiding this comment.
I don't understand this and will probably need to chat synchronously to grok it.
There was a problem hiding this comment.
I think you can see it here
https://en.bitcoin.it/wiki/Difficulty
| 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}. | ||
| 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}. |
There was a problem hiding this comment.
I you want to introduce a terminology section, these definition should be put there!
There was a problem hiding this comment.
Perhaps in a Glossary at the end but the initial definitions were for things not defined within the write up. Since window is defined in the paper, I didn't feel it needed to be in the definitions
| \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 |
There was a problem hiding this comment.
I wouldn't put this definition, it is kind of vague. I prefer use work with the usual semantic of the word.
|
|
||
| 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} |
There was a problem hiding this comment.
A more precise definition of a \emph{slice} ...?
I think you forgot to finish the phrase
| \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.% |
There was a problem hiding this comment.
I would like to stress the fact that a new shares is created every time that MEEF change. condition 1. is related to the fact that MMEF grows, and condition 2. is related to the appearence of a new block, meaning that MMEF decreases with a jump
|
|
||
| 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. % |
There was a problem hiding this comment.
we are just reserving a part of block reward to every slice, no scoring involved
| \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. |
There was a problem hiding this comment.
I found I typo reading this change. The summation index should be
| \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 The dependence on difficulty-based scoring is intentional so two shares with the same fee also account for computational work needed. |
There was a problem hiding this comment.
I would change it like this
" As mentioned above, it is important that so two shares with the same fee also account for computational work needed. Without this, two shares with the same fee would be paid equally, benefiting the one that required less computational effort to be produced. The most natural way to fix this is to construct fee-based score on top of difficulty-based score."
| \begin{enumerate} | ||
| \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 |
There was a problem hiding this comment.
it is a way to prove a statement.
You want to prove a statement
Here,
More details here
https://en.wikipedia.org/wiki/Proof_by_contradiction
|
|
||
| \item verify the Merkle tree for the slice with provided merkle path | ||
| \item verify the sum of the difficulty of verified shares is not greater then the slice difficulty | ||
| % I don't follow this one and hope to clarify % |
There was a problem hiding this comment.
What item you want to be clarified? The one above or below?
| \end{itemize} | ||
| Since redistribution of coinbase reweard is fixed with both methods, we assume it to be zero and we consider only the redistribution of block fees subsidy $F$. | ||
| Since distribution of block subsidy is fixed with both methods, we assume it to be zero and we consider only the distribution of block fees $F$. |
There was a problem hiding this comment.
Thank you, block fees subsidy doesn't make much sense
With Gary's review demand-open-source#1 I took advantage to apply a major review. Most notable changes are in chapter 3, where I treated uniformly the linearity of scoring, and added the consequences of it in Remark 3.3.1 for the actual payout. Apart from this, just minor changes.
With Gary's review demand-open-source#1 I took advantage to apply a major review. Most notable changes are in chapter 3, where I treated uniformly the linearity of scoring, and added the consequences of it in Remark 3.3.1 for the actual payout. Add notations in appendix Apart from this, just minor changes.
With Gary's review demand-open-source#1 I took advantage to apply a major review. Most notable changes are in chapter 3, where I treated uniformly the linearity of scoring, and added the consequences of it in Remark 3.3.1 for the actual payout. Add notations in appendix Apart from this, just minor changes.
With Gary's review demand-open-source#1 I took advantage to apply a major review. Most notable changes are in chapter 3, where I treated uniformly the linearity of scoring, and added the consequences of it in Remark 3.3.1 for the actual payout. Add notations in appendix Apart from this, just minor changes.
With Gary's review demand-open-source#1 I took advantage to apply a major review. Most notable changes are in chapter 3, where I treated uniformly the linearity of scoring, and added the consequences of it in Remark 3.3.1 for the actual payout. Add notations in appendix Apart from this, just minor changes.
With Gary's review #1 I took advantage to apply a major review. Most notable changes are in chapter 3, where I treated uniformly the linearity of scoring, and added the consequences of it in Remark 3.3.1 for the actual payout. Add notations in appendix Apart from this, just minor changes.
With Gary's review demand-open-source#1 I took advantage to apply a major review. Most notable changes are in chapter 3, where I treated uniformly the linearity of scoring, and added the consequences of it in Remark 3.3.1 for the actual payout. Add notations in appendix Apart from this, just minor changes.
With Gary's review #1 I took advantage to apply a major review. Most notable changes are in chapter 3, where I treated uniformly the linearity of scoring, and added the consequences of it in Remark 3.3.1 for the actual payout. Add notations in appendix Apart from this, just minor changes.
With Gary's review demand-open-source#1 I took advantage to apply a major review. Most notable changes are in chapter 3, where I treated uniformly the linearity of scoring, and added the consequences of it in Remark 3.3.1 for the actual payout. Add notations in appendix Apart from this, just minor changes.
For some of the content, I took liberties in making larger changes than I thought initially. I hope two discuss these changes and address some of the comments I left in the doc.