Silentiumd design questions

[josibake]

Haven't looked into the code yet, but had a few general questions:

1. It seems the tweak data index is being built by getting prevout information from bitcoind (via the txindex). Curious if you had an numbers on how long it takes to create the index?
2. The daemon can be run with two database: postgres and badgerDB - I'm not familiar with BadgerDB, but is this something lightweight enough where the index service could be run on a raspi? I'm thinking of the use case of a user running an index for their wallet as part of a node package like Umbrel, Raspiblitz, etc
3. Regarding the use case where a wallet user is running their own index (similar to how users run their own electrs servers), have you considered adding a way for the index daemon to do the scanning? In this model, the PWA would hold the spend key and then register the scan key with the index server and the index server does the scanning and notifies the PWA when it finds a transaction
   • For users able to run their own bitcoin node/index, this allows them to use the wallet without any bandwidth usage
   • In this model, the index could also get mempool transactions from the bitcoin node and scan those as well, allowing the index daemon to alert the wallet of unconfirmed transactions
4. I noticed in your README you are taking advantage of cut-through. Another idea is to add a "dust limit filter" where the client can say "exclude transactions where the unspent UTXOs are < dust_filter, i.e. if the largest unspent output of the transaction is < dust_filter it is not sent to the client. This avoids the client downloading and checking for UTXOs that would be unspendable anyways

Awesome work, btw! Will run the index and let you know if I have more feedback!

[louisinger]

Haven't looked into the code yet, but had a few general questions:

1. It seems the tweak data index is being built by getting prevout information from bitcoind (via the txindex). Curious if you had an numbers on how long it takes to create the index?

It depends on the getrawtransaction RPC performance. The current deployed server has a sync time close to 10secs/block. Which is huge and definitely need to be quicker. Off course, there are huge optimisations to do server-side.

2. The daemon can be run with two database: postgres and badgerDB - I'm not familiar with BadgerDB, but is this something lightweight enough where the index service could be run on a raspi? I'm thinking of the use case of a user running an index for their wallet as part of a node package like Umbrel, Raspiblitz, etc

Yes ! I'm running my own silentiumd server at home on an old raspberry PI (using badger).

3. Regarding the use case where a wallet user is running their own index (similar to how users run their own electrs servers), have you considered adding a way for the index daemon to do the scanning? In this model, the PWA would hold the spend key and then register the scan key with the index server and the index server does the scanning and notifies the PWA when it finds a transaction
   • For users able to run their own bitcoin node/index, this allows them to use the wallet without any bandwidth usage
   • In this model, the index could also get mempool transactions from the bitcoin node and scan those as well, allowing the index daemon to alert the wallet of unconfirmed transactions

Nice catch I didn't think about that. Btw not sure if this should be implemented directly in the indexer or if it should be an extra component running on top of silentiumd (in order to run this kind of "watcher" without running the indexer yourself).

[josibake]

Yes ! I'm running my own silentiumd server at home on an old raspberry PI (using badger).

That's amazing!

Btw not sure if this should be implemented directly in the indexer or if it should be an extra component running on top of silentiumd (in order to run this kind of "watcher" without running the indexer yourself).

Great point. So this means a user could run their own index + watcher on a raspi to power their mobile client, or they could install just the watcher on a raspi and connect to an index like silentiumd. Then, the bandwidth and ECDH is being done on the raspi and forward found payments to the mobile client. I think this is a crucial piece to have so that if people have concerns about the UX of the PWA, we can just point them to installing a tiny watcher or a watcher + index.

[josibake]

It depends on the getrawtransaction RPC performance.

We get around this in the Bitcoin Core index by using the rev*.dat files (undo blocks). There's also a PR for a silent payments index and an RPC so that we could have Bitcoin Core build the index and then anyone else can get the data per block via an RPC call to the index.

Long term, I've got a prototype for rust indexing utility using libbitcoinkernel, but this is still a ways out since the libbitcoinkernel project is still in the works. Just mentioning these options to say that this is something that can definitely be improved.

[yaeloss]

n00b question, but is there a meaningful way to also restore this wallet in another wallet like Sparrow, either by xpub or seed? Is there a unique derivation path apart from m/84 or 44?

For many, I know this likely defeats the purpose, but it'd be a helpful hack