BitShares Forum
Main => General Discussion => Topic started by: bitcrab on February 15, 2017, 09:50:32 am
-
in China exchanges, BTC withdrawl are banned for 1 month until the AML measurements are ready, so now many BTC traders go for outside dealings.
DEX is good as people can deposit CNY inside and then buy BTC from OpenLedger, which is outside of China goverment's control area. however, now the step of "deposit CNY" highly depend on transwiser, if one day the volume become too big to ignore, it's also possible that the China government to ban the business of transwiser.
maybe we can get help from "P2P gateway", however, to make "P2P gateway" feasible, I feel we need a new feature that can be called "conditional payment".
A want to buy100 bitCNY by paying 100 fiat CNY, so he contact B and they agree to make the deal, then B create a "conditional payment" to A for 100 bitCNY, ATM the 100 bitCNY is locked there, when B get 100 fiat CNY payment from A, then he confirm the "conditional payment" and A get the 100 bitCNY。
a "expiration time" can be set that if B neither confirm nor do anything else then after the expiration time the 100 bitCNY will automatically reach A's account.
if something happen that A and B need to cancel the deal then B can request "refund" and get the 100 bitCNY back if A confirm the refund.
if dispute happen, then an escrow, which is defined when the payment is created, will be introduced to decide how to distribute the locked fund.
this "conditional payment" is useful not only for BTC outside dealing, but also for scenarios like trading goods, international outsourcing, etc,.
possible to introduce this new feature? any thoughts?
-
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.
-
Yes, escrow service would be very useful. It requires trust to 3rd party only in case of dispute, doesn't it?
-
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.
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.
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.
What you described is a standard escrow service. Only 2 of 3 parties needs to agree so as long as the buyer and seller agree you don't need the judge, and that will happen 95% of the time. The buyer & seller just confirms on their sides. Only when one party disputes, the judge is necessary.
I'm actually working on a simple peer-2-peer gateway based on ratings & trust, but this is mainly for small amounts. For larger amounts I do think escrows will be essential.
It was planned a while back, but never implemented. An escrow feature is one of the most immediate features we should implement. I agree with you @bitcrab and would fully support this proposal.
-
agreed, escrow should be implemented asap, not sure how much work that would be.
-
agreed, 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.
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
yes, currently it is possible to do that using a 2-of-3 account, however this need to create a 2-of-3 account for each buyer-seller-escrow group, we need much better user experience.
and we need to develop that asap, with this feature, BTS will be an global off-site BTC market...so attractive!
-
"e-screw" account: 3of5 multisig group
e-screw selling ESCREW.CNY UIA against bitCNY.
If I want to withdraw bitCNY, i'll convert them to ESCREW.CNY on the market.
Next i must send memo to e-screw: "withdraw [my bank account number]"
This should trigger some e-screw's action:
Forbid me from transfers and trades ESCREW.CNY (conditional payment delivered).
Check how much i got to withdraw.
Create virtual order book on the outside webpage, for example "1000 bitCNY 'somerandomstring'
Now first guy who'll send 'somerandomstring' memo, should receive [my bank account number] back and is obligated to pay 1000 CNY to me.
When I receive money on my bank account, i must send another memo "confirm". Then my ESCREW.CNY must go back to issuer and my account is whitelisted again.
This way you don't need to touch CNY at all. I can confirm transaction without actually being part of multisig group.
However Buyer can be asshole and lock those virtual orders, without intention to buy anything.
However Seller can be asshole too, then Buyer must provide proof of bank transaction.
Good news: you can be asshole only once per account.
-
Checkout how byteball dev organized OTC trading for blackbytes. Blackbyte is a private token, which is not tracked in public ledger, only a hash of transaction is submitted to prevent double spend. Long story short, this is implemented the way which makes it impossible to trade blackbytes on BTC exchanges without modification of their code. So, the dev created a slack channel (https://byteball.slack.com/messages/trading_blackbyte, get invite at http://slack.byteball.org) with a chat bot, which allows users to place and query offers right in chat interface. There are also escrow guys who help to conduct trades. Simple and functional. Looks like a perfect scheme for OTC trading between fiat and bitFiat. Can something like this be implemented in bitshares client?
-
@yvv in trollbox, yes. You can send transactions. Could query market orders too. This could work like console actually.
-
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 BM
https://github.com/steemit/steem/issues/143
https://steemit.com/sip/@dan/escrow-sip-steem-improvement-proposal
2. Open Source STEEM Escrow GUI
https://steemit.com/utopian-io/@reazuliqbal/opensource-steem-escrow-gui
https://steemit.com/escrow/@xtar/open-source-standalone-gui-for-steem-escrow-transactions
-
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 BM
https://github.com/steemit/steem/issues/143
https://steemit.com/sip/@dan/escrow-sip-steem-improvement-proposal
2. Open Source STEEM Escrow GUI
https://steemit.com/utopian-io/@reazuliqbal/opensource-steem-escrow-gui
https://steemit.com/escrow/@xtar/open-source-standalone-gui-for-steem-escrow-transactions
Yes, I'm aware of this.
In regards to porting, we need to do step by step:
* finish the BSIP document https://github.com/bitshares/bsips/issues/44
* get the BSIP approved by BTS holders (stake-based voting)
* arrange dev resources
Contributions are always appreciated.
-
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).
-
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).
Correct.
-
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?
-
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?
I don't think that secrets need to be submitted online, that would greatly limit usage of the feature.
Just had another glance on InterLedger, I think it's for solve other issues, but not this one.
-
Bitbay and OpenBazaar have both implemented marketplace features. It is worth taking a look at their implementations.
Seems pretty straightforward... leverage reputation-based escrow agents with simple 2 of 3 multisig addresses.
I think if you're adding this feature, then you might as well implement a full-on decentralized market for goods, services, or cryptos/fiat.
It will require a minimal amount of extra effort to make a fully featured decentralized marketplace (compared to just adding a marketplace for crypto/fiat transactions).
(https://i.imgur.com/wwexCAj.png)
-
For reference:
https://github.com/bitshares/bitshares-core/issues/692
-
Maybe off-topic, but I think we should have some principles when discussing.
My principle:
* if an important "partner" business strongly wants a practicable feature, it gets highest priority.
* If more partners want it, it get more priority.
* requests from "potential partners" get lower priority.
Our dev resource is not unlimited, must focus on most important things.
-
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?!
-
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?!
That's a good idea.
-
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?!
Before submit a worker proposal for funding, dev team may try to post task requests on utopian.io, a project based on STEEM blockchain. Dev team may promise those who can deliver will get a big upvote in addition to utopian upvote bot. This will save a lot of time since workers proposals take time to get shareholder approved.
https://steemit.com/utopian-io/@deveerei/tutorial-for-utopian-task-announcements
-
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/
-
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/
This is something BTS need it since very long time ago. +5+5
-
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/
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.
So.. theoretically, is it possible that the operator of the website disappear with the customers' funds?
The on-chain escrow feature implemented on Steem would prevent that from happening. We're talking about building a similar one in BitShares.
-
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.
So.. theoretically, is it possible that the operator of the website disappear with the customers' funds?
... or keys will be lost or stolen. Previously, this happened with such centralized services so many times.
The on-chain escrow feature implemented on Steem would prevent that from happening. We're talking about building a similar one in BitShares.
This is the most important feature that should be implemented in BitShares, cause this will allow to do cheap, safe and decentralized fiat gates, which is so necessary for the network!
-
An escrow system is one of the next important features. It should be designed to handle conditional payment features like Byteballs.
-
I have already mentioned it on occasion, but I think the best solution to implement an escrow system is to use the most decentralized system that exists now to buy BTC, P2P way: Bisq. Why invent the wheel, if it already exists?
If Bisq implemented the option to change BTS or BitUSD by FIAT, then the purchase can be moved to the Bitshares DEX and the problem would be solved. There is not much danger that Bisq can remove volume from the DEX of bitshares, since the vast majority of Bisq's trade is exchange of BTC with FIAT, functionality that does not exist in the DEX. The exchange of cryptocurrencies in Bisq is wallet-to-wallet, and of very low volume. I do not think it could interfere with the type of smartcoins trade and low fees of the DEX.
Bisq can now trade with any type of cryptocurrencies, so it seems to me that the best approach for this project would be to contact the Bisq dev and propose a collaboration. Both projects would add synergies and win, so that a p2p-bridge would be available immediately. Precisely Bisq has modified its connections Tor to be able to work in mainland China and it turns out that there Bitshares has a good market. Makes sense.
-
Using the infrastructure from Bisq for FIAT exchange could give both projects huge traffic increase.
1. Integrating BTS and BitFIAT in Bisq (use BTS for security deposit and fees) https://github.com/bisq-network/docs/blob/master/exchange/howto/list-token.adoc
2. Writing a bridge to use the Bisq network for FIAT trading
There are already bitshares usere on the Bisq forum: https://bisq.community/t/add-steemusd-support-thread/340/18
-
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.
-
The Bisq forum is even less active than here. Their github project page seems a little active.
-
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.
-
Bisq and BTS are two different application, there is no competition only additional function.
-
Relevant:
I've been thinking of how best to implement this (https://bitsharestalk.org/index.php?topic=23800.0), 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.
-
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.
-
Relevant:
I've been thinking of how best to implement this (https://bitsharestalk.org/index.php?topic=23800.0), 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.
-
:) :)巨蟹 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.
-
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.
-
BSIP for discussion: https://github.com/bitshares/bsips/pull/76
@bitcrab
-
any updates?
-
Is it in development or was rejected?
-
There is now HTLC being enabled with 3.0.0
-
There is now HTLC being enabled with 3.0.0
Will HTLC make BSIP46 obsolete? (https://github.com/bitshares/bsips/pull/111)
-
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)
-
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?
-
May someone please clarify what HTCL is?
-
Nevermind, I found the answer here:
https://github.com/bitshares/bitshares-core/wiki/HTLC (https://github.com/bitshares/bitshares-core/wiki/HTLC)