-
Notifications
You must be signed in to change notification settings - Fork 300
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make chain-sources non-dependent on a specific bdk_chain
version.
#1543
Comments
I'm not well versed on the Concept ACK, as long as we settle on the same rust-bitcoin version of our other crates and the ecosystem (0.32.x ?), in that way I think we "minimize" any further downsides. I'll put more thought into it overnight, but we might've other structures/types that could be moved to |
I'll work towards making a concept PR for this. |
Rather than adding extra code/review work to make Once the final 1.0 is done we can start discussing what needs to go into the 2.0 milestone and even start working on some of the related redesigns in experimental PRs. I may sound like a broken record on this, but I believe a final stable 1.0 is more important right now than a perfect, future proofed 1.0 API. |
Not making |
Thinking ahead here. We are moving pub struct CheckPoint<B = BlockHash> {
// private fields...
} We want to update This can be done by: This means we will NOT be able to remove/change our current method names for this minor version bump. I'm wondering whether it will make sense to rename our Method names to be changed:
Also note that the |
@evanlinjin err I don't understand
Yes and I don't think it should have anything to do with |
I support the concept for this issue, I'm just not sure if we can get it coded, tested, reviewed, and merged this week. Otherwise we won't be able to include it in the beta.2 tag used for the 3rd party audit to start no later than Aug 26. And if not included in the review I wouldn't want to include it in the final 1.0 release. We should discuss on the dev call tomorrow. |
I had a chat with @evanlinjin and @LLFourn and Evan is going to make a run at doing the refactoring and have it ready to review Thur/Friday, Lloyd will help us review with goal of having it ready for me to merge no later than Sunday. Worst case if Evan finds the scope is too big to finish we we freeze 1.0 on it's own branch and this refactoring will have to be done as 2.0 changes |
Instead of updating a `TxGraph` with a `TxGraph`, we introduce a dedicated data object (`tx_graph::Update`). This brings us closer to completing bitcoindevkit#1543.
Instead of updating a `TxGraph` with a `TxGraph`, we introduce a dedicated data object (`tx_graph::Update`). This brings us closer to completing bitcoindevkit#1543.
Instead of updating a `TxGraph` with a `TxGraph`, we introduce a dedicated data object (`tx_graph::Update`). This brings us closer to completing bitcoindevkit#1543. Co-authored-by: Wei Chen <[email protected]>
Describe the problem
We may want to be able to iterate fast on
bdk_chain
without breakingWallet
. This meansWallet
may be of an older version ofbdk_chain
. Therefore,Wallet
(currently) will have to use older versions of chain sources (since our chain sources depend onbdk_chain
).It will be a nice property if projects that use BDK can stay put on a specific
bdk_chain
version, but still use the latest chain-source crate version.Additional context
Why would we need to break
bdk_chain
?There are a couple a breaking changes that we simply do not have enough time to include in the
v1.0-beta
release.Get rid of
IndexedTxGraph
and just put theIndexer
inTxGraph
. This removes a bunch of overhead and is in general much cleaner.Anchor
trait and make anchors unique to (Txid, BlockId) #1515Removing the anchor trait, and representing the
Anchor
as a concrete type is much cleaner and a less error-prone API.Both of these changes will break
ChangeSet
.Proposed solution
Introduce
bdk_core
crate that moves structures and types frombdk_chain
that will mostly stay constant.BlockId
,ConfirmationBlockTime
.CheckPoint
, introducetx_graph::Update
(instead of usingTxGraph
to updateTxGraph
).FullScanRequest
,FullScanResult
,SyncRequest
,SyncResult
.Chain sources will only depend on
bdk_core
. Note that we need to introducetx_graph::Update
though.Potential downsides
bdk_core
will still need to depend onbitcoin
. Any major version updates tobitcoin
will be a breaking change and we will need to introduce a new major version forbdk_core
. To make these suggested changes useful, we need to lock down on specific major releases ofbitcoin
.Acknowledgement
Thank you to @LLFourn for bringing up this idea.
The text was updated successfully, but these errors were encountered: