rephrase criteria: "Only query one address at a time from a specific connection context"

[kristovatlas]

should be more general

[kristovatlas]

Also this one:

Query multiple addresses at once using a technique that returns false positives

[dcousens]

Indeed, this isn't specifically an address issue, but the nature of any query. Also, the connection itself isn't important, but the nature of the establish-able identities on either end.

For example, in a central server situation, establishing multiple connections will not preserve your privacy if your origin IP does not change, or if all your queries are made in an orderly, or timely fashion.

[dcousens]

In an SPV situation, it is the same problem, you are just hoping that you can maintain a subnet variance such that attackers aren't able to afford it.

[dcousens]

Unless I'm missing something else RE unique connections?

[kristovatlas]

@dcousens I think you’re spot on. I think we can break this notion into two parts:

1. Separating bits of data that are not necessarily correlated on the blockchain into separate queries
2. Maximizing the number of other users of the query oracle who we could attribute each of your queries to, where “we” == the query oracle and passive network observers

The phrase “connection context” was intended to encapsulate the second part; I think it’s good enough, but welcome other suggestions that are not too wordy.

Since the time I opened this issue, the countermeasures in question have been tweaked a bit.

Only query one address at a time from a specific connection context

Has become criterion OBPPV3/CR26 (bba9be9cd221ff2b40afa74dcc424d420fb30120f2c0a0f007bdd07c66f1c054):

Balance information is obtained by making queries to other network participants that do not include multiple addresses in a specific connection context

I would propose this re-wording:

Queries for data that are not correlated on the blockchain are separated into multiple queries, and each query uses a separate connection context

Similarly, the countermeasure originally referenced:

Query multiple addresses at once using a technique that returns false positives

Has become criterion OBPPV3/CR27 (16b6ab28cba33110aebdac4a1c1309a5c31a599f31e641d9a46d718f1ad31db1):

Balance information is obtained via a method that matches a fraction of the blockchain beyond the addresses belonging to the wallet

I would reword this as:

Blockchain data is queried in a fashion that returns data corresponding to multiple elements not correlated to one another on the blockchain

I would add this JSON comment:

For example, this criterion may be met if bloom filters are used to lookup balance data.

[kristovatlas]

at next meeting, let's ACK/NACK these proposed re-wordings; NACK if further discussion is required

[dcousens]

Separating bits of data that are not necessarily correlated on the blockchain into separate queries

Do you instead mean:

that are conceivably correlated

[kristovatlas]

@dcousens yes, I think that is a fair statement

[kristovatlas]

that are conceivably correlated

3 ACKs on this wording during tonight's meeting

[crwatkins]

OK with "conceivably" & ACK above.