where you able to find out what was wrong with testnet3?
Not yet, thanks for the reminder. |
|
|
|
THANK YOU! I haven't worked with fastcgi much and just realized it was actually running an old version I installed from /usr/local/lib/python2.7/dist-packages/Abe/ instead of where I thought it was running from. All is working well now. Thanks!
Good point. While troubleshooting, it's better to leave FastCGI out of the picture, if possible. |
|
|
|
Hi MobGod, The last PM from you is about: File "/home/mobgod/abe_test/Abe/abe.py", line 354, in handle_chains
100.0 - (100.0 * (ss + more) / (total_ss + more)))
ZeroDivisionError: float division by zero
I fixed that. What happens when you pull/merge the latest code and try again? |
|
|
|
this one for Noirbits fails. It appears to trap the error at line 511 in abe.py
509 else:
510 percent_destroyed = '%5g' % (
=> 511 100.0 - (100.0 * ss / total_ss)) + '%'
512
513 body += [
I really appreciate your help trying to figure it out. This does not look like the latest version. Please update and try again. The current version has this at that part of the code: 510 if total_ss <= 0:
511 percent_destroyed = ' '
512 else:
513 percent_destroyed = '%5g' % (
514 100.0 - (100.0 * ss / total_ss)) + '%'
|
|
|
|
I keep getting a "RuntimeError: maximum recursion depth exceeded" error. It happens every time I start abe up, and every time I access a page the error shows up in the console.
This has been on the to-do list for a long time. I'll give it another look, but as I recall, it would take the better part of a day to code and test. First, run Abe once with --rescan in case that solves it. If you know Python, you can try sys.setrecursionlimit(300000) as suggested here. (Replace 300000 with a few more than the number of blocks in your chain, or try lower numbers until either success or another kind of crash.) I think this happens when the block files are "very" out of sequence: when a sequence of 1000 or more blocks all occur before one of their common ancestors. Could this be the case with your block files? Maybe this is normal for the latest Bitcoin versions, which I have not tested. Is there anything unusual about how your block files were created, or did you download the chain again after running Abe the first time? |
|
|
|
i deleted the chain and let it run with --rescan, it imported more blocks but it fails once again! same error, look at the crazby block file count
The block file number 100001 is okay, it just means blocks/blk00001.dat as opposed to the pre-0.8 ./blk0001.dat. As for the Merkle Root Mismatch, I would guess that Testnet3 is trying some new block format. I would be curious to see the raw data between offset 622216 and 622305 in your blk00001.dat file. |
|
|
|
Hello John again i'm getting errors i've tried what you told me it just skips the blocks not sure why than this
block_tx 8470 8734
Skipped 72 bytes at block end
block_tx 8471 8735
Skipped 72 bytes at block end
This is not an error, just a warning. This coin puts some extra data at the end of each block beyond what Bitcoin puts. Abe does not know what it is for, so it skips it. Can you browse the site? |
|
|
|
If the coin is derived from PPCoin/Peercoin, try the "ppcoin" branch (git checkout ppcoin). |
|
|
|
is it possible to have a 4 char code3, for example TBTC for Testnet Bitcoin? (according to README not, is this just a "you shouldnt do this" or a "this wont work and fucksup everything") dislike to try it out on my finally synced Abe and screw it up  if i change it to 4 chars in MySQL, will it work or does Abe bail out on it? Well, I don't think it will cause any big problem within Abe. Currencies traditionally have 3-character codes, so I named it char3 and made the column 3 wide. If you widen the column and put in 4 chars, it will not break the database. |
|
|
|
Hello John can you tell me how to fix this error i'm getting?
Failed to catch up {'blkfile_offset': 0, 'blkfile_number': 1, 'chain_id': 11, 'loader': None, 'dirname': u'/home/mobgod/.bitgem/', 'id': 4}
Traceback (most recent call last):
File "Abe/DataStore.py", line 2592, in catch_up
if not store.catch_up_rpc(dircfg):
File "Abe/DataStore.py", line 2753, in catch_up_rpc
raise InvalidBlock('block hash mismatch')
InvalidBlock: block hash mismatch
Please try with "default-loader=blkfile" in your abe.conf, or try the workaround I just pushed to GitHub. To make RPC work, we will have to find out how this coin hashes its blocks. |
|
|
|
PS.
Most of the people need something really simple and intuitive for browsing the block chain
Any thoughts of a really light minimalistic interface?
Well, it would be nice to separate Abe more into model/view/controller. Maybe JSON versions of the UI pages, and implement the UI in JavaScript? Thanks for the Testnet3 explorer! I don't know who uses Testnet3 or how to tell them, but I'm glad to know about it. |
|
|
|
If I click the >> link to browse to the beginning of the block chain, python barfs a big purple "division by zero" screen. Happened on a few of the abe installs I looked at. I'm testing mine for Doubloons at http://explorer.doubloons.net/chain/Doubloons. Any help to identify the problem would be appreciated. Interesting. Please update and see if this fixes it. The genesis block has zero output value, first time I've seen that. No premining there! |
|
|
|
Is there any way for Abe to not update the database with the latest transactions? Running in FastCGI mode, most requests take a long time to return a result because Abe is reading the most recent transactions and inserting them into the database. I know I can start in standalone mode, but then what's the point of FastCGI mode at all? Ideally what I'd like to do is have a process that runs in the background loading new transactions, sleeping for a few seconds or minutes, and loading again, forever. And the FastCGI side of things would just be a user interface to the back-end database, basically. Is that possible? Am I missing something obvious?
You are on the right track. I ought to be typing this into a new "readme-server.txt" file. Try "datadir=[]" in your FastCGI config to disable loading, and "no-serve" in the loader config to disable serving. |
|
|
|
can i have a Abe with sha256d chains and scrypt chains? also where is the docu for scrypt based chains?
Did you try it? http://explorer.litecoin.net/ appears Abe based, and doesn't LTC use scrypt? I'd suggest asking them if they had to change anything. They should give you the explorer source. (If not, I'd like to know...) Abe does not (yet) contain any special code for scrypt. That would be nice to add. |
|
|
|
Hi! I'm trying to get Abe working through RPC instead of reading my blockchain files directly and I'm having problems. I believe I've met all the requirements listed at the end of abe.conf regarding RPC, but when I try to start Abe, I get this: $ python -m Abe.abe --config abe.conf
no chain_id
Hi! Thanks for trying, and my apologies for the rough edges. If using an already loaded database, issue the following SQL before restarting: $ sqlite3 abe.sqlite
sqlite> UPDATE datadir SET chain_id = 1 WHERE dirname='/home/user/.bitcoin';
sqlite> .quit
I see almost no references in the documentation to "chain_id" so I'm really not sure what to do. Google has been no help. I tried renaming abe.sqlite and hoping it would just rebuild the entire database from scratch using RPC and in that case I get this: $ python -m Abe.abe --config abe.conf
ddl_implicit_commit=true
create_table_epilogue=''
max_varchar=4294967295
clob_type=CLOB
binary_type=buffer
int_type=str
Created silly table abe_dual
sequence_type=update
limit_style=native
commit
Failed to catch up {'blkfile_offset': 0, 'blkfile_number': 1, 'chain_id': 1, 'loader': u'rpc', 'dirname': u'/home/user/.bitcoin', 'id': 1}
Traceback (most recent call last):
File "Abe/DataStore.py", line 2551, in catch_up
if not store.catch_up_rpc(dircfg):
File "Abe/DataStore.py", line 2716, in catch_up_rpc
format = "binary")
File "Abe/DataStore.py", line 2254, in export_tx
'prevout_hash': store.hashout(prevout_hash),
File "Abe/DataStore.py", line 319, in rev
return x[::-1]
TypeError: 'NoneType' object has no attribute '__getitem__'
Abe initialized.
Listening on http://192.168.1.2:2750
Any ideas? Thanks for this, it is a bug that I may be able to fix. But try the update statement. |
|
|
|
[2013-05-14 10:42:53] >> File "Abe/DataStore.py", line 481, in sql
[2013-05-14 10:42:53] >> store.cursor.execute(cached, params)
[2013-05-14 10:42:53] >> InternalError: invalid page header in block 61022 of relation base/17556/17801 Do you know what's happening? Did my DB get corrupted? Offhand, it appears to be internal to the database system. I don't think "block 61022" refers to the blockchain. I'd try to dump and reload the database, and if that doesn't do it, search the web for "invalid page header in block". |
|
|
|
One option here would be to define the POW for a chain so that orphans are simply included. Nodes could store the headers for orphans.
I suppose you mean only the first block in an orphaned chain is included, or perhaps the first few blocks. Otherwise, it could be hard to distinguish "orphaned" chains from an attacker's chain or, if the attack is succeeding, from the honest chain. Orphaned blocks help protect the network under this scheme, where chain POW is replaced by the product of transaction fee times work over all transactions in the chain and all blocks, including orphans. This proposed system also features resistance to >> 50% attacks whose goal is to exclude a fraction of all transactions. |
|
|
|
This might require a database rebuild.
I would doubt it, just an SQL update of chain_code3. |
|
|
|
|
Show Posts
