Vote for HoboNickles in the 'greatest altcoin of all poll' at Altcoin Herald: http://altcoinherald.com/altcoin-polls/vote-greatest-altcoin/ 
Yep, already voted for Hobo:)
Topic: HoboNickels - HBN - High Fast Stake - Version 2.0! More Secure, Less Intensive - page 209. (Read 478852 times)
May 15, 2014, 01:20:09 PM
Yep, already voted for Hobo:)
May 15, 2014, 10:30:24 AM
Hi everyone,
I just want to let you know that I am going to be doing a bit of work for CAPs here in the near future. I am telling you this so, you can participate if you like, and so you are not worried about me leaving HBN, if code changes are slow to come over the next few weeks.
I am not leaving or abandoning HBN. In fact we have a lot of work to do, including some talk about hard forks. For bug fixes and network protection. And a few surprises!
But I figured CAP is a brother of HBN, so it needs a bit of love too.
You can read about my plans here: https://bitcointalksearch.org/topic/m.6698513
Thanks all!
I just want to let you know that I am going to be doing a bit of work for CAPs here in the near future. I am telling you this so, you can participate if you like, and so you are not worried about me leaving HBN, if code changes are slow to come over the next few weeks.
I am not leaving or abandoning HBN. In fact we have a lot of work to do, including some talk about hard forks. For bug fixes and network protection. And a few surprises!
But I figured CAP is a brother of HBN, so it needs a bit of love too.
You can read about my plans here: https://bitcointalksearch.org/topic/m.6698513
Thanks all!
Thanks for the update Tranz. Looking forward to the next HBN upgrade, it will be great to hammer out those last few bugs that require hard forks to resolve.
May 15, 2014, 10:12:26 AM
Vote for HoboNickles in the 'greatest altcoin of all poll' at Altcoin Herald: http://altcoinherald.com/altcoin-polls/vote-greatest-altcoin/
May 14, 2014, 11:40:57 PM
ElTomeko27 its good to see you on BTCtalk too now
You got my little support from Poland;P
May 14, 2014, 05:38:45 PM
Hi everyone,
I just want to let you know that I am going to be doing a bit of work for CAPs here in the near future. I am telling you this so, you can participate if you like, and so you are not worried about me leaving HBN, if code changes are slow to come over the next few weeks.
I am not leaving or abandoning HBN. In fact we have a lot of work to do, including some talk about hard forks. For bug fixes and network protection. And a few surprises!
But I figured CAP is a brother of HBN, so it needs a bit of love too.
You can read about my plans here: https://bitcointalksearch.org/topic/m.6698513
Thanks all!
I just want to let you know that I am going to be doing a bit of work for CAPs here in the near future. I am telling you this so, you can participate if you like, and so you are not worried about me leaving HBN, if code changes are slow to come over the next few weeks.
I am not leaving or abandoning HBN. In fact we have a lot of work to do, including some talk about hard forks. For bug fixes and network protection. And a few surprises!
But I figured CAP is a brother of HBN, so it needs a bit of love too.
You can read about my plans here: https://bitcointalksearch.org/topic/m.6698513
Thanks all!
I am in for the ride!!
May 14, 2014, 05:11:31 PM
Hi everyone,
I just want to let you know that I am going to be doing a bit of work for CAPs here in the near future. I am telling you this so, you can participate if you like, and so you are not worried about me leaving HBN, if code changes are slow to come over the next few weeks.
I am not leaving or abandoning HBN. In fact we have a lot of work to do, including some talk about hard forks. For bug fixes and network protection. And a few surprises!
But I figured CAP is a brother of HBN, so it needs a bit of love too.
You can read about my plans here: https://bitcointalksearch.org/topic/m.6698513
Thanks all!
I just want to let you know that I am going to be doing a bit of work for CAPs here in the near future. I am telling you this so, you can participate if you like, and so you are not worried about me leaving HBN, if code changes are slow to come over the next few weeks.
I am not leaving or abandoning HBN. In fact we have a lot of work to do, including some talk about hard forks. For bug fixes and network protection. And a few surprises!
But I figured CAP is a brother of HBN, so it needs a bit of love too.
You can read about my plans here: https://bitcointalksearch.org/topic/m.6698513
Thanks all!
May 14, 2014, 04:41:21 PM
ElTomeko27 its good to see you on BTCtalk too now
May 14, 2014, 02:33:13 PM
May 14, 2014, 01:30:27 PM
May 14, 2014, 01:10:44 PM
Ok so what if the HBN block chain will be much bigger than now??
When the chain grows larger it just means it takes longer to sync and takes up more storage. Right now the HBN chain is something like 700mb (at least that is the size of my appdata HBN folder), which is not bad at all. It will be somewhere around 1 gb per year.
Ok understood:)
and when it gets a lot much bigger, we can use an hosted version or electrum/multibit type of solution for people wanting to jumpstart the inital load or don't want to host the whole block chain.
With every problem there is a solution, right now this is not an issue. But it is a valid concern!
Looks doubtful to me.
as I understand it, I wouldn't see any reason why it shouldn't work.
The staking process takes into consideration what is held in an address. It doesn't care if you have the block chain on your computer or not. Once the client finds a block, it need to broadcast that block to the network like it would do for any other transaction. So with an electrum/multibit type wallet, you already almost all you need in your wallet (meaning your public/private key pair and transaction ability). What those current implementation lack is the ability of mining PoS blocks. But I would imagine that feature being easily added to those wallets.
Interesting.... Is the wallet source on github?? I wonder how hard it would be to merge the two wallets. It would mean figuring out getting coin control on there too.
i think its already been done in yacoin
May 14, 2014, 11:24:50 AM
Ok so what if the HBN block chain will be much bigger than now??
When the chain grows larger it just means it takes longer to sync and takes up more storage. Right now the HBN chain is something like 700mb (at least that is the size of my appdata HBN folder), which is not bad at all. It will be somewhere around 1 gb per year.
Ok understood:)
and when it gets a lot much bigger, we can use an hosted version or electrum/multibit type of solution for people wanting to jumpstart the inital load or don't want to host the whole block chain.
With every problem there is a solution, right now this is not an issue. But it is a valid concern!
Looks doubtful to me.
as I understand it, I wouldn't see any reason why it shouldn't work.
The staking process takes into consideration what is held in an address. It doesn't care if you have the block chain on your computer or not. Once the client finds a block, it need to broadcast that block to the network like it would do for any other transaction. So with an electrum/multibit type wallet, you already almost all you need in your wallet (meaning your public/private key pair and transaction ability). What those current implementation lack is the ability of mining PoS blocks. But I would imagine that feature being easily added to those wallets.
Interesting.... Is the wallet source on github?? I wonder how hard it would be to merge the two wallets. It would mean figuring out getting coin control on there too.
May 14, 2014, 08:36:07 AM
May 14, 2014, 04:20:04 AM
用了1.4以前丢失的都回来了。
May 14, 2014, 02:52:37 AM
I don't see any indication of height or getting or receiving blocks in your log. Very odd.. Is your client fully up to sync with the block explorer? http://hbn.blockx.info/get/chain/HoboNickels
Was this during the init download. Something seems off, you seem to have been caught up in an orphan loop check..
Was this during the init download. Something seems off, you seem to have been caught up in an orphan loop check..
I was not able to check it, because the hobonickelsd process already exited, so there was no RPC working. Probably it panicked after these lines in the log:
Code:
05/13/14 10:46:35 ERROR: CTransaction::ReadFromDisk() : OpenBlockFile failed
05/13/14 10:46:35 ERROR: mempool transaction missing input
05/13/14 10:46:35 ERROR: mempool transaction missing input
So I have to restarted it again. Running with -debug flag.
This was not during the initial load, the process was running for many hours before already.
May 14, 2014, 01:20:47 AM
i like the new wallet
May 13, 2014, 08:23:23 PM
Ok so what if the HBN block chain will be much bigger than now??
When the chain grows larger it just means it takes longer to sync and takes up more storage. Right now the HBN chain is something like 700mb (at least that is the size of my appdata HBN folder), which is not bad at all. It will be somewhere around 1 gb per year.
Ok understood:)
and when it gets a lot much bigger, we can use an hosted version or electrum/multibit type of solution for people wanting to jumpstart the inital load or don't want to host the whole block chain.
With every problem there is a solution, right now this is not an issue. But it is a valid concern!
Looks doubtful to me.
as I understand it, I wouldn't see any reason why it shouldn't work.
The staking process takes into consideration what is held in an address. It doesn't care if you have the block chain on your computer or not. Once the client finds a block, it need to broadcast that block to the network like it would do for any other transaction. So with an electrum/multibit type wallet, you already almost all you need in your wallet (meaning your public/private key pair and transaction ability). What those current implementation lack is the ability of mining PoS blocks. But I would imagine that feature being easily added to those wallets.
May 13, 2014, 06:45:22 PM
Unfortunately it is doing that all the time 
I have libboost 1.54...do you think it is worth to try upgrading to 1.55?
I have libboost 1.54...do you think it is worth to try upgrading to 1.55?Perfect tutorial here for libboost 1.55
https://coderwall.com/p/0atfug
Thank you, superresistant. I was curious about this as well.
I have updated to libboost 1.55 (luckily in Ubuntu 14.04 is already in repo) and it seems to work better. There were few situations where hobonickelsd took 100% CPU, but not that long/often anymore.
But today it crashed again (different cause)?:
Code:
05/13/14 10:46:31 ProcessSyncCheckpoint: pending for sync-checkpoint 0000000014c891e8153bff84e187217e53bf0123ef5215f5c79b6fafb1349a55
05/13/14 10:46:31 sending: getblocks (1029 bytes)
05/13/14 10:46:31 askfor block 716d8fba33600c93fa69 1402087979000000 (20:52:59)
05/13/14 10:46:32 received: checkpoint (108 bytes)
05/13/14 10:46:32 ProcessSyncCheckpoint: pending for sync-checkpoint 000000000b4a5a70483a2c1069559be9ff1259f49e6f94e0e14ad1d60fcd28d9
05/13/14 10:46:32 sending: getblocks (1029 bytes)
05/13/14 10:46:32 askfor block 716d8fba33600c93fa69 1402088099000000 (20:54:59)
05/13/14 10:46:32 received: inv (37 bytes)
05/13/14 10:46:32 got inventory: block 000000000b4a5a70483a have
05/13/14 10:46:32 sending: getblocks (1029 bytes)
05/13/14 10:46:33 received: inv (37 bytes)
05/13/14 10:46:33 got inventory: block ffd1e77b6676ca93358e have
05/13/14 10:46:35 ERROR: CTransaction::ReadFromDisk() : OpenBlockFile failed
05/13/14 10:46:35 ERROR: mempool transaction missing input
05/13/14 10:46:31 sending: getblocks (1029 bytes)
05/13/14 10:46:31 askfor block 716d8fba33600c93fa69 1402087979000000 (20:52:59)
05/13/14 10:46:32 received: checkpoint (108 bytes)
05/13/14 10:46:32 ProcessSyncCheckpoint: pending for sync-checkpoint 000000000b4a5a70483a2c1069559be9ff1259f49e6f94e0e14ad1d60fcd28d9
05/13/14 10:46:32 sending: getblocks (1029 bytes)
05/13/14 10:46:32 askfor block 716d8fba33600c93fa69 1402088099000000 (20:54:59)
05/13/14 10:46:32 received: inv (37 bytes)
05/13/14 10:46:32 got inventory: block 000000000b4a5a70483a have
05/13/14 10:46:32 sending: getblocks (1029 bytes)
05/13/14 10:46:33 received: inv (37 bytes)
05/13/14 10:46:33 got inventory: block ffd1e77b6676ca93358e have
05/13/14 10:46:35 ERROR: CTransaction::ReadFromDisk() : OpenBlockFile failed
05/13/14 10:46:35 ERROR: mempool transaction missing input
It can take CPU when it is getting a new block, or the client is working on a stake, it is normal for it is use 1 core, and on my quad sometimes it uses 2 full cores. That is the most I have seen.
Not sure I have seen that error before. Your debug looks complely different then any I have seen before. From Ubuntu to win xp.
Here is a how mine look.
Code:
7372
05/13/14 23:40:41 SetBestChain: new best=000000000319a40e64a4 height=844485 trust=2876684406729 date=05/13/14 23:40:21
05/13/14 23:40:41 AcceptPendingSyncCheckpoint : sync-checkpoint at 000000000319a40e64a48a459d9fad24d8fd3a1b714879acb9d202906ca2e446
05/13/14 23:40:41 ProcessBlock: ACCEPTED
05/13/14 23:40:42 ProcessSyncCheckpoint: pending for sync-checkpoint 000000000c4610b528c49b8fc6d9a5a4453f298fa9891bf74c1742563bed0e7c
05/13/14 23:40:42 received block 000000000c4610b528c4 sent from 31.16.103.210:7372
05/13/14 23:40:42 SetBestChain: new best=000000000c4610b528c4 height=844486 trust=2876684440261 date=05/13/14 23:40:29
05/13/14 23:40:42 AcceptPendingSyncCheckpoint : sync-checkpoint at 000000000c4610b528c49b8fc6d9a5a4453f298fa9891bf74c1742563bed0e7c
05/13/14 23:40:42 ProcessBlock: ACCEPTED
05/13/14 23:40:44 getblocks 844482 to 0000000010fa5a846f4c limit 500
05/13/14 23:40:44 getblocks stopping at 844482 0000000010fa5a846f4c
05/13/14 23:40:44 getblocks 844482 to 000000001c32d30250a1 limit 500
05/13/14 23:40:44 getblocks stopping at 844483 000000001c32d30250a1
05/13/14 23:40:44 getblocks 844482 to 0000000011ec95f00024 limit 500
05/13/14 23:40:44 getblocks stopping at 844484 0000000011ec95f00024
05/13/14 23:40:44 getblocks 844482 to 000000000319a40e64a4 limit 500
05/13/14 23:40:44 getblocks stopping at 844485 000000000319a40e64a4
05/13/14 23:40:44 getblocks 844482 to 000000000c4610b528c4 limit 500
05/13/14 23:40:44 getblocks stopping at 844486 000000000c4610b528c4
05/13/14 23:40:44 getblocks -1 to 00000000000000000000 limit 500
05/13/14 23:40:45 Flushing wallet.dat
05/13/14 23:40:41 SetBestChain: new best=000000000319a40e64a4 height=844485 trust=2876684406729 date=05/13/14 23:40:21
05/13/14 23:40:41 AcceptPendingSyncCheckpoint : sync-checkpoint at 000000000319a40e64a48a459d9fad24d8fd3a1b714879acb9d202906ca2e446
05/13/14 23:40:41 ProcessBlock: ACCEPTED
05/13/14 23:40:42 ProcessSyncCheckpoint: pending for sync-checkpoint 000000000c4610b528c49b8fc6d9a5a4453f298fa9891bf74c1742563bed0e7c
05/13/14 23:40:42 received block 000000000c4610b528c4 sent from 31.16.103.210:7372
05/13/14 23:40:42 SetBestChain: new best=000000000c4610b528c4 height=844486 trust=2876684440261 date=05/13/14 23:40:29
05/13/14 23:40:42 AcceptPendingSyncCheckpoint : sync-checkpoint at 000000000c4610b528c49b8fc6d9a5a4453f298fa9891bf74c1742563bed0e7c
05/13/14 23:40:42 ProcessBlock: ACCEPTED
05/13/14 23:40:44 getblocks 844482 to 0000000010fa5a846f4c limit 500
05/13/14 23:40:44 getblocks stopping at 844482 0000000010fa5a846f4c
05/13/14 23:40:44 getblocks 844482 to 000000001c32d30250a1 limit 500
05/13/14 23:40:44 getblocks stopping at 844483 000000001c32d30250a1
05/13/14 23:40:44 getblocks 844482 to 0000000011ec95f00024 limit 500
05/13/14 23:40:44 getblocks stopping at 844484 0000000011ec95f00024
05/13/14 23:40:44 getblocks 844482 to 000000000319a40e64a4 limit 500
05/13/14 23:40:44 getblocks stopping at 844485 000000000319a40e64a4
05/13/14 23:40:44 getblocks 844482 to 000000000c4610b528c4 limit 500
05/13/14 23:40:44 getblocks stopping at 844486 000000000c4610b528c4
05/13/14 23:40:44 getblocks -1 to 00000000000000000000 limit 500
05/13/14 23:40:45 Flushing wallet.dat
I don't see any indication of height or getting or receiving blocks in your log. Very odd.. Is your client fully up to sync with the block explorer? http://hbn.blockx.info/get/chain/HoboNickels
Was this during the init download. Something seems off, you seem to have been caught up in an orphan loop check..
May 13, 2014, 05:05:43 PM
Ok so what if the HBN block chain will be much bigger than now??
When the chain grows larger it just means it takes longer to sync and takes up more storage. Right now the HBN chain is something like 700mb (at least that is the size of my appdata HBN folder), which is not bad at all. It will be somewhere around 1 gb per year.
Ok understood:)
and when it gets a lot much bigger, we can use an hosted version or electrum/multibit type of solution for people wanting to jumpstart the inital load or don't want to host the whole block chain.
With every problem there is a solution, right now this is not an issue. But it is a valid concern!
Looks doubtful to me.
May 13, 2014, 03:31:03 PM
Ok so what if the HBN block chain will be much bigger than now??
When the chain grows larger it just means it takes longer to sync and takes up more storage. Right now the HBN chain is something like 700mb (at least that is the size of my appdata HBN folder), which is not bad at all. It will be somewhere around 1 gb per year.
Ok understood:)
and when it gets a lot much bigger, we can use an hosted version or electrum/multibit type of solution for people wanting to jumpstart the inital load or don't want to host the whole block chain.
With every problem there is a solution, right now this is not an issue. But it is a valid concern!
May 13, 2014, 02:34:19 PM
Ok so what if the HBN block chain will be much bigger than now??
When the chain grows larger it just means it takes longer to sync and takes up more storage. Right now the HBN chain is something like 700mb (at least that is the size of my appdata HBN folder), which is not bad at all. It will be somewhere around 1 gb per year.
Ok understood:)
Jump to: