Nope. No luck. I'm just going to have to try it in a Debian box.
It might be worth tring out nvc and see if you can compile it. Our coins are very similar. If are you are able to, and find a thing or 2 that needs changed for HBN. I would be appreciative, for a PR. I've got a bit of stake right in the wings....
|
|
|
"Interest" is not really something I want to see survive in the Bitcoin protocol's future. The idea of trying to replicate the current, broken financial system is outrageous.
Its not just "Interest", it is payment for work, not dissimilar to being paid to hash. You must hold the coins. You must use CPU to stake the coins. You must you use bandwidth to talk to the network. No one will do this for free.
|
|
|
Hi All,
Let me say a few things.
#1 Zack did ask me, and I do understand the frustration you all are going through, but I simply have no time to help. I have made 1 commitment and that is to HBN.
#2 Why do you want a new chain? I just synced up 2 computers with 1.5.3 and it they both got to the same chain. It was a a bit of a pain to get up to current block, had to close a few times, but both computers are at same chain, and I even have some stake going now.
#3 Regarding Cryptsy, if they do not want to list this coin, you can not force them. Simply open up a ticket and ask your ADT be returned to your wallet for sell orders, and your btc to your account for buy. Then go find a new exchange.
This is your coin. You don't need to pay people to fix it. All the answers are out here. Act like a community and find the answers.
I do wish you all the best. I will keep an eye out, and keep my wallet as a stake only node, to help the network. But so far it seems fine to me.
Good luck!
|
|
|
Oh, yeah. No problem with bitcoin-qt, it works just fine sand-alone. Incidentally, I also tried the maxcoin-qt, and it has the same problem. Of course, I'm using yum instead of apt. I'll make sure I have everything I can get from that list and report back about how it works. My fallback right now is to install a Debian distro in Boxes. Thanks. I do want to create a more static exe for linux in the future. But still working on coding right now. You may need the newest boost for HBN as I complied it with 1.55 but if you compile yourself you can use most version without issues.
|
|
|
New pool for the list: hbn.jtcpools.orgPPLNS - 1% fee - goes to charity - Lifewater International (safe drinking water) & Samaritan's Purse (disaster relief) +Monthly drawings for miners that donate - they could get 2X their donations I added your pool to the first page, and we'll get it added to the website here as well. Thanks!
I would like to get mine on the list as well hbn.cutk.comPROP, 0% fee, VARDIFF, DDOS protection Thanks guys we will get these added soon.
|
|
|
This should fix it.
I added your pool to the first page, and we'll get it added to the website here as well. Thanks!
|
|
|
unick, if you are available some night, I wouldn't mind doing a testnet run, just our 2 nodes, and see how that flushes out.
If not no worries. We can discuss over PM. Thanks
|
|
|
I will analyze these results and see if anything sticks out. Thanks for your assistance.
Edit: So far it only looks like the stake sat in the kernel for a bit longer on the mac, and a checkpoint( another block) was accepted while this one finally broadcast, and it was then rejected. I'll look more, but so far I think it is only the efficiency, or rather the inefficiency, of the stake miner on a mac.
Does anyone have experience with other PoS coins on a mac, is it common to get more orphans there?
I do have some improvement I plan to implement in Version 1.4, that should help this out, at least it will make the stake miner a bit more efficient.
|
|
|
Great news, well done as always king!
|
|
|
So as I write this I am restarting the Mac client but with the zip version of the compile (witch is on github now) and I'll see if the orphan block will try to restake later this night or tomorrow and see if the PoS block gets accepted or rejected with that client and I'll keep you posted with that.
Thanks so much. This will be helpful. ok, as soon as the client synced the block chain, it did succesfully mine a PoS block. So it looks like the dmg compile had some kind of a bug in it. I'll still keep an eye on it tomorrow for any kind of unwanted behaviors. and I'll report if any issues are found. Prefect thanks for trouble shooting this for us. Let me know if Coin Control seems good, and if you see any different between the win version (if you use it) and the Mac version. Feel free to post an address for your help. okay, here's a quick update. I had to redownload the blockchain because I had issues with the wallet (I think it's the corrupted issue that was mentioned earlier in this thread). That took over 24 hours but now my wallets load fine. So it's been 9 hours that I let the wallet sit for it to stake and while it does stake, I find that the orphan rate is way higher than on the windows client. It could be just a coincidence, I don't know for sure. On 13 inputs, I had 6 orphan (all one after the other) the last input just got in ~30 minutes ago and was accepted. I'll continue to monitor and report. If you need more details, I would be glad to share them with you. Just let me know and what you need exactly I noticed the orphan rate was higher on the mac in version 1.2 as well. A friend took a snapshot of his transactions. The coins did eventually get accepted but seemed to take 2-1 orphan to accept. Were as windows I get 90% accepted. So this might be an issue with the mac client, I got 2 more orphans since I posted this morning. Do you have an idea as why this happens? As of right now, no I do not know. 2 potential reasons come to mind. 1 the stake takes too long in the kernel and once it gets out, the difficulty or time for next PoS has changed and it is no longer valid. The other reason may the calculation done are not 100% correct on the mac client. More information can be retrieved by starting the client with the following switches: -printcoinstake -printcreation Perhaps the debug.log will give a clue as to why the mac is not quite right, at least for stakes.
|
|
|
Anyone know why the "gethashespersec" RPC call always returns 0?
How are pools showing the correct network hash rate?
gethashespersec would only show your hash rate if you are mining with -gen=1. To see the network hash rate type getmininginfo
|
|
|
So as I write this I am restarting the Mac client but with the zip version of the compile (witch is on github now) and I'll see if the orphan block will try to restake later this night or tomorrow and see if the PoS block gets accepted or rejected with that client and I'll keep you posted with that.
Thanks so much. This will be helpful. ok, as soon as the client synced the block chain, it did succesfully mine a PoS block. So it looks like the dmg compile had some kind of a bug in it. I'll still keep an eye on it tomorrow for any kind of unwanted behaviors. and I'll report if any issues are found. Prefect thanks for trouble shooting this for us. Let me know if Coin Control seems good, and if you see any different between the win version (if you use it) and the Mac version. Feel free to post an address for your help. okay, here's a quick update. I had to redownload the blockchain because I had issues with the wallet (I think it's the corrupted issue that was mentioned earlier in this thread). That took over 24 hours but now my wallets load fine. So it's been 9 hours that I let the wallet sit for it to stake and while it does stake, I find that the orphan rate is way higher than on the windows client. It could be just a coincidence, I don't know for sure. On 13 inputs, I had 6 orphan (all one after the other) the last input just got in ~30 minutes ago and was accepted. I'll continue to monitor and report. If you need more details, I would be glad to share them with you. Just let me know and what you need exactly I noticed the orphan rate was higher on the mac in version 1.2 as well. A friend took a snapshot of his transactions. The coins did eventually get accepted but seemed to take 2-1 orphan to accept. Were as windows I get 90% accepted.
|
|
|
HoboNickels can now be exchanged for Real Gold, Platinum, Silver, and Palladium @ www.MintageMasterMind.com Diversify your assets! Thanks! Good luck on your site.
|
|
|
So as I write this I am restarting the Mac client but with the zip version of the compile (witch is on github now) and I'll see if the orphan block will try to restake later this night or tomorrow and see if the PoS block gets accepted or rejected with that client and I'll keep you posted with that.
Thanks so much. This will be helpful. ok, as soon as the client synced the block chain, it did succesfully mine a PoS block. So it looks like the dmg compile had some kind of a bug in it. I'll still keep an eye on it tomorrow for any kind of unwanted behaviors. and I'll report if any issues are found. Prefect thanks for trouble shooting this for us. Let me know if Coin Control seems good, and if you see any different between the win version (if you use it) and the Mac version. Feel free to post an address for your help.
|
|
|
So as I write this I am restarting the Mac client but with the zip version of the compile (witch is on github now) and I'll see if the orphan block will try to restake later this night or tomorrow and see if the PoS block gets accepted or rejected with that client and I'll keep you posted with that.
Thanks so much. This will be helpful.
|
|
|
I`m looking for opportunity to keep wallet address from 1.2 and migrate to 1.3 - is that safely possible?
I have done this as well and it works. startup clean version 1.2 with your bad wallet and use -salvagewallet after gui, close startup clean version 1.3 with your new salvaged wallet ( I also used -salvagewallet, but I don't think you need to) You will lose orphans(good thing) and your address book (bad)(use export on v1.2 before you salvage) but it should work on in version 1.3
|
|
|
I just did this same thing with another wallet that another person had an issue with, and i was able to move those coins off that wallet. You beat me to the punch!
So what I think is the safest thing to do is simply generate a new wallet with version 1.3. Then Back it up! With both a copy and a dumpwallet. Then move the coins from 1.2 wallet to the new version 1.3.
For now I am still experimenting as well. But I think this is good. I don't know of any wallet made from version 1.3 that also had this issue with 1.3.
You can send me back to here Eo6DvKHvUiHqCBXj6T6uWdbpEH8DtT3Guk
Thank you too!
Sent! Trans ID: aad96869bdd2a2dea6d52a29c8de250f6a03f818d75af1f7c957d2d6c43037e0-000 I`m looking for opportunity to keep wallet address from 1.2 and migrate to 1.3 - is that safely possible? If it is just one private key you can: dumpprivekey <public key> in version 1.2 then in version 1.3 you can importprivkey If you want the entire wallet, let me do a few things to see.
|
|
|
Yes I have a hard shutdown before. Remove db file and those 2 folders. I get 2 wallet files: default and mining. Only the wallet-mining.dat file get error message when launching wallet client. I tried copy mining DAT file to somewhere else and "load" that DAT manually. Still get following message: "Critical error loading wallet xxx.dat:CDB() / error 22" Is it means this wallet file is currupted? We have a resolution for this. If you want to do it yourself, you need to get a computer that has ver 1.2 and move those coins to a new fresh wallet made with version 1.3 I can do this for you if you like. PM me.
|
|
|
|