Topic: [BlockScan] Counterparty (XCP) Block Explorer - page 4. (Read 31856 times)
Most of the volume is on Bter so I would prefer it be based on the last trade for Bter btcxcp and bitstamp btcusd. If you want to future proof it a bit you could go volume weighted for the top 3-4 exchanges on each pair.
@mtbitcoin, on home page the exchange rate of XCP is based on the last BTC Sell (for XCP) trade executed on the DEx, which was few days back.
Maybe you should the rate from Coinmarketcap or weighted average from main exchanges?
Maybe you should the rate from Coinmarketcap or weighted average from main exchanges?
Does Coinmarketcap have an API for pulling prices?
@mtbitcoin, on home page the exchange rate of XCP is based on the last BTC Sell (for XCP) trade executed on the DEx, which was few days back.
Maybe you should the rate from Coinmarketcap or weighted average from main exchanges?
Maybe you should the rate from Coinmarketcap or weighted average from main exchanges?
So, not to get too off-topic in your thread but, doesn't Counterwallet take care of the required/provided fee situation i.e are people tweaking things without knowing the impact or... are they trying to minimize fees and the wallet can't handle all of those cases?
I think most people aren't tweaking things because they don't know what they mean (but it could be checked of course, by looking at BTC Sell orders, especially expired).
Matches aren't handled in the wallet but below in counterpartyd (which is why counterpartyd can still use BTC Sell although it was recently removed from Counterwallet).
Works now, thanks!
Hi,
No "Access-Control-Allow-Origin" header is present on the requested resource. That's the error message I get when trying to access the data with Javascript. Also, it seems the specific asset balance does not work: http://xcp.blockscan.com/api2.aspx?module=address&action=balance&btc_address=16WhhnUUCZVvszFxsaCG3d6v77Qin1LErQ&asset=XCP
Thanks.
No "Access-Control-Allow-Origin" header is present on the requested resource. That's the error message I get when trying to access the data with Javascript. Also, it seems the specific asset balance does not work: http://xcp.blockscan.com/api2.aspx?module=address&action=balance&btc_address=16WhhnUUCZVvszFxsaCG3d6v77Qin1LErQ&asset=XCP
Thanks.
I have fixed the asset balance issue. Will look into the other (CORS) issue.
Can you send me a copy of the javascript text snippet or better still jsfiddle link so that I do not have to recreate a script?
Edit: Can you give your javascript another try and let me know if you are still running into issues?
Hi,
No "Access-Control-Allow-Origin" header is present on the requested resource. That's the error message I get when trying to access the data with Javascript. Also, it seems the specific asset balance does not work: http://xcp.blockscan.com/api2.aspx?module=address&action=balance&btc_address=16WhhnUUCZVvszFxsaCG3d6v77Qin1LErQ&asset=XCP
Thanks.
No "Access-Control-Allow-Origin" header is present on the requested resource. That's the error message I get when trying to access the data with Javascript. Also, it seems the specific asset balance does not work: http://xcp.blockscan.com/api2.aspx?module=address&action=balance&btc_address=16WhhnUUCZVvszFxsaCG3d6v77Qin1LErQ&asset=XCP
Thanks.
Also, I've not looked at counterpartyd but are zero-confirmation orders something you could show? (maybe dimmed to show they aren't active yet)
I've just added the ability to view pending zero confirmation sends, orders, cancels and issuances (dimmed) when looking at the address transaction pageTo test this out either do a test transaction or pull up one of the source/destination addresses at http://blockscan.com/pending. And then lookup the address transactions at the search box
This is still work in progress though and might need some fine tuning.
Very cool. That should be helpful in seeing how fast things are happening on the network level.
Also, I've not looked at counterpartyd but are zero-confirmation orders something you could show? (maybe dimmed to show they aren't active yet)
I've just added the ability to view pending zero confirmation sends, orders, cancels and issuances (dimmed) when looking at the address transaction page
To test this out either do a test transaction or pull up one of the source/destination addresses at http://blockscan.com/pending. And then lookup the address transactions at the search box
This is still work in progress though and might need some fine tuning.
So, not to get too off-topic in your thread but, doesn't Counterwallet take care of the required/provided fee situation i.e are people tweaking things without knowing the impact or... are they trying to minimize fees and the wallet can't handle all of those cases?
Actually my purpose is to see order matches that were awaiting bbc pay to see if I want to try and fill one of them. I don't get why so many matches expire but some of them are at low/high prices which makes them interesting.
Most of the expirations are due to the required/provided fee mismatches in addition to incomplete BTCPays
Actually my purpose is to see order matches that were awaiting BTCpay to see if I want to try and fill one of them. I don't get why so many matches expire but some of them are at low/high prices which makes them interesting.
I've started looking at the order matches screen and have a request. Would it be possible to have that sorted by price or pair then price? Otherwise, seeing more results per page would help with the usability.
Also, I've not looked at counterpartyd but are zero-confirmation orders something you could show? (maybe dimmed to show they aren't active yet)
Also, I've not looked at counterpartyd but are zero-confirmation orders something you could show? (maybe dimmed to show they aren't active yet)
To sort by price, we have to first sort by pair. I will look into increasing the page results first.
Are you looking at the order_matches in order to determine if your order has matched? If yes, then the recommended way is to look up your order first and click on the view button. This will show you your order details and related order_matches and btcpays (if any) under separate tabs
At the moment, the orders need at least 1 confirmation to make it into the counterpartyd. For 0 confirmation orders (and transctions) you can view the mempool table available under http://blockscan.com/pending. It is in RAW json data, but you should still be able to see if your transaction made it in.
Cheers
I've started looking at the order matches screen and have a request. Would it be possible to have that sorted by price or pair then price? Otherwise, seeing more results per page would help with the usability.
Also, I've not looked at counterpartyd but are zero-confirmation orders something you could show? (maybe dimmed to show they aren't active yet)
Also, I've not looked at counterpartyd but are zero-confirmation orders something you could show? (maybe dimmed to show they aren't active yet)
The order matches table has a column block_index. (Because of re-matches, the larger tx_index value isn't reliable.)
I have updated both the order_matches and orderinfo(matches) with the block number
Can you add the field "match_expire_index" from https://github.com/CounterpartyXCP/counterpartyd/blob/master/lib/blocks.py#L318 to table on http://www.blockscan.com/order_match.aspx?
Because it's not easy to figure out when one's order was matched.
Because it's not easy to figure out when one's order was matched.
Is the match_expire_index used to used to designate the block index when the order was matched?
It's used to designate the block at which an order match will expire.
That was what I thought so too... Having said that, how would suggest that we determine the block that an order matches?
Can this be done by looking at the larger value of either the tx0_index or tx1_index ?
The order matches table has a column block_index. (Because of re-matches, the larger tx_index value isn't reliable.)
Can you add the field "match_expire_index" from https://github.com/CounterpartyXCP/counterpartyd/blob/master/lib/blocks.py#L318 to table on http://www.blockscan.com/order_match.aspx?
Because it's not easy to figure out when one's order was matched.
Because it's not easy to figure out when one's order was matched.
Is the match_expire_index used to used to designate the block index when the order was matched?
It's used to designate the block at which an order match will expire.
That was what I thought so too... Having said that, how would suggest that we determine the block that an order matches?
Can this be done by looking at the larger value of either the tx0_index or tx1_index ?
Can you add the field "match_expire_index" from https://github.com/CounterpartyXCP/counterpartyd/blob/master/lib/blocks.py#L318 to table on http://www.blockscan.com/order_match.aspx?
Because it's not easy to figure out when one's order was matched.
Because it's not easy to figure out when one's order was matched.
Is the match_expire_index used to used to designate the block index when the order was matched?
It's used to designate the block at which an order match will expire.
Can you add the field "match_expire_index" from https://github.com/CounterpartyXCP/counterpartyd/blob/master/lib/blocks.py#L318 to table on http://www.blockscan.com/order_match.aspx?
Because it's not easy to figure out when one's order was matched.
Because it's not easy to figure out when one's order was matched.
Is the match_expire_index used to used to designate the block index when the order was matched?
Can you add the field "match_expire_index" from https://github.com/CounterpartyXCP/counterpartyd/blob/master/lib/blocks.py#L318 to table on http://www.blockscan.com/order_match.aspx?
Because it's not easy to figure out when one's order was matched.
Because it's not easy to figure out when one's order was matched.
Jump to: