New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EIP 1576 #1576

Open
wants to merge 1 commit into
base: master
from
Jump to file or symbol
Failed to load files and symbols.
+243 −0
Diff settings

Always

Just for now

Copy path View file
@@ -0,0 +1,243 @@
---
eip: 1576
title: Simple Whisper bid negotiation protocol
author: Isaac Patka <isaac+zy@bloom.co>, Dustin van Schouwen <dustin+xy@bloom.co>
status: Draft
discussions-to: https://github.com/hellobloom/EIPs/issues/1
type: Standards Track
category: ERC
requires: 627
created: 2018-07-27
---
## Simple Summary
Set of protocols for encrypted, dark messaging continuity and bid negotiation on Whisper over ÐΞVp2p/libp2p.
## Abstract
The following standard specifies two protocols - a low-level "bulletin" protocol for publicly posting a message and then dissociating into anonymous Whisper topics for message anonymity/obfuscation, and, on top of that, a protocol for publishing a solicitation for bids that dissociate into encrypted private channels with each message, finalizing, optionally, with a message providing information specific to or required for the on-chain communication of information relating to some good or service.
## Motivation
On-chain negotiation for different providers to offer bids on a given on-chain action is costly, while off-chain negotiation suffers from inability to adequately find peers without centralization. Whisper protocol built on top of ÐΞVp2p, given adequate peer association, offers several advantages for a negotiation protocol, including anonymity, obfuscation of message origin, and built-in encryption, as well as the added benefit for Ethereum-based systems of reuse of existing technology, as Whisper functionality is built into the standard geth or Parity client. A decentralized marketplace involving bid solicitation, or any other sort of negotiation process, as a prerequisite to on-chain transactions benefits from all of the above.
## Rationale
A simple, lightweight and fully flexible protocol for messaging chaining, and then additionally for economic negotiations, was desired. An original protocol of fixed-price-for-good negotiations was replaced with an abstract "bid_type" key and secondary parameters to accomodate any type of economic transaction. Top-level fields in the protocol were reserved for key protocol features, while the "data" key hosts type-specific information.
# Message Protocol
## Specification
**Initial message**
{
"request_uuid": "ad9db457-24c0-48fe-9b63-f45199b8b6f3", // Persistent UUID for connection
"uuid": "1510a5fb-88d8-4264-bd5a-1b875dda4e5b", // Unique UUID for this message
"public_key": "...", // One time use key for subsequent messages
"topic": "0x1234abcd", // Topic for follow-up messages to be published to
"type": "...", // Any string identifying message type. Unspecified in messaging protocol standard.
"data": {
...
}
}
**Subsequent messages**
{
"session_uuid": "ad9db457-24c0-48fe-9b63-f45199b8b6f3", // Persistent UUID for connection
"uuid": "3814d733-850b-4aff-80b2-70bc946d7f09", // Unique UUID for this message
"re_uuid": "1510a5fb-88d8-4264-bd5a-1b875dda4e5b", // Unique UUID for this message
"public_key": "...", // One time use key for subsequent messages
"topic": "0xfb139fa8", // Topic for follow-up messages to be published to
"type": "...", // Any string identifying message type. Unspecified in messaging protocol standard.
"data": {
...
}
}
The message protocol is the lower-layer protocol of the specification, allowing a general public request of any form to arbitrarily dissociate from a publicly known Whisper topic into a topic divulged in the initial message (which is encrypted with a symmetric key available to some community or the public), after which point the communications dissociate from any publicly known topic, as each subsequent message in the message protocol uses random key rotation to obfuscate the topic location of the conversation. Subsequent message topics are derived from the uuid of the incoming message. This message protocol allows arbitrary public broadcasts to transform into private communications over Whisper, while retaining 'ghost' identities identifying a consistent set of two participants in a conversation (possibly extensible to n > 2 with key sharing schemes) by way of key identification.
# Negotiation Protocol
All negotiation messages contain payloads of minified JSON data. The original message is encrypted by a publicly known symmetric key, while subsequent messages are encrypted using asymmetric ECDSA. This bid request and acceptance protocol uses the underlying message protocol to allow an pseudonymous bidding process with dark messaging.
## Specification
**(1) Solicitation message**
Solicitation for bids on an arbitrary subject.
Topic: Any
Encrypted by: public topic
From: Bid requester
To: Community or public
{
"session_uuid": "2c2c03eb-11b6-43e5-86fd-30ed8c13ad08", // A unique identifier
"uuid": "42c56c06-0335-4671-9e4c-f185ef1678f6", // Message-specific unique-ID
"type": "solicit", // Message type
"public_key": "...", // Single-use ECDSA public for bidders to encrypt their reply
"topic": "0x1234abcd", // Whisper topic which acts like symmetric key for message. Preselected and shared out of band if initial broadcast or derived from uuid of recieved message. Poorly selected topic may make subsequent messages more conspicuous
"data": {
"bid_type": "flat", // Type of bid being requested - flat-price "flat", rate-based "rate", "loan", etc.. Specific parameters for a given bid type provided in "bid_terms"
"bid_terms": {
"currency": "eth", // Arbitrary currency specification
"amount": "0.2", // Maximum amount willing to pay
},
[...] // Other negotiation-specific information (type of service or good being requested, or other stipulations)
}
}
**(2) Original bid message**
Provides bid in response to solicitation. Bid data may optionally contain proof of ownership of an Ethereum address with some tangential information associated with it (dApp identity or similar).
Topic: "topic" from (1)
Encrypted by: "public_key" from (1)
From: Bidder
To: Bid requester
{
"session_uuid": "2c2c03eb-11b6-43e5-86fd-30ed8c13ad08", // A unique identifier
"uuid": "84658413-4b3b-4d72-9b8f-aa67105d96ce", // Message-specific unique-ID
"re_uuid": "42c56c06-0335-4671-9e4c-f185ef1678f6", // UUID of message being replied to
"type": "bid", // Message type
"public_key": "...", // Single-user ECDSA public key for bidders to encrypt message for
"topic": "0x4321dcba", // Preselected or randomly selected Whisper topic for subsequent messages. Reduces computational overhead for Whisper filtering, but for a poorly selected topic, may make subsequent messages more conspicuous
"data": {
"bid_type": "flat",
"bid_terms": {
"currency": "eth", // Arbitrary currency specification (likely same as ask_currency from message (1), but not necessarily)
"amount": "0.1", // Amount bid
},
"eth_address": "...", // (Optional) Ethereum address (may be used to prove identity in relation to some dApp)
"signature": "...", // (Optional) Signature of text "#{regarding}#{bid}#{current_topic}", in order to prove ownership of eth_address
"signature_format": "v1#ethSigUtil.signTypedData", // (Optional) Signature format
[...] // Bid-specific stipulations or other arbitrary data
}
}
**(3) Bid acceptance or bid rejection**
Requester notifies bidder of bid acceptance or rejection. Acceptance would entail the bidder sending acknowledgement, while rejection may or may not entail the bidder sending a more appropriate bid in the format of message (2), depending on rejection_type being absolute or conditional. Rejection messages are optional. Rejection messages may also be broadcast to the same audience as the solicitation indicating that an accepted bid has been found and all others should not expect to receive any further communication.
Topic: "topic" from (2)
Encrypted by: "public_key" from (2)
To: Bidder
From: Bid requester
{
"session_uuid": "2c2c03eb-11b6-43e5-86fd-30ed8c13ad08", // A unique identifier
"uuid": "1c526b53-8813-4477-bd01-e71424e006e2", // Message-specific unique-ID
"re_uuid": "84658413-4b3b-4d72-9b8f-aa67105d96ce", // UUID of message being replied to
"type": "accept", // Message type
"public_key": "...",
"topic": "0xa1b2c3d4",
"data": {
"bid_type": "flat", // Confirming bid type from message (2)
"bid_terms": {
"currency": "eth", // This and subsequent terms confirming terms from message (2)
"amount": "0.1",
},
[...] // (Optional) Additional data
}
}
{
"session_uuid": "2c2c03eb-11b6-43e5-86fd-30ed8c13ad08", // A unique identifier
"uuid": "1c526b53-8813-4477-bd01-e71424e006e2", // Message-specific unique-ID
"re_uuid": "84658413-4b3b-4d72-9b8f-aa67105d96ce", // UUID of message being replied to
"type": "reject", // Message type
"public_key": "...",
"topic": "0xa1b2c3d4",
"data": {
"bid_type": "flat", // Confirming bid type from message (2)
"bid_terms": {
"currency": "eth", // This and subsequent terms confirming terms from message (2)
"amount": "0.1",
},
"rejection_type": "absolute", // "absolute" or "conditional" - conditional would entail "data" attribute outlining additional parameters
"conditions": ["bid_amount", "bid_currency"], // Arbitrary array of conditions, ideally using machine-readable keys from previous messages or messages' data objects.
[...] // (Optional) Other acknowledgement-related data
}
}
**(4) Acknowledgement message**
Bidder confirms intent to proceed with bid, sending any information involved with execution of bid request, and green-lighting bid requester to do the same.
Topic: "topic" from (3)
Encrypted by: "public_key" from (3)
To: Bid requester
From: Bidder
{
"session_uuid": "2c2c03eb-11b6-43e5-86fd-30ed8c13ad08", // A unique identifier
"uuid": "80f8cec2-175b-46e2-99b4-8e9f836fc17a", // Message-specific unique-ID
"re_uuid": "1c526b53-8813-4477-bd01-e71424e006e2", // UUID of message being replied to
"type": "ack", // Message type
"public_key": "...", // Single-user ECDSA public key for bidders to encrypt message for
"topic": "0x4321dcba",
"data": {
"bid_type": "flat", // Confirming bid type from message (2)
"bid_terms": {
"currency": "eth", // This and subsequent terms confirming terms from message (2)
"amount": "0.1",
},
[...] // (Optional) Other acknowledgement-related data
}
}
**(5) Job details message**
Bid requester responds to acknowledgement from bidder with any details required to execute on job. This will usually involve details on how the requester and bidder should proceed with an out of band communication channel. Relevant job details could also be shared over Whisper but users may run into message payload size limits.
Topic: "topic" from (4)
Encrypted by: "public_key" from (4)
To: Bidder
From: Bid requester
{
"session_uuid": "2c2c03eb-11b6-43e5-86fd-30ed8c13ad08", // A unique identifier
"uuid": "abd8ab40-880f-4649-b3e3-d2c86ee4480d", // Message-specific unique-ID
"re_uuid": "80f8cec2-175b-46e2-99b4-8e9f836fc17a", // UUID of message being replied to
"type": "job_details", // Message type
"public_key": "...", // Single-user ECDSA public key for bidders to encrypt message for
"topic": "0xa4b3c2d1",
"data": {
"url": "https://www....", // Endpoint for gathering information, providing information, or anything else
"job_data": {
[...] // Job data - entirely specific to type of job being performed, left to be specified per use case in the future
},
[...] // (Optional) Other acknowledgement-related data
}
}
**(6) Subsequent communications (optional)**
Any subsequent communications naturally continue the key rotation and topic jumping patterns from the prior messages, retaining the relevant payload data schema, but carry no specified meaning in relation to the protocol.
{
"session_uuid": "2c2c03eb-11b6-43e5-86fd-30ed8c13ad08", // A unique identifier
"uuid": "86bfc325-6d8a-4721-baf2-f18f0cde522a", // Message-specific unique-ID
"re_uuid": "abd8ab40-880f-4649-b3e3-d2c86ee4480d", // UUID of message being replied to
"type": "followup", // Message type, depends on implementation
"public_key": "...", // Single-user ECDSA public key for bidders to encrypt message for
"topic": "0x18273645",
"data": {
[...] // Schema unspecified
}
}
## Implementation
Both protocols are implemented (with some negligible schema changes) as the Bloom Protocol [Attestation Kit](https://github.com/hellobloom/attestation-kit). The Whisper-specific implementation code can be found [here](https://github.com/hellobloom/attestation-kit/tree/master/app/shared/whisper), with Typescript specifications for message types found [here](https://github.com/hellobloom/attestation-kit/blob/master/app/shared/whisper/msgTypes.ts), and the majority of the sample code [here](https://github.com/hellobloom/attestation-kit/blob/master/app/shared/whisper/requesterActions.ts) and [here](https://github.com/hellobloom/attestation-kit/blob/master/app/shared/whisper/attesterActions.ts).
## Copyright
Copyright and related rights waived via CC0.
ProTip! Use n and p to navigate between commits in a pull request.