Overall still a profitable venture ::: Hodl 

Proof of burn. 4 BTC was burned.

Sorry to hear that. If its any consolation you only lost 4 BTC (which is what you burned then)

hmmphh... I am not too sure but I don't remember seeing an OP_return in the output script of the send transactions

For all of the transactions to work they need 80 bytes. Some way along if I recall correctly, there was an attempt to put certain transactions through with an OP_Return (40 bytes) but that was shelved aside as the transactions were taking longer than usual (possibly due to miners blocking/not processing OP_Return ??)

I am assuming that once the OP_Return (80 bytes) is "mainstream" the shift to using OP_Return will occur

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.

Is that already in place?  From what I understand that those changes would take a while to be implemented by Eligus

Most of the expirations are due to the required/provided fee mismatches in addition to incomplete BTCPays

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

Thank you dexX7 

I have updated both the order_matches and orderinfo(matches) with the block number

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 ?

Is the match_expire_index used to used to designate the block index when the order was matched?

running into some SSL security prompt issues on IE...

I like what you did with CoinMachine.co. Straight forward and clean design. Tried the service and the notifications were prompt and precise

Ok. Completed as per above. You can now get the both the latest DEX prices for a BTCPAY & NonBTCPay asset pairs.

The code for the NonBTCPay assets pair is still new so it's under testing. Do let me know if you see anything out of place

ex:

http://xcp.blockscan.com/api2.aspx?module=price&asset1=BTC&asset2=SJCX

http://xcp.blockscan.com/api2.aspx?module=price&asset1=SJCX&asset2=XCP
http://xcp.blockscan.com/api2.aspx?module=price&asset1=XCP&asset2=SJCX


Cheers

The daemon went down so we were backed up a bit. After restarting it we're up to date

You can check the main page to see which are the last block processed, if its not up to date it most likely means the daemon is down

If you run and have access to the CLI, you can do anything

Sure, that makes sense. And the API would be a good fit for that.

I will look into that as soon as I finish up some of the other changes that I have been working on recently

Cheers