Robert Netzke
Robert Netzke
> Nevermind above, but I am wondering if there's a way to remove LocalChain from bdk_kyoto. Maybe, but either this approach or adding a `disconnect_block` would allow for even more...
> Just my opinion, I would prefer a method that explicitly removed blocks Sure, that makes sense. I wasn't sure how public the `ChangeSet` are meant to be in general....
Okay, updated with those suggestions.
Thanks for catching those. Updated again
In reference to the comment, there is some reason to believe, although no certainty that the new block a transaction confirms in will be connected at the same height as...
As a preface, in [this issue](https://github.com/bitcoindevkit/bdk-kyoto/issues/63), (from what I understand) you've expressed it is desirable to handle blocks directly, and I agree. That is why I would like for `Wallet`...
> Right now this will mean it will have to emit C (to contradict B) and A (the ancestor of C and B) Ideally, the node does not have to...
Hate to beat a dead horse here but I am sort-of coming around to this model. I'm just struggling now to understand what the use of one of these dead...
Sure, so having stricter topological requirements would enable more flexibility from an API point of view. Yeah, I mean I can punt on this for now.
> Implement finish_no_persist on the TxBuilder Is it okay if I write a slightly more complex macro for this? Edit: We also need to implement `finish` and `finish_no_persist` for `BumpFeeTxBuilder`....