I've been thinking of how best to implement
this, and I think we may not need any new API calls to make this a reality. It is fairly straightforward GUI work once the design is finalized.
Most custom operations to make this work are used just to record information permanently on the blockchain in a pre-determined schema. Everything else can be done client-side by leveraging the current implementation of multi-signature accounts.
command (description):provide_escrow (offer escrow services)
publish_offer (sell/buy a crypto token)
cancel_offer (cancel an offer)
initiate_trade (match an existing offer)
request_arbitration (ping the escrow agent to let them know arbitration is needed)
rate_account (rate the counterparty/escrow agent in a trade)
Schema:provide_escrow:
{
"meta_type": "p2p_trade",
"sub_type": "provide_escrow",
"publisher": String (account ID),
"escrow": Boolean (true... currently providing escrow OR false... not currently providing escrow)
}
publish_offer:
{
"meta_type": "p2p_trade",
"sub_type": "publish_offer",
"offer_id": String (a unique ID... similar to how there are IDs for uias, tokens, etc.),
"publisher": String (account ID),
"offer_type": String ("ask"... selling crypto OR "bid"... buying crypto),
"crypto_id": String (UIA/Smartcoin/Token ID that they want to buy/sell),
"accepting": Array of Strings (what the user will accept in return ["bitcoin", "cash in the mail", "chase bank deposit"] etc.),
"price": Integer (Price offered),
"amount": Integer (Amount offered),
"terms": String (details including terms for the trade... ID required? Time limit? Restrictions? etc.),
"escrow_options": Array (array of account IDs that the user is willing to use as Escrow Agents for the trade)
}
cancel_offer:
{
"meta_type": "p2p_trade",
"sub_type": "cancel_offer",
"offer_id": String (a unique ID... similar to how there are IDs for uias, tokens, etc.),
"publisher": String (account ID),
}
initiate_trade:
{
"meta_type": "p2p_trade",
"sub_type": "initiate_trade",
"offer_id": String (a unique ID... similar to how there are IDs for uias, tokens, etc.),
"escrow_agent": String (an account ID that has declared themselves as available for escrow using provide_escrow, and that the offer has included in the array of preferred escrow agents: escrow_options),
"publisher": String (account ID)
}
request_arbitration:
{
"meta_type": "p2p_trade",
"sub_type": "request_arbitration",
"offer_id": String (the unique ID of the offer... similar to how there are IDs for uias, tokens, etc.),
"publisher": String (account ID)
}
rate_account:
{
"meta_type": "p2p_trade",
"sub_type": "rate_account",
"offer_id": String (the unique offer ID of the escrow agent or counterparty you are rating ... similar to how there are IDs for uias, tokens, etc.),
"rating": Integer (a rating of your experience with the counterparty or escrow agent... 1 through 4),
"comment": String (a description of your rating)
"publisher": String (account ID)
}
How it works:
Escrow AgentsEscrow Agents will be used as arbitrators. Anyone can be an Escrow Agent by declaring themselves available for such services using the provide_escrow command. Initially it will likely be trusted community members, but the reputation system allows new users to build reputations as Escrow Agents too.
Publish OfferLike publishing a listing on LocalBitcoins.com, each offer to buy/sell a token will be published on the blockchain using publish_offer. This will contain all applicable information including which token, escrow agents, price, etc... then one of two things can happen:
The publisher of the offer can cancel it using cancel_offer, or someone can choose to be the counterparty to a trade by using initiate_trade.
Initiate Tradeinitiate_trade first creates a 2 of 3 multi-signature account with the original offerer, the counterparty initiating the trade, and the escrow agent the counterparty chose from the list of escrow agents the offerer is willing to use.
Requesting Arbitration or Completing The TradeIf both parties in the trade agree that it was completed successfully, then there is no need for the Escrow Agent to do anything. In this case, a transaction out if the multi-signature account can be proposed. If arbitration is meccessary, then request_arbitration can be used to notify the escrow agent of the neccesity of arbitration.
Establishing ReputationsAfter trades, users can permanently record their experience with the escrow/counterparty on the blockchain with a simple star rating and description to elaborate. rate_account should only count if the account has completed a trade with the escrow agent or counterparty. The last rate_account should be used, which will allow accounts to update their rating after the fact if problems arise.
Sybil Attack Detterents:Sybil attacks on the ratings can be solved several ways completelu client-side. By simply giving more weight (or sorting in descending order) to the amount of BTS the reviewer owns. A web of trust system can also be created where people add other BTS accounts they trust. Obviously, filtering reviews to only show if the accounts have successfully completed a trade.
---------
The schema is not completely thought out. I have not spent much time on it, but you guys get the idea. It can be improved upon if there is interest.
The meta_type property of the schema can be used to filter applicable data from the blockchain, and the sub_type can be used to process (or further filter) them.
Show Posts
