[ANN][YAC] Yacoin Block Explorer now LIVE! http://yacexplorer.tk

[sairon]

http://yacexplorer.tk/ is down.

Yes, it is. I'm trying to figure out why the hell is it breaking the database all the time.

[sairon]

Server up again, let's see for how long it will last this time...

EDIT: Gah, it went down again... -.-" However, I found out that this is a known problem in Abe related to concurrent blockchain processing when new block is received from the network (race condition or something). I've implemented a quick fix - using a separate process for writing new blocks into DB once in a while (so webpage might be delayed by up to 60 seconds, not a big deal). Hopefully this avoids another DB corruption until proper fix is implemented in Abe.

[sairon]

Just wondering: Do we have any live graphs?

It's on my TODO list.

Graphs now live at http://yacexplorer.tk/graphs.htm. Updated every hour.

[St.Bit]

Why are there negative intervalls?

[sairon]

Why are there negative intervalls?

Some miners try to decrease difficulty by including timestamps from the future in the block. These timestamps are chcecked by the network and accepted if they're within 2 hours of local time. By pretending it took almost 2 hours to solve a block instead of 1 minute, these miners trick the network into decreasing difficulty by a little fraction (around 2% the last time a checked). It also creates these weird data points in the graphs.

From https://en.bitcoin.it/wiki/Block_timestamp (Forum warning: Possible phishing link!):

A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.

[sairon]

It is code inherited from Bitcoin which uses 10 minutes block time so YACoin maximum future time should be dropped to 12 minutes.

Yeah, thanks for the correction.

[sairon]

Two suggestions:

1. Remove showing 2016 blocks (count=2016) since it has no connection with YAC, it is made for cryptocoins that retarget every 2016 blocks.
2. Put link for this thread somewhere on explorer webpages.

Done.

[dreamwatcher]

Server up again, let's see for how long it will last this time...

EDIT: Gah, it went down again... -.-" However, I found out that this is a known problem in Abe related to concurrent blockchain processing when new block is received from the network (race condition or something). I've implemented a quick fix - using a separate process for writing new blocks into DB once in a while (so webpage might be delayed by up to 60 seconds, not a big deal). Hopefully this avoids another DB corruption until proper fix is implemented in Abe.

Ahh, my young ABE Padawan.  

The first step in your quest for a smooth running explorer is to switch to the FastCGI server and stop using the default built in python server.

You have the right idea about separate processes for update verses serve. Keep two copies of abe.py with different names like abe.py and uabe.py.

Any requests from the web server will use one abe.py with a conf file that uses a empty bracket for datadir (datadir = [] ). This will stop web requests from tripping an update.

To update the database use the blocknotify option in the coin daemon conf file and point it to a script that will run the second abe.py (uabe.py) with a full conf file to trigger a database update. The reason for the two named abe.py has to do with FastCGI sticking its big nose into your database update process if it has the same name as the process it trips.

If you need any more help, just let me know.  

[sairon]

Server up again, let's see for how long it will last this time...

EDIT: Gah, it went down again... -.-" However, I found out that this is a known problem in Abe related to concurrent blockchain processing when new block is received from the network (race condition or something). I've implemented a quick fix - using a separate process for writing new blocks into DB once in a while (so webpage might be delayed by up to 60 seconds, not a big deal). Hopefully this avoids another DB corruption until proper fix is implemented in Abe.

Ahh, my young ABE Padawan.  

The first step in your quest for a smooth running explorer is to switch to the FastCGI server and stop using the default built in python server.

You have the right idea about separate processes for update verses serve. Keep two copies of abe.py with different names like abe.py and uabe.py.

Any requests from the web server will use one abe.py with a conf file that uses a empty bracket for datadir (datadir = [] ). This will stop web requests from tripping an update.

To update the server use the blocknotify option in the coin daemon conf file and point it to a script that will run the second abe.py (uabe.py) with a full conf file to trigger a database update. The reason for the two named abe.py has to do with FastCGI sticking its big nose into your database update process if it has the same name as the process it trips.

If you need any more help, just let me know.  

I already solved it, but thanks anyway.

[sairon]

Two suggestions:

1. Remove showing 2016 blocks (count=2016) since it has no connection with YAC, it is made for cryptocoins that retarget every 2016 blocks.
2. Put link for this thread somewhere on explorer webpages.

Done.

You replaced 2016 with 1440 (in what sense is that value relevant to YAC?) and there is no link pointing to this thread. 

1) 1 day / 60 second blocks = 1440 blocks/day
2) at the end of technical info http://yacexplorer.tk/graphs.htm#tech

[sairon]

1. Why would someone ever switch to 1440 blocks shown on a single page? It is pointless since there will hardly ever be exactly 1440 blocks solved in one day.
2. Cool, but it is on graphs page, not main page so anyone checking just block, address or transaction will never see it.

1) meh
2) why would they want to? imo anyone interested in details will browse through the technical info and find the links there

[sairon]

Implemented new block explorer feature: getbalance API call:
http://yacexplorer.tk/chain/Yacoin/q/getbalance/YOUR_ADDRESS_HERE

EDIT: Also, approximate network hashrate over last N blocks (default N = 1440 blocks = ~1 day):
http://yacexplorer.tk/chain/Yacoin/q/hashrate

[JahPowerBit]

Implemented new block explorer feature: getbalance API call:
http://yacexplorer.tk/chain/Yacoin/q/getbalance/YOUR_ADDRESS_HERE

cool! thank you.
If you can implemente this 2 queries for Yacoin:

https://blockchain.info/pushtx
http://blockchain.info/unspent?address=address

Brainwallet.org will be easy to be adapted for Yacoin..

[JahPowerBit]

Please some one can explain me why this transaction have 0 confirmation, and why i can not find it on yacexplorer

Code:

Status: 0/unconfirmed
Date: 6/12/13 01:55
Debit: 0.00 YAC
Net amount: -1189.99 YAC
Transaction ID: 7a86082a5685784ad33cec31a5300a611b9f4076a0c2b1d1d7f2c035a6d3e7e5

Staked coins must wait 520 blocks before they can return to balance and be spent. When you generated this proof-of-stake block, it was broadcast to the
 network to be added to the block chain. If it fails to get into the chain, it will change to "not accepted" and not be a valid stake. 
This may occasionally happen if another node generates a proof-of-stake block within a few seconds of yours.

http://yacexplorer.tk/search?q=7a86082a5685784ad33cec31a5300a611b9f4076a0c2b1d1d7f2c035a6d3e7e5

Thanks!!

[JahPowerBit]

Restart YACoin client with -rescan option once. If it does not help, restart it with -reindex option once (it takes some time to complete).

Thank you a lot, but it does not work 
My wallet always indicates stakes = 0 and the transaction is still not confirmed ..
Please someone tell me that I have not lost permanently in 1800 YAC 

[JahPowerBit]

resolved by a simple "repairwallet" 
thanks

[dreamwatcher]

Restart YACoin client with -rescan option once. If it does not help, restart it with -reindex option once (it takes some time to complete).

Thank you a lot, but it does not work  
My wallet always indicates stakes = 0 and the transaction is still not confirmed ..
Please someone tell me that I have not lost permanently in 1800 YAC  

OK, the indicator for me is that it does not indicated it broadcast the transaction to any node. This tells me the client created the transaction, but for whatever reason it was never broadcast (Client was shut-down or crashed before it broadcast the transaction).

This means your wallet (client) believes you had a -1800 transaction. but in reality it was never broadcast and therefor not in the block chain. The thing that needs to be done is to remove that transaction out of your wallet, as it is not a real transaction.

Couple of way to solve this when it gets this bad:

1. Always backup your current wallet

2. Dump/import key method - Dump the private key for the address involved in the transaction (dumpprivkey), this will display the private key to that address. Close the client.  Rename your current wallet.dat. Restart the client. Import the private key (importprivkey <Private key you got before>). When the cursor comes back (It might not say anything), restart the client. The new wallet should show the coins from the address you just imported. Your old wallet will still have that transaction, and not accept the real transaction. Your best bet is to move whatever coins you have in the old wallet to the new wallet and go from there.( rename the wallet.dat and switch the old wallet back to wallet.dat...etc...etc...)

3. You could use PYwallet to delete all the transactions in your current wallet and force a TRUE rescan, as the wallet will have no transactions in it, the client will have to find all the transactions associated with it.Instructions for that are a bit more detailed and setting up PYwallet is system specific (Windows or linux).

EDIT: Looks like it was solved while I was typing this up...

[JahPowerBit]

EDIT: Looks like it was solved while I was typing this up...

yep double   ! thank you very much and very sorry for your time!!

i type "help" to search command for dump all my private keys et reload them in another wallet, when i saw the "repairwallet" command.. and eureka :-)
thank you again all!!