It would end up covered by all major media outlets. People all around the world would celebrate the event for a month. Marijuana would become legal everywhere. All fearmongers and warlords would suddenly wake up and admit they had no idea what they were doing. All manipulators and exploiters would realise we are all one. It would be a new golden age.
Mmmm... tempting. Will it also make Obama return the Nobel Peace Prize? If so, I'm sold!  |
|
|
|
Also, thumbs up for using client with Yak logo. I gather you're not going to add the new logo to http://yacexplorer.tk/ then?  Never!!!1  |
|
|
|
Looks like I found a PoS block last night.
Strange that the wallet does not correctly compute the PoS reward and shows 0.00 instead. Added to TODO. (Or does it after the stake matures?) Also, thumbs up for using client with Yak logo. "Recent transactions" should show PoS reward. Coins were returned to same address but with PoS reward added so balance was increased, not 0.0 I know it was increased, but the screenshot still says 0.00 YAC. That's my point. |
|
|
|
Looks like I found a PoS block last night.
Strange that the wallet does not correctly compute the PoS reward and shows 0.00 instead. Added to TODO. (Or does it after the stake matures?) Also, thumbs up for using client with Yak logo. |
|
|
|
Has anyone been able to replicate this issue?
Not me. |
|
|
|
So I've been looking at some debug logs and ran across something odd (at least I think it's odd). CheckStakeKernelHash() : using modifier 0xa9af09d37a300bb2 at height=154202 timestamp=2013-08-01 18:02:40 UTC for block from height=142294 timestamp=2013-07-23 20:44:31 UTC
CheckStakeKernelHash() : check protocol=0.3 modifier=0xa9af09d37a300bb2 nTimeBlockFrom=1374612271 nTxPrevOffset=81 nTimeTxPrev=1374612263 nPrevout=0 nTimeTx=1379486052 hashProof=000001ba7f7b71fa5eeec8b4e464342726fe1bef01cdd0db7b410b603be348b6
CheckStakeKernelHash() : using modifier 0x5618ea1f2889f8bd at height=77336 timestamp=2013-06-01 18:11:21 UTC for block from height=68725 timestamp=2013-05-23 18:53:33 UTC
CheckStakeKernelHash() : check protocol=0.3 modifier=0x5618ea1f2889f8bd nTimeBlockFrom=1369335213 nTxPrevOffset=81 nTimeTxPrev=1369335128 nPrevout=0 nTimeTx=1379486726 hashProof=000011f091518cf774ae3c71d88d4257dfed09c5ef6a63298adcc7c32f518b6b
CheckStakeKernelHash() : using modifier 0x30c0434569cf6ba7 at height=157536 timestamp=2013-08-04 00:02:43 UTC for block from height=145271 timestamp=2013-07-26 01:13:07 UTC
CheckStakeKernelHash() : check protocol=0.3 modifier=0x30c0434569cf6ba7 nTimeBlockFrom=1374801187 nTxPrevOffset=417 nTimeTxPrev=1374801169 nPrevout=0 nTimeTx=1379487196 hashProof=0005d78e8d8ddbee76bf1eeea0faf18d54dce5ca67f684621ae882f96189bf38
CheckStakeKernelHash() : using modifier 0xb116bb613840cfa9 at height=153484 timestamp=2013-08-01 06:03:45 UTC for block from height=141428 timestamp=2013-07-23 05:20:30 UTC
CheckStakeKernelHash() : check protocol=0.3 modifier=0xb116bb613840cfa9 nTimeBlockFrom=1374556830 nTxPrevOffset=419 nTimeTxPrev=1374556730 nPrevout=1 nTimeTx=1379487336 hashProof=00055edcf744bcecb45589548f6c6e84796aa2bb977fae305bd4db5ded2c9eac
Is it normal for old PoS block info to show up in the debug.log? It looks like it's trying to process these 4 blocks and it's been failing. One of these is from June 1st. O.o I think it's checking old PoS outputs being spent in current transactions, but I'm not sure. |
|
|
|
I'll try making some code tweaks to show this in GUI.
Hmm... The best I seem to come up with is adding an RPC call to determine if PoS miner thread was started. Dunno how to interact with the Qt gui from the bitcoind code (not a GUI coder). |
|
|
|
Hi Sairon.
I've got two "CPUMiner started for proof-of-stake" in my debug.log since I installed the CC version yesterday. The time-stamp at the top looks like it might be in UNIX time since it doesn't match mine. So the PoS minting seems to be working.
Does the CPUminer just not use much of the CPU to mine PoS blocks? It's still sitting at 1-3% CPU usage.
Yeah, it's just trying every now and then - computes one hash, checks if it's suitable for a PoS block and then slacks off for a while (half a second). (I've had it running for over 100 days on my server with no coins and it consumed just around 60 hours of CPU time.) |
|
|
|
Hi BitMega. I've had..
server=1
rpcuser=forsetifox
rpcpassword=coins
rpcallowip=192.168.*.*
rpcport=7687
maxconnections=24
In my yacoin.conf since the beginning. Adding "gen=0" will make it start to mine PoS blocks?
My CPU is at 1-2% usage right now. Doesn't seem to be working. =/
Dunno how you do it on Windows, but if you can manage to view process threads (and if Windows permits custom thread names), you will see a single thread named "bitcoin-miner" even if you're not PoW mining (if you are PoW mining in Yacoin-QT, then you'll see NUMBER_OF_CPUS + 1 bitcoin-miner threads) - this thread is the PoS miner. EDIT: or simply search debug.log file for "CPUMiner started for proof-of-stake". I'll try making some code tweaks to show this in GUI. |
|
|
|
8 connections are plenty if you're not a pool or a miner. I once tweaked the node on my block explorer server to have as much connections as possible (it was hovering around 130 IIRC), but I saw no actual benefit, so I closed the port in firewall and allowed only outbound connection (thus reducing the chance on potential attackers).
Network can't exist if everyone allow just outbound connections. True. However, I don't see myself reverting that decision as my VPS bill is 100% payment for I/O requests at the moment.  More connections = more block requests from peers = more I/O load on my server = higher upkeep cost for me. |
|
|
|
I'm assuming he meant a user-friendly clicky GUI thingy.  Not sure why that feat is removed in the first place?  No idea. BTW, we should really switch from BerkeleyDB to LevelDB... These client start-up times are driving me crazy. Why you think it is up to database? Bitcoin was using BerkeleyDB for years and even though blockchain size was in gigabytes and number of transactions far exceeded any other cryptocoin I never experienced as long startups as with YACoin. Most LTC and NVC "clones" start much faster than YACoin as well. Is there some kind of tool that could monitor what exactly is YACoin doing for those 6+ minutes at it's startup? I'm not certain it's the DB, but I inserted debug statements into the loading code and most of the time was spent loading the blockchain into memory. IMHO the main reason is the number of blocks (we will be on par with BTC pretty soon, and BTC switched to LevelDB AGES ago). Dunno about the other coins though. Also the loading algorithms might be heavily outdated and thus slow. That said, this needs further investigation and a fix ASAP. Some code references: * https://github.com/yacoin/yacoin/blob/master/src/init.cpp#L671 (the comment in particular) * https://github.com/yacoin/yacoin/blob/master/src/db.cpp#L824 (IIRC the slowest part of the code) * https://github.com/yacoin/yacoin/blob/master/src/db.cpp#L642 (some heavy-weight sanity checking, IIRC the second slowest part) * https://github.com/yacoin/yacoin/blob/master/src/db.cpp#L884 (maybe [but I'm really just guessing] this might be also a fairly slow operation, especially as the number of coin stakes will grow) Thanks! As a sidenote, I have YAC, XPM and BTC clients running on my computer, each with maxconnections=32 in .conf file. After 12 hours or so, the situation with number of nodes connected is usualy something like listed bellow. YACoin - 32 connections Bitcoin - 24 connections Primecoin - 12 connections No idea how to properly interpret that data though. One of the reasons why YACoin gets so much more connections could be the lack of UPnP with Coin Control versions (which I solved using PortMapper), e.g. nodes that connect to network after my node went online need to connect to other nodes to complete syncing but due to Coin Control nodes not being able to accept connections it is my node that ends up "slammed". FYI, I'm located at Eastern Europe. 8 connections are plenty if you're not a pool or a miner. I once tweaked the node on my block explorer server to have as much connections as possible (it was hovering around 130 IIRC), but I saw no actual benefit, so I closed the port in firewall and allowed only outbound connection (thus reducing the chance on potential attackers). Also, the code is smart enough to connect to different subnets to minimize the risk of connecting to "bad" nodes (eg. someone could spam your peer list with nodes that he controls - and they will usually fall into the same network subnet). So you might just happen to be one of only a few nodes in that particular network "area". |
|
|
|
Hi all, I have had a question I've wanted to ask for a while now. Is there a way of knowing how many active nodes/wallets are operating on the network? Has there been much fluctuation in the number of active wallets?
Determining the number of active nodes should be possible by either forcing your client to connect to an unlimited number of nodes and waiting a long time ( quick slow and dirty) OR you could parse the peers.dat file inside yacoin data directoy (where the yacoin.conf file is) and try pinging each IP from the list you get (may be inaccurate due to dropped ICMP packets on their firewall and whatnot) or better yet, connecting to the yacoin port (this might help against the firewall issue). But still, the nodes behind overly restrictive firewalls will appear as offline. So the best bet is to actually force the client to connect to all of them (and waiting, waiting, waiting...). Heh, so actually you can read the number of peers in the peers.dat file by looking at debug.log file: Flushed 13214 addresses to peers.dat 114ms
I've also modified the source to output these addresses in plaintext format. Working on gathering more info (last seen, etc...), then I might publish a KML file with approximate location of these IP addresses and their status (online/offline) so it could be viewed as an overlay in Google Maps/Earth. EDIT: Done! https://maps.google.com/maps?q=http://yacexplorer.tk/static/peers.kml You can get the raw files here http://yacexplorer.tk/graphs.htm#statsOnline/offline status is not (yet) included. However, I doubt it will be of any use as it is constantly changing, so I'm giving this a very low priority. Some screenshot pr0n below (US and EU):   |
|
|
|
I'm assuming he meant a user-friendly clicky GUI thingy. Not sure why that feat is removed in the first place? No idea. BTW, we should really switch from BerkeleyDB to LevelDB... These client start-up times are driving me crazy. |
|
|
|
I also was curious if there was any plan of including a minor into the wallet, kinda like feathercoin wallet does, I think it would a be a great idea for people starting that is not too tech savvy and wanted to participate in CPU mining. Thanks
But there is already CPU miner built-in all wallets. It is not as sophisticated nor it kickass as standalone CPU miner but it hashes! To run it, start YACoin wallet with -gen parameter and eventualy add -genproclimit=X where X is number of CPU cores you want to mine with. To mine with just one CPU core use: yacoin-qt.exe -gen -genproclimit=1 I'm assuming he meant a user-friendly clicky GUI thingy. |
|
|
|
Hi all, I have had a question I've wanted to ask for a while now. Is there a way of knowing how many active nodes/wallets are operating on the network? Has there been much fluctuation in the number of active wallets?
Determining the number of active nodes should be possible by either forcing your client to connect to an unlimited number of nodes and waiting a long time ( quick slow and dirty) OR you could parse the peers.dat file inside yacoin data directoy (where the yacoin.conf file is) and try pinging each IP from the list you get (may be inaccurate due to dropped ICMP packets on their firewall and whatnot) or better yet, connecting to the yacoin port (this might help against the firewall issue). But still, the nodes behind overly restrictive firewalls will appear as offline. So the best bet is to actually force the client to connect to all of them (and waiting, waiting, waiting...). I also was curious if there was any plan of including a miner into the wallet, kinda like feathercoin wallet does, I think it would a be a great idea for people starting that is not too tech savvy and wanted to participate in CPU mining. Thanks.
This is on my TODO list, so it might get implemented, eventually. |
|
|
|
Address balance list updated up to block #210732. Also, here's a normalized hashrate graph, assuming 50% hashrate decrease on each Nfactor change (I'm not entirely convinced it's correct). The formula I'm using is: f_normalize(time, hashrate) = hashrate / (0.5**(f_getNfactor(time) - 9))
where 0.5 is the hashrate decrease factor and 9 is the Nfactor we're normalizing for (N=1024 as in litecoin and other altcoins). I don't like the sharp drops after each Nfactor change. Any clues as to why might this be happening? Could this be because of broken GPU miners that needed code changes for each N change? Also, need feedback on the 50% figure.  |
|
|
|
I used GCC 4.8.1. I made it with: qmake "USE_UPNP=- USE_DBUS=1 USE_IPV6=1 USE_QRCODE=1" make Was this resolved? |
|
|
|
Sorry if this has already been asked, but what is the most up to date YAC wallet now? Also, I remember reading a while ago that a new wallet is being developed with control over individual sending addresses. Is this still in the works? I'd like to tip the dev team, which direction should I throw that to?
If you want to download prebuilt windows binary of Yacoin-QT with CC included (and the Yak logos, LOL), I've created this thread: https://bitcointalk.org/index.php?topic=276948Please report any bugs you find (but I hope there are no more bugs). You can send tips for the Coin Control to me. Also, some crapcoin is copying my source changes for Coin Control! IMPORTANT!
Stop using the published versions of Yacoin with Coin Control - there's a critical bug when NOT selecting a custom change address (the new change address is not reserved from keypool and thus your coins disappear forever). Fixed in recent git commit, updated binaries coming soon.
So you have fixed this bug in github source too? We are considering to add this in ZcCoin. Thanks. And there was one more story with EcoCoin dev e-mailing me concerning my changes to Abe block explorer. Funny as hell! |
|
|
|
Out of curiosity, what is this saying that suggest an attack is going on rather than just people mining? I'm new to cryptocurrencies.
As an attacker you mine on your own chain for a while (without broadcasting it to all the others), then suddenly add your blocks and so overrule the legit chain. All transactions on the legit chain while that period will be reversed so you can buy stuff without actually loosing coins. Well, this might not have been intentional. Someone could have had a lot of PoS blocks found all at once or some PoS blocks were not broadcast to all nodes (and with PoS having a higher priority than PoW, they easily overtook the chain). Also, this was happening a lot in the early days of YAC (diff = 0 and stuff). The replacing blocks were AFIK all PoW so this isn't just a minor coincidence. It's either a attacker that wants to harm YAC or a serious bug. None of that should be taken too lightly. We will see. Nope, 11.9.2013 16:54:36 REORGANIZE: Connect 1 blocks; 00000007c5835b4968bd..547db4922a8b8e71ff85
was a PoS block that wiped out 34 PoW blocks. (You see it's a PoS by the hash's first bytes - 547db4922a8b8e71ff85 - no leading zeroes = very lwo difficulty = PoS block). Can anyone check if there were some reversed transactions?
Surely there were some (if not all). I would advise exchanges to wait for at least 60 confirmations (or even 120 to be safe) before crediting funds to accounts as they are the most likely target of these attacks (if they even are attacks). Most likely this was just someone syncing their client while minting PoS blocks (haven't checked the code yet, but it's entirely possible that the PoS minter is enabled even before fully synced - or it might have had believed it was synced while it was 34 blocks behind [which is not a lot, since we have 60 second block target]). IMHO the blockchain cummulative work calculation formula should be changed to something more sensible, eg. give PoS only a slightly higher priority than PoW. This would massively reduce such reorgs as seen in the posts above. |
|
|
|
|
Show Posts
