[ANN][YAC] YACoin ongoing development

[forsetifox]

Hm.. I've had coins in my wallet for 34 days and no PoS blocks made yet. Is there something I need to do for that to happen?

[forsetifox]

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. =/

[sairon]

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.

[forsetifox]

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.

[sairon]

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.)

[forsetifox]

Great. 

Thanks for the help BitMega and Sairon.

[sairon]

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).

[Joe_Bauers]

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).

Signals and slots sairon... signals and slots      I will try to find some time to do this before the next release.

[kentt]

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,

Code:

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).

My node switched to "~15 blocks remaining" mode, e.g. not synced, so it was not just ordinary PoS "overtake". Only after 15 more legit blocks
were found node went to synced mode.

This has been a known problem for months.  Check about 30 pages back or so (I don't care enough to find the link).  This would be a really trivial attack.  I think it's surprising that this hasn't be exploited more often.

Is this a problem?  Back reading it seems like a huge issue.

[Gorgoy]

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:

Code:

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#stats

Online/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):

Wow, that is totally awesome, Thanks so much for the explorer. I have spent a long while playing with it, it's an eye opener. Nice to see so many people out there using YAC and all the nodes operating.

[forsetifox]

So I've been looking at some debug logs and ran across something odd (at least I think it's odd).

Code:

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

[pmconrad]

Does the CPUminer just not use much of the CPU to mine PoS blocks? It's still sitting at 1-3% CPU usage.

Actually, that's the point of PoS...

[sairon]

So I've been looking at some debug logs and ran across something odd (at least I think it's odd).

Code:

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.

[forsetifox]

Ran a log last night and it looks like the client checks for a PoS block every 6 hours. =3

ComputeNextStakeModifier: prev modifier=0x3fc817798fd58499 time=2013-09-18 06:02:45 UTC
ComputeNextStakeModifier: prev modifier=0xba202540b22ec501 time=2013-09-18 12:03:42 UTC
ComputeNextStakeModifier: prev modifier=0xa8b1bafe6ce3d92c time=2013-09-18 18:00:51 UTC


I'm not a pro so I might be reading this wrong. It looks like it's trying to submit a PoS block and the network isn't taking it? Then when a new block comes along from the network it just drops the PoS block..

Code:

ComputeNextStakeModifier: prev modifier=0x3fc817798fd58499 time=2013-09-18 06:02:45 UTC
ComputeNextStakeModifier: new modifier=0xba202540b22ec501 time=2013-09-18 12:01:44 UTC
SetBestChain: new best=00000007ecaeca0c5c27  height=217576  trust=7562537080695  date=09/18/13 12:03:42
ProcessBlock: ACCEPTED
received: inv (37 bytes)
  got inventory: block 00000007ecaeca0c5c27  have
sending: getblocks (965 bytes)
force request: block 00000007ecaeca0c5c27
sending: inv (37 bytes)
received: inv (37 bytes)
  got inventory: block 00000007ecaeca0c5c27  have
sending: getblocks (965 bytes)
force request: block 00000007ecaeca0c5c27
received: inv (37 bytes)
  got inventory: block 00000007ecaeca0c5c27  have
sending: getblocks (965 bytes)
force request: block 00000007ecaeca0c5c27
received: inv (37 bytes)
  got inventory: block 00000007ecaeca0c5c27  have
sending: getblocks (965 bytes)
force request: block 00000007ecaeca0c5c27
sending: inv (37 bytes)
received: inv (37 bytes)
  got inventory: block 00000007ecaeca0c5c27  have
sending: getblocks (965 bytes)
force request: block 00000007ecaeca0c5c27
received: getblocks (965 bytes)
getblocks -1 to 00000000000000000000 limit 500
Flushing wallet.dat
Flushed wallet.dat 73ms
received: getblocks (965 bytes)
getblocks -1 to 00000000000000000000 limit 500
Flushed 12388 addresses to peers.dat  33ms
received: inv (37 bytes)
  got inventory: block 00000007801f1bfe7dbf  new
askfor block 00000007801f1bfe7dbf   0 (00:00:00)
sending getdata: block 00000007801f1bfe7dbf
sending: getdata (37 bytes)
received: block (6188 bytes)
received block 00000007801f1bfe7dbf
ComputeNextStakeModifier: prev modifier=0xba202540b22ec501 time=2013-09-18 12:03:42 UTC

[Joe_Bauers]

In the meantime... The beta test for 0.4.1 is available, which includes the new icons created by Mjbmonetarymetals.
Please test it out, but don't use your main wallet 

https://github.com/yacoin/yacoin/releases/tag/testing_0.4.1-b

[Thirtybird]

In the meantime... The beta test for 0.4.1 is available, which includes the new icons created by Mjbmonetarymetals.
Please test it out, but don't use your main wallet 

https://github.com/yacoin/yacoin/releases/tag/testing_0.4.1-b

Where's the fun in that?  All the versions are beta aren't they? 

[forsetifox]

Looks like I found a PoS block last night.



Temporarily empty wallet. Waiting for 155 more confirms before the coins come back.



Debug log stuffs!

Code:

CheckStakeKernelHash() : using modifier 0x1ae36b5e6f68aaed at height=182323 timestamp=2013-08-23 18:00:27 UTC for block from height=173398 timestamp=2013-08-14 19:17:24 UTC
CheckStakeKernelHash() : pass protocol=0.3 modifier=0x1ae36b5e6f68aaed nTimeBlockFrom=1376507844 nTxPrevOffset=2305 nTimeTxPrev=1376507233 nPrevout=0 nTimeTx=1379675556 hashProof=00005fca74d75283f081ce6fdad9f949d9adc64b3fa23f03c390f213553f63c4
CPUMiner : proof-of-stake block found 4c35d7775b2d59b0caf45625254923583a420cd34a8f0f8634b65f7de181f494
BitcoinMiner:
new block found  
  hash: 4c35d7775b2d59b0caf45625254923583a420cd34a8f0f8634b65f7de181f494  
target: 00000003ffff0000000000000000000000000000000000000000000000000000
CBlock(hash=4c35d7775b2d59b0caf4, ver=3, hashPrevBlock=000000032221e6a0edf5, hashMerkleRoot=6f3af4df33, nTime=1379675556, nBits=1d03ffff, nNonce=0, vtx=2, vchBlockSig=3045022100c16c3c633a42552c57848e35a36b2910503df6bb205c760f51a1bf2a4ceef269022040d5708f016f8ca063ab09a858987426f3ebb30d19371a04c2700d9cdeab6a3c)
  Coinbase(hash=7812f3c874, nTime=1379675556, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, 4294967295), coinbase 030e5c03029300062f503253482f)
    CTxOut(empty)
  Coinstake(hash=a0bb9e5540, nTime=1379675556, ver=1, vin.size=1, vout.size=3, nLockTime=0)
    CTxIn(COutPoint(5170917857, 0), scriptSig=304402206786dfa582db241b)
    CTxOut(empty)
    CTxOut(nValue=609.0002, scriptPubKey=03045f0748834e8c528660acab9390920889a1ac73688da933d588d3f026323c15 OP_CHECKSIG)
    CTxOut(nValue=609.0002, scriptPubKey=03045f0748834e8c528660acab9390920889a1ac73688da933d588d3f026323c15 OP_CHECKSIG)
  vMerkleTree: 7812f3c874 a0bb9e5540 6f3af4df33 
generated 0.00
CheckStakeKernelHash() : using modifier 0x1ae36b5e6f68aaed at height=182323 timestamp=2013-08-23 18:00:27 UTC for block from height=173398 timestamp=2013-08-14 19:17:24 UTC
CheckStakeKernelHash() : check protocol=0.3 modifier=0x1ae36b5e6f68aaed nTimeBlockFrom=1376507844 nTxPrevOffset=2305 nTimeTxPrev=1376507233 nPrevout=0 nTimeTx=1379675556 hashProof=00005fca74d75283f081ce6fdad9f949d9adc64b3fa23f03c390f213553f63c4
ComputeNextStakeModifier: prev modifier=0xfca7c9c62cff3d2e time=2013-09-20 06:01:09 UTC
AddToWallet a0bb9e5540  new
WalletUpdateSpent found spent coin 1211.0099yac 517091785726fe4bf9e7eda9bd3c04eb76439d534f807184e56faf0a829c25fe
NotifyTransactionChanged 517091785726fe4bf9e7eda9bd3c04eb76439d534f807184e56faf0a829c25fe status=1
NotifyTransactionChanged a0bb9e5540b75277f8ac8ab29a0306fff35abc762b3617bae58af76f0e7aee0c status=0
updateWallet 517091785726fe4bf9e7eda9bd3c04eb76439d534f807184e56faf0a829c25fe 1
   inWallet=1 inModel=1 Index=295-296 showTransaction=1 derivedStatus=1
updateWallet a0bb9e5540b75277f8ac8ab29a0306fff35abc762b3617bae58af76f0e7aee0c 0
   inWallet=1 inModel=0 Index=585-585 showTransaction=1 derivedStatus=0
SetBestChain: new best=4c35d7775b2d59b0caf4  height=220174  trust=7686018163021  date=09/20/13 11:12:36
ProcessBlock: ACCEPTED

[sairon]

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.

[sairon]

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.

[forsetifox]

I'll post a screenshot once they come back.

 

What the recent transactions looks like now.