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

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to