Silent Payments – Receive private payments from anyone on a single static address without requiring any interaction or extra on-chain overhead

Silent_Payments.md

Silent Payments

Receive private payments from anyone on a single static address without requiring any interaction or extra on-chain overhead.

Update: This now has a BIP and WIP implementation

Overview

The recipient generates a so-called silent payment address and makes it publicly known. The sender then takes a public key from one of their chosen inputs for the payment, and uses it to derive a shared secret that is then used to tweak the silent payment address. The recipient detects the payment by scanning every transaction in the blockchain.

Compared to previous schemes¹, this scheme avoids using the Bitcoin blockchain as a messaging layer² and requires no interaction between sender and recipient³ (other than needing to know the silent payment address). The main downsides are the scanning requirement, the lack of light client support, and the requirement to control your own input(s). An example use case would be private one-time donations.

While most of the individual parts of this idea aren't novel, the resulting protocol has never been seriously considered and may be reasonably viable, particularly if we limit ourselves to detecting only unspent payments by scanning the UTXO set. We'll start by describing a basic scheme, and then introduce a few improvements.

Basic scheme

The recipient publishes their silent payment address, a single 32 byte public key: X = x*G

The sender chooses an input containing a public key: I = i*G

The sender tweaks the silent payment address with the private key that corresponds to their chosen input: X' = hash(i*X)*G + X

Sincei*X == x*I (Diffie-Hellman Key Exchange), the recipient can detect the payment by calculating hash(x*I)*G + X for each input key I in the blockchain and seeing if it matches an output in the corresponding transaction.

Improvements

UTXO set scanning

If we forgo detection of historic transactions and only focus on the current balance, we can limit the protocol to only scanning the transactions that are part of the UTXO set when restoring from backup, which may be faster.

Jonas Nick was kind enough to go through the numbers and run a benchmark of hash(x*I)*G + X on his 3.9GHz Intel(R) Core(TM) i7-7820HQ CPU, which took roughly 72 microseconds per calculation on a single core. The UTXO set currently has 80 million entries, the average transaction has 2.3 inputs, which puts us at 2.3*80000000*72/1000/1000/60 = 221 minutes for a single core (under 2 hours for two cores).

What these numbers do not take into account is database lookups. We need to fetch the transaction of every UTXO, as well as every transaction for every subsequent input in order to extract the relevant public key, resulting in (1+2.3)*80000000 = 264 million lookups. How slow this is and what can be done to improve it is an open question.

Once we're at the tip, every new unspent output will have to be scanned. It's theoretically possible to scan e.g. once a day and skip transactions with fully spent outputs, but that would probably not be worth the added complexity. If we only scan transactions with taproot outputs, we can further limit our efforts, but this advantage is expected to dissipate once taproot use becomes more common.

Variant using all inputs

Instead of tweaking the silent payment address with one input, we could instead tweak it with the combination of all input keys of a transaction. The benefit is that this further lowers the scanning cost, since now we only need to calculate one tweak per transaction, instead of one tweak per input, which is roughly half the work, though database lookups remain unaffected.

The downside is that if you want to combine your inputs with those of others (i.e. coinjoin), every participant has to be willing to assist you in following the Silent Payment protocol in order to let you make your payment. There are also privacy considerations which are discussed in the "Preventing input linkage" section.

Concretely, if there are three inputs (I1, I2, I3), the scheme becomes: hash(i1*X + i2*X + i3*X)*G + X == hash(x*(I1+I2+I3))*G + X.

Scanning key

We can extend the silent payment address with a scanning key, which allows for separation of detecting and spending payments. We redefine the silent payment address as the concatenation of X_scan, X_spend, and derivation becomes X' = hash(i*X_scan)*G + X_spend. This allows your internet-connected node to hold the private key of X_scan to detect incoming payments, while your hardware wallet controls X_spend to make payments. If X_scan is compromised, privacy is lost, but your funds are not.

Address reuse prevention

If the sender sends more than one payment, and the chosen input has the same key due to address reuse, then the recipient address will also be the same. To prevent this, we can hash the txid and index of the input, to ensure each address is unique, resulting in X' = hash(i*X,txid,index)*G + X. Note this would make light client support harder (edit: not necessarily, see here).

Noteworthy details

Light clients

Light clients cannot easily be supported due to the need for scanning. The best we could do is give up on address reuse prevention (so we don't require the txid and index), only consider unspent taproot outputs, and download a standardized list of relevant input keys for each block over wifi each night when charging. These input keys can then be tweaked, and the results can be matched against client-side block filters. Possible, but not simple. (edit: some more ideas how to do light client support here)

Effect on BIP32 HD keys

One side-benefit of silent payments is that BIP32 HD keys⁴ won't be needed for address generation, since every address will automatically be unique. This also means we won't have to deal with a gap limit.

Different inputs

While the simplest thing would be to only support one input type (e.g. taproot key spend), this would also mean only a subset of users can make payments to silent addresses, so this seems undesirable. The protocol should ideally support any input containing at least one public key, and simply pick the first key if more than one is present.

Pay-to-(witness-)public-key-hash inputs actually end up being easiest to scan, since the public key is present in the input script, instead of the output script of the previous transaction (which requires one extra transaction lookup).

Signature nonce instead of input key

Another consideration was to tweak the silent payment address with the signature nonce⁵, but unfortunately this breaks compatibility with MuSig2 and MuSig-DN, since in those schemes the signature nonce changes depending on the transaction hash. If we let the output address depend on the nonce, then the transaction hash will change, causing a circular reference.

Sending wallet compatibility

Any wallet that wants to support making silent payments needs to support a new address format, pick inputs for the payment, tweak the silent payment address using the private key of one of the chosen inputs, and then proceed to sign the transaction. The scanning requirement is not relevant to the sender, only the recipient.

Preventing input linkage

A potential weakness of Silent Payments is that the input is linked to the output. A coinjoin transaction with multiple inputs from other users can normally obfuscate the sender input from the recipient, but Silent Payments reveal that link. This weakness can be mitigated with the "variant using all inputs", but this variant introduces a different weakness – you now require all other coinjoin users to tweak the silent payment address, which means you're revealing the intended recipient to them.

Luckily, a blinding scheme⁶ exists that allows us to hide the silent payment address from the other participants. Concretely, let's say there are two inputs, I1 and I2, and the latter one is ours. We add a secret blinding factor to the silent payment address, X + blinding_factor*G = X', then we receive X1' = i1*X' (together with a DLEQ to prove correctness, see full write-up⁶) from the owner of the first input and remove the blinding factor with X1' - blinding_factor*I1 = X1 (which is equal to i1*X). Finally, we calculate the tweaked address with hash(X1 + i2*X)*G + X. The recipient can simply recognize the payment with hash(x*(I1+I2))*G + X. Note that the owner of the first input cannot reconstruct the resulting address because they don't know i2*X.

The blinding protocol above solves our coinjoin privacy concerns (at the expense of more interaction complexity), but we're left with one more issue – what if you want to make a silent payment, but you control none of the inputs (e.g. sending from an exchange)? In this scenario we can still utilize the blinding protocol, but now the third party sender can try to uncover the intended recipient by brute forcing their inputs on all known silent payment addresses (i.e. calculate hash(i*X)*G + X for every publicly known X). While this is computationally expensive, it's by no means impossible. No solution is known at this time, so as it stands this is a limitation of the protocol – the sender must control one of the inputs in order to be fully private.

Comparison

These are the most important protocols that provide similar functionality with slightly different tradeoffs. All of them provide fresh address generation and are compatible with one-time seed backups. The main benefits of the protocols listed below are that there is no scanning requirement, better light client support, and they don't require control over the inputs of the transaction.

Payment code sharing

This is BIP47². An OP_RETURN message is sent on-chain to the recipient to establish a shared secret prior to making payments. Using the blockchain as a messaging layer like this is generally considered an inefficient use of on-chain resources. This concern can theoretically be alleviated by using other means of communicating, but data availability needs to be guaranteed to ensure the recipient doesn't lose access to the funds. Another concern is that the input(s) used to establish the shared secret may leak privacy if not kept separate.

Xpub sharing

Upon first payment, hand out a fresh xpub instead of an address in order to enable repeat payments. I believe Kixunil's recently published scheme³ is equivalent to this and could be implemented with relative ease. It's unclear how practical this protocol is, as it assumes sender and recipient are able to interact once, yet subsequent interaction is impossible.

Regular address sharing

This is how Bitcoin is commonly used today and may therefore be obvious, but it does satisfy similar privacy requirements. The sender interacts with the recipient each time they want to make a payment, and requests a new address. The main downside is that it requires interaction for every single payment.

Open questions

• Exactly how slow are the required database lookups? Is there a better approach?
• Is there any way to make light client support more viable?
• What is preferred – single input tweaking (revealing an input to the recipient) or using all inputs (increased coinjoin complexity)?
• Are there any security issues with the proposed cryptography?
• In general, compared to alternatives, is this scheme worth the added complexity?

---

Thanks to Kixunil, Calvin Kim, and Jonas Nick, holihawt and Lloyd Fournier for their help/comments, as well as all the authors of previous schemes. Any mistakes are my own.

There is also a discussion of this scheme on the bitcoin-dev mailing list.

Footnotes

1. Stealth Payments, Peter Todd: https://github.com/genjix/bips/blob/master/bip-stealth.mediawiki ↩

2. BIP47 payment codes, Justus Ranvier: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki ↩ ↩²

3. Reusable taproot addresses, Kixunil: https://gist.github.com/Kixunil/0ddb3a9cdec33342b97431e438252c0a ↩ ↩²

4. BIP32 HD keys, Pieter Wuille: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki ↩

5. 2020-01-23 ##taproot-bip-review, starting at 18:25: https://gnusha.org/taproot-bip-review/2020-01-23.log ↩

6. Blind Diffie-Hellman Key Exchange, David Wagner: https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406 ↩ ↩²

@real-or-random thanks for taking the time to look at the proposal.

Is there a reason why you don't call it stealth addresses?

I don't have a strong opinion on the name, but the implemented stealth address proposal (as well as how it's implemented in Monero, I believe) ended up adding an op_return for ECDH to every transaction, which seemed like an important enough distinction to give it a different name. In an earlier draft I had it named "Simplified Stealth Payments".

I think ECDH performance can still be improved in libsecp256k1, so maybe these numbers will get better even

Nice, that's certainly good news.

I guess the DB lookups are more problematic anyway

I briefly discussed this with @Kixunil who had some ideas about it, but as of yet I still don't have a good intuition for how bad it'll be.

I suggest reaching out to other projects that have implemented stealth addresses, most notably Monero

Thanks for the suggestion, they must have dealt with some of the problems. I did talk to Grin devs briefly, since they do recovery from the UTXO set, but it seemed too different to be relevant.

And to clarify, the watch-only key idea is also described in the stealth payments draft BIP, I just listed it again to give a complete overview.

Strong agreement with naming differently to avoid confusion. Regarding speed, I think we will have to write a benchmark to know exactly. Shouldn't be rocket science anyway. :)

As for the benchmark, I implemented the basic scheme in c (not sure if it's completely correct), on top of PR #994 from https://github.com/bitcoin-core/secp256k1/.

The file is:

https://github.com/w0xlt/secp256k1/blob/a9677ad9f064efd6c1f91afb9fa2f5d2ab43cd03/examples/spbs.c

I think it would be better to integrate that PR with Bitcoin Core and make the change in the wallet to get the benchmark than to re-implement the scan logic in rust-bitcoin, wouldn't it?

@w0xlt I'd like to see both benchmarks. Many wallets are built on top of Core as an external program which I believe is good architecture so would be interesting to know if the overhead is prohibitive.

@w0xlt Nice work implementing it into secp256k1. I agree with @Kixunil that both benchmarks would be interesting and that it would be nice if the implementation could function as software that operates external from Core.

I think there are some ways to improve the performance using the lower level internal APIs of the library. Some ideas:

1. I guess ECDH is doing constant time multiplication (which it should) but remember the "scanning key" doesn't necessarily hold funds so you should actually make the "scanning key" a mandatory part of the spec (i.e. 64 byte silent addresses) and always do the scanning using variable time multiplication. I wonder if Jonas was doing this with his benchmarks.
2. After multiplying the shared secret by G and adding it back don't convert back to affine coordinates -- do the comparison by using a fast Jacobian == Affine function (not sure if this exists in the library). This saves you doing a modular inversion. Whether this is faster may depend on whether you have to done comparison per tx or many (i.e. is the output always in the same place).

@LLFourn nice ideas however lack of constant time scanning may leak privacy. I don't expect the improvement to be significant, is it?

@Kixunil leak privacy in what adversarial model? The improvement would be significant ~25%.

@LLFourn hmm, now that I think about it more, I guess it's not that easy to get the timings from e.g. a sandboxed application. 25% sounds good!

I made a basic implementation: bitcoin/bitcoin#24897.

I believe it can be used for bench-marking. There is a functional test in the implementation (test/functional/wallet_silentpayment.py). I've also been running some silent payments on signet and apparently this implementation is working as expected.

To send a silent payment, a new silent_payment: true option has been added to send RPC.
Example: /src/bitcoin-cli -regtest -named send outputs="[{\"bcrt1pwlh5xuyrpgfunwyww8cfu78yfs2yqyevl7yturavahh5kgxwdd2q5hzgfu\": 1.1}]" fee_rate=1 options="{ \"silent_payment\": true}"

This option instructs the command to verify that all outputs are Taproot addresses and tweaks all of them using the private key of the first input.
The resulting transaction will have different outputs than those originally entered by the user.

This can be verified in DescriptorScriptPubKeyMan::CreateSilentPaymentAddress and in spend.cpp::CreateSilentTransaction.

The recipient's wallet needs a new flag called SILENT_PAYMENT. This flag allows an additional scan that verifies that the wallet keys match the silent payment scheme. When it detects a silent payment that belongs to the wallet, it is stored in a rawtr() descriptor.

./src/bitcoin-cli -regtest -named createwallet wallet_name="recipient" silent_payment=true

Scanning logic can be verified in DescriptorScriptPubKeyMan::VerifySilentPaymentAddress.

The file that implements the Basic Scheme section of this article is src/wallet/silentpayment.cpp.

There are more details in the PR description. Let me know if more information is needed.

@RubenSomsen Just to be clear (maybe this should be explicit in the BIP) the private key the silent payment recipient needs to derive to spend form the silent output is: x' = hash(x*I) + x (mod p) ?

Just because ECDH and a shared secret are involved, I wanted to make sure the sender does not also have the private key to spend the silent output.

@w0xlt well done, this looks promising. Could you elaborate a little bit about the scanning process? I take it you're scanning every block and not just the UTXO set? Note the variant using all inputs should actually be faster in terms of scanning, so it may be preferable.

@pinheadmz yes that is correct, by adding the recipient key to the shared secret, we ensure only the recipient can spend it.

@RubenSomsen yes that is true. The silent payment scanning methods (CWallet::VerifySilentPayment and DescriptorScriptPubKeyMan::VerifySilentPaymentAddress) are called in CWallet::AddToWalletIfInvolvingMe.

If I understand correctly, this method is a central point to check transactions coming from mempool and new blocks. As this implementation adds the transaction to the wallet in a rawtr description, I first considered this method.

Would an RPC like scantxoutset() be better for benchmarking?

I use the private key of the first input to tweak all public keys of the outputs (except change). Therefore, it is one tweak per output. When it comes to iterations, I think it's the same as if a hash of all inputs were used. In the text you mention "one tweak per transaction". Wouldn't that be one tweak per output ?

@w0xlt

Would an RPC like scantxoutset() be better for benchmarking?

I think both could be interesting. The advantage of scanning during block validation is that you don't have to do any additional database lookups, and you'll also find spent outputs. The downside is that you won't take advantage of the fact that you can skip spent outputs.

In terms of benchmarks for your current implementation, the main question I'd have is how much slower block validation becomes compared to when you don't scan for silent payments.

I use the private key of the first input to tweak all public keys of the outputs (except change). Therefore, it is one tweak per output. When it comes to iterations, I think it's the same as if a hash of all inputs were used.

Yes, that seems like the same amount of effort. Just note that such a design would be limiting, as it'd be incompatible with receiving from coinjoins.

In the text you mention "one tweak per transaction". Wouldn't that be one tweak per output ?

I can see how that can be confusing. If you want to see if you received a payment, for every transaction you do the following: you take the combined key of all inputs, use it to calculate your silent payment address, and then you compare it with all the outputs to see if any of them match. So while you're comparing all the outputs, you're only tweaking once.

I changed the scantxoutset RPC to have a silent_payment parameter. But scanning the UTXO Set for silent payments takes much longer than regular transactions, possibly prohibitively.

The main reason seems unrelated to the silent payment scheme, but that the Bitcoin Core UTXO Set only stores the unspent transaction outputs, not the inputs.
Therefore, for each coin in the UTXO Set, it is necessary to retrieve the transaction to know the inputs.
And after that, it is necessary to retrieve the previous transaction to know the scriptPubKey being spent by the first input, so we will know how to extract the pubkey from the scriptSig.

Even the GetTransaction() method being used alone, without any silent payment scheme, it is possible to notice a long time to finish the scan.

I added a cache to store the EDCH results for each input. Probably this implementation can be quite optimized, but I think the basic structure is this.

However, Bitcoin Core does not support UTXO Set scanning as a wallet operation. This RPC is a tool for scanning descriptors. Maybe assumeUTXO will change that.

When receiving a valid new transaction from the mempool, the transaction being spent is already available in the UTXO Set, so this performance issue does not occur. The cost is only related to the EDCH for each wallet key.

For this reason, I initially prioritized how to handle silent transactions coming from mempool and this operation seems quite feasible. But it's good to have both metrics.

To test (example):
$ bitcoin-cli -regtest scantxoutset start "[{\"desc\": \"tr(tprv8ZgxMBicQKsPe4mDP1295ti2BqcgFzPWkKnvsGyKVerGqf9tDif6yR4yLcK6Pf49tQ1HRQK2vjXrAVqxVUJCtXWn3AAiacXnXhUf6nxBJAp/86'/1'/0'/0/*)#pskyw6xd\", \"range\": [0,5]}]" true

@w0xlt

for each coin in the UTXO Set, it is necessary to retrieve the transaction to know the inputs. And after that, it is necessary to retrieve the previous transaction

Yeah, this ends up being roughly 264 million lookups for the entire UTXO set...

I added a cache to store the EDCH results for each input. Probably this implementation can be quite optimized

Perhaps during IBD you could consider storing the relevant input key with each Taproot UTXO and then use this additional information to scan the UTXO set after IBD completes. Note that the simplest implementation of this might have duplicate entries, as there is only one relevant input per transaction but there can be multiple UTXOs. Incidentally, the resulting list of input keys is the same information that light clients would need to perform their own scanning.

I initially prioritized how to handle silent transactions coming from mempool and this operation seems quite feasible. But it's good to have both metrics.

Makes sense to me

I added a functional test for the scantxoutset that uses the silent_payment parameter, so it will be easier to make changes and confirm that the test works. The current logic passes the test because there are no performance issues in regtest.

Perhaps during IBD you could consider storing the relevant input key with each Taproot UTXO and then use this additional information to scan the UTXO set after IBD completes.

It can work. I will try to build an index for this.

Note I gave an online presentation on Silent Payments. You can check it out here.

I will try to build an index for this

@w0xlt 👍

@RubenSomsen thanks for the url. I will watch the presentation.

I implemented the index in the latest commit. The node can be started with ./src/bitcoind -silentpaymentindex.
With this index, the UTXO Set scan for one key is relatively fast on signet, at least.
This index is also used when the wallet is loading and scanning blocks.

I also added a restriction to not allow the creation or loading of wallets with silent_payment flag without the index not being active or synchronized. This changes the interface a bit, but I think it's the best way to prevent the wallet from being in an inconsistent state.

scantxoutset RPC can be run without risks on mainnet, as it does not require wallet or coins.

I think that the current implementation can be used for benchmarking.

I implemented the index in the latest commit

@w0xlt Very well done, happy to see you've taken it this far already. I'd love to play around with it, but I don't have a lot of time on my hands right now. Any chance you'd be willing to provide the numbers? What I'd be curious about is a.) how many UTXOs there are on signet and b.) how long it took you to scan them c.) on what kind of hardware. This could then be extrapolated to the Bitcoin full UTXO set.

And a question: are you currently keeping an index for taproot UTXOs only, or for all UTXOs? While technically only taproot UTXOs are required, a benchmark on the full set seems good for now.

Also, would you be open to a more direct line of communication via IRC or Telegram? I'm RubenSomsen on both.

Edit: another thing I'd be curious about: how much longer does it take to do IBD with and without this additional index.

@RubenSomsen Here are some numbers. I haven't benchmarked it before because I use a virtual machine for development, so it's not isolated enough for a reliable stat, but these numbers can be used as a rough estimate. The configuration I used is a VMWare guest machine with 8 cores of virtual processors and 20 MB of RAM. I don't think this reflects performance if the same configuration was used on the host machine.

The stat below shows the number of UTXO (on the signet and mainnet) and how long it takes. I used std::chrono::steady_clock for more accurate results. This also includes the silent payment index created from genesis block to the tip.

(on signet) silentpaymentindex is enabled at height 90627 in 5m
(on mainnet) silentpaymentindex is enabled at height 736986 in 330m (5h30min)

scantxoutset signet:
  "txouts": 1053822,
  "height": 90805,
  "silent_payment": true,
  "duration_seconds": 82,
  "keys": 1

scantxoutset mainnet:
  "txouts": 81893320,
  "height": 737045,
  "silent_payment": true,
  "duration_minutes": 18,
  "keys": 1

Wallet Rescan (Signet):
Rescan completed from block 90149 to 91029 (880 blocks): 20 minutes

Wallet Rescan (Mainnet):
Rescan completed from block 737050 to 737097 (47 blocks): 43 seconds

And a question: are you currently keeping an index for taproot UTXOs only, or for all UTXOs?

Only transactions where all outputs are Taproot.

    for (auto& vout : tx->vout) {
        std::vector<std::vector<unsigned char>> solutions;
        TxoutType whichType = Solver(vout.scriptPubKey, solutions);

        if (whichType != TxoutType::WITNESS_V1_TAPROOT) {
            return false;
        }
    }

In previous versions, there was no index but now all the above methods (except mempool transactions) use the index. If the above numbers are reasonable, a non-indexed version can be considered.

Thanks for making the contact available. I'll be in touch.

Thank you @RubenSomsen for the proposal and kudos @w0xlt for the implementation.

We were discussing this proposal with folks at Trezor and here are our takes:

• for a hardware wallet we need to use the "scanning key option" for obvious reasons
• address reuse prevention via txid:vout of input is great idea
• we should come up with an address format for silent payments so people won't accidentally send coins to void
• address format could encode different options, such as the scanning key use, address reuse prevention, etc. see the proposal below

Address format rough proposal:

• bech32m address, hrp = sp1
• encoded data
  • 00 || X_spend (don't use scanning key, don't use address reuse prevention)
  • 01 || X_spend || X_scan (use scanning key, don't use address reuse prevention)
  • 02 || X_spend (don't use scanning key, use address reuse prevention)
  • 03 || X_spend || X_scan (use scanning key, use address reuse prevention)
  • bit 0 of the first byte says whether to use the scanning key, bit 1 of the first byte says whether to use address reuse prevention

For efficient implementation of scanning it would be great if we were able to come up with a scheme where only one input pubkey is required. (In this case we could just enrich each entry of the UTXO set with one particular pubkey). It could trivially be always the first input of the TX, but this unfortunately breaks the BIP69 lexicographical ordering of inputs. Need more thoughts on this.

Nice proposal, I wonder if it's beneficial to have it configurable that much. Seems to increase complexity and going with mandatory scanning key and mandatory address reuse prevention looks fine to me. That being said, some form of feature flags/versioning would be good to have.

Nice proposal, I wonder if it's beneficial to have it configurable that much.

Yeah. For Trezor we would use both the scanning key and the address reuse prevention. If others are fine with not having these two flags configurable, so am I and we could just use 00 || X_spend || X_scan and mandate address reuse prevention.

If we forgo detection of historic transactions and only focus on the current balance, we can limit the protocol to only scanning the transactions that are part of the UTXO set when restoring from backup, which may be faster.

From the above benchmarks (and implementation requirements) it seems that detection of historical transactions (spent TXOs) is not particularly practical. The silentpaymentindex would need to support the whole blockchain and not just the UTXO set. I think this is worth noting when comparing to other protocols, for example BIP47. On the other hand, enabling hardware wallet participation using scanning keys is a nice advantage.

Unlike BIP47 however, I don't believe this scheme will be compatible with popular light client protocols such as the Electrum protocol, even if modified to support it, as the scanning burden on the server would be too great for that model of operation. This will make widespread wallet support difficult to achieve.

The silentpaymentindex would need to support the whole blockchain and not just the UTXO set.

I am not sure I understand this comment. The only thing you need is the enriched UTXO set where each UTXO also has associated public key(s) used for ECDH. If we come up with a method where it's always deterministic which public key has been used, this index will be only (32 * utxo_count) bytes big.

The only thing you need is the enriched UTXO set

I was referring to retrieving the whole transaction history (including spent TXOs), which would mean scanning beyond the UTXO set.

Thanks for the numbers @w0xlt.

Thanks for making the contact available. I'll be in touch.

Note I have seen any messages yet, in case something went wrong.

@prusnak thanks for the feedback.

it would be great if we were able to come up with a scheme where only one input pubkey is required

Other than BIP69, another issue with picking the first input is that only one coinjoin participant can make a silent payment. To summarize our options:

Using the 1st input:

• Breaks BIP69, thus leaking information
• Only one silent payment per coinjoin
• Coinjoin recipient knows which input is yours

Using a random input:

• Increases scanning cost and input database size (at least 2x)
• Coinjoin recipient knows which input is yours

Using all inputs:

• Increases coinjoin complexity to collaboratively generate the address

If others are fine with not having these two flags configurable, so am I

Yeah, minimizing the flags where possible, as @Kixunil said, seems preferable. I think reuse prevention and the scanning key can just be the default, as the downsides seem fairly minimal.

detection of historical transactions (spent TXOs) is not particularly practical. The silentpaymentindex would need to support the whole blockchain

@craigraw the index is not required if you want to find historic transactions. In that case you'd just actively scan the entire history during IBD.

And in general, we'd need to compare scanning every tx during IBD versus creating the index during IBD and then scanning the UTXO set. If the latter is not significantly faster, it should perhaps be left out of v1 to keep things simple.

Note that BIP69 is not widely implemented and I believe most developers are in favor of randomization. The main argument is that some protocols can't order the inputs/outputs so random ordering helps hide them.

In that case you'd just actively scan the entire history during IBD.

Generating a silent address before IBD, and redoing IBD for every new silent address does not seem particularly practical to me. It also seems to rule out light client support for historic transactions.