Bitcoind REST sync

[TheBlueMatt]

Its probably not all that important and most folks wouldn't use it, but if its possible to do a sync via bitcoind REST easily, it'd be nice to support. I assume BDK would have to support it and that's kinda it since LDK already does?

[tnull]

Its probably not all that important and most folks wouldn't use it, but if its possible to do a sync via bitcoind REST easily, it'd be nice to support.

Hmm, I'm not fully convinced, could you reiterate the benefits over RPC, besides the absence of any authentication method?
I think there are performance benefits, but can't fully recall how impactful they are?

I assume BDK would have to support it and that's kinda it since LDK already does?

No, actually we're not using the bdk_bitcoind_rpc crate but chose to unify chain polling for both LDK and BDK based on lightnig-block-sync, so if we want we should be able to add REST support independently from BDK.

[TheBlueMatt]

Hmm, I'm not fully convinced, could you reiterate the benefits over RPC, besides the absence of any authentication method?

Abscence of auth is really important, eg it means you can run one bitcoind and have multiple services talk to it, without the ability to do things like stop the node, disconnect all its peers, etc.

I think there are performance benefits, but can't fully recall how impactful they are?

Nontrivial - you skip the JSON + hex encoding for various things and can fetch straight binary. Maybe more important, you can trivially slap nginx in front of it and cache block data and the like rather than having bitcoind load it from disk.

[tnull]

Nontrivial - you skip the JSON + hex encoding for various things and can fetch straight binary. Maybe more important, you can trivially slap nginx in front of it and cache block data and the like rather than having bitcoind load it from disk.

Ah, right. Thanks for refreshing my memory. I agree we should go for it, should be easy enough.

[enigbe]

Hi @tnull, happy to take this on if it's unassigned. Are there any specific considerations or preferences you'd like me to keep in mind before I get started?

[tnull]

Hi @tnull, happy to take this on if it's unassigned.

Cool, go for it!

Are there any specific considerations or preferences you'd like me to keep in mind before I get started?

I think generally you'll want to keep it as analogous / DRY as possible w.r.t. the RPC variant. You'll want to use
https://docs.rs/lightning-block-sync/latest/lightning_block_sync/rest/struct.RestClient.html for it.

Also note that we're planning to do a bunch of cleanups/refactors/code moves in the chain module after #486 lands, so you might or might not want to wait on that, as it could bring some rebase pain.

[enigbe]

Thanks.