Proposal: Use Custom Transaction Type for P2P Fiat/Crypto On/Off Ramps

[abit]

http://docs.bitshares.org/development/namespaces/chain.html#_CPPv2N8graphene5chain16custom_operationE

Ok. Thanks to @abit too.

Almost all of the proposed API calls are unneccesary, and can use the custom transaction types.

The documentation is really bad for this stuff though. Something with the schema for the commands would go a long ways. I saw there was a command that returns the schema for the custom operations, but the command does not seem to work with bitshares-ws NPM module API.


It seems like the following commands may be useful for such an implementation:

custom_operation
custom_evaluator
custom_id_type
custom_object_type

Custom operations usually do nothing other than validating authorities. So there will be no "custom_object" in the core, nor evaluator or custom_id_type. Business logic around it would be "customized" (not in the core consensus).

Ok, so custom_operation can be used for all custom operations.

How can these custom operations be queried and filtered using the API? Or would one need to download all custom operations starting from from the genesis block, and process them client-side?

If the latter, then that is definitely not ideal. Some type of query and filter API call would be handy.

I would suggest Meteor's version of MongoDB-styled syntax since custom operations are aschematic. It is easy to learn and fairly straightforward. Two API calls would cover all use cases: find_custom_operation and find_one_custom_operation. These commands should accept MongoDB-styled queries. These API calls would be very powerful for building decentralized applications on top of Bitshares. https://docs.meteor.com/api/collections.html#Mongo-Collection-find

As I've mentioned, if we do it in the node, we can write a new plugin to parse and store info about custom operations, and/or use export data to external services e.g. the Elastic Search Objects plugin (https://github.com/bitshares/bitshares-core/pull/500), then query as needed. Except doing in the node, we can also setup external scripts to listen and parse blocks then store related data to external databases e.g. MongoDb then setup 3rd services e.g. blockchain explorer to query them. Do it in client side is also possible, since some people want to verify the data by themselves.

By the way, I still think it's better to go with the "conditional payment" feature aka on-chain escrow (https://github.com/bitshares/bsips/issues/44), since custom operations enforce nothing but merely recording data.

[CoinHoarder]

http://docs.bitshares.org/development/namespaces/chain.html#_CPPv2N8graphene5chain16custom_operationE

Ok. Thanks to @abit too.

Almost all of the proposed API calls are unneccesary, and can use the custom transaction types.

The documentation is really bad for this stuff though. Something with the schema for the commands would go a long ways. I saw there was a command that returns the schema for the custom operations, but the command does not seem to work with bitshares-ws NPM module API.


It seems like the following commands may be useful for such an implementation:

custom_operation
custom_evaluator
custom_id_type
custom_object_type

Custom operations usually do nothing other than validating authorities. So there will be no "custom_object" in the core, nor evaluator or custom_id_type. Business logic around it would be "customized" (not in the core consensus).

Ok, so custom_operation can be used for all custom operations.

How can these custom operations be queried and filtered using the API? Or would one need to download all custom operations starting from from the genesis block, and process them client-side?

If the latter, then that is definitely not ideal. Some type of query and filter API call would be handy.

I would suggest Meteor's version of MongoDB-styled syntax since custom operations are aschematic. It is easy to learn and fairly straightforward. Two API calls would cover all use cases: find_custom_operation and find_one_custom_operation. These commands should accept MongoDB-styled queries. These API calls would be very powerful for building decentralized applications on top of Bitshares. https://docs.meteor.com/api/collections.html#Mongo-Collection-find

[abit]

http://docs.bitshares.org/development/namespaces/chain.html#_CPPv2N8graphene5chain16custom_operationE

Ok. Thanks to @abit too.

Almost all of the proposed API calls are unneccesary, and can use the custom transaction types.

The documentation is really bad for this stuff though. Something with the schema for the commands would go a long ways. I saw there was a command that returns the schema for the custom operations, but the command does not seem to work with bitshares-ws NPM module API.


It seems like the following commands may be useful for such an implementation:

custom_operation
custom_evaluator
custom_id_type
custom_object_type

Custom operations usually do nothing other than validating authorities. So there will be no "custom_object" in the core, nor evaluator or custom_id_type. Business logic around it would be "customized" (not in the core consensus).

[CoinHoarder]

http://docs.bitshares.org/development/namespaces/chain.html#_CPPv2N8graphene5chain16custom_operationE

Ok. Thanks to @abit too.

Almost all of the proposed API calls are unneccesary, and can use the custom transaction types.

The documentation is really bad for this stuff though. Something with the schema for the commands would go a long ways. I saw there was a command that returns the schema for the custom operations, but the command does not seem to work with bitshares-ws NPM module API.


It seems like the following commands may be useful for such an implementation:

custom_operation
custom_evaluator
custom_id_type
custom_object_type

[pc]

http://docs.bitshares.org/development/namespaces/chain.html#_CPPv2N8graphene5chain16custom_operationE

[CoinHoarder]

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 Agents
Escrow 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 Offer
Like 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 Trade
initiate_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 Trade
If 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 Reputations
After 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.