conditional payment feature?

[severo]

Strongly agree, practically there is nothing to do in the technical aspect, Bisq allows the exchange by Fiat of BTC, Dash and LTC.

https://markets.bisq.network/?pmarket=BTC
https://markets.bisq.network/?market=dash_usd
https://markets.bisq.network/?pmarket=LTC

Just add BTS, BitCNY and BitUSD. It is a commercial and negotiation work with Bisq more than technical. The implications of having a full FIAT p2p bridge (the only one that exists) with the DEX can be huge, especially in China, just what Bitshares needs now.

[abit]

The Bisq forum is even less active than here. Their github project page seems a little active.

[severo]

So far, Bisq has a modest size, is another reason why it would not be a danger to Bitshares, and has just what Bitshares needs: a Fiat Gateway full p2p. I think the time has come to add and not to subtract. It is the way in which all the big companies have grown.

I do not know if you realize another advantage of using an external p2p Gateway to Bitshares: If a node incorporated some FIAT exchange system, even P2P, there could be legal and regulatory problems for witnesses, depending on their country.
However, since Bisq is an external App used by each user, those problems do not arise.
I think this has the potential to be a great idea  that should be explored.

[bench]

Bisq and BTS are two different application, there is no competition only additional function.

[CoinHoarder]

Relevant:

I've been thinking of how best to implement this, and I think we only need six new API calls to make this a reality. The rest is fairly straightforward GUI work.

The six API calls I am proposing are similar to publish_asset_feed. They are mostly used just to record information permanently in the blockchain in a pre-determined schema. The rest can be done client-side and 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)

API Call 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)
}

request_arbitration (ping the escrow agent to let them know arbitration is needed)
{
  "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.)
}

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)
}

Almost everything can be done client-side with no need for changes in the protocol since 2 of 3 multisignature accounts are used. The only changes in the protocol I can think of:
1. Initiate trade creates a 2 of 3 multi-signature account with the original offerer, the counterparty initiating the trade, and the chosen escrow agent
2. rate_account should only be able to be done if the user has completed a trade with the escrow agent or counterparty

The schema is not completely thought out. I do not want to spend much time on it without knowing if the idea will be disregarded or not, but you guys get the idea. It can be improved upon if there is interest.

[severo]

This is a wonder for its simplicity and functionality, this should be supported by everyone. I only have one question with the signature the escrow agent. Who would it be? If this person is a witness, as the active witnesses fluctuate over time it could be the case that the witness who signed the start of an operation is not the same as in the closing of the operation. Then someone other than an active witness is needed. Someone chosen by the community? We need to solve this, but the solution is magnificent.

[abit]

Relevant:

I've been thinking of how best to implement this, and I think we only need six new API calls to make this a reality. The rest is fairly straightforward GUI work.

...

Good initiative.

I think you know well that if all these be implemented on client side, then no API is needed at all. These "operations" are all making changes to the blockchain state, via transactions, the only thing need to do is a client that builds the transactions and signs them and broadcast. On the opposite, the server side or the chain, can/need do nothing other than verifying the transaction which need no change on the code.

However, you do need tools to query who are offering escrow services, who is selling/buying, and etc. This need to be done via a service, API, plugin or etc.

[chenlocus]

  :)巨蟹  and abit are all here.

Using escrow service is great idea.  I am still confused on:
1. how to pick up the escrow agents, steemit can use reputation as a key element for people to vote, how about BTS?
2.  the fee seems all go to escrow agents, so the sellers ( recipients ) may lack of motivation to exchange fiat or bitUSD to buyers.

[bench]

Why does Bisq require a security deposit?

Security deposits create incentives for both buyer and seller to follow the rules of Bisq's trading protocol. They are locked into multisig escrow along with the bitcoin being traded, and are returned to each user when the trade completes successfully. If a trade goes to arbitration and one party is found to have violated Bisq's trading protocol, some or all of that party's security deposit may be awarded to their counterparty. Examples of protocol violations include a buyer failing to pay a seller, or a seller failing to acknowledge receipt of a buyer's payment. Most Bisq trades complete without any problem thanks in part to the incentives that security deposits create.

The security deposit and an escrow agent is only used, when something goes wrong. The risk of value change during the trade for bitFIAT is not a problem like BTC.

[abit]

BSIP for discussion: https://github.com/bitshares/bsips/pull/76

@bitcrab