rfc: DATUM mining interface requirements #31002

1. 
   Sjors commented at 12:09 pm on September 30, 2024: member

   The Mining interface is designed with Stratum v2 in mind, and can likely also be used to incrementally improve Statum “v1” applications.

   Ocean recently announced DATUM. So far it’s proprietary and undocumented, but hopefully that changes. It could be a good test for the generality of the Mining interface to see if the DATUM gateway requires any additional methods.

   Here’s the current interface:

   https://github.com/bitcoin/bitcoin/blob/d812cf11896a2214467b6fa72d7b763bac6077c5/src/interfaces/mining.h#L47-L106

   Where createNewBlock returns:

   https://github.com/bitcoin/bitcoin/blob/d812cf11896a2214467b6fa72d7b763bac6077c5/src/interfaces/mining.h#L30-L45

   Additionally #30955 proposes to add getCoinbaseMerklePath() and submitSolution(), and https://github.com/Sjors/bitcoin/pull/52 proposes to add waitFeesChanged.

   cc @luke-jr

2. fanquake added the label Mining on Sep 30, 2024
3. 
   josibake commented at 1:40 pm on October 2, 2024: member

   I think this highlights a clear advantage of having a more “generic” mining interface exposed over an IPC interface: different mining protocols can use the same interface from Bitcoin Core, without needing protocol specific¹ changes for each protocol to be implemented in Bitcoin Core.

   As you mentioned, our current interface is designed with SV2 in mind, but given this is all relatively new code, it would be great to hear from the folks building DATUM whether or not this interface works out of the box and if not , what changes to the generic interface would be needed.

   ---

   1. Pragmatically, it might make sense to have a few protocol specific methods exposed in the interface for performance / simplicity, but ideally most of the protocol specific logic is managed in the process connecting to the Bitcoin Core mining interface ↩︎

4. 
   jonatack commented at 4:30 pm on October 2, 2024: member

   So far it’s proprietary and undocumented, but hopefully that changes.

   Agree. I believe it may be MIT-licensed and public soon. Edit: was confirmed to me with an ETA of Oct 18 or before.

5. 
   luke-jr commented at 4:36 pm on October 5, 2024: member

   Bitcoin Core has been working toward trying to centrally dictate mining policy, so should really not be used for mining. OCEAN/DATUM’s goal is to decentralise mining, not merely switch the central dictator from Bitmain/Foundry to Bitcoin Core.

   That being said, there is already a generic/standard mining interface: getblocktemplate. It has worked for years and nothing additional is needed for DATUM.

6. Sjors closed this on Oct 5, 2024

   ---

7. 
   Sjors commented at 4:07 am on December 13, 2024: member

   From casual reading of the DATUM Gateway README (since there’s still no spec), the Mining interface could be useful in a few places:

   1. No need to tell users to manually set -blockmaxsize and -blockmaxweight, because createNewBlock() can pass a custom coinbase weight reservation through its BlockCreateOptions argument. On a related note, #31384 (comment) discusses the idea of adding -maxcoinbaseweight, and the README suggests Knots will do something similar.

   2. No need to use -blocknotify (which launches datum_gateway and presumable then calls getblocktemplate). Instead datum_gateway could run as a deamon and call waitTipChanged() and waitNext() #31283 which return when there’s a new block or better fees. Also easier to setup between two machines.

   Looking at the “Template/Share Requirements for Pooled Mining” I don’t see any blocking issues at first glance.

   Must include generation transaction outputs provided by the pool in the order provided

   Must include the primary coinbase tag as provided by the pool

   Must include the unique identifier provided by the pool

   I’m assuming the datum_gateway adds these to the template? (since getblocktemplate doesn’t include a coinbase transaction)

8. 
   luke-jr commented at 11:50 pm on December 21, 2024: member

   No need to tell users to manually set -blockmaxsize and -blockmaxweight, because createNewBlock() can pass a custom coinbase weight reservation through its BlockCreateOptions argument.

   Seems like it would be trivial to add this to GBT. The current approach in Knots isn’t ideal (since it would override blockmaxsize/weight if the miner intentionally sets them lower).

   No need to use -blocknotify (which launches datum_gateway and presumable then calls getblocktemplate)

   It only sends a signal to the already-running DATUM gateway, but yes, it’s not ideal to require the additional configuration. GBT does already support longpolling, however, it’s just not implemented in DATUM Gateway yet (see https://github.com/OCEAN-xyz/datum_gateway/issues/3)

   [list of stuff] I’m assuming the datum_gateway adds these to the template?

   Yes, it creates the generation transaction.

   the Mining interface could be useful in a few places:

   Seems like this would be better suited to a PR on the datum_gateway repo.

9. 
   Sjors commented at 8:09 am on December 24, 2024: member

   Seems like it would be trivial to add this to GBT.

   Agreed.

   Seems like this would be better suited to a PR on the datum_gateway repo.

   My only goal here is to figure out if the Mining interface needs anything for DATUM that it doesn’t need for Stratum v2. Whether you actually use it is up to you of course.

Contributors
Sjors josibake jonatack luke-jr

Labels
Mining