Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2012-12-06 📝 Original message:Re: the newest spec. ...
📅 Original date posted:2012-12-06
📝 Original message:Re: the newest spec. Rather than make the signature over the
"concatenation of", why not just make it a signature over the
serialized protobuf minus the signature field (as I did in my demo
code). Otherwise it seems like we'd need more code than really
necessary. We can state explicitly tags must be ordered if you want,
even though all implementations should do that already.
> Thumbnail sketch: escrow service or participant sends around an
> EscrowProposal, gets EscrowProposalACK's with public keys to use, then sends
> all participants an EscrowEstablished message with the final multisig script
> or address.
Yeah, that sounds reasonable. Not that we should really design it now,
but let's use the term "mediation" rather than "escrow", which has
connotations of depositing funds with the escrow service.
I think it's best to see the existing payment messages as structures
that'll get filled out with more features over time. So rather than
have a separate EscrowProposal message, you would integrate it with
payment requests. Older clients that don't understand mediation would
just ignore the extra data they don't recognize.
message PaymentRequest {
....
// One per mediator acceptable to the seller.
repeated MediationProposal mediation_data = 10;
}
message MediationProposal {
required SignedMediatorIdentity identity = 2;
// Opaque bytes that the mediator can be asked to turn into a human
readable description
// of how disputes will be mediated. The merchant sets this to
describe whatever policy it
// is willing to go along with, so policies may be arbitrarily complicated.
required bytes policy = 3;
}
message SignedMediatorIdentity {
required MediatorIdentity identity = 1;
// If the identity data is signed ...
optional string pki_type = 2;
optional bytes pki_data = 3;
optional bytes pki_signature = 4;
}
message MediatorIdentity {
// Name of the mediator to be displayed to the user.
required string friendly_name = 1;
// PNG image that can be used to represent the mediator to the user.
optional bytes logo = 2;
// Some text shown to the user under the name explaining the
mediators policies, why they should be chosen, etc.
optional string blurb = 3;
// An HTTP URL where a mediator can be reached to do things like
prove ownership of pubkeys, initiate the protocols, etc.
required string contact_url = 4;
}
... etc ....
So the user experience would be that when a payment request is received:
- older clients ignore the mediation_data field and do a direct
payment as normal
- newer clients ask the user to pick a mediator (if they want to) and
if mediation is requested, the PaymentRequest is then discarded and
the next step of the mediation protocol begins.
The old request has to be discarded because the outputs would have
been written on the assumption of no mediation being in use (for
backwards compatibility).
Anyway, though I'm awfully guilty, let's not get off track. Just that
this is how I imagined new payment features being done - as new
extensions to the payment protocol, which would be a living document
amended by BIPs.
📝 Original message:Re: the newest spec. Rather than make the signature over the
"concatenation of", why not just make it a signature over the
serialized protobuf minus the signature field (as I did in my demo
code). Otherwise it seems like we'd need more code than really
necessary. We can state explicitly tags must be ordered if you want,
even though all implementations should do that already.
> Thumbnail sketch: escrow service or participant sends around an
> EscrowProposal, gets EscrowProposalACK's with public keys to use, then sends
> all participants an EscrowEstablished message with the final multisig script
> or address.
Yeah, that sounds reasonable. Not that we should really design it now,
but let's use the term "mediation" rather than "escrow", which has
connotations of depositing funds with the escrow service.
I think it's best to see the existing payment messages as structures
that'll get filled out with more features over time. So rather than
have a separate EscrowProposal message, you would integrate it with
payment requests. Older clients that don't understand mediation would
just ignore the extra data they don't recognize.
message PaymentRequest {
....
// One per mediator acceptable to the seller.
repeated MediationProposal mediation_data = 10;
}
message MediationProposal {
required SignedMediatorIdentity identity = 2;
// Opaque bytes that the mediator can be asked to turn into a human
readable description
// of how disputes will be mediated. The merchant sets this to
describe whatever policy it
// is willing to go along with, so policies may be arbitrarily complicated.
required bytes policy = 3;
}
message SignedMediatorIdentity {
required MediatorIdentity identity = 1;
// If the identity data is signed ...
optional string pki_type = 2;
optional bytes pki_data = 3;
optional bytes pki_signature = 4;
}
message MediatorIdentity {
// Name of the mediator to be displayed to the user.
required string friendly_name = 1;
// PNG image that can be used to represent the mediator to the user.
optional bytes logo = 2;
// Some text shown to the user under the name explaining the
mediators policies, why they should be chosen, etc.
optional string blurb = 3;
// An HTTP URL where a mediator can be reached to do things like
prove ownership of pubkeys, initiate the protocols, etc.
required string contact_url = 4;
}
... etc ....
So the user experience would be that when a payment request is received:
- older clients ignore the mediation_data field and do a direct
payment as normal
- newer clients ask the user to pick a mediator (if they want to) and
if mediation is requested, the PaymentRequest is then discarded and
the next step of the mediation protocol begins.
The old request has to be discarded because the outputs would have
been written on the assumption of no mediation being in use (for
backwards compatibility).
Anyway, though I'm awfully guilty, let's not get off track. Just that
this is how I imagined new payment features being done - as new
extensions to the payment protocol, which would be a living document
amended by BIPs.