Bitcoin Silent Payment syncing is shit compared to Monero. Even after recent improvements. I attempted for the 3rd time to give it a chance. Extremely slow.
Discussion
Silent Payment syncing on a full node, which you should have anyway, should add less than 1% overhead.
For light clients there isn't even a full spec yet on how to do that, so I'm not sure what mechanism you used. It should be comparable to bip158 sync.
In any case Silent Payments are just a way to avoid address reuse, they're not trying to achieve the same thing as Monero.
Sure, ideally, but realistically the vast majority of users are not going to ever run a node. There are millions of Bitcoiners, yet only ~50,000 node runners at best. And the privacy implications are not as detrimental to Monero users for using a public node as they are for Bitcoin since amounts and receivers are still not visible to malicious nodes. Monero syncing is relatively fast even when using a public remote node, so not sure why it's so much slower for Bitcoin SP.
Cake and Silentium are the only wallets that I know of right now that have Silent Payments
Silent Payments also allow you to post a public address and still prevent third parties from knowing what addresses payments/donations are going to. It's essentially the Bitcoin version of Monero Stealth Addresses.
> And the privacy implications are not as detrimental to Monero users for using a public node as they are for Bitcoin
Do you understand how BIP158 filters work?
Monero/Samourai/Red guys always just throw around podcast buzzwords they have no actual understanding of. No use argumenting, they will just throw more buzzwords.
I don't know how Cake and Silentium work exactly. There is no standard yet for light clients, so claiming that non-standard experimental software is slow, is just not that relevant. Let's wait and see.
Isn't BIP158 for querying a node without exposing all your addresses? I don't think it hides sender/amount/receiver from the public node when you broadcast the transaction does it?
Correct me if I'm wrong
Transaction broadcast is a completely different issue than scanning. One shot Tor connections are a nice potential way to deal with that.
Dandelion would be nicer, but so far nobody has implemented it in a DoS resistant matter. Part of the problem there is that the Bitcoin Core mempool is already extremely complicated, though I'm still hopeful that will improve, e.g. with cluster mempool.
I mean it is still pretty relevant to the topic of using public nodes. Unless you're someone who plans on never broadcasting transactions.
But looks cool