0 Members and 1 Guest are viewing this topic.
Not really .. and HTLC only has two parties. An escrow may have three parties (and additional mediator)
Will HTLC make BSIP46 obsolete? (https://github.com/bitshares/bsips/pull/111)
There is now HTLC being enabled with 3.0.0
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.
Relevant:Quote from: CoinHoarder on March 09, 2018, 02:28:42 amI'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....
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....
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 agent2. rate_account should only be able to be done if the user has completed a trade with the escrow agent or counterpartyThe 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.
QuoteSellers’ funds are allocated on p2p-bridge in BitShares blockchain only at the moment of making the deal. When the seller confirms receiving fiat, funds are sent to the buyer.If the deal is cancelled, the funds are sent back to the wallet. Thus we serve as an escrow and guarantee safety of making the deal to both parties.So.. theoretically, is it possible that the operator of the website disappear with the customers' funds?
Sellers’ funds are allocated on p2p-bridge in BitShares blockchain only at the moment of making the deal. When the seller confirms receiving fiat, funds are sent to the buyer.If the deal is cancelled, the funds are sent back to the wallet. Thus we serve as an escrow and guarantee safety of making the deal to both parties.
The on-chain escrow feature implemented on Steem would prevent that from happening. We're talking about building a similar one in BitShares.
take a look at this project, it is a alfa version of a "localbitshares" that now in test by Russian community https://www.p2p-bridge.org/
Considering that we want to grow the network, have limited human resources but have a governance system for funds,how about we setup some bounties to implement features and let the shareholders decide which ones to fund:* conditional payments (general)* escrow system (specific)* dividends feature (existing code)* atomic cross-chain swaps (existing code)Of course, we cannot ask the current set of developers to do *all* the work, but we can use the funds at our dispose (worker proposals) to find talent and let them do stuff while earning some money?!
IMHO, an escrow feature only makes sense if you allow other "conditions" to withdraw from an escrow balance.Pretty much like what is needed for atomic cross chain swaps, where you have to provide a "secret" to claim funds.That secret could be a signature, or could be a password, or, if you want, a mathematical condition that needs to be met (think, POW)I'd like to have this feature to be compatible with the needs for interledger.org. That would enable quite some usecaes if you ask me.Anyone up for creating the specs for it?
It should be noted that escrow is already possible by using a dedicated account for each escrow operation (such accounts can be re-used for subsequent escrows).
This feature is very powerful to run web site like LocalBitcoin and localEthereum. After some research, I found that there is Escrow Operations code in STEEM, another graphene project. Perhaps core developers can look into this.1. Add Escrow Operations in STEEM by BMhttps://github.com/steemit/steem/issues/143https://steemit.com/sip/@dan/escrow-sip-steem-improvement-proposal2. Open Source STEEM Escrow GUIhttps://steemit.com/utopian-io/@reazuliqbal/opensource-steem-escrow-guihttps://steemit.com/escrow/@xtar/open-source-standalone-gui-for-steem-escrow-transactions
Quote from: fav on February 21, 2017, 08:19:19 amagreed, escrow should be implemented asap, not sure how much work that would be.You could do that today using a 2-of-3 account .. ideally a service would offer this for a profit and recycle old used and completed escrow accounts instead of registering a new one
agreed, escrow should be implemented asap, not sure how much work that would be.
Quote from: Thom on February 15, 2017, 03:16:46 pmThis is a typical escrow service, which I thought was built into BitShares 2.0 now. Escrow always requires trust in a 3rd party (the escrow agent) which may not be acceptable to some. Companies such as transwiser would be ideal candidates to serve as that trusted 3rd party for those in the east. I'm fuzzy on the details, but IIRC an escrow type service could be setup by transwiser for each escrow transaction. Once deposit into that account is made in full transwiser changes permission to lock out access until depositor signals the recipient has completed the agreed contract, then transwiser opens permissions to recipient to transfer funds.It's not ideal, and may in fact not even be feasible due to overhead, time etc.I don't know if there are other solutions for escrow services or not. I believe the ability to setup "supervisor" accounts or accounts with hierarchical permissions were implemented as a "corporate" feature, not an escrow facility. This is an area we need documentation to describe, if it hasn't been.I feel there are some misunderstanding, in my imagination, in most of the cases escrow is just "included" as a standby judge for possible dispute, in more than 95% of the trades there will be no dispute and the escrow need to do nothing, only when dispute happen, the trading parties will be called to judge the dispute.I feel BTS can go into off-site BTC trading business by providing this "conditional payment" feature, yes this is just a feature and the escrow inside provide service and escrows will charge service fee when they are called to judge.
This is a typical escrow service, which I thought was built into BitShares 2.0 now. Escrow always requires trust in a 3rd party (the escrow agent) which may not be acceptable to some. Companies such as transwiser would be ideal candidates to serve as that trusted 3rd party for those in the east. I'm fuzzy on the details, but IIRC an escrow type service could be setup by transwiser for each escrow transaction. Once deposit into that account is made in full transwiser changes permission to lock out access until depositor signals the recipient has completed the agreed contract, then transwiser opens permissions to recipient to transfer funds.It's not ideal, and may in fact not even be feasible due to overhead, time etc.I don't know if there are other solutions for escrow services or not. I believe the ability to setup "supervisor" accounts or accounts with hierarchical permissions were implemented as a "corporate" feature, not an escrow facility. This is an area we need documentation to describe, if it hasn't been.