Author Topic: Poloniex adding Tether and keeping the XUSD BTC pair it seems  (Read 12413 times)

0 Members and 1 Guest are viewing this topic.

Offline yankey

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

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
I have some improvements to the previous post.

tl;dr: This post describes how to implement a decentralized BTC/BitBTC exchange (with bid and ask orders) on the BitShares blockchain where the BTC sellers are motivated to settle their debts within T hours (T = 30 is a good choice) or else they forfeit a bond to their BitBTC-selling counterparty (who also gets back the BitBTC they paid for the failed trade) that is worth at most X% (obviously less than 100%) of the amount that the counterparty paid for the trade. All of this functions if we assume that at least some quorum (a threshold of at least a majority is preferred) of the active delegates do their job (and do it honestly). The BitBTC seller is exposed to the risk that a quorum of delegates (a quorum higher than the threshold) collude to defraud them out of the matched BitBTC they offered. The BTC seller is exposed to the risk that the quorum of delegates collude to defraud them out of the matched BTC offered as well as the X% BitBTC bond. Finally, there is no reason this has to be limited to BitBTC. The same mechanism could function for a BTC/BitUSD market, although because of the volatility risk it may be necessary to change the value of X to ensure that it is unlikely for the price of BTC (in BitUSD) to grow faster than X% in T hours (nor X'% in T' hours).


Before I had said that only the ask orders would exist on the blockchain. The bid orders would be immediate or cancel only. But I think it is fine if there is another type of regular bid order that sits in the order book. Like the other bid order, this regular bid order specifies the unique number of Bitcoin addresses in the ask orders that it is allowed to match against, the signed void transaction (which I will now call a withdraw transaction) with the nLockTime roughly T hours in the future, and a BitBTC bond that is X% of the quantity of BitBTC requested in the bid order. However, in this case I think T should be closer to 30 hours and perhaps X should still be 10% or maybe it should be more to compensate for the larger amount of time that the ask's BitBTC could be locked up (these are parameters that can vary with the specific market). The immediate or cancel bid orders will have their own time T' < T and percentage X' <= X (but I recommend that X'/T' >= X/T). These regular bid orders would first match with any ask orders they overlap with at the moment they are submitted to create the same types of positions ("immediate positions") as the IOC (Immediate or Cancel) orders (meaning they would use the T' and X' parameters) then any remaining amount would sit in the order book and if it later gets matched will create a "latent position" and will instead use parameters T and X. The reason for the larger T > T' is because we can expect the bidder to be online to submit the Bitcoin transaction immediately after the IOC bid is submitted, but by the time a sitting bid order is matched, the bidder may have already gone offline. Therefore T should be large enough to give the bidder enough time to check if the bid has been matched and settle the payments with a Bitcoin transaction. If the bid is partially matched 24 hours after first submitting the bid, the bidder has the remaining 6 hours to cancel remaining bid orders, settle his obligations by making the necessary payments through a Bitcoin transaction, and then resubmit the bids for the remaining quantity (I discuss a better way of doing this using "renew transaction" below).

A bidder (someone who has BTC and wants BitBTC) first needs to submit a "BTC deposit" transaction on the BitShares blockchain. A "BTC deposit" transaction requires a pointer to a confirmed BTC balance on the Bitcoin blockchain, a signed "BTC withdraw" transaction (which is a signed Bitcoin transaction spending the BTC balance with some nLockTime Bitcoin block in the future and with an appropriate transaction fee included), and a positive integer N specifying the maximum number of unique Bitcoin addresses that bid orders paid through this balance can be matched against. Initially, the "BTC deposit" balance is inactive and can't be used to do anything (although it can be made void by the owner). For the "BTC deposit" balance to become active, it requires an "activate BTC deposit" transaction to be submitted to the blockchain which activates the "BTC deposit" balance and also initializes two mutable fields of the "BTC deposit" balance: a timestamp (called the "expiration time" of the "BTC deposit" balance) which estimates an upper bound on the time by which this balance will be forced to move; and a quantity (called the "BTC quantity" of the "BTC deposit" balance) which represents the amount of BTC held in the actual balance on the Bitcoin blockchain. The blockchain considers an "activate BTC deposit" transaction valid if it sets these two values and is signed by the necessary quorum of delegates (no one else can generate this transaction). The signature could either be done as a multisig or even better using a threshold signature where the public key of the threshold is already established in the block header (that is another discussion). Initially, the delegates set the timestamp to the estimated time the Bitcoin block specified by the nLockTime in "BTC withdraw" transaction will be generated (assuming 10 minute block intervals). The delegates are expected to produce the "activate BTC deposit" transaction for any "BTC deposit" transaction that is valid (meaning that it points to an actual confirmed unspent BTC balance on the blockchain that had not been submitted as a "BTC deposit" to the BitShares blockchain before, and the signed "BTC withdraw" transaction is valid).

A bid order for BitBTC in the BTC/BitBTC market specifies a limit price, a BitBTC quantity, the "BTC deposit" balance from which it will pay the BTC, and whether it is IOC or not. The bid order must also include some amount of BitBTC as part of bond for the order. If the bid order is IOC, then X'% of the quantity must be provided. A submitted bid order can only be IOC if the "expiration time" of the "BTC deposit" balance that the bid is associated with is less than T' hours in the future. If the bid order is not IOC, then X% of the quantity must be provided. Even if a submitted bid order is not IOC it is still required that the "expiration time" of the "BTC deposit" balance that the bid is associated with be less than T hour in the future. Also for any bid order submission to be accepted (regardless of whether IOC or not) into the blockchain, the outstanding BTC to be paid or being offered thus far for all positions and open bids (including the newly submitted pending bid) associated with the "BTC deposit" balance cannot exceed the "BTC quantity" of the "BTC deposit" balance. When bid orders are submitted a reverse index is maintained from the "BTC deposit" balance to the bid orders that are using them. When the bid order is IOC it will match against ask orders that existed prior to the block it is included in without paying any overlap fees up to the limit price (meaning it is a limit order), and anything that is not matched will then be cancelled and the corresponding BitBTC returned to the bidder. When the bid order is not IOC, it will match against ask orders that existed prior to and included in the block in which the bid order is included in with the standard overlap rules and the price set at the limit price, and anything that is not matched will sit at the limit price in the order book as a latent bid order. The positions formed from bids matching with asks immediately after submission of the bid are called "immediate positions". These positions take X'% of the BitBTC quantity matched from the bid and store it in escrow along with the quantity of BitBTC matched from the ask. The positions formed from asks matching with bids immediately after the submission of the ask are called "latent positions". These positions take X% of the BitBTC quantity matched from the bid and store it in escrow along with the quantity of BitBTC matched from the ask. Each of these positions is associated with a particular "BTC deposit" balance (the one of the bid that was matched to form the position) and an appropriate reverse index is maintained from the balance to these positions (along with the open bid orders as well). Since X >= X', some amount of the BitBTC bond provided with a non-IOC bid will be unnecessary assuming there are any "immediate positions" formed from that bid. The quantity of BitBTC matched into "immediate positions" times (X-X')% will be refunded back to the bidder immediately after submitting the bid. The remaining BitBTC bond will stay with the latent bid orders to cover the X% bond for matching.

When a Bitcoin transaction spending the balance pointed to by the "BTC deposit" transaction is confirmed in the Bitcoin blockchain, the delegates are expected to submit an appropriate multisig (or threshold sig) transaction to the BitShares blockchain that causes several possible things to occur. The delegates submit a "BTC balance moved" transaction which specifies the "BTC deposit" transaction it refers to and also specifies a renew flag, a BitShares block height, and a varint. Also, if the renew flag is set to true, the transaction also includes the new values for the "expiration time" and "BTC quantity" of the "BTC deposit" balance. The renew flag is a boolean which if true tells the blockchain to renew the balance (and thus keep the existing open bids associated with the "BTC deposit" balance) and if false tells the blockchain to cancel the balance (and thus cancel all existing open bids associated with the "BTC deposit" balance and return their BitBTC bonds back to the bidder). The varint encodes information specifying which BTC addresses (of the ones associated with the matched asks that the bidder has an obligation to eventually pay) were paid in full (according to the bidder's obligation as of the moment of the block specified by the block height) by the Bitcoin transaction. A list of BTC addresses of asks that were matched against the bids associated to a particular "BTC deposit" balance can be compiled at any time (any block) in a deterministic order (in lexicographical order of the BTC address for example). The varint encodes a bit array, where the block height specifies the block at which the ordered list of BTC addresses of the asks should be compiled for the given "BTC deposit" balance and the bit array specifies in the same order whether or not that address was paid the full amount that they were owed by the bidder's BTC transaction. The blockchain determines all of the BTC addresses the bidder needs to pay (and how much BTC the bidder needs to pay to each) as of the block specified by the block height and generates a ephemeral map between BTC addresses and BTC amounts to be paid. The blockchain then generates a new ephemeral map from the first by filtering out any of the BTC addresses that were not paid in full according to the bit array. The blockchain then determines all of the BTC addresses the bidder needs to pay (and how much BTC the bidder needs to pay to each) as of a block which is either the current block the "BTC balance moved" transaction is included in if the renew flag is false or the block in which the latest "renew balance" transaction (discussed below) associated with the "BTC deposit" balance was submitted if the renew flag is true, and generates a third ephemeral map between BTC addresses and BTC amounts to be paid. For each of the BTC addresses A in the third map, the blockchain takes the amount to be paid from the third map (AMOUNT_OWED BTC) and compares it to the amount to be paid for the corresponding address A in the second map (AMOUNT_PAID BTC), or sets AMOUNT_PAID to 0 if A does not exist in the second map. AMOUNT_PAID should never exceed AMOUNT_OWED, but it can be less. For each of the "immediate positions" and "latent positions" associated with the "BTC deposit" balance and address A (restricted only to the positions formed prior to the block that is 5 blocks prior to the block in which the latest "renew balance" transaction associated with the "BTC deposit" balance was included in, if renew flag is true, and no restriction if it is false), which have Y BitBTC held in escrow in the position, (AMOUNT_PAID/AMOUNT_OWED)*Y BitBTC is taken from the escrow of the position and sent to the bidder and the rest (if any) is sent to the ask side of the position.

An owner of a "BTC deposit" balance can submit a "renew balance" transaction on the "BTC deposit" balance which specifies everything a "BTC deposit" transaction does (pointer to BTC balance, signed "BTC withdraw" transaction, and a new value for N). If any existing "renew balance" transaction was associated to the "BTC deposit" balance, it is replaced by the new one. A "renew balance" transaction will not be submitted into a block if the block height of the block it is submitted into is not greater than 5 more than the block height of the block in which the "BTC deposit" transaction was submitted in. When a Bitcoin transaction spending the balance pointed to by the "BTC deposit" transaction is confirmed in the Bitcoin blockchain and the delegates are expected to create and submit the "BTC balance moved" transaction, they need to first check whether a "renew balance" transaction is associated with the "BTC deposit" balance. If so, they need ensure the following:
  • The pointer in the "renew balance" transaction points to an output balance of the transaction that spent the BTC balance that was pointed to by the "BTC deposit" transaction.
  • The accumulated quantity of BTC asked by all the open bid orders associated to this "BTC deposit" balance is less than or equal to the quantity of BTC held in the new output balance pointed to by the "renew balance" transaction.
  • The signed "BTC withdraw" transaction in the "renew balance" transaction is valid (meaning it spends the new output balance, has the appropriate Bitcoin fee, and has the necessary signatures) and has an nLockTime that is at a Bitcoin block in the future that is estimated (based on 10 minute block intervals) to be produced prior to T hours in the future.
If all of the above are true, the delegates will create the "BTC balance moved" transaction with the renew flag set to true. If any of the above are false, the delegates will create the "BTC balance moved" transaction with the renew flag set to false. The delegates then come to a consensus on the block height to use in the "BTC balance moved" transaction, which is selected to be the block height of the block that is 5 blocks prior to the block that the aforementioned "renew balance" transaction exists in if the renew flag is set to true or the most recent block that enough of the delegates (enough to satisfy the multisig or threshold sig properties of the "BTC balance moved" transaction) can reach a consensus on (typically just the current head block at the time the transaction is being created) if the renew flag is set to false. The delegates then calculate the ordered list of (A, Y) where the A represents the BTC addresses that are owed BTC (and Y is the quantity of BTC they are owed) due to matching of the bids associated with the "BTC deposit" balance with asks as of the specified block height, where the order of the list is determined through lexicographical ordering of A. Each delegate can then map this list of tuples to a bit sequence (the bit array) by outputting a 1 bit if there exists an output balances in the Bitcoin transaction spending the BTC balance which can be claimed by address A and the quantity of BTC in that output balance is greater than or equal to Y, and outputting a 0 bit otherwise. Once this bit array has been calculated, they can each calculate the varint encoding the bit array (essentially representing the bit array as a large unsigned integer and then serializing it as a varint) and include that in the transaction. Finally, if the renew flag is set to true, the delegates also add a new "BTC quantity" field to the transaction which is set to the amount of BTC in the new output balance and also add a new "expiration time" field to the transaction which is set to the estimated time that the Bitcoin block specified by the nLockTime in new signed "BTC withdraw" transaction will be generated (assuming 10 minute block intervals). They then finalize the transaction, collectively sign (multisig or threshold) the transaction, and submit it into the BitShares blockchain.

If the bidder wants to guarantee (assuming delegates behave) that his obligations will be fully satisfied rather than partially satisfied (so that he doesn't lose any of his BitBTC bond), he needs to do a few things. First, the bidder must always submit the Bitcoin transaction satisfying his obligations well before the deadline (the time when the nLockTime of the submitted "BTC withdraw" transaction becomes active). Second, if the bidder does not intend to renew the "BTC deposit" balance, he must cancel all open bid orders associated with that "BTC deposit" balance prior to generating the Bitcoin transaction that satisfies his obligations. Third, if the bidder does intend to renew the "BTC deposit" balance, he must first submit the appropriate and valid "renew balance" transaction and have it confirmed in the BitShares blockchain before broadcasting the Bitcoin transaction that satisfies his obligations up to the point of 5 blocks prior to the block the latest "renew balance" transaction was included in. This means whenever the bidder wants to update his renew checkpoint, the bidder's client will calculate obligations as of the current block, generate and sign a valid Bitcoin transaction (called the "spending transaction") spending the BTC balance that satisfies the current obligations and sends the rest (minus necessary transaction fee) back to an address the bidder controls (called the "renewed balance"), calculate the pointer to this "renewed balance", generate and sign a valid (with necessary fees) Bitcoin transaction (called the "new withdraw transaction") spending the "renewed balance" back to an address the bidder controls, and generate, sign, and broadcast a new BitShares "renew transaction" on the "BTC deposit" balance that includes the new pointer, the "new withdraw transaction", and a potentially new value for N. Once the BitShares transaction is included in the blockchain, the client can verify whether the bidder's obligations as of the block 5 blocks prior to the block this "renew transaction" is included in is the same as the bidder's obligations at the beginning of this process (which will almost always be true as long as the "renew transaction" is included in the BitShares blockchain without abnormal delays). If it is not true, the client gives the bidder the option to try again with a new "renew transaction" or the bidder can instead choose to cancel his open bids to avoid this potential (but rare) problem. After confirming the previous corner case, the client then gives the bidder the option to broadcast the "spending transaction" to the Bitcoin blockchain. If the bidder agrees, then this will start off the process that eventually causes the delegates to generate the corresponding "BTC balance moved" transaction which should settle the bidder's obligations as of the block the renew checkpoint process was started but still leave any remaining and future (if more of the open bids get matched) obligations to be handled later (at most approximately T hours later) using the "renewed balance" instead.

One thing to keep in mind with the "renew transaction" is if the new value of N for the "BTC deposit" balance is smaller than the number of unique BTC addresses of the asks of the collective "immediate positions" and "latent positions" associated with the "BTC deposit" balance, the market will automatically cancel all open bids associated with the "BTC deposit" balance. Furthermore, as soon as a latent bid being matched with an ask causes the number of unique BTC addresses of asks of the collective positions associated with the "BTC deposit" balance to be equal to N, the market engine will cancel all open bids associated with the "BTC deposit" balance (even ones that would have otherwise been matched in that same block). And in the case of newly placed immediate or latent bid matching against multiple asks, the market engine will ensure that the bid order (and any other bid order operations associated with the "BTC deposit" balance that are in the same transaction) will cancel as soon as the number of unique BTC addresses of asks of the collective positions associated with the "BTC deposit" balance becomes equal to N (even if they would have otherwise matched). This is all to ensure that the bidder is never put into a situation where to fully satisfy all of their obligations they need to create a Bitcoin transaction that has more than (N+1) outputs.

It is clear why a Bitcoin transaction spending the BTC balance may not satisfy any of the bidder's obligations (it could simply be the "BTC withdraw" transaction being submitted when the nLockTime passes because the bidder didn't settle his debts in time) and regular operation should consist of BTC transactions that satisfy all of the bidder's obligations. But what would be the reason for partial satisfaction of the bidder's obligations. One situation I can think of is if there are a lot of matches of tiny quantity with different ask counterparties (meaning different BTC addresses). Now the N parameter specified should put an upper bound on this (so the Bitcoin transaction the bidder needs to create to satisfy all obligations doesn't get too big), but if all N consist of a few satoshi matches, the bidder is better off letting the 10% of the accumulated satoshi in BitBTC bonds go to the ask counterparties rather than wasting a Bitcoin transaction fee satisfying these obligations with a large Bitcoin transaction with N+1 outputs (assuming transaction fees scale with Bitcoin transaction size). However, if 1 of the N actually is a match for 0.01 BTC and the remaining (N-1) are for a few satoshis, then if the system were designed such that obligations had to be fully satisfied or else the bidder loses all of his BitBTC bonds (which is of course a simpler design than the above), the bidder would lose approximately 0.001 BitBTC in bonds unless he fully satisfied the obligations with a large Bitcoin transaction that had (N+1) outputs. However, while a regular transaction spending the balance back to the bidder might not take a fee more than 0.0001 BTC, the transaction with (N+1) outputs might be (assuming reference implementation of Bitcoin) ceil((125 + 34*N)/1000) * 0.0001 BTC. So with N = 330, the bidder might have to pay a transaction fee of 0.0012 BTC which would be worth more (even after discounting the 0.0001 BTC transaction fee he has to pay no matter what) than the approximately 0.001 BitBTC bond he would forfeit by just retracting his BTC balance. To prevent these types of scenarios, partial satisfaction of the bidder's obligation is allowed through the way the "BTC balance moved" transaction is designed to include the bit array rather than just a simple boolean. The size of the bit array wouldn't be too large. The bit array would be represented as a big unsigned integer (which would have to be less than 2^(N+1)) and then serialized as a varint. A reasonable upper bound on N could be prescribed by the blockchain (it is unlikely for the number of unique BTC addresses in the collective positions of the bidder to become very large normally anyway), and/or the blockchain could require that the fee of the "BTC deposit" transaction (and any "renew balance" transaction) to be of the form a + b*ceil(log(N)/log(2)), where a and b are blockchain prescribed constants and N is the parameter supplied by the user within the transaction.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
The parties have to agree on a txid because there might be multiple transactions between the same buyer and seller, e.g. if Alice puts up 5 offers of 1 BitBTC each, and Eve takes all 5 offers, unless you have some way of distinguishing the transactions, Eve's 1 BTC payment to faithfully settle the first transaction might result in BTS releasing the escrowed BitBTC for all 5 offers, resulting in Eve effectively buying 5 BitBTC for 1 BTC total instead of 1 BTC each.

There is no need for the protocol to behave in that manner. It could simply consider all payments between Eve's address to Alice's address to be a payment in the exact order that their orders were matched on the blockchain. Also, I was thinking if they would further want to distinguish transactions they could always generate new Bitcoin addresses, associate those new addresses with their orders, and make sure to send their payments from that address. But whatever, perhaps the transaction ID approach is a more robust solution (just make sure to avoid any transaction malleability bugs), although it seems to require closer integration of the Bitcoin wallet with the BitShares wallet.


But the txid alone is not sufficient.  Alice doesn't want to agree to a contract of the form, "release BitBTC to Bob if <txid> is confirmed on the Bitcoin network."  Rather to protect Alice the contract needs to say, "release BitBTC to Bob if <txid> is confirmed on the Bitcoin network and <txid> transfers 1 BTC to Alice (as well as possibly some side effects)."  In your system the delegates have to semantically interpret the Bitcoin transaction, they have to "recognize" that the transaction "means" 1 BTC is sent from Alice to Bob.  In your system, if Bob's using a Bitcoin wallet which does something unusual, resulting in the coins being transferred to Alice without triggering the recognition logic, Bob's SOL and Alice ends up with his BTC while keeping her BitBTC.

I'm not sure why the semantic interpretation by the delegates of a payment of bitcoins from one address to another would not be robust. But again, your approach is perfectly fine it just means the Bitcoin wallet needs to be integrated into the BitShares client (which is something I want anyway by the way, it just requires more work). So users would send their BTC to the Bitcoin receive address provided by their BitShares client and then once they have it in that wallet they could then use it to buy BitBTC from this market.


To elaborate why nLockTime is necessary to make the protocol atomic:  In your system, if Bob sends the Bitcoin transaction out near the end of the 24 hour window, such that it's unconfirmed when 24 hours has expired, the delegates may release escrowed BitBTC to Alice -- but Bob has no way to recall the transaction sending BTC since he already broadcast it to the Bitcoin network.  For that matter, it is possible Bob sent the transaction out at the beginning of the 24-hour window and no miner happened to include it (perhaps Bob's misconfigured Bitcoin wallet pays no fee or a very low fee).

The trick to making it truly atomic is for the escrow to do nothing until the coins have been sent somewhere.  This means the escrow will release Alice's BitBTC back to her if Bob spends the BTC on something else (and Bob forfeits his bond).  But there is still an obvious problem with that approach:  Bob could be malicious (or simply have an extended outage) and not spend the BTC for a long time (or even forever), keeping Alice's BitBTC locked in escrow until and unless he decides to spend them!  The way to fix the obvious problem is to give Alice a way to force the BTC to be sent back to Bob, which will trigger the "Bob spent the BTC on something else" logic.  So Alice won't put her BitBTC in escrow for an extended period until Bob's sent her a transaction which transfers Bob's BTC back to Bob himself.

Of course there is now another obvious problem:  If malicious, Alice might immediately broadcast the transaction sending the BTC back to Bob, triggering the "Bob spent the BTC on something else" logic and making Bob forfeit his bond!  To prevent this problem, you need to make sure the transaction sending the BTC back to Bob cannot be accepted by the Bitcoin network until some time has elapsed.  Which is exactly the purpose of nLockTime.

I get it now. Thanks. The problem seems to all come from the fact that Bitcoin does not have an expiration time for transactions like BitShares does. Otherwise Bob could make his BTC payment to Alice expire before the end of the 24 hour window. That way if it was stuck in the network for a while until the deadline passed it would be void and be equivalent to Bob never submitting the transaction in the first place. Because Bitcoin doesn't have this feature, you implement it using a separate transaction with nLockTime that makes the first void and require this explicit void operation before the delegates consider the delivery of the BTC to have failed.

This does considerably complicate the order matching process though. I need to think about this more. I would appreciate if you write out the steps of how the order matching works from the initial asks and bids to delivery of BTC.

Edit: Okay, how about the following...
Ask orders (selling BitBTC for BTC) are like regular BitBTC sell orders except they also require a BTC receive address.

Bid orders (buying BitBTC with BTC) are very different orders. First, they are IOC (Immediate or Cancel) orders. This means they will try to match against existing ask orders and any amount that is not filled immediately will be returned back to the bidder. They also require the 10% BitBTC bond in order to match against the BitBTC ask orders. Also, the bid order can specify the unique number of Bitcoin addresses in the ask orders that it is allowed to match against (this is to limit the size of the Bitcoin transaction the bidder will need to create to fulfill their obligation). Finally, they must include a signed Bitcoin transaction that spends a specific BTC balance existing (and already confirmed) on the Bitcoin blockchain (presumably back to the original owner) with nLockTime set to a Bitcoin block that is less than or equal to N blocks away from the current (by the time of the block the transaction is being considered to be included in) head Bitcoin block. The value of N is fixed for the market and I would suggest N = 36 which corresponds to an estimated deadline of less than 6 hours in the future. The BTC balance this signed transaction is spending needs to be greater than the BTC amount that the bidder must pay to satisfy the orders that would be matched; if it does not, the transaction is invalid and does not match any orders.

Once the bid and ask orders are matched, the BitBTC being sold and the BitBTC of the bidder's bond are put into escrow. There will be as many escrows as the unique bid-ask match combinations made with that transaction. These escrows are grouped together as part of the bid transaction that created them. All of the BitBTC in these escrows will be sent to their respective ask counterparty if the bidder spends the BTC balance associated with the bid transaction in a way that does not follow their obligation to deliver. If the BTC balance is spent in a way that does follow the bidder's obligation to deliver, then all of the BitBTC in these escrows will be sent to the bidder. The bidder has until the nLockTime of the signed Bitcoin transaction that was submitted as part of the bid transaction becomes valid (for example 6 hours after submitting the bid) to get a valid delivery transaction submitted and confirmed in the Bitcoin blockchain. A transaction spending the BTC balance is considered a valid delivery transaction if the outputs of the transaction include all the Bitcoin addresses associated with the ask orders that were matched with the bid transaction and the BTC amount sent to each of these addresses is the one that they are owed according to the matching rules of the market.

This process maintains atomicity. If the bidder's delivery transaction is not confirmed by the 6 hour deadline, anyone (most likely one of the ask counterparties, but it can even be done by the delegates) can publish the signed deadline transaction included as part of the bid transaction to the Bitcoin blockchain. The BTC remains in control of the bidder but it also triggers the  delegates to release the escrow to the respective ask counterparties (thus the bidder loses his BitBTC bond). Same process happens if the bidder transfers the BTC balance to himself with another transaction prior to the 6 hour deadline. If the delivery transaction is confirmed on the Bitcoin blockchain, the delegates release the escrow to the bidder (the bidder gets the BitBTC they paid for as well as their bond back).

The benefit of this approach over the one you proposed (at least as I understood it) is that the bidder does not need to know the counterparty of the ask order that their bid will match against prior to submitting the bid order. Also, there is no additional task required of the counterparty who submitted the ask order after submitting the ask order in order for the process to continue to completion (either successful delivery of the BTC or a failure but with the BitBTC to be released back with the bond bonus).
« Last Edit: February 27, 2015, 10:59:43 pm by arhag »

Offline theoretical

To elaborate why nLockTime is necessary to make the protocol atomic:  In your system, if Bob sends the Bitcoin transaction out near the end of the 24 hour window, such that it's unconfirmed when 24 hours has expired, the delegates may release escrowed BitBTC to Alice -- but Bob has no way to recall the transaction sending BTC since he already broadcast it to the Bitcoin network.  For that matter, it is possible Bob sent the transaction out at the beginning of the 24-hour window and no miner happened to include it (perhaps Bob's misconfigured Bitcoin wallet pays no fee or a very low fee).

The trick to making it truly atomic is for the escrow to do nothing until the coins have been sent somewhere.  This means the escrow will release Alice's BitBTC back to her if Bob spends the BTC on something else (and Bob forfeits his bond).  But there is still an obvious problem with that approach:  Bob could be malicious (or simply have an extended outage) and not spend the BTC for a long time (or even forever), keeping Alice's BitBTC locked in escrow until and unless he decides to spend them!  The way to fix the obvious problem is to give Alice a way to force the BTC to be sent back to Bob, which will trigger the "Bob spent the BTC on something else" logic.  So Alice won't put her BitBTC in escrow for an extended period until Bob's sent her a transaction which transfers Bob's BTC back to Bob himself.

Of course there is now another obvious problem:  If malicious, Alice might immediately broadcast the transaction sending the BTC back to Bob, triggering the "Bob spent the BTC on something else" logic and making Bob forfeit his bond!  To prevent this problem, you need to make sure the transaction sending the BTC back to Bob cannot be accepted by the Bitcoin network until some time has elapsed.  Which is exactly the purpose of nLockTime.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical


This algorithm sounds a lot like https://github.com/drltc/bitbond-proposal/blob/master/btc-trade.md which I brought up back in September.

Interesting... I had not seen that document before. As tonyk mentioned I was quoting myself. The proposals are extremely similar (although I don't understand why you need to complicate the Bitcoin transactions so much with redacted transactions and the nLockTime stuff).

Also, I think allowing the bids and asks to specify a bond percentage complicates the market too much (makes it 2-dimensional). I think it is better for everyone (simpler to understand matching rules) to just hard code it per market. Different markets with different hard coded percentages (in the market's definition) could exist however. But I think a market with a 10% bond is a pretty decent one that hopefully most people would use (so that the liquidity would be high in that market).

Your protocol is not atomic if the Bitcoin network is slow.  I've had transactions take a long time to get confirmed on Bitcoin (turned out because my fees were too low).  The parties have to agree on a txid because there might be multiple transactions between the same buyer and seller, e.g. if Alice puts up 5 offers of 1 BitBTC each, and Eve takes all 5 offers, unless you have some way of distinguishing the transactions, Eve's 1 BTC payment to faithfully settle the first transaction might result in BTS releasing the escrowed BitBTC for all 5 offers, resulting in Eve effectively buying 5 BitBTC for 1 BTC total instead of 1 BTC each.

But the txid alone is not sufficient.  Alice doesn't want to agree to a contract of the form, "release BitBTC to Bob if <txid> is confirmed on the Bitcoin network."  Rather to protect Alice the contract needs to say, "release BitBTC to Bob if <txid> is confirmed on the Bitcoin network and <txid> transfers 1 BTC to Alice (as well as possibly some side effects)."  In your system the delegates have to semantically interpret the Bitcoin transaction, they have to "recognize" that the transaction "means" 1 BTC is sent from Alice to Bob.  In your system, if Bob's using a Bitcoin wallet which does something unusual, resulting in the coins being transferred to Alice without triggering the recognition logic, Bob's SOL and Alice ends up with his BTC while keeping her BitBTC.

If both parties agree on the exact bytes of a proposed delivery transaction (as in my system), the protocol simply fails if Alice and Bob's wallets don't both recognize that the proposed delivery transaction will in fact deliver the BTC to Alice.  The reason the signature of the proposed delivery transaction must be withheld / redacted is to allow Bob to stop the transaction from being broadcast on the Bitcoin network if Alice doesn't agree.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
This algorithm sounds a lot like https://github.com/drltc/bitbond-proposal/blob/master/btc-trade.md which I brought up back in September.

Interesting... I had not seen that document before. As tonyk mentioned I was quoting myself. The proposals are extremely similar (although I don't understand why you need to complicate the Bitcoin transactions so much with redacted transactions and the nLockTime stuff).

Also, I think allowing the bids and asks to specify a bond percentage complicates the market too much (makes it 2-dimensional). I think it is better for everyone (simpler to understand matching rules) to just hard code it per market. Different markets with different hard coded percentages (in the market's definition) could exist however. But I think a market with a 10% bond is a pretty decent one that hopefully most people would use (so that the liquidity would be high in that market).
« Last Edit: February 26, 2015, 10:25:07 pm by arhag »

zerosum

  • Guest
Who is being quoted here?

Quote
Alice has BitBTC and wants to exchange it for BTC. Bob has BTC (as well as a little bit of BitBTC already) and wants to exchange it for (more) BitBTC. There is a special BitBTC/RealBTC exchange on the BitShares system. Since the BitShares blockchain cannot actually hold real BTC, the bid orders for BitBTC on this BitBTC/RealBTC exchange are actually requests to buy the BitBTC with real BTC and with some BitBTC provided as a surety bond to ensure payment of the real BTC in a timely manner.

Let's say Alice places an ask order for 2 BitBTC at a price of 0.99 BTC/BitBTC and the ask order also has her BTC address (1A...). Bob sees this ask order and matches it with his bid order for 1.5 BitBTC at a price of 0.99 BTC/BitBTC. His bid order includes 0.15 BitBTC to be used as part of the surety bond (let's pretend that the market requires that 10% of the BitBTC quantity of the bid must be posted as the surety bond). Bob's bid order also includes his BTC address (1B...) from which he is expected to send the BTC payment to Alice's Bitcoin address.

Once these two orders are matched, Bob's 0.15 BitBTC joins Alice's 1.5 BitBTC and gets locked as collateral in a special escrow contract. At this point, Alice will still have an ask order for 0.5 BitBTC at a price of 0.99 BTC/BitBTC in the order book. This escrow contract requires a delivery confirmation to occur within 24 hours for the entire collateral to be send to Bob. The delegates monitor the Bitcoin blockchain for a total transfer of at least 1.485 BTC (1.5 BitBTC * 0.99 BTC/BitBTC = 1.485 BTC) from 1B... to 1A... between the time the orders were matched until 24 hours after that. If that condition is met, the delegates will sign off on the delivery confirmation for that escrow contract. Once a super majority of the active delegates have signed off on the delivery confirmation of the escrow contract (prior to the 24 hour expiration time), the delivery will be confirmed and all the collateral (1.65 BTC) will be sent to Bob. If this does not happen prior to the 24 hour expiration time, then all the collateral will instead go to Alice.

Bob has to put some BitBTC up so that attackers who want to just cause damage to BitBTC sellers are discouraged. If Alice is forced to lock up some BitBTC for 24 hours without getting payment for the promised trade, she will at least be rewarded with 10% profit after the 24 hours. If Bob trusts the delegates to do their job, he should be confident that he will get back his surety bond and will also get the 1.5 BitBTC he was promised as long as he delivers the 1.485 BTC from his 1B... address to Alice's 1A... address within 24 hours (it is best to not leave it to the last hour to ensure the delegates have enough time to sign off on the delivery confirmation).

This algorithm sounds a lot like https://github.com/drltc/bitbond-proposal/blob/master/btc-trade.md which I brought up back in September.

He is quoting himself. The original was posted on nullstreet forum. I will try to find it for you.

[edit] Here is the thread: http://forum.nullstreet.com/index.php/643-hedgewallet-project ...Sorry could not figure out how to post link to a particular post on that forum.

[edit 2] yes it is similar to your solution at  the link above. Arhag posted it in response to a suggestion of mine. If you are interested the link is there in the original nullstreet thread. The main difference is developing the idea [you call Market-based approach] specifically for BTS.
« Last Edit: February 26, 2015, 07:51:39 pm by tonyk2 »

Offline theoretical

Who is being quoted here?

Quote
Alice has BitBTC and wants to exchange it for BTC. Bob has BTC (as well as a little bit of BitBTC already) and wants to exchange it for (more) BitBTC. There is a special BitBTC/RealBTC exchange on the BitShares system. Since the BitShares blockchain cannot actually hold real BTC, the bid orders for BitBTC on this BitBTC/RealBTC exchange are actually requests to buy the BitBTC with real BTC and with some BitBTC provided as a surety bond to ensure payment of the real BTC in a timely manner.

Let's say Alice places an ask order for 2 BitBTC at a price of 0.99 BTC/BitBTC and the ask order also has her BTC address (1A...). Bob sees this ask order and matches it with his bid order for 1.5 BitBTC at a price of 0.99 BTC/BitBTC. His bid order includes 0.15 BitBTC to be used as part of the surety bond (let's pretend that the market requires that 10% of the BitBTC quantity of the bid must be posted as the surety bond). Bob's bid order also includes his BTC address (1B...) from which he is expected to send the BTC payment to Alice's Bitcoin address.

Once these two orders are matched, Bob's 0.15 BitBTC joins Alice's 1.5 BitBTC and gets locked as collateral in a special escrow contract. At this point, Alice will still have an ask order for 0.5 BitBTC at a price of 0.99 BTC/BitBTC in the order book. This escrow contract requires a delivery confirmation to occur within 24 hours for the entire collateral to be send to Bob. The delegates monitor the Bitcoin blockchain for a total transfer of at least 1.485 BTC (1.5 BitBTC * 0.99 BTC/BitBTC = 1.485 BTC) from 1B... to 1A... between the time the orders were matched until 24 hours after that. If that condition is met, the delegates will sign off on the delivery confirmation for that escrow contract. Once a super majority of the active delegates have signed off on the delivery confirmation of the escrow contract (prior to the 24 hour expiration time), the delivery will be confirmed and all the collateral (1.65 BTC) will be sent to Bob. If this does not happen prior to the 24 hour expiration time, then all the collateral will instead go to Alice.

Bob has to put some BitBTC up so that attackers who want to just cause damage to BitBTC sellers are discouraged. If Alice is forced to lock up some BitBTC for 24 hours without getting payment for the promised trade, she will at least be rewarded with 10% profit after the 24 hours. If Bob trusts the delegates to do their job, he should be confident that he will get back his surety bond and will also get the 1.5 BitBTC he was promised as long as he delivers the 1.485 BTC from his 1B... address to Alice's 1A... address within 24 hours (it is best to not leave it to the last hour to ensure the delegates have enough time to sign off on the delivery confirmation).

This algorithm sounds a lot like https://github.com/drltc/bitbond-proposal/blob/master/btc-trade.md which I brought up back in September.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile

https://tether.to/faqs/

"Tether is the world’s first fiat currency token platform to exist on the Blockchain"

I understand that to mean decentralised.  And isn't bitasset's yield close to zero?

You understand incorrectly, but perhaps as intended:

Quote
Tether currency is backed 100% by actual fiat currency assets in our reserve account and always maintains a one-to-one ratio with any currency held. For example 1 USD₮ = 1 USD. With almost zero conversion and transfer fees, Tether currency is redeemable for cash at any time.

So it's a token on a blockchain, issued by a centralized entity, and they promise they'll redeem it for fiat.  Same as Ripple IOUs, CoinoUSD on NXT, or UIA IOUs on BitShares.

Also bitUSD interest is over 2% right now, significantly higher than my bank is offering on even CDs of any term length.

EDIT: Tether might be a good gateway partner if they'd issue their IOUs directly on our chain also.  If they've got the fiat end infrastructure anyway, they might as well use it to its full potential.

I am trying to understand the classification here. It seems 'centralised' = 'counter-party risk'.  Does that mean bitcoin falls into the 'centralised' group (since it requires an centralised exchange for fiat)?

Tether (former realcoin) is...
...centralized insofar it relies on a centralized entity (company/individual) holding reserves to back the value of the Thether tokens.
...decentralized insofar as the tether tokens are tracked on a blockchain. So the customer has the private keys (in principle), but not if mechanisms are built in to revoke the user issued assets.
The category tether tokens fit in are: User issued assets.
« Last Edit: February 18, 2015, 02:04:18 pm by delulo »

Offline yellowecho

Fiat on and off ramp (via Bitfinex wire transfers) for BitShares without needing to convince the company to even touch the BitShares client.

Just make the following substitutions in the above quote: s/BitBTC/BitUSD/g, s/RealBTC/BitfinexUSD/g, s/BTC/USDT/g.

 +5% +5%
696c6f766562726f776e696573

Offline yankey

  • Jr. Member
  • **
  • Posts: 30
    • View Profile
Tether IOUs? will get them into the idea of fiat on the chain..... until the next gox event i guess.

Offline merlin0113

  • Sr. Member
  • ****
  • Posts: 286
    • View Profile
In-blockchain IOUUSD? This is really good to have something like this by other ppl outside bitshares which means this USD shares kinda "VALUE ". I can boldly predict this will encourage elite ppl of bitshares enthusiasim to launch their own GATEWAY USD, when bts wallet is stable.

来自我的 M040 上的 Tapatalk

Offline jsidhu

  • Hero Member
  • *****
  • Posts: 1335
    • View Profile
Hired by blockchain | Developer
delegate: dev.sidhujag

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile

https://tether.to/faqs/

"Tether is the world’s first fiat currency token platform to exist on the Blockchain"

I understand that to mean decentralised.  And isn't bitasset's yield close to zero?

You understand incorrectly, but perhaps as intended:

Quote
Tether currency is backed 100% by actual fiat currency assets in our reserve account and always maintains a one-to-one ratio with any currency held. For example 1 USD₮ = 1 USD. With almost zero conversion and transfer fees, Tether currency is redeemable for cash at any time.

So it's a token on a blockchain, issued by a centralized entity, and they promise they'll redeem it for fiat.  Same as Ripple IOUs, CoinoUSD on NXT, or UIA IOUs on BitShares.

Also bitUSD interest is over 2% right now, significantly higher than my bank is offering on even CDs of any term length.

EDIT: Tether might be a good gateway partner if they'd issue their IOUs directly on our chain also.  If they've got the fiat end infrastructure anyway, they might as well use it to its full potential.

I am trying to understand the classification here. It seems 'centralised' = 'counter-party risk'.  Does that mean bitcoin falls into the 'centralised' group (since it requires an centralised exchange for fiat)?
No.  People set up exchanges for Bitcoin because they thought Bitcoin had value and was worth trading, not because they wanted to back Bitcoin with fiat in order to give Bitcoin value.

Tether directly claims that the source of its value is that it's backed by the fiat in their account. So it's directly dependent on that central account holder for its value.  If that central entity fails, the tokens will almost undoubtedly become worthless.

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube

https://tether.to/faqs/

"Tether is the world’s first fiat currency token platform to exist on the Blockchain"

I understand that to mean decentralised.  And isn't bitasset's yield close to zero?

You understand incorrectly, but perhaps as intended:

Quote
Tether currency is backed 100% by actual fiat currency assets in our reserve account and always maintains a one-to-one ratio with any currency held. For example 1 USD₮ = 1 USD. With almost zero conversion and transfer fees, Tether currency is redeemable for cash at any time.

So it's a token on a blockchain, issued by a centralized entity, and they promise they'll redeem it for fiat.  Same as Ripple IOUs, CoinoUSD on NXT, or UIA IOUs on BitShares.

Also bitUSD interest is over 2% right now, significantly higher than my bank is offering on even CDs of any term length.

EDIT: Tether might be a good gateway partner if they'd issue their IOUs directly on our chain also.  If they've got the fiat end infrastructure anyway, they might as well use it to its full potential.

I am trying to understand the classification here. It seems 'centralised' = 'counter-party risk'.  Does that mean bitcoin falls into the 'centralised' group (since it requires an centralised exchange for fiat)?
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.