Author Topic: conditional payment feature?  (Read 16675 times)

0 Members and 1 Guest are viewing this topic.

Offline Sapiens

  • Jr. Member
  • **
  • Posts: 35
    • View Profile

Offline Sapiens

  • Jr. Member
  • **
  • Posts: 35
    • View Profile
May someone please clarify what HTCL is?

Offline dexy

  • Newbie
  • *
  • Posts: 13
    • View Profile
  • BitShares: dexy
Not really .. and HTLC only has two parties. An escrow may have three parties (and additional mediator)

That's why i asked :)
I'd like to see the opportunity to make escrow transactions with a mediator.
Are there any moves in this direction?

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Will HTLC make BSIP46 obsolete? (https://github.com/bitshares/bsips/pull/111)
Not really .. and HTLC only has two parties. An escrow may have three parties (and additional mediator)

Offline dexy

  • Newbie
  • *
  • Posts: 13
    • View Profile
  • BitShares: dexy
« Last Edit: April 09, 2019, 07:45:34 am by dexy »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
There is now HTLC being enabled with 3.0.0

Offline dexy

  • Newbie
  • *
  • Posts: 13
    • View Profile
  • BitShares: dexy
Is it in development or was rejected?

Offline dexy

  • Newbie
  • *
  • Posts: 13
    • View Profile
  • BitShares: dexy

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
BitShares committee member: abit
BitShares witness: in.abit

Offline bench

Quote
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.
Be part of the change and vote for the bitshares-vision proxy!

Offline 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.

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
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.
BitShares committee member: abit
BitShares witness: in.abit

Offline severo

  • Full Member
  • ***
  • Posts: 71
    • View Profile
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.

Offline CoinHoarder

  • Hero Member
  • *****
  • Posts: 660
  • In Cryptocoins I Trust
    • View Profile
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.
https://www.decentralized.tech/ -> Market Data, Portfolios, Information, Links, Reviews, Forums, Blogs, Etc.
https://www.cryptohun.ch/ -> Tradable Blockchain Asset PvP Card Game

Offline bench

Bisq and BTS are two different application, there is no competition only additional function.
Be part of the change and vote for the bitshares-vision proxy!