From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Filippo Merli <fmerli1@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
Date: Sat, 11 Sep 2021 01:09:30 +0000 [thread overview]
Message-ID: <pqkX9ft1aIX7oRHcgAL2jxwO1VZlnSpWrwNiwhD0ru_-zH9LpQbc5008jmR3dg_z0q_k5zwCQPrhPryLRIYP7aUn8EvjpSeX7zfMztLsfzs=@protonmail.com> (raw)
In-Reply-To: <CAO1K=nnGXasdu_M4NgCkcCFMB16sW5r-Xd462d6jfR9mBBCgSA@mail.gmail.com>
Good morning Filippo,
> Hi!
>
> From the proposal it is not clear why a miner must reference other miners' shares in his shares.
> What I mean is that there is a huge incentive for a rogue miner to not reference any share from
> other miner so he won't share the reward with anyone, but it will be paid for the share that he
> create because good miners will reference his shares.
> The pool will probably become unprofitable for good miners.
>
> Another thing that I do not understand is how to resolve conflicts. For example, using figure 1 at
> page 1, a node could be receive this 2 valid states:
>
> 1. L -> a1 -> a2 -> a3 -> R
> 2. L -> a1* -> a2* -> R
>
> To resolve the above fork the only two method that comes to my mind are:
>
> 1. use the one that has more work
> 2. use the longest one
> Btw both methods present an issue IMHO.
>
> If the longest chain is used:
> When a block (L) is find, a miner (a) could easily create a lot of share with low difficulty
> (L -> a1* -> a2* -> ... -> an*), then start to mine shares with his real hashrate (L -> a1 -> a2)
> and publish them so they get referenced. If someone else finds a block he gets the reward cause he
> has been referenced. If he finds the block he just attaches the funded block to the longest chain
> (that reference no one) and publishes it without sharing the reward
> (L -> a1* -> a2* -> ... -> an* -> R).
>
> If is used the one with more work:
> A miner that has published the shares (L -> a1 -> a2 -> a3) when find a block R that alone has more
> work than a1 + a2 + a3 it just publish (L -> R) and he do not share the reward with anyone.
My understanding from the "Braid" in braidpool is that every share can reference more than one previous share.
In your proposed attack, a single hasher refers only to shares that the hasher itself makes.
However, a good hasher will refer not only to its own shares, but also to shares of the "bad" hasher.
And all honest hashers will be based, not on a single chain, but on the share that refers to the most total work.
So consider these shares from a bad hasher:
BAD1 <- BAD2 <- BAD3
A good hasher will refer to those, and also to its own shares:
BAD1 <- BAD2 <- BAD3
^ ^ ^
| | |
| | +------+
| +-----+ |
| | |
+--- GOOD1 <- GOOD2 <- GOOD3
`GOOD3` refers to 5 other shares, whereas `BAD3` refers to only 2 shares, so `GOOD3` will be considered weightier, thus removing this avenue of attack and resolving the issue.
Even if measured in terms of total work, `GOOD3` also contains the work that `BAD3` does, so it would still win.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2021-09-11 1:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-06 10:15 Prayank
2021-09-07 23:38 ` ZmnSCPxj
2021-09-08 10:03 ` pool2win
2021-09-10 9:30 ` Filippo Merli
2021-09-11 1:09 ` ZmnSCPxj [this message]
2021-09-11 7:54 ` Filippo Merli
2021-09-13 8:03 ` pool2win
-- strict thread matches above, loose matches on Subject: below --
2021-08-29 5:57 pool2win
2021-09-02 6:46 ` Billy Tetrud
2021-09-06 6:23 ` David A. Harding
2021-09-06 7:29 ` Eric Voskuil
2021-09-06 7:54 ` David A. Harding
2021-09-06 8:26 ` Eric Voskuil
2021-09-06 9:03 ` pool2win
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pqkX9ft1aIX7oRHcgAL2jxwO1VZlnSpWrwNiwhD0ru_-zH9LpQbc5008jmR3dg_z0q_k5zwCQPrhPryLRIYP7aUn8EvjpSeX7zfMztLsfzs=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=fmerli1@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox