Also, I wonder whether a default mempool size is too small for a large number of unconfirmed transactions, hence the "not synced' message on the client which appears during slow block periods...?
Hopefully all this improves in 21 blocks from now.
I'm having extreme performance troubles with blockexplorer.auroracoin.eu. The only thing that solves it (for a while) is to re-load the whole blockchain and rebuild bitcoin-abe database. I think it has to do with the mempool transactions. Same with auroraexplorer.atorox.net. It seems to get problems if amount of not-verified transactions gets over ~1000. It helps to keep auroracoind offline or restart it every now and then. I described the problem in the bitcoin-abe thread. Does description fit what is happening on your side? |
|
|
|
I have a question about mempool transactions regarding performance: So I'm running http://blockexplorer.auroracoin.eu and because I have allocated quite a machine to the task everything has been zappy and fine this morning. However when I checked back from work an hour later I saw loads of exceptions saying "error: [Errno 32] Broken pipe", the nginx I have in front reporting gateway timeouts. I'm hypothesizing the db queries are the bottleneck. I tried rebuilding the database (drop it completely and rebuild)... that didn't help, it started again right away. There are loads of mempool transactions in AURoracoin because we're being pool-hopping-attacked to the point where there hasn't been a block for 6 hours or so. Another instance I run with same setup, but on quite weak machine (vm) was able to cope with the load quite well and didn't suffer broken pipes. What fixed it was to re-initialize BOTH the blockchain of the AuroraCoind AND the db (just db didn't help). Now the question: how are mempool transactions handled and could the existance of many mempool transactions have considerable impact on db (or abe.py) performance? I'm a bit confused... does anyone have an idea what could've been causing this? It could be transactions being left open, suboptimal SQL, or  If you have a collection of Python stack traces or database process lists from during the timeouts, they might point to the offender(s). This is the error
Exception happened during processing of request from ('178.63.69.203', 49828)
Traceback (most recent call last):
File "/usr/lib/python2.7/SocketServer.py", line 295, in _handle_request_noblock
self.process_request(request, client_address)
File "/usr/lib/python2.7/SocketServer.py", line 321, in process_request
self.finish_request(request, client_address)
File "/usr/lib/python2.7/SocketServer.py", line 334, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python2.7/SocketServer.py", line 651, in __init__
self.finish()
File "/usr/lib/python2.7/SocketServer.py", line 704, in finish
self.wfile.flush()
File "/usr/lib/python2.7/socket.py", line 303, in flush
self._sock.sendall(view[write_offset:write_offset+buffer_size])
error: [Errno 32] Broken pipe
(I think nginx (load-balancing here) or the client times out because it's taking too long) on AuroraCoind debug.log I see this:
22478 ThreadRPCServer method=getrawtransaction
22479 ThreadRPCServer method=getrawtransaction
22480 ThreadRPCServer method=getrawtransaction
22481 ThreadRPCServer method=getrawtransaction
22482 ThreadRPCServer method=getrawtransaction
22483 ThreadRPCServer method=getrawtransaction
22484 ThreadRPCServer method=getrawtransaction
22485 ThreadRPCServer method=getrawtransaction
22486 ThreadRPCServer method=getrawtransaction
22487 ThreadRPCServer method=getrawtransaction
22488 ThreadRPCServer method=getrawtransaction
22489 ThreadRPCServer method=getrawtransaction
22490 ThreadRPCServer method=getrawtransaction
22491 ThreadRPCServer method=getrawtransaction
22492 ThreadRPCServer method=getrawtransaction
22493 ThreadRPCServer method=getrawtransaction
22494 ThreadRPCServer method=getrawtransaction
22495 ThreadRPCServer method=getrawtransaction
22496 ThreadRPCServer method=getrawtransaction
22497 ThreadRPCServer method=getrawtransaction
22498 ThreadRPCServer method=getrawtransaction
22499 ThreadRPCServer method=getrawtransaction
22500 ThreadRPCServer method=getrawtransaction
22501 ThreadRPCServer method=getrawtransaction
22502 ThreadRPCServer method=getrawtransaction
22503 ThreadRPCServer method=getrawtransaction
22504 ThreadRPCServer method=getrawtransaction
about 500 per secondspsql> select * from pg_stat_activity; reports only one IDLE connection |
|
|
|
|
the "icelander should cpu-mine idea" is a drop in the bucket, I think. not enough hashing power.
paying for scrypt hashing power could work (either outright or using bounties for pools to find blocks < 5400).
The problem is: we're driving away the icelandic noobs who must think this coin is broken (which it is... confirmation times in the range of days can be called "broken", like banking system) or this crypto-stuff just doesn't work.. must be a fad.
|
|
|
|
The hard fork will made today??
probably not  . It's just 20 blocks to go, but we're really crawling. I doubt it's a timewarp attack. It's just the mining power leaving (multipools) because of too low profitability. Just wondering.. would it make any difference, if all Icelanders started to solo mine? pool-mining is ok (no problem), just not in a pool that will automatically have you mine the most profitable coin. |
|
|
|
molecular: You think balduro can manage/solve problems with time warp attack by BitcoinExpress?
quite honestly: I don't think the problems are a result from BitcoinExpress attack. It's just multipools on/off-ing us. Baldur's soltution is/was the hard-fork which will be effective block 5400. There's not much we can do except get miners to mine AUR and keep mining if we are. |
|
|
|
The hard fork will made today??
probably not . It's just 20 blocks to go, but we're really crawling. I doubt it's a timewarp attack. It's just the mining power leaving (multipools) because of too low profitability. |
|
|
|
last difficulty adjustment was from 1691.849 to 2406.9
That's more than 25%. Someone said the change was capped at 25%.
Can someone explain?
I made too quick conclusion: int64 nActualTimespanMax = ((nTargetTimespan*75)/50);
int64 nActualTimespanMin = ((nTargetTimespan*50)/75); That's not +-25%, it is +50% / -33% okay, thanks. |
|
|
|
last difficulty adjustment was from 1691.849 to 2406.9
That's more than 25%. Someone said the change was capped at 25%.
Can someone explain?
Another puzzle is that blocks generated with the same hashing power should only take twice as long for difficulty 2000 as it would for 1000. Yet blocks, when difficulty is 2000, seem to take about 10x longer to get created. So most of the hashing power must automatically desert the coin at >2000. Price/difficulty must be the factor for this. yes, of course. This is the multipools hopping to more profitable coins. At least that's the explanation I have. Also, I wonder whether a default mempool size is too small for a large number of unconfirmed transactions, hence the "not synced' message on the client which appears during slow block periods...?
Hopefully all this improves in 21 blocks from now.
I'm having extreme performance troubles with blockexplorer.auroracoin.eu. The only thing that solves it (for a while) is to re-load the whole blockchain and rebuild bitcoin-abe database. I think it has to do with the mempool transactions. |
|
|
|
|
last difficulty adjustment was from 1691.849 to 2406.9
That's more than 25%. Someone said the change was capped at 25%.
Can someone explain?
|
|
|
|
More like:
432607.2 Airdrop coins in circulation, 4.12% of a total 10,500,000 Airdrop coins.
Why isnt no multi-pool-patch applied?
block 5400, for christs sake  |
|
|
|
I want to learn programming but I'm extremely lazy. I took a course a few years back in college and it was really boring so I couldn't get into it. But it is an increasingly-useful skill in today's world.
Programming is difficult, but a very worthwhile challenge. You can keep reaching way above your current skill level. Programming is extremely tedious. It is boring unless you are extremely motivated and find the challenge interesting. I wrote about 800 LOC yesterday (not including whitespace nor comments). This is considered to be quite high. https://www.google.com.ph/search?q=average+LOC+per+dayI didn't think I could still do that. I used to be quite a prolific coder. For me, coding is most fun when at the end of the day I have less lines of code than at the beginning of the day. |
|
|
|
Thanks molecular for recording, I agree that it is "good enough". It's a pity that BXB staff didn't record the microphone...
It was a pleasure. Btw the image which you posted on previous page is gone...
fixed. Strange problems with btctalk image proxy. |
|
|
|
I want to blog about the Airdrop. Do you have a current number for me how many Coins already have been claimed by people of Iceland? Many thanks in advance!  326013.6 Airdrop coins in circulation, 3.1% of a total 10,500,000 Airdrop coins.
|
|
|
|
|
If the claims reported are valid (there are indications not all of them are), then AuroraCoin is already a huge success in terms of adoption by a large community... 1.7% is significant. Actually it's HUGE!
Now add to that a network effect in the coming months and we might be looking at something incredible.
I just hope people are using the android app so people can use AUR in their daily lives.
If adoption goes above 5%, my next holiday destination is booked.
|
|
|
|
cool, thanks! Biggest drawback is the audio quality imo, but it's bearable. Reminds me of bitcoin conference 2012 in London where the guy recording the audio from the microphone LOST ALL THE DATA so I could just throw away all the recorded video footage. fuck. hehe. |
|
|
|
It doesn't bother anyone that people in California and Australia are claiming the coins? Or that the ID number isn't only for Icelandic people? Or that there is an easily accessible database of 70,000 numbers that were hacked (i.e. I could probably go claim some coins right now. Actually....)...no doubt there is some widespread fraud here.
As far as I understood the process, first you input your Kennitala (and here anyone could copy/paste one) but then you need to confirm your ID by means of: -Facebook account, must be preexisting to Airdrop -SMS received on a icelandic phone So I don't think fraud is as simple as you make it out to be If it's true that most claims are not fraudulent then AuroraCoin is already a HUGE SUCCESS. Well over 1% of the population have claimed coins. That's above any kind of adoption rate we've seen so far, no? Congratulations are in order for balduro (given the claims are real). Thank you, man, for pulling this off. Well done. EDIT: Let's hope the fork works as intended... those block-times are unbearable. |
|
|
|
Just posted this on the auroracoin facebook page: Coins... currency, are social entities: They exist inside the web that is formed by humans and their relationships: work, debt, love, family, country county, taxes... etc. The "maturity" of a currency is attained through time as the relationships enumerated above start using channels, conduits. As such, the speed of adoption or repudiation of a currency is entirely dependent on the evolution of these relational webs, their utility as reservoirs of shared "trust/distrust". if the algorithm that facilitates the cripto revolution is sturdy, social webs will evolve and adapt to the transactional opportunities afforded by the "public ledger" of the criptocoins... But to expect that this evolution will happen overnight is to not understand how social webs evolve over time to adapt to new inputs; It is to be expected that Aur, -as BTC-. will go through plateau phases of valuation at the same time that an environment of con artists, merchants, speculators etc. will emerge to try to take advantage of the gullible or of those that have no patience or time or are in dire need of a few Krona. The experiment has started. The crucial element now, besides the distribution mechanism is the speed of adoption of the cripto as a transactional entity in this specific case of Iceland, but it also applies to all criptos. BTC is further down the road of maturity for the simple reason of its longevity (5 years since 10,000btc bought one pizza)... The "Character" of the icelandic community will be reflected on the gyrations of Aur. Good luck! https://www.facebook.com/groups/AuroraCoin/I agree and love the expression "cripto". One remark: Bitcoin might be further along, but AuroraCoin might overtake it because of the specifics of the community it targets. |
|
|
|
AUR can be a success if merchants learn how to accept it as payment before consumers learn how to dump the coins on exchanges.
The clock is ticking.
In other news.. AUR has disappeared off CMC?
..aaand it's gone. Just stale datapoints, since the block explorer is down. These slow blocks get a lot of transactions, looks like auroracoind gets jammed when there are enought of them.. I have to reset auroracoind every now and then.. Trying to keep this running: http://auroraexplorer.atorox.net/chain/AuroraCoinI've been having massive problems with bitcoin-abe. ([Broken Pipe]). I think it's related to mempool transactions (we've got many of these building up because we're finding no blocks) Reset of abe database hasn't helped. Having auroracoind reload the blockchain helped. Don't know what to make of it, asked in bitcoin-abe thread. |
|
|
|
I have a question about mempool transactions regarding performance: So I'm running http://blockexplorer.auroracoin.eu and because I have allocated quite a machine to the task everything has been zappy and fine this morning. However when I checked back from work an hour later I saw loads of exceptions saying "error: [Errno 32] Broken pipe", the nginx I have in front reporting gateway timeouts. I'm hypothesizing the db queries are the bottleneck. I tried rebuilding the database (drop it completely and rebuild)... that didn't help, it started again right away. There are loads of mempool transactions in AURoracoin because we're being pool-hopping-attacked to the point where there hasn't been a block for 6 hours or so. Another instance I run with same setup, but on quite weak machine (vm) was able to cope with the load quite well and didn't suffer broken pipes. What fixed it was to re-initialize BOTH the blockchain of the AuroraCoind AND the db (just db didn't help). Now the question: how are mempool transactions handled and could the existance of many mempool transactions have considerable impact on db (or abe.py) performance? I'm a bit confused... does anyone have an idea what could've been causing this? |
|
|
|
I've also added a population reach (currently 0.004% of Icelanders).
should be 0.4% |
|
|
|
|
Show Posts
