Add honest overview#4
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)
| @@ -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
|
|
||
| ## 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
arminsabouri
force-pushed
the
semi-honest
branch
3 times, most recently
from
a4f4cd0 to
0ec5678
Compare
arminsabouri
changed the title
arminsabouri
force-pushed
the
semi-honest
branch
3 times, most recently
from
20a9130 to
49eeba3
Compare
nothingmuch
left a comment
nothingmuch
left a comment
There was a problem hiding this comment.
didn't review the updated semi honest yet
|
|
||
| ## Motivation | ||
|
|
||
| This protocol is best understood as a collaborative transaction construction protocol for mutually trusting parties. Its purpose is to let participants jointly build a transaction with potentially better privacy properties and cost savings than a unilateral construction. The other parties are not trusted with the safety of your funds. What they are trusted with is liveness (showing up, responding, and progressing the round) and privacy (handling protocol information honestly and not needlessly leaking it). |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
Where is the right place for this? this would be partially a repeat bc these points are already covered in the main overview
There was a problem hiding this comment.
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
|
|
||
| ### Psuedo Outputs | ||
|
|
||
| // Move to semi-honest. In honest, peers can just declare how much they are burning in their input messages |
There was a problem hiding this comment.
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
|
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 |
arminsabouri
force-pushed
the
semi-honest
branch
3 times, most recently
from
7cb7ec2 to
da0eb36
Compare
|
|
||
| Required channel properties: | ||
|
|
||
| All participants can publish protocol messages to the same session channel, with messages authenticated and kept confidential within the participant set. Each participant is able to read and merge messages from all others into their own local transaction view. While message delivery may be delayed or received out of order, the protocol ensures eventual dissemination and reconciliation of all messages within the session window `T_session` if all parties behave honestly. |
There was a problem hiding this comment.
the protocol ensures eventual dissemination and reconciliation of all messages within the session window
T_sessionif 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
There was a problem hiding this comment.
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.
Is this as simple as making T_session optional?
There was a problem hiding this comment.
IMO yes, and in practice it could still be sent just with a value that is effectively or practically infinite
arminsabouri
force-pushed
the
semi-honest
branch
from
da0eb36 to
be495e7
Compare
|
Moving to draft until I address a few more things |
|
Stole some of the language for the cyclical payments graph issue from #6 |
i'll see you in court! |
| R->>S1: session invitation (s, session params) | ||
| R->>S2: session invitation (s, session params) |
There was a problem hiding this comment.
how does R know that S1 and S2 have opted in?
|
|
||
| * **Global transaction fields**: `nVersion`, `locktype` (time or height based) | ||
| * **Feerate**: each participant contributes fees proportional to the weight of their inputs and outputs | ||
| * **Input constraints**: `nSequence` |
There was a problem hiding this comment.
a list of allowed or forbidden input types
|
|
||
| The `SessionCreator` fixes the following parameters before the session opens. All participants must verify that the final transaction conforms to the relevant parameters before signing. Size limit cannot be enforced. The `SessionCreator` only knows their immediate neighborhood of peers but those peers may invite others. | ||
|
|
||
| * **Global transaction fields**: `nVersion`, `locktype` (time or height based) |
There was a problem hiding this comment.
these could be intervals as well, if the max lattice is used
|
|
||
| Required channel properties: | ||
|
|
||
| All participants can publish protocol messages to the same session channel, with messages authenticated and kept confidential within the participant set. Each participant is able to read and merge messages from all others into their own local transaction view. While message delivery may be delayed or received out of order, the protocol ensures eventual dissemination and reconciliation of all messages within the session window `T_session` if all parties behave honestly. |
There was a problem hiding this comment.
IMO yes, and in practice it could still be sent just with a value that is effectively or practically infinite
|
|
||
| When the `balance` reaches zero and receiver confirmations are received, every participant can independently verify the transaction is balanced and proceed to witness provision. | ||
|
|
||
| This honest variant does not require an explicit Ready-to-Sign declaration on the success path. With pseudo-output accounting, readiness is implicit once participants converge on the same message set and each participant has contributed at least one input before final output/pseudo-output closure. |
There was a problem hiding this comment.
-
phased input/output registration not needed, individual clients should just send their inputs before their outputs so that the balance mechanism will usually work out
-
we should describe that the balance mechanism is not 100% reliable and may require re-signing if an entire set of messages doesn't get delivered (maybe we call it "optimistic signing" or whatever)
-
this should explain that to make use of ready to sign signalling or really any form of strong consistency mechanism because that needs to be bootstrap with agreement or consensus over a set of initial inputs or participants.
| @@ -0,0 +1,168 @@ | |||
| # Overview: Multiparty transaction construction in honest peer threat model | |||
|
|
|||
| The following is a concrete description of the honest multiparty transaction construction protocol. To understand why certain choices design were made, it is recommended to read the [overview document](./00_overview.md) first. | |||
There was a problem hiding this comment.
nit: *certain design choices were made
| ### SessionCreator | ||
|
|
||
| Either an `Initiator` or a `Responder` may create the session. The party that does so is the `SessionCreator`. | ||
| The `SessionCreator` is responsible to creating session parameters (defined below), bootstrapping the transport mechanism and disseminating session information to the rest of the peers to the best of their capabilities. `SessionCreator` holds no special authority once the session is live. They simply become a participant. |
|
|
||
| Before signing, each sender must receive explicit confirmation from all of its receivers of the PSBT’s unique ID (defined in the [draft BIP](https://github.com/payjoin/multiparty-protocol-docs/pull/6/)) which commits to the complete output set and verify that every confirmed ID matches the one computed locally. | ||
|
|
||
| In a cyclic payment graph, such as Alice pays Bob, Bob pays Carol, and Carol pays Alice, net-positive receivers can initiate safely and break the dependency cycle. Senders sign only after every receiver has confirmed the PSBT unique ID. Once all net-positive receivers confirm, the protocol can treat all funds as fully accounted for. |
There was a problem hiding this comment.
what's the intended behavior when all participants are net-zero (e.g. an equal-denomination coinjoin)?
There was a problem hiding this comment.
net-positive should be defined as >= 0 not > 0
5 participants
No description provided.