btcec: remove import of chainhash #1848
Conversation
The chainhash import is challenging for consumers of the latest tagged btcd module (v0.22.0-beta) because that module revision has its own chainhash package. This creates an ambiguous import when trying to import both the older btcd module and btcec/v2 which requires the standalone module version of chainhash. This is the brute solution. An alternative would be to create a chaincfg/chainhash/v2 module and have btcec/v2 require that instead.
|
I'm comfortable with this solution but would love to hear from @Roasbeef before approving/merging. |
Pull Request Test Coverage Report for Build 2220593558
💛 - Coveralls |
|
Yah, the v2 option seemed simpler but it has cascading effects. e.g. btcutil has to go to v2 since chainhash types are in it's exported API, which is breaking for txscript, wire, etc. The more I think about this and see how it has been playing out for consumers, the more I think the "right" solution for the current btcd dev cycle (before your next product release) is to get to btcd/v2 (module, not product) right away, before all other module activities, because countless projects import the btcd(/v0) module. Then get btcd/v2 on a bunch of new v2 submodules. Otherwise, the legacy btcd module will become more and more problematic, especially if any new submodule imports it or anything ambiguously from it, such as chainhash. #1825 (comment) Unless the plan to to make the btcd module something that is never imported (just there for the CLI app), only the submodules imported, it really is necessary because of breaking changes since the last v0.22 tag. Whether we like it or not, with the invent of Go modules, the entire ecosystem is essentially forced to bump their semantic import version (the /vX on the import path) if there are any breaking changes. While more modules => more burden for btcsuite, carving out sub-modules can at least reduce the frequency of such bumps. It's a balance that's hard to get right. (And it requires far to much thought to get right IMO, but that's the state of things) |
|
I'm on board, but think we should wait for this to be merged first: #1820 It defines some new tagged hash combinations, and just needs another pass on my end up update the nonce derivation to the latest musig2 BIP. I don't really foresee many other standardized "tagged hash" prefixes in the near future, and needing to add to a new map element in two areas (optional since they can pass a custom tag in any case) isn't too bad. |
|
If we're going along with #1850 then I think it makes sense to actually merge this first, so the new slimmer module retains the old Go version requirement. |
|
Converting to draft as I'm actually fairly hopeful about the new resolution proposed in the comment #1839 (comment). Happy to repoen this though if it seems desirable regardless. |
|
This is fortunately no longer required. 🥳 |
Pull Request Test Coverage Report for Build 2220593558Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
One option to quickly resolve #1839
This duplicates some code, but requires no import path changes, only a new btcec/v2 tag. For a proper solution, a chainhash/v2 module is still required (e.g. 39b1193 plus a large cascade of deps like btcutil/v2 and all the way up) since it's not just btcec that will introduce this ambiguous import.