Add honest & 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]

didn't review the updated semi honest yet

[nothingmuch]

here probably isn't the right place to go into all the detail but "mutually trusting" should be qualified at least somewhat.

specifically:

we trust peers with respect to liveness (so not to deviate from the protocol, or disappear i.e. crash faults, which also means we trust they won't get disconnected from the internet in the synchronous communication model when/if we rely on timeouts for liveness)

we trust peers with respect to privacy, i.e. we trust that they will forget/delete any private information they may observe like timing information, ordering of messages, metadata obtained from the transport layer like IP addresses, etc etc

we do not need to trust peers with safety on the consensus layer, i.e. producing transactions that will cause us to lose money, because we assume SIGHASH_ALL, ensuring that funds are always disbursed in accordance with our intents. so any safety violations in the sense of entering an invalid state (like producing a transaction that overspends its input funds and therefore will never be valid) is therefore defined to be a liveness failure (so the liveness guarantees we would like to make are not just for a single transaction construction session among a fixed set of participants, but the juxtaposition of all such sessions that an individual participant participates in)

[arminsabouri]

Where is the right place for this? this would be partially a repeat bc these points are already covered in the main overview

[nothingmuch]

the overview is going to go through the blender at some point, but even if it was already finalized in scope i still think it's worth specifying here so that someone who just wants to read about what this protocol actually needs/assumes doesn't have to digest an overview of a suite of related protocols

these definitions are very stable so i think redundancy is fine for the purposes of clear exposition and reducing reader fatigue, it's not like we're going to iterate on what they mean so there's no one document that is authoritative about what they are

[nothingmuch]

we need either this or some "ready to sign" announcement, i would prefer just one mechanism and this one can be optimized in the BFT setting to avoid making proofs in the happy path

see above for comment about how to define concretely, i'm leaning towards not adding dummy outputs as those may end up in actual transactions due to bugs / user error, and other than inflating the scriptPubKey to above blocksize limit the only mechanism preventing such transactions from being broadcast is standardness (so e.g. empty)

they would also need an exception when calculating size and feerates

[nothingmuch]

https://docs.iroh.computer/protocols/documents - looks like iroh does have set reconcilation and builds on its underlying gossip abstraction, so that's what we actually want for message dissemination

either way i think this stuff should be abstracted away, we should define in this document what kind of broadcast channel we need, what its properties are, and give some examples of ways of instantiating it instead of coupling this doc to the particulars of any one implementation

the more important idea is that iroh is a good example of something suitable for building this (and perhaps more imporantly, that it isn't suitable for interacting with untrusted peers, but could still be used in the semi honest setting when interacting with trusted peers within that context), not that we specifically want to build on iroh or whatever

[nothingmuch]

the protocol ensures eventual dissemination and reconciliation of all messages within the session window T_session if all parties behave honestly.

T_session implies synchronous communication model so "honestly" implies no crash faults, but i think it's perfectly fine to define this in both the sync and async or partial synchrony settings and only require eventual consistency on the set of messages.

also, i now remember why i brought up raft: we can't guarantee termination without ensuring the input set is finalized, which is an agreement/consensus problem. we can only guarantee eventual consistency, and once a balance == condition is reached then signing can proceed, but in principle there may be a whole set of omission faults due to one user getting partitioned, and failing to contribute their inputs, which in the partial synchrony or async setting is not considered faulty

[nothingmuch]

Suggested change

	# Overview: Multiparty PayJoin for honest peer threat model
	# Overview: Multiparty transaction construction in honest peer threat model

hmm, there's no requirement for this to be payjoin, and it also supports net settlement, so i think this is more accurate

a payment is just an understanding between peers that one will use $d$ fewer sats in their outputs than contributed by their inputs, and the other will be allowed to claim $d$ more. just inviting someone to a session may take the form of a payment with value 0, but i think it makes more sense to do this in two steps:

1. initiate contact with the peer
2. inform peer of payment intent
3. create session or wait for session creation

in order to make this simple to reason about, perhaps initiation should always create a session, 0 or more payment intents can be sent with respect to a particular session, and then sessions can be explicitly merged prior to what we're now calling "session creation", and that can be renamed into "commencement" or something which is a bit less of a mouthful.

this decouples sessions from connections, and ensures that tracking which payment is expected in which session is always unambiguous

[arminsabouri]

I'm struggling to undestand how this is different than whats written today. When the inititator and responder connect that is an implicit 2 party session creation and they are just waiting for mp pj session to kickstart

[nothingmuch]

payjoin implies a payment, but payment is just one reason to join into a multiparty transaction

e.g. internal to an organization, there likely won't be payments

so we should not call it multiparty payjoin (though that label makes sense in semi-honest setting), that implies it's less general

[arminsabouri]

Moving to draft until I address a few more things