Could you require BTC Sell XCP Buy orders to Proof of Burn some very marginal amount of BTC? - it would serve as a deterrent from placing Spam orders.
It's a catch 22 in this case. Because a proof of burn address most likely already has XCP on balance and a XCP escrow would work. Also checking an address for proof of burn should be trivial but over time the effectiveness would diminish as new users flood the system. I think an optional XCP fees escrowed system and an option for sellers to only matched orders with XCP escrowed could work. As biggest fish pointed out its only time that centralized exchanges start popping out and most btc /XCP trades would take place here. The key word here is here is 'optional' escrow. |
|
|
|
Another suggestion:
Require 1XCP to be escrowed for each order match beyond the first, which is returned on successful BTCpay, otherwise it goes to the person whose order was offline for the lockin period?
Thus a new BTC order must be submitted for EACH order to be wiped unless they escrow XCP
Edit: or even 0.01 XCP to be escrowed.
Obviously such a change should be implemented at a certain block number in future to allow people to prepare for the changeover.
Those are several of the glaring problems I see (order wiping, High fees, etc.).
+1 going forward we will need to work on mechanisms to prevent intentional abuse and trolling. A small value of 0.1 or perhaps a percentage value of the XCP purchased could be escrowed and refunded after a btcpay is successfully completed. Failing which these coins are distributed among the matched orders that are not paid or just burnt as fees Then one would need to own XCP before being able to buy XCP on the distributed exchange (with BTC). Yes ...I noticed that after posting which is why I edited my post. Could a small value of btc be locked up then as fees transaction fees Going forward I wonder if some sort of reputation system could be placed depending on order history of the address. Perhaps when placing an order another requirement I.e fee-required ..could rep_required=5. Meaning an address that is correctly completed 5 successful btcpay orders are only allowed to match The above is a simplistic example but something similar could be worked on. Alternatively orders with escrowed XCP are categorized differently and sellers can specify that they will only want to match with purchasers that have XCP escrowed I think going forward it's quite obvious that using the platform for anything even closely resembling hft would be unpractical so the additional requirements before placing an order can be accepted |
|
|
|
Another suggestion:
Require 1XCP to be escrowed for each order match beyond the first, which is returned on successful BTCpay, otherwise it goes to the person whose order was offline for the lockin period?
Thus a new BTC order must be submitted for EACH order to be wiped unless they escrow XCP
Edit: or even 0.01 XCP to be escrowed.
Obviously such a change should be implemented at a certain block number in future to allow people to prepare for the changeover.
Those are several of the glaring problems I see (order wiping, High fees, etc.).
+1 going forward we will need to work on mechanisms to prevent intentional abuse and trolling. A small value of 0.1 or perhaps a percentage value of the XCP purchased could be escrowed ( XCP or btc) and refunded after a btcpay is successfully completed. Failing which these coins are distributed among the matched orders that are not paid or just burnt as fees. |
|
|
|
Add a basic shareholders list (tab) based on address balances for a specific asset type under the individual asset type info http://blockscan.com/asset.aspx |
|
|
|
When two orders at different prices are matched, the final price is always that of the earlier order. (It's the same with bets and odds.)
Noted. Tq. I was looking at the data in the order_matches table and it looked as if the higher price was matching (later order) but I might have been mistaken |
|
|
|
I am confused. Does the exchange ensures the lowest asks will be filled first? If not, it's quite counter-intuitive. Previously, dgex, the Nxt exchange also did not ensure this and it's quite easy for people to manipulate the price.
counterpartyd matches orders based on the best available price, yes, if the fee conditions are satisfied. Then may I ask how come the price listed in blockscan as others pointed out can be matched? Is it a bug, or just there were no better price? Thanks a lot. Actually what I noticed is that you can technically "overpay" for an existing order if I am not mistaken. So this would mean that when an order is matched, the matched prices would not necessarily be the same the order requested price. Most of the times this would not be an issue as both prices would be the same. I am not entirely sure which price to display at blockscan so at the moment I am sticking to ask order price and not the actual (possibly overpaid) price paid. I am waiting this out till the official web gui comes out and then will standardize the prices and other variables Cheers |
|
|
|
|
Hi
I think it's best you bring this up in the main forums. What I can and will do is to try to ensure that the information displayed both in blockscan and counterparty is the same
Also take note that there are a lot of changed taking place during the early stages
|
|
|
|
It looks quite confusing, order book should group orders with the same price in 1 line, then user may be able to click to see all orders at that price, the remain column is not necessary, just show the sum of available at each price on the top level, simply put making it looks like normal order book
I've removed the original order volume and just have the actual remaining amount listed. I had it there earlier for "troubleshooting" just in case to catch any errors. However, I am not too sure on what do you mean by grouping the price in the same line?? most exchanges (i.e like btc-e) have these listed on separate lines. This also gives you a feel of your place in the queue because the orders are on a separate lines. I think at this point a lot of people are also using the page to confirm if their order has actually gone through and breaking down the transactions allow this (vs grouping) them up cheers |
|
|
|
Overview Dividends Updates Contacts Asset_ID: 2632494122289 Issuer: 1FCkCQCnEtHQ3j7NqdkAnkqQUvqfti4XoA Time Stamp: 2/1/2014 10:45:57 PM Transaction: 2843 recorded at Block #283652 Tx Hash: 91aed459a4cb1bbd500e1ffea62e84a0c8988971d251d307f7485d6cd57d79a8 Total Amount Issued: [Issue No.1 at Block#283652] 10000000000 Divisible: True Transfer: False Remark: Valid The difference between counterpartyd_build and blockscan.com: counterpartyd_build: Asset Name: MPTSTOCKAsset ID: 101249773934Total Issued: 200.0blockscan.com: Asset Info MPTSTOCKF Asset_ID: 2632494122289 Issuer: 1FCkCQCnEtHQ3j7NqdkAnkqQUvqfti4XoA Time Stamp: 2/1/2014 10:45:57 PM Transaction: 2843 recorded at Block #283652 Tx Hash: 91aed459a4cb1bbd500e1ffea62e84a0c8988971d251d307f7485d6cd57d79a8 Total Amount Issued: [Issue No.1 at Block#283652] 10000000000My question is , which one is correct? I have marked the difference in red. I also posted this at: https://bitcointalk.org/index.php?topic=395761.2440The AssetID is a bit confusing. Previous builds did not include the CHECKSUM character and the AssetID was calculated based on this.. But when the CheckSum character was added to the later releases the MPTSTOCK-became->MPTSTOCKF. And this (MPTSTOCKF) is what its officially referred to in this counterparty client when doing a "asset" command. However, the ASSETID is still calculated based on "MPTSTOCK" and not "MPTSTOCKF I understand that the code is still alpha and changes like these are to be expected for the betterment of the protocol. However, I don't really have a way to know what gets broken on blockscan whenever these changes take place... I believe I have already corrected this issue and asset page on blockscan should match what you see in the counterparty client. If I have missed out anything please let me know I am going to take a step back from the making changes at blockscan and most likely wait till the changes stabilize a bit before trying to fix stuff after this cheers |
|
|
|
I've found another (major) difference between blockscan.com and counterpartyd: http://blockscan.com/address.aspx?q=1JUXwDjh21yLkUhKNdggenexZK8XpeXTRxInitially blockscan.com was showing a successful trade and a balance of 29 XCP in the above account. Now it shows that the initial order TIMED OUT, and a balance of 0 XCP :-( However: ~$ counterpartyd address 1JUXwDjh21yLkUhKNdggenexZK8XpeXTRx Balances +-------+--------+ | Asset | Amount | +-------+--------+ | BTC | ?? | | XCP | 29.0 | +-------+--------+ My local counterpartyd still believes I have 29 XCP. (cross-posted at: https://forums.counterparty.co/index.php/topic,2.0.html ) I am running the develop branch I am getting the following which matches with blockscan is showing Balances +-------+----------+ | Asset | Amount | +-------+----------+ | BTC | 0.004257 | +-------+----------+ |
|
|
|
... The protocol uses 10000000000 to represent 100 of an asset but blockscan doesn't properly show that, so it should read 100.00000000 instead of 10000000000. Also blockscan is currently having some trouble with assets.
I have corrected the display issue. It now divides the value before displaying the total issuances. Your issued shares now read "100". What other issues are you having with assets? |
|
|
|
|
Is anyone else running into issues when attempting a send (latest develop branch) ??
Traceback (most recent call last):
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 514, in <module>
print(unsigned_tx_hex) if args.unsigned else json_print(bitcoin.transmit(unsigned_tx_hex))
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 392, in transmit
return rpc('sendrawtransaction', [signed_tx_hex])
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 91, in rpc
raise exceptions.BitcoindError('{}'.format(response_json['error']))
lib.exceptions.BitcoindError: {'message': 'TX rejected', 'code': -22}
|
|
|
|
Yea there's people trolling the price right now
Overview
Last DEX Matched Price : 50.0000 BTC/XCP @ $39,492.500
Total XCP Supply: 2648755.9218 ($104,605,993,241.63)
Total XCP Transactions: 3281 transactions
Last Block Number: 284379
We need greater exposure and greater liquidity for XCP
Why not quote some kind of moving average that takes volume into account instead? Or else filter out these very low volume threads and add a note to that effect. Or both. -rotalumis There is insufficient data points at this point of time. The actual matched and paid BTC/XCP order pairs is miniscule at the moment. However, this should change over time when we have more liquidity (I.e GUI/web client is launched, etc). Cheers |
|
|
|
Yea there's people trolling the price right now
Overview
Last DEX Matched Price : 50.0000 BTC/XCP @ $39,492.500
Total XCP Supply: 2648755.9218 ($104,605,993,241.63)
Total XCP Transactions: 3281 transactions
Last Block Number: 284379
We need greater exposure and greater liquidity for XCP
There is almost no liquidity at the moment and the prices can be easily manipulated. Please take note that the prices on blockscan are based on order_matches data and does not necessarily mean it has been settled. There is no api at the moment to get an accurate figure and I am trying to see how best to pull the data out from the db. Once the official web client is out I will work at this again because I will at least have reference data to work with |
|
|
|
Issue:XCP not returned from escrow after cancellation of Orderhttp://blockscan.com/address.aspx?q=17PgVzRSSSjc2aN8Lyp1x9QayKzPzY2pKja) I placed a sell order for 250 XCP order b) the order was matched by the engine, but the buyer did not make any payment yet. c) I cancelled the order d) I did not receive back the XCP from escrow The Balance should be: 1432-400-200-200=632 Instead it is 382 XCP and 250 from Escrow is missing. I know there was similar issue not sure what the resolution for that was. (I am on the latest build). I see the correct sum, with all of the correct components, in the latest version of the develop branch. (And I see the correct sum in Blockscan.com, too, for that matter.) On a similar note after an unfilled sell XCP order has expired, how do we get the XCP credited back? Thanks It gets credited automatically from my experience. I am running the develop branch and I do not see this happening. From a PM from you, you mentioned running the "purge" command. however this this now throws an error. |
|
|
|
Issue:XCP not returned from escrow after cancellation of Orderhttp://blockscan.com/address.aspx?q=17PgVzRSSSjc2aN8Lyp1x9QayKzPzY2pKja) I placed a sell order for 250 XCP order b) the order was matched by the engine, but the buyer did not make any payment yet. c) I cancelled the order d) I did not receive back the XCP from escrow The Balance should be: 1432-400-200-200=632 Instead it is 382 XCP and 250 from Escrow is missing. I know there was similar issue not sure what the resolution for that was. (I am on the latest build). I see the correct sum, with all of the correct components, in the latest version of the develop branch. (And I see the correct sum in Blockscan.com, too, for that matter.) On a similar note after an unfilled sell XCP order has expired, how do we get the XCP credited back? Thanks |
|
|
|
THanks, I gave it a look already, but yeah it's a bit messy. Still a great creation overall nonetheless, mad props! There is a latest price snapshot for the DEX exchange available on the main page. Once there is sufficient data, I will look into a price historical chart. However, given that we have more than 100 assets listed I will only work on the BTC/XCP charts on the dex I am slowly making my way through the order page to clean it up a bit. I've already added some filters. If you have any suggestions please feel free to post it here.. |
|
|
|
Thanks for your input Vitalik. Speaking from the Wall Street perspective, not all exchanges out there are even suitable for high frequency trading (witness the recent rise of electronic exchanges - ARCA, BATS, etc). Not all participants are interested in "low-quality" liquidity so to speak, as provided by most high-frequency exchanges (which was one of the indirect causes of the infamous 2010 Flash Crash). Not all assets need to be traded on a real-time basis (real estate [which has many analogies with BTC], bonds, and mutual funds for instance). It's not also widely appreciated that official settlement for stock trades occurs not instantaneously, but 3 days ( the T+3 rule). In contrast, 1 hour (6 confirmations) is widely acknowledged to be a reasonable settlement time for even the largest BTC trades. The blockchain more closely resembles, say, the housing market or the contracts/swaps derivatives markets, which don't operate in any way similar to HFT even though they handle trillions of dollars in notional value. So the notion that non-highly liquid markets can't be valuable is absurd. +1. Well said. I do believe that XCP will have its place in time to come. |
|
|
|
|
Show Posts
