Conversation
|
Wonderful. looking forward to reading. excellent seeing this pushed |
DanGould
left a comment
DanGould
left a comment
There was a problem hiding this comment.
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)
semi-honest.md
Outdated
| @@ -0,0 +1,93 @@ | |||
| # Overview: Semi-honest multiparty PayJoin | |||
|
|
|||
| The following is a concrete description of the semi-honest multiparty PayJoin protocol. To understand why certain design choise were made, it is recommended to read the [overview document](./00_overview.md) first. | |||
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Relative links should work as long as the path is correct. Its working here
There was a problem hiding this comment.
I didn't realize this PR was pushing to payjoin:overview and not payjoin:main. This is right. Please merge.
arminsabouri
force-pushed
the
semi-honest
branch
from
9a73a49 to
f4081bb
Compare
|
|
||
| ## Threat model | ||
|
|
||
| This protocol operates in a semi-honest (honest-but-curious) model. All participants are assumed to economically approximate and thus follow the protocol as specified. They are not expected to deviate from the rules or misbehave in any form. However, they may attempt to learn as much as possible from the messages they observe. |
There was a problem hiding this comment.
| This protocol operates in a semi-honest (honest-but-curious) model. All participants are assumed to economically approximate and thus follow the protocol as specified. They are not expected to deviate from the rules or misbehave in any form. However, they may attempt to learn as much as possible from the messages they observe. | |
| This protocol operates in a semi-honest (honest-but-curious) model. All participants are assumed to economically proximate and thus follow the protocol as specified. They are not expected to deviate from the rules or misbehave in any form. However, they may attempt to learn as much as possible from the messages they observe. |
|
|
||
| // TODO: Since mailboxes are variably sized this may leak information about the number of participants and the size of the transaction. | ||
|
|
||
| Alternatives to appending have been discussed [here](https://github.com/payjoin/rust-payjoin/issues/365) |
There was a problem hiding this comment.
i believe that discussion topic should be updated to reflect improved understanding, i think what's written here supersedes everything i was spitballing there
|
|
||
| ### Shared session secret | ||
|
|
||
| A session is defined by a single ephemeral shared secret (S). Any participant who learns (S) can join the session. Knowledge of this secret is the only admission control mechanism. |
There was a problem hiding this comment.
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)
|
|
||
| ## Protocol phases | ||
|
|
||
| Input and output registration can be sent in any order. Ordering and sorting semantics must be defined a priori. |
There was a problem hiding this comment.
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
| Each participant submits the transaction inputs they control. Inputs must be posted as independent messages. | ||
| Inputs are not attributed to participants. Observers of the mailbox should not be able to determine which inputs originate from the same party. | ||
|
|
||
| // TODO: introducing jitter? Waitign for some other messages? |
There was a problem hiding this comment.
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
|
|
||
| If the protocol stalls, the session must be abandoned. A new session must be created if participants wish to try again. | ||
|
|
||
| // TODO: This is in the semi-synchronous / synchronous setting so we should talk about timeouts? |
There was a problem hiding this comment.
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
4 participants
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 .