Hi Filippo,
If a malicious miner, M broadcasts {m1, m2 ... mn} at a regular interval, *and*
also broadcasts {m1*, mn*} where mn* is bitcoin block then M will cheat all
other miners of their reward. You correctly identified this attack. The problem
stems from the fact that I wanted to use the bitcoin block as the sentinel to
mark the shares from the DAG that need to be rewarded. There's a few approaches
we can take here, but I think the best one is that the hub broadcasts a
"sentinel" to mark out the point in logical time up to which shares will be
rewarded.
m1* <-------------------- mn*<--------+
|
m1 <----m2 <---m3 <-------------------+
^ ^ ^ |
| | | |
| | +-----------+ |
| | | |
| +--------+ | SENTINEL
+-----+ | | |
| | | |
a1 <------ a2 <-----a3 <------+
In the above diagram, when hub receives mn*, the bitcoin block to be rewarded,
the hub has also received {m1...m3, a1...a3} and therefore rewards all those
shares and broadcasts this logical time to the p2p by sending a sentinel
announcement.
This solution will also scale to the multiple hubs construction, as each hub
will define their own sentinel and the miners working with each hub can
independently verify their shares are being correctly rewarded. The solution
also handles the case where M is not referencing any other shares.
The above alternative, might also answer your question about why we need to
build a DAG. With a DAG we can capture logical time. Without a DAG, the above
solution will require the hub to announce the hash of shares from each miner
that have been rewarded.
I really appreciate you taking the time to go through the proposal and pointing
out the attack. I hope the above solution addresses your concerns.
Thanks and best regards
pool2win
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
