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]

i think we should hedge re the URI mechanism for now, the more i think about it the more pressing it seems to have payment instructions that allow for post quantum HPKE, sender initiated interactions, and long term / reusable authenticated channels to be established, as all of these make a material difference for multiparty and especially for semi-honest multiparty

[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]

we also require a total size limit

if the number of participants is known then we can say each participant gets so many weight units

i'm not sure how to handle this but we can also just ignore it (so that technically producing a nonstandard or even invalid transaction due to being oversized is still considered "success" if it could have been valid without the blocksize limit) because i don't think that would be a problem in practice

[arminsabouri]

I agree. I'm not sure how feasible this is. The session creator would know the lower bound but anyone can invite others

[nothingmuch]

i think we just note this limitation, and don't bother with it, bitcoiners shouldn't have that many friends ;-)

[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

	Candidate instantiations include [Iroh gossip + set reconciliation](https://docs.iroh.computer/connecting/gossip), [MDK](https://github.com/marmot-protocol/mdk), or a shared append-only mailbox like a [BIP-77 Directory](https://github.com/bitcoin/bips/blob/master/bip-0077.md). These are examples, not normative requirements.
	Candidate instantiations include [Iroh documents](https://docs.iroh.computer/protocols/documents), [MDK](https://github.com/marmot-protocol/mdk), or a shared append-only mailbox like a [BIP-77 Directory](https://github.com/bitcoin/bips/blob/master/bip-0077.md). These are examples, not normative requirements.

[nothingmuch]

Suggested change

	However, transport-level metadata privacy is still important against external observers. Content encryption alone does not prevent traffic analysis.
	Note that encryption alone does not prevent traffic analysis, so an external passive adversary, and in particular a global passive adversary, may be able to infer the use of this protocol, potentially correlate its use to a transaction broadcast and even attribute particular inputs and outputs to the specific participants based on metadata such as message sizes.

[nothingmuch]

this paragraph should be moved to just before the example transports paragraph

[nothingmuch]

i think this is more simply stated as reliable delivery? we need all parties to receive all messages eventually, i.e. converge on the set of all messages.

"set reconcilation" is a bunch of related protocols that are specifically tailored to handle the situation where neither side as a proper subset

set reconcilation could be used with unordered messages, but if a single server orders messages (arbitrarily) it can rely on a checkpoint index, there's no need

[nothingmuch]

with pseudo outputs this is implicit so long as every user manages to contribute an input some time before the other users' final txout or pseudo-output, so there's no need to declare this explicitly

precise per satoshi accounting is needed for fairness in semi-honest (ish, arguably covert adversaries are outside of semi-honest threat model but still) or for bft, per theft of wasabi fees by certain coordinators. by ensuring that every pseudo-output, along with its idempotence id, is committed to in the session transcript, mining fee contributions can't be stolen by malicious users.

if proofs are needed for output validity due to equivocation by one of the parties on the fast path, then after proofs are posted outputs should send an explicit ready to sign, but that's only needed on the sad path of BFT not for this version of the protocol

[nothingmuch]

Suggested change

Participants provide witnesses for the inputs they control. Once all witnesses are available, any participant can serve as the [BIP-174 combiner role](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#user-content-Combiner), assemble the fully signed transaction and broadcast it to the Bitcoin network.

Participants provide [finalized](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#user-content-Input_Finalizer) witnesses for the inputs they control. Once all witnesses are available, any participant can serve as the [BIP-174 combiner role](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#user-content-Combiner), assemble the fully signed transaction and broadcast it to the Bitcoin network.

[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

[nothingmuch]

again i think we should be agnostic to communication model, timeouts can be used for synchronous communication model, but in some settings it's fine for messages to only be delivered eventually

[nothingmuch]

Suggested change

	Concretly peers are trusted with:
	## Trust Model