Search content
Sort by
Showing 20 of 185 results by Hoshimaru
It's up & running dreamwatcher \(^_^)/ (*)
At first I had some trouble with it because I'm already running a vhost on that server for bitcoin-abe.
The configuration of this virtual host is slightly different to what's written in the docs on github:
.morningminerals.com:80>
ServerName .morningminerals.com
ServerAlias .morningminerals.com
ProxyPreserveHost On
ProxyErrorOverride On
DocumentRoot /home/akira/www/cce
Order allow,deny
Allow from all
ProxyPass /images !
ProxyPass /robots.txt !
ProxyPass /css !
ProxyPass /js !
.morningminerals.com>
Order allow,deny
Allow from all
ProxyPass / http://localhost:8222/
ProxyPassReverse / http://localhost:8222/
Without the added green directive it won't load the bootstrap files located in documentroot.
Also, the domain/host must specified in each individual vhost's conf or only one of them works ;-)
At first I had some trouble with it because I'm already running a vhost on that server for bitcoin-abe.
The configuration of this virtual host is slightly different to what's written in the docs on github:
.morningminerals.com:80>
ServerName .morningminerals.com
ServerAlias .morningminerals.com
ProxyPreserveHost On
ProxyErrorOverride On
DocumentRoot /home/akira/www/cce
Order allow,deny
Allow from all
ProxyPass /images !
ProxyPass /robots.txt !
ProxyPass /css !
ProxyPass /js !
.morningminerals.com>
Order allow,deny
Allow from all
ProxyPass / http://localhost:8222/
ProxyPassReverse / http://localhost:8222/
Without the added green directive it won't load the bootstrap files located in documentroot.
Also, the domain/host must specified in each individual vhost's conf or only one of them works ;-)
Re: [ANNOUNCE] Abe 0.7: Open Source Block Explorer Knockoff
It is more or less done. What's left was just a few string for the pages served to the user and invert the sign of the minted value.
Bitcore v0.1.18 has this issue:
{ '0': 'livenet', '1': '1 of 1 peers connected' }
{ '0': 'livenet', '1': '1 of 1 peers connected' }
{ '0': 'livenet', '1': '1 of 1 peers connected' }
FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory
Aborted
npm ERR! weird error 134
npm WARN This failure might be due to the use of legacy binary "node"
npm WARN For further explanations, please read
/usr/share/doc/nodejs/README.Debian
npm ERR! not ok code
But we shouldn't discuss this in this in John's thread. It's completely off-topic. I already raised this on Github and labs.bitpay.com
I stick with ABE: It serves its purpose well and is quite elegant in its use
And if you don't like the look & feel it has, you can immitate Insight's. I believe someone already did this by the way, using bootstrap.
Bitcore v0.1.18 has this issue:
{ '0': 'livenet', '1': '1 of 1 peers connected' }
{ '0': 'livenet', '1': '1 of 1 peers connected' }
{ '0': 'livenet', '1': '1 of 1 peers connected' }
FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory
Aborted
npm ERR! weird error 134
npm WARN This failure might be due to the use of legacy binary "node"
npm WARN For further explanations, please read
/usr/share/doc/nodejs/README.Debian
npm ERR! not ok code
But we shouldn't discuss this in this in John's thread. It's completely off-topic. I already raised this on Github and labs.bitpay.com
I stick with ABE: It serves its purpose well and is quite elegant in its use
And if you don't like the look & feel it has, you can immitate Insight's. I believe someone already did this by the way, using bootstrap.That sounds like you ran out of RAM, is this being ran on a small vps?
Re: [ANNOUNCE] Abe 0.7: Open Source Block Explorer Knockoff
It is more or less done. What's left was just a few string for the pages served to the user and invert the sign of the minted value.
Bitcore v0.1.18 has this issue:
{ '0': 'livenet', '1': '1 of 1 peers connected' }
{ '0': 'livenet', '1': '1 of 1 peers connected' }
{ '0': 'livenet', '1': '1 of 1 peers connected' }
FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory
Aborted
npm ERR! weird error 134
npm WARN This failure might be due to the use of legacy binary "node"
npm WARN For further explanations, please read
/usr/share/doc/nodejs/README.Debian
npm ERR! not ok code
But we shouldn't discuss this in this in John's thread. It's completely off-topic. I already raised this on Github and labs.bitpay.com
I stick with ABE: It serves its purpose well and is quite elegant in its use And if you don't like the look & feel it has, you can immitate Insight's. I believe someone already did this by the way, using bootstrap.
Bitcore v0.1.18 has this issue:
{ '0': 'livenet', '1': '1 of 1 peers connected' }
{ '0': 'livenet', '1': '1 of 1 peers connected' }
{ '0': 'livenet', '1': '1 of 1 peers connected' }
FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory
Aborted
npm ERR! weird error 134
npm WARN This failure might be due to the use of legacy binary "node"
npm WARN For further explanations, please read
/usr/share/doc/nodejs/README.Debian
npm ERR! not ok code
But we shouldn't discuss this in this in John's thread. It's completely off-topic. I already raised this on Github and labs.bitpay.com
I stick with ABE: It serves its purpose well and is quite elegant in its use
And if you don't like the look & feel it has, you can immitate Insight's. I believe someone already did this by the way, using bootstrap.Thank for your reply. I got over exited today because of passing a screening for a job I'd really like to do, hence the stupid questions.
The client I use doesn't have a hashrate field to be returned and that's indeed what went wrong. Peers and richlist are now populated as well.
I'll do the webserver part sometime tomorrow or the following days. So far I love OS CCE v4.0. You've created a fantastic piece of software m(._.)m
Concerning InnoDB vs MariaDB, there is not much I can do about it, except install a private instance of mysql on the VPS. The offloaded DB is running as:
mysql Ver 14.14 Distrib 5.5.43, for debian-linux-gnu (x86_64) using readline 6.3
Connection id: 25126661
Current database:
Current user: mine1_cce@23.92.65.26
SSL: Not in use
Current pager: stdout
Using outfile: ''
Using delimiter: ;
Server version: 5.5.5-10.0.14-MariaDB-1~precise-log mariadb.org binary distribution
Protocol version: 10
Connection: daldb.vpsdime.com via TCP/IP
Server characterset: latin1
Db characterset: latin1
Client characterset: utf8
Conn. characterset: utf8
TCP port: 3306
Uptime: 5 days 8 hours 42 min 20 sec
I thought it was InnoDB due to the engine being set to default:
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
| Engine | Support | Comment | Transactions | XA | Savepoints |
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
| CSV | YES | CSV storage engine | NO | NO | NO |
| MRG_MyISAM | YES | Collection of identical MyISAM tables | NO | NO | NO |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO |
| BLACKHOLE | YES | /dev/null storage engine (anything you write to it disappears) | NO | NO | NO |
| MyISAM | YES | MyISAM storage engine | NO | NO | NO |
| InnoDB | DEFAULT | Percona-XtraDB, Supports transactions, row-level locking, and foreign keys | YES | YES | YES |
| ARCHIVE | YES | Archive storage engine | NO | NO | NO |
| FEDERATED | YES | FederatedX pluggable storage engine | YES | NO | YES |
| PERFORMANCE_SCHEMA | YES | Performance Schema | NO | NO | NO |
| Aria | YES | Crash-safe tables with MyISAM heritage | NO | NO | NO |
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
The reported SQL error ... will it break something in the fuctionality or stability while running your block explorer?
The client I use doesn't have a hashrate field to be returned and that's indeed what went wrong. Peers and richlist are now populated as well.
I'll do the webserver part sometime tomorrow or the following days. So far I love OS CCE v4.0. You've created a fantastic piece of software m(._.)m
Concerning InnoDB vs MariaDB, there is not much I can do about it, except install a private instance of mysql on the VPS. The offloaded DB is running as:
mysql Ver 14.14 Distrib 5.5.43, for debian-linux-gnu (x86_64) using readline 6.3
Connection id: 25126661
Current database:
Current user: mine1_cce@23.92.65.26
SSL: Not in use
Current pager: stdout
Using outfile: ''
Using delimiter: ;
Server version: 5.5.5-10.0.14-MariaDB-1~precise-log mariadb.org binary distribution
Protocol version: 10
Connection: daldb.vpsdime.com via TCP/IP
Server characterset: latin1
Db characterset: latin1
Client characterset: utf8
Conn. characterset: utf8
TCP port: 3306
Uptime: 5 days 8 hours 42 min 20 sec
I thought it was InnoDB due to the engine being set to default:
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
| Engine | Support | Comment | Transactions | XA | Savepoints |
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
| CSV | YES | CSV storage engine | NO | NO | NO |
| MRG_MyISAM | YES | Collection of identical MyISAM tables | NO | NO | NO |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO |
| BLACKHOLE | YES | /dev/null storage engine (anything you write to it disappears) | NO | NO | NO |
| MyISAM | YES | MyISAM storage engine | NO | NO | NO |
| InnoDB | DEFAULT | Percona-XtraDB, Supports transactions, row-level locking, and foreign keys | YES | YES | YES |
| ARCHIVE | YES | Archive storage engine | NO | NO | NO |
| FEDERATED | YES | FederatedX pluggable storage engine | YES | NO | YES |
| PERFORMANCE_SCHEMA | YES | Performance Schema | NO | NO | NO |
| Aria | YES | Crash-safe tables with MyISAM heritage | NO | NO | NO |
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
The reported SQL error ... will it break something in the fuctionality or stability while running your block explorer?
Re: [ANNOUNCE] Abe 0.7: Open Source Block Explorer Knockoff
No disrespect to altcoins but are you saying that insight is pretty *stable* for bitcoin? Or do we have similar issues with bitcoin as well?
I think it's okay to state that Insight is stable for Bitcoin and safe to use as it's intended for Bitcoin in the first place and Bitpay's business after all. Altcoin support is basically a bunch of hacks that work for some and doesn't for others. POS is basically not supported at all. That being said, they are moving from Bitcore to Bitnode for the fundamentals of their products. I didn't have a look at it, but the way bitcore has evolved over time, altcoins might be a definite no-go with this explorer.The issue I have is probably specific to the version I use. If I take a more recent version in my case, it's back from scratch and the success rate might just be as miserable.
Hello \(^_^)/
The whole blockchain got loaded
I've got some questions concerning how to continue now:
After it finished, it calls the statistics module:
This statistics steps in incredibly fast, so I was kind of suspicious that it did it's job.
Unlike the other modules, it didn't create a log file and I only have these:
When I launch python websrv.py, I can only connect to it using lynx localhost:8222 (I did not setup Apache yet, as it's currently serving Abe)
Shouldn't I be able to connect from a remote client as well even without Apache involved? Opening this port 8222 in iptables doesn't change its behaviour.
server.log contains:
Using this text based browser, I noticed that the peers and richlist pages are not populated.
I believe the last lines in comm.log are from this statistics module:
I can query the table address and it looks completely filled as one would expect.
The whole blockchain got loaded
I've got some questions concerning how to continue now:
After it finished, it calls the statistics module:
Code:
akira@Mineralscoin:~/CCE$ python dbload.py -v -l
Processing Block: 1749237 of 1749236
Calling Statistics Module
Database load complete
Processing Block: 1749237 of 1749236
Calling Statistics Module
Database load complete
This statistics steps in incredibly fast, so I was kind of suspicious that it did it's job.
Unlike the other modules, it didn't create a log file and I only have these:
- comm.log
- loader.log
- server.log
When I launch python websrv.py, I can only connect to it using lynx localhost:8222 (I did not setup Apache yet, as it's currently serving Abe)
Shouldn't I be able to connect from a remote client as well even without Apache involved? Opening this port 8222 in iptables doesn't change its behaviour.
server.log contains:
Code:
[29/Jun/2015:11:18:35] ENGINE Daemonized to PID: 11612
[29/Jun/2015:11:18:35] ENGINE Started monitor thread '_TimeoutMonitor'.
[29/Jun/2015:11:18:35] ENGINE PID 11612 written to '/home/akira/CCE/cherrypy.pid'.
[29/Jun/2015:11:18:35] ENGINE Serving on 127.0.0.1:8222
[29/Jun/2015:11:18:35] ENGINE Bus STARTED
[29/Jun/2015:11:18:35] ENGINE Started monitor thread '_TimeoutMonitor'.
[29/Jun/2015:11:18:35] ENGINE PID 11612 written to '/home/akira/CCE/cherrypy.pid'.
[29/Jun/2015:11:18:35] ENGINE Serving on 127.0.0.1:8222
[29/Jun/2015:11:18:35] ENGINE Bus STARTED
Using this text based browser, I noticed that the peers and richlist pages are not populated.
I believe the last lines in comm.log are from this statistics module:
Code:
ERROR:root:06-29 16:25:05 (1064, u"You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ': '74.15099844', u'proof-of-stake': '0.00024414'}' at line 1") : query no return
ERROR:root:06-29 16:25:05 UPDATE stats SET curr_diff = %s : query no return
ERROR:root:06-29 16:25:05 'networkhashps' : General stat module error
ERROR:root:06-29 16:25:05 UPDATE stats SET curr_diff = %s : query no return
ERROR:root:06-29 16:25:05 'networkhashps' : General stat module error
I can query the table address and it looks completely filled as one would expect.
How much space does the DB require?
Guess I'll just have to test in on the VPS this weekend. My test VM with 16GB storage ran out of diskspace after ~800k blocks.
Also, I can't find a way to specity the mysql host in the configuration file. Does it absolutely need a local mysql server to function? I'd prefer using a remote mysqldb that could handle all the queries more easily.Can I change the host address in comm.py without breaking it?
Changed the host and it works with a remote server
Lol... with abe it was a little harder to get this working...
Lookin' forward to a completely loaded DB \(^_ ^)/
Guess I'll just have to test in on the VPS this weekend. My test VM with 16GB storage ran out of diskspace after ~800k blocks.
Also, I can't find a way to specity the mysql host in the configuration file. Does it absolutely need a local mysql server to function? I'd prefer using a remote mysqldb that could handle all the queries more easily.
Code:
conn = pymysql.connect(db=CONFIG["database"]["dbname"], host='127.0.0.1', port=3306, user=CONFIG["database"]["dbuser"],passwd=CONFIG["database"]["dbpassword"])
Changed the host and it works with a remote server
Lol... with abe it was a little harder to get this working...
Lookin' forward to a completely loaded DB \(^_ ^)/
Thank you for replying dreamwatcher
I've doubled the amount of RAM for the VM and it did accelerate the process. It loaded over 200000 blocks the past half hour.
I must agree with you that the daemon and qt wallet is very slow. Changing the rpc timeout to 60 seconds in comm.py and the deamon's config also seems to have a positive effect.
We discovered that our coin was forked from Hackcoin and have managed to more or less clean the code and take control, but that never solved the performance issues. In fact, it has been like this since the beginning and staking puts a considerable amount of stress on the system, which shouldn't happen. I'm working with a coin that has been abandoned by the original developer and the two of us trying to keep it afloat, are no developers.
The VM is basically running on top of a computer that I used for mining altcoins last year. I extended the memory to 16GB, but the CPU is still the old one, an Intel Celeron G1610, which probably acts as a bottleneck for quite demanding processes. I intend on replacing it soon.
The VPS that runs bitcoin-abe atm is a 4 vCPU VM with 6GB RAM and 30GB SSD storage and has an offloaded MySQL DB running on Dual E5 2620 CPUs, 384GB RAM and 8 x 480GB SSD on RAID10. I don't worry about its performance in running CCE.
It's just that before deploying something, I tend to test it first and see what I can expect
The things like the rich list and largest tx... is that processed after all the blocks are loaded or when invoking stats.py? I imagine it will take some time to process it on 1.7M blocks.
I've doubled the amount of RAM for the VM and it did accelerate the process. It loaded over 200000 blocks the past half hour.
I must agree with you that the daemon and qt wallet is very slow. Changing the rpc timeout to 60 seconds in comm.py and the deamon's config also seems to have a positive effect.
We discovered that our coin was forked from Hackcoin and have managed to more or less clean the code and take control, but that never solved the performance issues. In fact, it has been like this since the beginning and staking puts a considerable amount of stress on the system, which shouldn't happen. I'm working with a coin that has been abandoned by the original developer and the two of us trying to keep it afloat, are no developers.
The VM is basically running on top of a computer that I used for mining altcoins last year. I extended the memory to 16GB, but the CPU is still the old one, an Intel Celeron G1610, which probably acts as a bottleneck for quite demanding processes. I intend on replacing it soon.
The VPS that runs bitcoin-abe atm is a 4 vCPU VM with 6GB RAM and 30GB SSD storage and has an offloaded MySQL DB running on Dual E5 2620 CPUs, 384GB RAM and 8 x 480GB SSD on RAID10. I don't worry about its performance in running CCE.
It's just that before deploying something, I tend to test it first and see what I can expect
The things like the rich list and largest tx... is that processed after all the blocks are loaded or when invoking stats.py? I imagine it will take some time to process it on 1.7M blocks.
Hi
Thanks again for the PM. I finally managed to get some time to give OS-CCE a try.
Configuring your explorer is really a piece of cake. Great!
I took a me a minute to realize I had to manually create the tables using mysql cce -u -p < newdb.sql
Contrary to Bitcoin-abe, it seems that loading the DB with ./dbload.py -n -v is much slower?
It takes like 10 minutes to load 1000 blocks on a virtual machine with Ubuntu Server 14.04 with 2GB RAM. Does it heavily rely on RAM? I might have to increase it?
Another reason I can think of is the checking back 250 blocks to detect orphaned blocks? This might be too far in the past for my coin? My blockchain has over 1.7 million blocks (just over 1 year old)
Or is this due to me having reniced the wallet daemon to "19"? It's a habit I took while working with VPS servers as these companies often don't like high loads and will charge you for it or terminate your contract.
Anyway, I'm looking forward to the day it's synched to see what it's going to be like \(^_^)/
Hmmz... I had to restart dbload ..
A little later: ~1000 blocks
Or
I'm confused now
Edit:Looks like it's solved by adding the -l argument.
Thanks again for the PM. I finally managed to get some time to give OS-CCE a try.
Configuring your explorer is really a piece of cake. Great!
I took a me a minute to realize I had to manually create the tables using mysql cce -u -p < newdb.sql
Contrary to Bitcoin-abe, it seems that loading the DB with ./dbload.py -n -v is much slower?
It takes like 10 minutes to load 1000 blocks on a virtual machine with Ubuntu Server 14.04 with 2GB RAM. Does it heavily rely on RAM? I might have to increase it?
Another reason I can think of is the checking back 250 blocks to detect orphaned blocks? This might be too far in the past for my coin? My blockchain has over 1.7 million blocks (just over 1 year old)
Or is this due to me having reniced the wallet daemon to "19"? It's a habit I took while working with VPS servers as these companies often don't like high loads and will charge you for it or terminate your contract.
Anyway, I'm looking forward to the day it's synched to see what it's going to be like \(^_^)/
Hmmz... I had to restart dbload ..
Code:
akira@positron:~/CCE$ ./dbload.py -n -v
Processing Block: 6368 of 1637812
Main Loop cannot concatenate 'str' and 'int' objects
akira@positron:~/CCE$ ./dbload.py -v
Recheck Called
Processing Block: 7188 of 1637812
Processing Block: 6368 of 1637812
Main Loop cannot concatenate 'str' and 'int' objects
akira@positron:~/CCE$ ./dbload.py -v
Recheck Called
Processing Block: 7188 of 1637812
A little later: ~1000 blocks
Code:
Processing Block: 10192 of 1637812
Main Loop (1062, u"Duplicate entry '-1' for key 'PRIMARY'")
Main Loop (1062, u"Duplicate entry '-1' for key 'PRIMARY'")
Or
Code:
Processing Block: 13430 of 1637812
Main Loop sequence index must be integer, not 'str'
Main Loop sequence index must be integer, not 'str'
I'm confused now
Edit:
Re: [ANNOUNCE] Abe 0.7: Open Source Block Explorer Knockoff
Ufff, people still fight with getting old Abe to work?
Why not use something simple to install like Insight or RPC Ace?
Why not use something simple to install like Insight or RPC Ace?
Insight is quite a challenging or rather problematic block explorer to set up.
In the the newer versions of bitcore it's even more unclear where to go to re-configure it to match your coin's properties if you already managed to change it from SHA to whatever algo your coin uses.
Those using older insight/insight-api/bitcore versions which were easier to configure, will notice that Insight runs no longer than 15 minutes before losing its connections to the insight api/bitcore due to a memory leak, stalling the Node process and ultimately clogging up the whole server if not restarted right after the 'crash'. I guess it's doable with enough resources, time and effort. The Reddcoin and Startcoin team managed to get it done. Startcoin crowdfunded the conversion to X11 POW for START on Startjoin to get a pro do it for them. I don't know about Reddcoin's team though.
Furthermore, Bitpay ignores every single "issue" on Github or question asked on their Labs forum if you even dare to include the word altcoin or a subject that is something else than Bitcoin concerning their products. I'm waiting for over a month now concerning this memory leak. They don't even take 5 seconds to tell you to fuck off with your altcoin. Nothing. I find this quite disrespectful. You are free to choose not to support users who use your product in a different way than intended, but at least have the decency to write a statement about it and put it on the website or the fine print at the bottom: "We do not support altcoins". Is that too difficult?
Until they embrace altcoins or that a skilled developer decides to build a universal block explorer, Abe is basically the only accessible block explorer we have.
I'm back with a question ;-)
I didn't run my testnet for several weeks while looking into other things, such as getting Bitpay's Insight to work with X11.
Tonight, I wanted to check something on my private testnet and when I launched the wallet, it crashed with that assertion fault many altcoins have at launch and where they told you to delete the whole shebang except for wallet.dat:
I could salvage it by running this command instead of deleting everything:
What would cause GetStakeModifierChecksum to fail? The hash on May 1 is still the same on June 1, so it should be able to process that assert command correctly?
Is there an altcoin that actually solved it? From what I could find, the crash is something first introduced by Peercoin, which is a serious crypto.
I didn't run my testnet for several weeks while looking into other things, such as getting Bitpay's Insight to work with X11.
Tonight, I wanted to check something on my private testnet and when I launched the wallet, it crashed with that assertion fault many altcoins have at launch and where they told you to delete the whole shebang except for wallet.dat:
Code:
Wallets/xyzcoin/xyzcoin-qt -conf=home/akira/.xyzcoin/xyzcoinTestnet.conf -datadir=/home/akira/.xyzcoin/testnet-1/ -testnet=1 -irc=0 -dnsseed=0
xyzcoin-qt: src/kernel.cpp:372: unsigned int GetStakeModifierChecksum(const CBlockIndex*): Assertion `pindex->pprev || pindex->GetBlockHash() == (!fTestNet ? hashGenesisBlock : hashGenesisBlockTestNet)' failed.
Aborted
xyzcoin-qt: src/kernel.cpp:372: unsigned int GetStakeModifierChecksum(const CBlockIndex*): Assertion `pindex->pprev || pindex->GetBlockHash() == (!fTestNet ? hashGenesisBlock : hashGenesisBlockTestNet)' failed.
Aborted
I could salvage it by running this command instead of deleting everything:
Code:
Wallets/xyzcoin/xyzcoin-qt -conf=home/akira/.xyzcoin/xyzcoinTestnet.conf -datadir=/home/akira/.xyzcoin/testnet-1/ -testnet=1 -irc=0 -dnsseed=0 -loadblock=/home/akira/.xyzcoin/testnet-1/blk0001.dat
The wallet load the blocks, then closes without my intervention. After relaunching it with the first command, everything is up & running.What would cause GetStakeModifierChecksum to fail? The hash on May 1 is still the same on June 1, so it should be able to process that assert command correctly?
Is there an altcoin that actually solved it? From what I could find, the crash is something first introduced by Peercoin, which is a serious crypto.
Re: [ANN] GridPay | Gate Keeper Multi-Platform Node.js wallet | Merchant API | NFC !
This is very disgusting
+1What on earth happened here?
is there a definite list of all the coins using Blackcoin PoS2.0 ? Noticed that there are alot of altcoins both old and new that are now using or changing their code to implement PoS2.0 but would be interesting to see a list of them somewhere
Are you going to add POS v2.0 to DIG?Re: [ANNOUNCE] Abe 0.7: Open Source Block Explorer Knockoff
Hello
I've migrated my super node and dns seed to a high performance VPS. The last thing to do is moving bitcoin-abe.
Because my host gave me an offloaded mysql database, I couldn't import the SQL files genereted by mysqldump due to not having mysql "super privileges".
The only option left is rebuilding the database. This seems to fail unfortunately:
The connect-args are:
Although I can connect with the mysql command to my database, bitcoin-abe seems to be obstinately trying to connect using a unix socket. How is that even possible? If you don't give a remote server's IP, leave it empty or just enter 127.0.0.1 or localhost, it connects to the local MySQL DB by default, using the socket, but as soon as you specify and IP address, it should connect over TCP. Unless I misread the error log above, it still want to connect to a local MySQL DB? How do you use bitcoin-abe with a remote database?
I've migrated my super node and dns seed to a high performance VPS. The last thing to do is moving bitcoin-abe.
Because my host gave me an offloaded mysql database, I couldn't import the SQL files genereted by mysqldump due to not having mysql "super privileges".
The only option left is rebuilding the database. This seems to fail unfortunately:
Code:
python -m Abe.abe --config minerals-abe/abe-min.conf --commit-bytes 100000 --no-serve
Reconnecting after rollback error: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)")
Reconnecting to database.
Reconnecting after rollback error: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)")
Reconnecting to database.
Reconnecting after rollback error: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)")
Reconnecting to database.
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/usr/local/lib/python2.7/dist-packages/Abe/abe.py", line 2101, in
sys.exit(main(sys.argv[1:]))
File "/usr/local/lib/python2.7/dist-packages/Abe/abe.py", line 2095, in main
store = make_store(args)
File "/usr/local/lib/python2.7/dist-packages/Abe/abe.py", line 159, in make_store
store = DataStore.new(args)
File "/usr/local/lib/python2.7/dist-packages/Abe/DataStore.py", line 3277, in new
return DataStore(args)
File "/usr/local/lib/python2.7/dist-packages/Abe/DataStore.py", line 187, in __init__
store.initialize()
File "/usr/local/lib/python2.7/dist-packages/Abe/DataStore.py", line 629, in initialize
store.configure()
File "/usr/local/lib/python2.7/dist-packages/Abe/DataStore.py", line 927, in configure
config = store._sql.configure()
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 614, in configure
sql.configure_ddl_implicit_commit()
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 699, in configure_ddl_implicit_commit
if sql._test_ddl():
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 706, in _test_ddl
sql.drop_table_if_exists("%stest_1" % sql.prefix)
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 677, in drop_table_if_exists
sql._drop_if_exists("TABLE", obj)
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 674, in _drop_if_exists
sql.rollback()
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 603, in rollback
sql.reconnect()
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 292, in reconnect
return sql.conn()
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 275, in conn
sql._conn = sql.connect()
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 233, in connect
conn = sql.module.connect()
File "/usr/lib/python2.7/dist-packages/MySQLdb/__init__.py", line 81, in Connect
return Connection(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 187, in __init__
super(Connection, self).__init__(*args, **kwargs2)
_mysql_exceptions.OperationalError: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)")
Reconnecting after rollback error: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)")
Reconnecting to database.
Reconnecting after rollback error: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)")
Reconnecting to database.
Reconnecting after rollback error: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)")
Reconnecting to database.
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/usr/local/lib/python2.7/dist-packages/Abe/abe.py", line 2101, in
sys.exit(main(sys.argv[1:]))
File "/usr/local/lib/python2.7/dist-packages/Abe/abe.py", line 2095, in main
store = make_store(args)
File "/usr/local/lib/python2.7/dist-packages/Abe/abe.py", line 159, in make_store
store = DataStore.new(args)
File "/usr/local/lib/python2.7/dist-packages/Abe/DataStore.py", line 3277, in new
return DataStore(args)
File "/usr/local/lib/python2.7/dist-packages/Abe/DataStore.py", line 187, in __init__
store.initialize()
File "/usr/local/lib/python2.7/dist-packages/Abe/DataStore.py", line 629, in initialize
store.configure()
File "/usr/local/lib/python2.7/dist-packages/Abe/DataStore.py", line 927, in configure
config = store._sql.configure()
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 614, in configure
sql.configure_ddl_implicit_commit()
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 699, in configure_ddl_implicit_commit
if sql._test_ddl():
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 706, in _test_ddl
sql.drop_table_if_exists("%stest_1" % sql.prefix)
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 677, in drop_table_if_exists
sql._drop_if_exists("TABLE", obj)
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 674, in _drop_if_exists
sql.rollback()
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 603, in rollback
sql.reconnect()
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 292, in reconnect
return sql.conn()
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 275, in conn
sql._conn = sql.connect()
File "/usr/local/lib/python2.7/dist-packages/Abe/SqlAbstraction.py", line 233, in connect
conn = sql.module.connect()
File "/usr/lib/python2.7/dist-packages/MySQLdb/__init__.py", line 81, in Connect
return Connection(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 187, in __init__
super(Connection, self).__init__(*args, **kwargs2)
_mysql_exceptions.OperationalError: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)")
The connect-args are:
Code:
connect-args {"user":"XXX","db":"XXX","passwd":"XXX","host":"19X.2X1.X5X.X4X","port":3306}
Although I can connect with the mysql command to my database, bitcoin-abe seems to be obstinately trying to connect using a unix socket. How is that even possible? If you don't give a remote server's IP, leave it empty or just enter 127.0.0.1 or localhost, it connects to the local MySQL DB by default, using the socket, but as soon as you specify and IP address, it should connect over TCP. Unless I misread the error log above, it still want to connect to a local MySQL DB? How do you use bitcoin-abe with a remote database?
well i must confess i couldnt derive any information from this testnest forum thank you a more simplified version would do
In what way would you want to see this simplified? I don't think it can be simplified? I dived into the code and try to figure out things by tinkering with it.@Yarkol: I found out for the alerts on my testnet
It's not the client version but effectively the protocol version as mentionned in Bitcoin's alert_test.
Thanks you for explaining
If I understand it correctly, it means that I have to make the sum of
static const int CLIENT_VERSION =
1000000 * CLIENT_VERSION_MAJOR
+ 10000 * CLIENT_VERSION_MINOR
+ 100 * CLIENT_VERSION_REVISION
+ 1 * CLIENT_VERSION_BUILD;
Which for clients v1.0.0.0 up to v1.1.0.0 would mean that the values of these variables are 1000000 and 10100000?
I created a new keypair for the testnet to try it out. I'm sure that part of the equation is correct.
If I understand it correctly, it means that I have to make the sum of
static const int CLIENT_VERSION =
1000000 * CLIENT_VERSION_MAJOR
+ 10000 * CLIENT_VERSION_MINOR
+ 100 * CLIENT_VERSION_REVISION
+ 1 * CLIENT_VERSION_BUILD;
Which for clients v1.0.0.0 up to v1.1.0.0 would mean that the values of these variables are 1000000 and 10100000?
I created a new keypair for the testnet to try it out. I'm sure that part of the equation is correct.
Today I took a look at the alert system and wanted to try it on my local tesnet.
For this exercise I generated a new key pair and took a look at the sendalert command. I struggled with minversion and maxversion first, not realizing it needs an interger value instead of string.
I finally figured it out and issued this command:
Which returned the following:
That looks okay, except for the nVersion being higher than nMaxVer:-X
And unfortunately for me, I don't see the message being propagated on the testnet. It's not bound to a block. I should be able to see the alert were it the that I used a higher nMaxVer, right? In the status bar of the QT client it's not visible and when issuing getinfo in the debug console, I can't see it either.
My guess is that I indeed made a mistake with nMinVer and nMaxVer.
What version does this value actually corresponds to? The protocol version or client version?
in version.h I can find different versions:
My first though was to retry the command, but raising nMaxVer to 60013.
Instead of issuing an alert, it gives me and error:
I'm a little confused here. Am I overseeing something?
For this exercise I generated a new key pair and took a look at the sendalert command. I struggled with minversion and maxversion first, not realizing it needs an interger value instead of string.
I finally figured it out and issued this command:
Code:
sendalert "Alert Message Test" "3082011302010104202ae345b4eb41db61fcb7aa8684a75e77386ca8c0861e4dde2dc200664017fb89a081a53081a2020101302c06072a8648ce3d0101022100fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f300604010004010704410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8022100fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141020101a144034200041b7d83afec586c91ac96a7a43aea2e1c7803bd6506c50f0658611908053a4198d8e1bc5278a57cc2866e0a2dad24feab40bb9efe8c986dc51ecec67f7e104c69" 60000 60000 1 1
Which returned the following:
Code:
{
"strStatusBar" : "Alert Message Test",
"nVersion" : 60013,
"nMinVer" : 60000,
"nMaxVer" : 60000,
"nPriority" : 1,
"nID" : 1
}
"strStatusBar" : "Alert Message Test",
"nVersion" : 60013,
"nMinVer" : 60000,
"nMaxVer" : 60000,
"nPriority" : 1,
"nID" : 1
}
That looks okay, except for the nVersion being higher than nMaxVer:-X
And unfortunately for me, I don't see the message being propagated on the testnet. It's not bound to a block. I should be able to see the alert were it the that I used a higher nMaxVer, right? In the status bar of the QT client it's not visible and when issuing getinfo in the debug console, I can't see it either.
My guess is that I indeed made a mistake with nMinVer and nMaxVer.
What version does this value actually corresponds to? The protocol version or client version?
in version.h I can find different versions:
Code:
//
// client versioning
//
static const int CLIENT_VERSION =
1000000 * CLIENT_VERSION_MAJOR
+ 10000 * CLIENT_VERSION_MINOR
+ 100 * CLIENT_VERSION_REVISION
+ 1 * CLIENT_VERSION_BUILD;
//
// network protocol versioning
//
static const int PROTOCOL_VERSION = 60013;
// earlier versions not supported as of Feb 2012, and are disconnected
static const int MIN_PROTO_VERSION = 209;
// nTime field added to CAddress, starting with this version;
// if possible, avoid requesting addresses nodes older than this
static const int CADDR_TIME_VERSION = 31402;
// only request blocks from nodes outside this range of versions
static const int NOBLKS_VERSION_START = 60002;
static const int NOBLKS_VERSION_END = 60006;
// BIP 0031, pong message, is enabled for all versions AFTER this one
static const int BIP0031_VERSION = 60000;
// "mempool" command, enhanced "getdata" behavior starts with this version:
static const int MEMPOOL_GD_VERSION = 60002;
// client versioning
//
static const int CLIENT_VERSION =
1000000 * CLIENT_VERSION_MAJOR
+ 10000 * CLIENT_VERSION_MINOR
+ 100 * CLIENT_VERSION_REVISION
+ 1 * CLIENT_VERSION_BUILD;
//
// network protocol versioning
//
static const int PROTOCOL_VERSION = 60013;
// earlier versions not supported as of Feb 2012, and are disconnected
static const int MIN_PROTO_VERSION = 209;
// nTime field added to CAddress, starting with this version;
// if possible, avoid requesting addresses nodes older than this
static const int CADDR_TIME_VERSION = 31402;
// only request blocks from nodes outside this range of versions
static const int NOBLKS_VERSION_START = 60002;
static const int NOBLKS_VERSION_END = 60006;
// BIP 0031, pong message, is enabled for all versions AFTER this one
static const int BIP0031_VERSION = 60000;
// "mempool" command, enhanced "getdata" behavior starts with this version:
static const int MEMPOOL_GD_VERSION = 60002;
My first though was to retry the command, but raising nMaxVer to 60013.
Instead of issuing an alert, it gives me and error:
Code:
sendalert "ALERT ALERT"
"3082011302010104202ae345b4eb41db61fcb7aa8684a75e77386ca8c0861e4dde2dc200664017fb89a081a53081a2020101302c06072a8648ce3d0101022100fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f300604010004010704410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8022100fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141020101a144034200041b7d83afec586c91ac96a7a43aea2e1c7803bd6506c50f0658611908053a4198d8e1bc5278a57cc2866e0a2dad24feab40bb9efe8c986dc51ecec67f7e104c69"
60000 60013 10 2 1
Failed to process alert.
(code -1)
"3082011302010104202ae345b4eb41db61fcb7aa8684a75e77386ca8c0861e4dde2dc200664017fb89a081a53081a2020101302c06072a8648ce3d0101022100fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f300604010004010704410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8022100fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141020101a144034200041b7d83afec586c91ac96a7a43aea2e1c7803bd6506c50f0658611908053a4198d8e1bc5278a57cc2866e0a2dad24feab40bb9efe8c986dc51ecec67f7e104c69"
60000 60013 10 2 1
Failed to process alert.
(code -1)
I'm a little confused here. Am I overseeing something?
I think "timestamp too early" problem is PoS problem. So Bitcoin won't be affected due to this.
[...]
NB: I am a newb to these things.
[...]
NB: I am a newb to these things.
I'm no expert either. This is like the first code I see since more than 8 years. I completely wasted my degree in computer science for other interests that didn't turn out to be career boosters at all, but that's another story
I'm getting very curious about how things work and I try to get some understanding. Even if it's far above my own level of comprehension, I give it a try :p
That being said, the link you gave me is an interesting post about this. I did look further and found out that this is not only a test run on POS coins. Bitcoin also has this check around lines 2559-2562 in main.cpp:
Code:
// Check timestamp against prev
if (block.GetBlockTime() <= pindexPrev->GetMedianTimePast())
return state.Invalid(error("%s: block's timestamp is too early", __func__),
REJECT_INVALID, "time-too-old");
if (block.GetBlockTime() <= pindexPrev->GetMedianTimePast())
return state.Invalid(error("%s: block's timestamp is too early", __func__),
REJECT_INVALID, "time-too-old");
I've also found coins, such as Nimbus, where for some reason they decided to comment out this check for POW and POS. This is apparently not a very good idea. Even bitcoin has newer blocks with earlier timestamps, which goes in against the logic. The protocol is designed to reject them.
I found this example on stackexchange:
Block #180966 with timestamp "2012-05-20 23:02:53" >> http://blockchain.info/block-height/180966
Block #180967 with timestamp "2012-05-20 23:02:13" >> http://blockchain.info/block-height/180967
This here ("Timejacking & Bitcoin") is an interesting article about timestamps and possible exploits if
not being taken care of correctly. Thus, removing the check is a no-go. Did nimbus ever block chain problems by ignoring the timestamp check? That's a coin I didn't bother mining last year.
Stackexchange user Chris Moore summarized it as
Quote
The protocol rejects blocks with a timestamp earlier than the median of the timestamps from the previous 11 blocks or later than 2 hours after the current network time. Any other timestamp is acceptable. Note that 'network time' may differ from the actual time, since the bitcoin network attempts to correct for incorrect clock settings by taking the median of the time reported by all connected peers as the network time.
I think it makes sense. After this 2 hours, of not mining, the last block known by the two clients was indeed too old to be accepted. Restarting the clients, gave them the new and actual time, after which mining could be resumed as it met the time requirements again.
I did turn of mining for ~1 hour, and both cpuminers could proceed where they left of.
To confirm this time on the network requirement, I will stop mining again for 2 hours or more (time to watch a movie ;-) or go for an evening walk) and see if the blocks will be rejected again. If they do, I'll restart one of the two clients and see what happens. I think both miners will resume operation as soon as one of the clients refreshes its timestamp on the testnet network.
No, but X11 implementation requires an external miner.
Okay. That explains why it didn't work ^^"