The fetch-stealth call should only return tx hash.

[evoskuil]

Otherwise the caller must always follow-up with requests for all transactions, which is very wasteful.

[narodnik]

It's better this way though, because otherwise the server might have to send a huge block of transactions. This way the client receives the hashes then gradually downloads the transactions.

In other words, it is better for wallets which might have multiple stealth addresses they need to synchronize, while doing other critical tasks, as opposed to receiving one giant 4 mb packet that stops their connection.

[evoskuil]

Without a way to privately recover the transactions, this problem defeats a primary benefit of stealth. However the same basic issue currently exists for non-stealth payments to standard addresses (i.e. using privately-passed HD wallet addresses). The resolution to this will ultimately be to support PIR queries. However a stealth response of a set of tx hashes followed by a PIR query for transactions is going to suffer from an intersection attack, so I'm not sure how else to resolve the central privacy issue with this.

[narodnik]

Sorry, what's PIR queries? Any link? Thanks.

[evoskuil]

https://en.m.wikipedia.org/wiki/Private_information_retrieval

[evoskuil]

The "gradually" term in your previous comment is an attempt to break a timing attack. I wouldn't consider this effective or particularly friendly from a usage standpoint. If one has control of the user's network or the server this is easily defeated. Using encryption on the wire the network arrack is hard, but the public server based attack remains trivial.

[narodnik]

I think it's more a way to stave off resource starvation. Imagine starting a new wallet that you want to synchronize for the first time. The wallet can put the stealth synchronization to a background thread at a low priority allowing it to be usable. It's not desirable to immediately download all transaction data immediately. With the hashes + fetching, you essentially have a resumable download and you can calculate the progress.

[narodnik]

Thanks for the link on PIR. I don't know how stealth has changed, but before it was based on inexact prefix matching that would return false positive transactions. So the idea there was that you'd also fetch transactions that weren't for you. You could increase or decrease this with the number of bits in the prefix. Not sure if that helps.

[evoskuil]

Nothing in stealth design has changed since the initial (v2) release apart from the completion of a couple of aspects.

The PIR objective of blockchain-based stealth transaction discovery would be satisfied if client download all transactions signaled by the filtered query. I think that given the options this is best because it allows the client to throttle the response. In version4 all responses will support pagination, so this specialization would not be necessary.

However, the current implementation is hazardous because it encourages unsafe usage. We are returning sufficient stealth metadata to the client for the client to detect the specific transaction(s) of interest. This is only useful in the case where the client does not intend to download the full set of transactions.

So I would be fine with client pulling the transactions, but in this case we should eliminate the stealth metadata from the initial response as it constitutes dead code. In doing so we can also eliminate server indexing of both the ephemeral public key hash and the stealth public key hash. We would only send the transaction hashes that satisfy the indexed filter.

We can easily add a blockchain.fetch_stealth2 in version3, while retaining a deprecated blockchain.fetch_stealth - allowing clients to transition. If clients are already properly implemented they would require only trivial changes as they would already be downloading all transactions and would not require the stealth metadata.

[narodnik]

Interesting problem. I think this implies that stealth addresses should have a timelimit on them. Otherwise you have a stealth address with an unlimited number of transactions in its prefix that you have to read forever. If there was a limit, then you would re-issue the address with a stronger or weaker prefix.

However the key hashes, are so you can tell which rows are valid, then it's up to the client to mix in some invalid transaction hashes. I was confused before but that's the basic idea for anonymizing transactions. When you multiply the keys, only the client can see which addresses belong to it.

[evoskuil]

However the key hashes, are so you can tell which rows are valid, then it's up to the client to mix in some invalid transaction hashes.

The key hashes are in the transactions, so indexing them and returning them in the query result is unnecessary and encourages unsafe use.

When you multiply the keys, only the client can see which addresses belong to it.

Sure, but again, this should be done at the client - since the client must download the transactions anyway.

If there was a limit, then you would re-issue the address with a stronger or weaker prefix.

Time in Bitcoin is measured in blocks. The amount of clock time passed has no affect on the query results, only change in the blockchain does that. So the minimum height parameter of the query accomplishes this objective.

However it is possible that over time for a given prefix, this may become insufficient. It's also the case that one may wish to revoke a prefix for reason of compromise.