Closed Sjors closed 4 months ago
I agree it's a good convention, and may give users bad habits if we don't do it, but it really doesn't add much (any?) privacy without taproot, requires keeping track of a counter and doing more work to check many addresses. That's why we decided to start without it (and we also introduced a lot of quite fundamental changes in Phoenix, so it was nice to somewhat limit the scope of that release).
I'm not sure we'll add this before taproot, but we'll start working on taproot soon partly because it really improves this specific use-case!
doesn't add much (any?)
Assuming most chain analytics companies are either lazy, incompetent, or both, I suspect it does add privacy. Not against a competent attacker of course.
That's true. We'll see if we're able to change that before taproot, depending on how the timeline for finishing splicing and starting taproot end up looking like.
We're exploring the following scheme for address rotation: https://delvingbitcoin.org/t/is-static-musig2-key-with-a-variable-tweak-safe/215
Don't hesitate to chime in if what we're doing looks insecure or unsatisfying!
It looks satisfying, since it results in a different address each time, and nothing interesting is revealed unless the fallback script is used. Looking forward to see wizard comments about safety, lgtm IANAC (I Am Not a Cryptographer)
This works now!
I'm not sure how much privacy that really adds, but it's a good convention.
You could use a ranged descriptor:
wsh(and_v(v:pk([0000000/52h/0h/0h]xpub…/*),or_d(pk(02...),older(...))))#00000000
(in that case the constant public key in
or_d
is a dead giveaway, but I don't know if you can use an xpub there. But that will get better with taproot.