Add semi-honest overview

[arminsabouri]

Kickstarting the semihonest overview. There has been alot of questions (and misunderstandings) about concrete protocol details and the information is distributed (payjoin/rust-payjoin#362, payjoin/rust-payjoin#365, https://github.com/payjoin/btsim/blob/master/src/tx_contruction.rs, https://github.com/arminsabouri/lattice-psbt).

This is a living document that attempts to collect all the notes we have produced on this topic over the past year. And provides concrete details.

This is a living document. There is more to hash out, specifiy and bikeshed over .

[DanGould]

Wonderful. looking forward to reading. excellent seeing this pushed

[DanGould]

I see every reason to commit what's here as a great start. I think my suggestions make it easier to read and adopt a frame consistent with reality and our past framing of it (privacy as a negative right rather than an entitlement)

[DanGould]

Please commit ./00_overview to main. Until it's committed to the same branch or the link references the foreign branch this is a broken link

[arminsabouri]

Relative links should work as long as the path is correct. Its working here

[DanGould]

I didn't realize this PR was pushing to payjoin:overview and not payjoin:main. This is right. Please merge.

[nothingmuch]

this kind of implies (appropriately) messages are signed by this key and a directory can verify signatures on messages, but i believe this should be stated more explicitly

alternatively if this is intended to imply only a MAC by the shared secret, i think that a publicly verifiable signature makes more sense because semantically it's the same for the peers (it's repudiable, since the private key is shared) but allows the directory to exclude messages from unrelated parties.

this seems like a useful property for scenarios where multiple directory servers are used in conjunction for the same session, as just being able to read the mailbox doesn't confer the ability to write to it (and both are independent of the ability to decrypt the messages)

[nothingmuch]

if eager zk proofs are added for BFT version of this, then inputs should be finalized before ouptuts start being added, since otherwise there's a weak privacy leak - an output added after an input could not derive its funding from that input

if proofs are added only after the fact if necessary (both simpler and more efficient in the happy path but potentially more fragile to byzantine participants as they can waste more of everyone's bandwidth with txouts that will eventually only get pruned) then this will not be a problem as an input can be added after the output and any proof of that output's validity can still depend on the homomorphic commitment associated with the input

[nothingmuch]

given a set or sequence of n protocol messages to be posted and (under the synchronous communication model's assumptions) a time window during which these messages could be posted, sample n uniformly random times within that window and assign the messages to these times

if the number of messages is not yet known the delays can be sampled from an exponential distribution, but the total time may be unbounded necessitating rejection sampling

in either case this can be modeled as a Poisson process, stationary in the first case and inhomogenous in the second if rejection sampling is needed

arrival times in a Poisson process are independent and random

the superposition of Poisson processes is still a Poisson process which ensures that messages introduced this way don't leak temporal information about their originator under the assumption that the time windows derived by individual clients aren't disjoint

in the asynchronous communication model, delays on messages could introduce enough separation between the messages of different users in order to allow them to be partitioned but that is unavoidable

[nothingmuch]

i don't think this inherently one or the other, if timeouts are set to infinity and parties are honest then even in the async model they will eventually succeed

imo this layer should remain agnostic to the communication as much as possible but absolutely the choice of communication model should be discussed so yes we should talk about timeouts

[nothingmuch]

i don't think the directory should verify anything about the transcript.

instead it can use per UTXO rate limiting to ensure abuse can be prevented, but session encryption should just use symmetric keys completely opaque to the directory

semi-honest also implies that all parties to a session will behave, so unless somebody spams random mailboxes associated with a session, something arguably addressed by rate limiting, there's no need to verify anything