Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review #1

Open
plebhash opened this issue Sep 6, 2024 · 10 comments
Open

Review #1

plebhash opened this issue Sep 6, 2024 · 10 comments

Comments

@plebhash
Copy link

plebhash commented Sep 6, 2024

Starting this issue with some reviews and suggestions

@plebhash
Copy link
Author

plebhash commented Sep 6, 2024

In the beginning of Section 2, the term "mining round" is defined:

Indeed, it is difficult even to compare shares produced between a block and the following (we call this a mining round).

But then, there are multiple references to the term "window".

As a reader, I felt confused by this. What is a "window"? Is it the same idea as a "mining round"?

  • If yes: it would be good to unify all references to this concept under the same name, and avoid implicit synonyms.
  • If no: it would be good to avoid confusion by providing a formal definition for the term "window".

@plebhash
Copy link
Author

plebhash commented Sep 6, 2024

The paper is using the term coinbase reward in a way that IMHO could cause confusion to the reader.

My understanding of coinbase reward is: the total sum of satoshis in the outputs of the coinbase.

Those sats are being "minted", in the sense that:

  • new sats were created out of thin air as part of the block subsidy (50 BTC, 25 BTC, 12.5 BTC, etc...)
  • fees were "burned" on the outputs of their transactions, and an equivalent amount of sats are created from thin air into the coinbase outputs

The paper is currently using the term coinbase reward (represented by variable $r$) to refer to what I just called block subsidy, where perhaps a different letter could be used to represent this variable (e.g.: $B$).

I believe the term coinbase reward should be reserved for the more generic idea of the total sum of rewards in the coinbase (which is correctly represented as variable $R$ ).

In other words:

$Coinbase Reward = Block Subsidy + Fees$

or:

$R = B + F$

@plebhash
Copy link
Author

plebhash commented Sep 6, 2024

In Section 3.1 (Remark)

If I understand correctly, this formula should be:

$\sum_{i=0}^{N} score_d(s_i) = 1$

in other words: index of sum is $i$, not $j$

@plebhash plebhash changed the title Review: PPLNS with Job Declaration Review Sep 6, 2024
@plebhash
Copy link
Author

plebhash commented Sep 6, 2024

While I read SV2 stuff, I like to create visual diagrams to help me understand things better. I did something similar for stratum-mining/sv2-spec#98 and felt it was a very valuable learning experience for me.

While I read this paper, I created some visuals to organize my thoughts.

If the authors feel they are useful, they are free to use and modify them without attribution.

All files were created on the platform draw.io, and are available for further customization as different pages on this link.

PPLNS with Job Declaration-coinbase reward drawio (1)

PPLNS with Job Declaration-slices drawio (1)

PPLNS with Job Declaration-MMEF drawio (2)

@plebhash
Copy link
Author

plebhash commented Sep 6, 2024

I believe Section 3.2 could be improved

The concept "Fee-based score" could be renamed to "Fee-Difficulty-based score", to make it clear that these two dimensions are taken into consideration.

Also, the notation could be $score_{f,d}(s_i)$ instead of $score_f(s_i)$ (subscript is $f,d$ instead of just $f$)

@lorbax lorbax closed this as completed Sep 7, 2024
@lorbax lorbax reopened this Sep 7, 2024
@lorbax
Copy link
Owner

lorbax commented Sep 7, 2024

As a reader, I felt confused by this. What is a "window"? Is it the same idea as a "mining round"?

* If yes: it would be good to unify all references to this concept under the same name, and avoid implicit synonyms.

* If no: it would be good to avoid confusion by providing a formal definition for the term "window".

Usually in the context of $\text{PPL}N \text{S}$, the window are the $N$ consecutive shares before the one that is a new block. Perhaps I should make it more clear.

$Coinbase Reward = Block Subsidy + Fees$
in this case you'd have that the coinbase reward depends on the blocks fees. Perhaps it is better use the word "coinbase" for something that depends only on coinbase, like the coinbase output. I will review the notation and think about it btw.

If I understand correctly, this formula should be:

∑ i = 0 N s c o r e d ( s i ) = 1

in other words: index of sum is i , not j

correct! thank you!

I believe Section 3.2 could be improved

The concept "Fee-based score" could be renamed to "Fee-Difficulty-based score", to make it clear that these two dimensions are taken into consideration.

Also, the notation could be s c o r e f , d ( s i ) instead of s c o r e f ( s i ) (subscript is f , d instead of just f )

The improvement you are suggesting is to change the name of the section and the subscripts or are you indirectly referring to something more?

While I read SV2 stuff, I like to create visual diagrams to help me understand things better. I did something similar for stratum-mining/sv2-spec#98 and felt it was a very valuable learning experience for me.

While I read this paper, I created some visuals to organize my thoughts.

If the authors feel they are useful, they are free to use and modify them without attribution.

All files were created on the platform draw.io, and are available for further customization as different pages on this link.

PPLNS with Job Declaration-coinbase reward drawio (1)

PPLNS with Job Declaration-slices drawio (1)

PPLNS with Job Declaration-MMEF drawio (2)

I like a lot the second and third diagrams, I will look carefully over the WE and think to add them.

@lorbax
Copy link
Owner

lorbax commented Sep 7, 2024

@plebhash thanks for the review, I will apply it over the WE!

@plebhash
Copy link
Author

plebhash commented Sep 7, 2024

Usually in the context of PPL𝑁S, the window are the 𝑁 consecutive shares before the one that is a new block. Perhaps I should make it more clear.

So a PPLNS window could contain multiple mining rounds? It would be good to make that clear to the reader.

The improvement you are suggesting is to change the name of the section and the subscripts or are you indirectly referring to something more?

If the reader reads "Fee-based score", they could be induced to misunderstand that this score is uni-dimensional ("only fees matter, difficulty is irrelevant"), which would be incorrect.

In general, I would aim to always use the term "Fee-Difficulty-based score" instead of "Fee-based score".

And the subscripts $f,d$ would also help emphasize that. If the reader sees $score_f(s_i)$ in isolation (without the full formula), they could be induced to the same misunderstanding I mentioned above ("only fees matter, difficulty is irrelevant"). So always using $score_{f,d}(s_i)$ helps avoid this.

I like a lot the second and third diagrams, I will look carefully over the WE and think to add them.

It's great to hear that. Like I said in the previous message, you can further edit the images via the provided link on the draw.io platform. All images are on the same file, divided into different "pages", which you can navigate on the bottom of the draw.io UI.

If you decide to use them in the paper, no attribution is needed.

@lorbax
Copy link
Owner

lorbax commented Sep 9, 2024

So a PPLNS window could contain multiple mining rounds? It would be good to make that clear to the reader.

Yes. With mining round I mean all the shares with the same prevhash, so are the shares produced between a block and the following one. The core idea of PPLNS is that the window of shares that are paid have to cross multiple blocks found by the pool (and therefore multiple mining rounds). In the next commit I make it clear.

@lorbax
Copy link
Owner

lorbax commented Sep 9, 2024

If the reader reads "Fee-based score", they could be induced to misunderstand that this score is uni-dimensional ("only fees matter, difficulty is irrelevant"), which would be incorrect.

I think that this is possible only if you read just the sections' title, because it is mentioned at the end of first paragraph of Section 3 and explicitly written in the first point of the Remark in the same Section:

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.

I would have to change "fee-based score" with "fee-difficulty-based score" in the whole article, which would make it a bit pedant. I think it is more practical to keep implicit the difficulty dependence, even when discussing it with other people. Nevertheless, I will discuss it with the other author:

lorbax added a commit that referenced this issue Sep 9, 2024
lorbax added a commit that referenced this issue Sep 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants