Wouldn’t this require the custodian to first share the UTXO(s) they will use for the silent payment with Alice/Charlie so they can calculate the end destination address?
This is the exact opposite of the claim you made multiple times:
Indeed, that is necessary for wallet software to create a signed transaction.
This is the exact opposite of the claim you made multiple times:
No, I said it is trivial to generate a new address. I did not say it is trivial to share it, or have the counterparty validate it as correct. This is the part you are missing. With Silent Payments, you can do this once per persona. With HD wallets, you have to do this once per payment - and that makes all the difference. This is borne out in the data - because it is so difficult/inconvenient, address reuse is prevalent. With 70% address reuse, the current reality of your example is that Alice and Charlie are sending to the same onchain address for Bob, creating a cryptographic link visible to everyone - strictly worse than the Silent Payments alternative.
I highly doubt any custodian would implement this since it is probing mechanism that worsens the custodian’s privacy.
With the exception of donations, you already have to be in contact with the counterparty to negotiate the terms of the transaction.
Psychologically, I would hesitate more to send a donation to a SP address compared to a BTCPay generated address because I don’t know if the recipient still has the keys for the SP address (which does not encode an expiration date).
This functionality is already possible by just sharing a new xpub with each sender, it doesn’t have to be a new SP address. Even still, this marginal UX benefit is risky compared to generating a new address for each payment: I personally check to see if my existing BTC is still in my wallet before accepting more coins. Things like automated weekly payroll are a disaster if the recipient’s keys are stolen during the week.
With the exception of donations, you already have to be in contact with the counterparty to negotiate the terms of the transaction.
Many (most?) transactions involve repeat payments where the amount is already determined. This is one of the reasons address reuse is so high - negotiating a new onchain address for each repeat payment is simply too inconvenient.
This functionality is already possible by just sharing a new xpub with each sender, it doesn’t have to be a new SP address.
Sharing an SP address per persona is much better than sharing an xpub per sender, both in terms of privacy and convenience.
These arguments remind me of the objections to HD wallets back in the day (xpub-as-total-exposure privacy problem, single-point-of-failure critique of the seed etc) and miss the fact that benefits vastly exceed the possible pitfalls. This is a privacy thread, and if you fail to acknowledge that the current approach is leading to high address reuse then you fail to acknowledge reality.
…Citation? What data set exists to derive this estimation from?
The reality is that a lot of people use Electrum based light wallets and every address gets completely exposed to chain surveillance anyway. Generating new addresses doesn’t even begin to benefit the user unless their wallet is a BIP157/158 light client, or a full node.
Oh, I forgot to add in this thread: PathCoin is not relevant to the discussion, as it was only a theoretical concept that might push towards some interesting offline protocol (it could be relevant to privacy if it was practically usable, but it wasn’t, it was no more than a “starting idea for future research”, really).
On CISA:
Fabian just posted a full-agg BIP draft: https://groups.google.com/g/bitcoindev/c/TF5mPfy58RQ/m/vAk1Mfg2AwAJ
For more information on CISA, I recommend Fabian’s HRF research report: CISA Research Paper - Human Rights Foundation
1 Like
And Half-agg received BIP number 454: BIP458: Half-Aggregation of BIP 340 Signatures by fjahr · Pull Request #2205 · bitcoin/bips · GitHub 
Edit: The number changed to 458 to allow for consecutive numbers for the CISA proposal.
2 Likes
A recent podcast episode with Dan Gould on the state of Payjoin.
The website has a transcript and a link to the video, my notes below:
- Payjoin Foundation is a non-profit dedicated to supporting Payjoin
- Payjoin Dev Kit 1.0.0 release imminent (payjoin-1.0.0-rc.4 in releases)
- BIP-77 (AKA Payjoin v2 / async Payjoin)
- Async Payjoin is available in Cake Wallet and Bull Bitcoin Mobile
- Current focus: getting PDK 1.0.0 released, getting BIP-77 out of draft
- Future work: addressing privacy problems, multi-party Payjoin
- Blog post: How Wallet Fingerprints Damage Payjoin Privacy.