Oddbean new post about | logout
▲ ▼
SaberhagenTheNameless | 15 days ago (raw) | root | parent | reply | flag +2 
 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.
▲ ▼
provoost | 15 days ago (raw) | root | parent | reply | flag +1 
 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.
▲ ▼
SaberhagenTheNameless | 15 days ago (raw) | root | parent | reply | flag 
 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.
▲ ▼
provoost | 15 days ago (raw) | root | parent | reply | flag +1 
 > 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?
▲ ▼
hdhvcdd | 15 days ago (raw) | root | parent | reply | flag 
 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.
▲ ▼
provoost | 15 days ago (raw) | root | parent | reply | flag +2 
 The Joe-Roganization of technical discussion? :-)
▲ ▼
eskrkw | 15 days ago (raw) | root | parent | reply | flag +1 
 Not sure about Joe Rogan, but the red guys are probably more offensive, as if you insult them directly when you introduce them to the concept of technical tradeoffs using their thing as example.
▲ ▼
SaberhagenTheNameless | 15 days ago (raw) | root | parent | reply | flag 
 What "buzzwords" were said?
▲ ▼
provoost | 15 days ago (raw) | root | parent | reply | flag +1 
 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.
▲ ▼
SaberhagenTheNameless | 15 days ago (raw) | root | parent | reply | flag 
 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
▲ ▼
provoost | 15 days ago (raw) | root | parent | reply | flag +2 
 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.
https://github.com/bitcoin/bitcoin/pull/29415
▲ ▼
SaberhagenTheNameless | 15 days ago (raw) | root | parent | reply | flag 
 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