Hi everyone,
I wanted to buy TEKcoin but with such an outragrous price, I will buy HoboNickel instead. I'm done with day-trading, I lost to much real money woth this. Just buy, keen enjoy. Time to settle down. And maybe, in time, I will get my money back :-)
Tranz, I wanted to thank you for the multiwallet. I am escrow for Mintcoin and I would really need a wallet - unfortunately, dev on mintcoin is not as was as it could be, so I'm stuck with guessing. Maybe one day the multiwallet will be ported to MINT.
I would like to ask a question: both TEK and HBN date from 2013 and still the forum doesn't have that much post (not even 100). Newer coins have pagination in the hundred (700 for MINT, already almost 300 for SHARE, 1500 for BC...
How do you explain that? I know this is not lack of popularity so what? New coins, new mindsets?
the old coins for the most part avoided un-needed hype. Agreed, most of the pages on those threads, are 1 or 2 lines, or 2 people arguing back and forth for page after page. I'm glad this is shorter, and has a bit more substance. |
|
|
|
I see the changes here. https://github.com/argakiig/TEK/commit/25afd030534947e2b14633d8e7264e84dbeac4f6I am not sure commenting out the checkblocksig is a great idea. You are really opening yourself up for an attack. Might be better to re-active it at a certain height. Like after the block the download has been on. So for instance might try this. if (!CheckBlockSignature() && nHeight > 100000) return DoS(100, error("CheckBlock() : bad block signature")); This way it will not check the first 100k blocks for the sig but will check the remaining. Anyway it is worth testing and getting it to be able to still use the check sig for future blocks. The lower height number you can get to the better. I am going to run a few compiles and see how low I can get the height to go on the said line. Good catch Tranz. No problem. I would also suggest putting in a hardcoded checkpoint at the block you use, or a few others behind it. So if you end up using block 50,000, be sure to have a checkpoint at say block 25,000 and 50,000. This will help prevent anyone from exploiting the code during init download. Also If anyone is willing I would like to trade HBN for some TEK. The price between our coins is similar but both tend to fluctuate quite a bit. I'd do 1.5 to 1. So 10,000 HBN for 7,500 TEK. Min block trade of 10k. Let me know. Thanks! |
|
|
|
I see the changes here. https://github.com/argakiig/TEK/commit/25afd030534947e2b14633d8e7264e84dbeac4f6I am not sure commenting out the checkblocksig is a great idea. You are really opening yourself up for an attack. Might be better to re-active it at a certain height. Like after the block the download has been on. So for instance might try this. if (!CheckBlockSignature() && nHeight > 100000) return DoS(100, error("CheckBlock() : bad block signature")); This way it will not check the first 100k blocks for the sig but will check the remaining. Anyway it is worth testing and getting it to be able to still use the check sig for future blocks. The lower height number you can get to the better. |
|
|
|
2.5% POS / 15 days for 6 months lowering by 0.5% every 6 months until it hits 1%
You really lower the number of days for stake. 15 days is WAY to long. Should be more like 5 days or even less. You want a PoS only coin, but if coins have to age that long, the block chain will be very slow. This was my point at the start of ADTv2, I was ignored then. if you have a crazy short coin age to stake its not much different from trying to have crazy short block times we have had no issues with the stake time the issue causing the problem is stake blocks being broadcast before the block chain is in sync causing forks as you have said you made the POS code for ADT so the issue was caused by code you did if that part of the code worked right we wouldn't be at the stage we are now if ADT had shorter stake time and more stake encouraging people to stake the problem we now have would be 10 times worse ! changes can be done in the future if things don't work out well or the users want it right now the main issue is the POS causing forks I changed 2 parms, as I was asked to do. That was all I did. You can clearly see that here ( https://github.com/CryptoRepairCrew/Android-Token-V2/commits/master/src) I was not asked to review all the of the problems, and fix them. This would be the admins job. Black coin has the stake starting in hours, not days or weeks or months. It is fine. If you are having problems with clients staking before full block chain download. You can tighten this via line 4336 in main. while (vNodes.empty() || IsInitialBlockDownload()) This code works well for every other client out there, but if you are having trouble you could add in a min number of peers, or a 5 min wait to be sure, ect. This should also not be an issue if the Checkpoint server is running, as it would simply reject those blocks and the chain would carry on as normal. Edit: To be clear, I have 0, repeat ZERO desire to take over this coin. I have no problem offering advice, but I will not do the work for you. |
|
|
|
Dencoin is in the franko collective, I am also along with TEK, hes done wok for TEK before. Everyone in the collective works together to help each other daily, its a very active group 24/7 skype activity etc. He wants to possibly provide a service for TEK himself(he has ran a Tekcoin pool before but i think he has another idea atm) and needed/wanted the source to work. You can search through threads about his pools etc, very trustworthy legit guy. WE really need this fix lets pony up a nice bounty, it will let us get out working syncing wallets updated mac etc.
This is good. I do hope this done properly on github, so we can track and review the source code changes easily. Hopefully it gets released sooner rather then later.  |
|
|
|
presstab, or tranz, I'm reading through the code, something I've wanted to do, but it's a bit overwhelming, huge congrats to you guys that know what it's doing.
I was trying to find some simple things, like stake age, stake interest, etc. I found the total coins and block.
One question is why is everything * COIN, which is like 1000000?
static const int64 COIN = 1000000;
int64 nSubsidy = 1 * COIN;
static const int64 MAX_MONEY = 100000000 * COIN;//100 million
Anyway, it doesn't make much sense, one line in main.h says 5% interest, and then in main.cpp it says 100% but the exact same variable is assigned, no modifications, so wouldn't it still be 5%
I do see in main.cpp that you do some coinyear manipulations, I expect this is where you get the 40% from.
// tekcoin: reward for coin-year is cut in half every 64x multiply of PoS difficulty
// A reasonably continuous curve is used to avoid shock to market
// (nRewardCoinYearLimit / nRewardCoinYear) ** 4 == bnProofOfStakeLimit / bnTarget
//
// Human readable form:
//
// nRewardCoinYear = 1 / (posdiff ^ 1/4)
I can't get macosx to compile, evidently it's an issue with maverick and some binaries. Trying to see if I can work around it, gets toward the end, and I get unknown symbols, etc.
--o
You don't want to use Floating Point Arithmetic in the wallet, it can be difficult to get cross system compiles to all work in the exact same way. So anything dealing with the number of coins is multiplied by COIN. This way you can still do normal integer division, but get to the same answer, instead of dealing with decimals. Regarding the stake algo. This is an inflation control method. Many coins use this same thing to lower the yearly interest as the number of coins and the amount of stake increases. Without such a control in place, the coin would be subject to run away inflation. Look what happened to CENT. About the Mac, this is still out of my knowledge based, hopefully for not much longer. Unick has help get a mac wallet for HBN, so he may be able to comment. He is very busy with other project too, so try not to bug him too much with 100 PMs  |
|
|
|
2.5% POS / 15 days for 6 months lowering by 0.5% every 6 months until it hits 1%
You really lower the number of days for stake. 15 days is WAY to long. Should be more like 5 days or even less. You want a PoS only coin, but if coins have to age that long, the block chain will be very slow. This was my point at the start of ADTv2, I was ignored then. |
|
|
|
Has anyone else using the Windows wallet noticed that it doesn't open fast anymore? When Tranz first released the update where he said he had addressed a problem that was slowing the loading process, my wallet opened lightning fast at first - I think like 10-20 seconds.
My computer had to be restarted yesterday and I noticed the hbn wallet took a really long time to open.
it works really fine for me - 15 to 20 secs to open Yes, the only time it is slow, is if you set it to start up with Windows. I think windows simply limits the CPU usage until all other process are loaded. I notice the same thing with BitCoin Core as well. |
|
|
|
Have you asked Tranz?
he made it clear last time that he doesn't want to help competing coins Please don't tell lies. I have done work for ADT twice now. I have helped RPC, TEK, GLB, and a few others. Some for free, and some I have received payment, although I never asked for a penny. I did give you advice on your ADTv2 to increase not only the PoS interest (slightly) but more importantly to speed up the process. You said No. I listened, and told ahmed you were making a mistake. I get no less then 10+ PMs a week asking for help with their coins, or creating one for them, ect. I can't do this. So my main response is no, sorry. I am still at a complete loss, how anyone, and there are many out there, can be an admin of a C++, Crypto Currency, and not be able to code? What exactly are you doing? Anyway Zach I wish you no ill will. But please don't drag my name through the mud because you are having troubles. Good luck! |
|
|
|
I've had 2 crashes in the same situation, trying to send a transaction and the client quits Application Specific Information:
abort() called
terminating with uncaught exception of type std::length_error: basic_string::_S_create it's not a big deal, just wanted to mention it Which OS is this? And is your wallet encrypted? I thought I mentioned it  It's OS X (Mavericks) and yes it's encrypted Hmm ok. I think there is still a small bug, that if the wallet is encrypted but unlocked, and you send coins. It first locks the wallet, but still tries to run stake. If you don't type in your password quickly enough, the wallet could crash. If you cancel it, it simply locks the wallet and stops the stake. A work around, would be to lock the wallet manually first, then send the coins, then unlock when done. Or you could use the rpc command walletpassphrase without the mintonly switch. This will allow all sends, without first locking the wallet, and prompting for password. I have only thought this could be the case, but didn't see a real world issue till now. I'll look more closely at this. Thanks unick. |
|
|
|
I've had 2 crashes in the same situation, trying to send a transaction and the client quits Application Specific Information:
abort() called
terminating with uncaught exception of type std::length_error: basic_string::_S_create it's not a big deal, just wanted to mention it Which OS is this? And is your wallet encrypted? |
|
|
|
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? carloss Hello Carloss. Does this happen only during initial synchronization with the network? Or all the time.
If all the time, there is a known bug in older version of boost, which can cause the wallet to go out of sync. I am using 1.55 without any issues.
If it is only during the initial block chain download, then restarting once should be more then enough. I occasionally have to do this when doing the init sync. But even on my Pi, I didn't have to do it once. I just started it up and let it go..
Its worth a shot. If this doesn't fix it, let us know. Might need to run the client in -debug mode and give me a bigger log file to help diagnose it. So far this is the first of this specific situation happening. |
|
|
|
Hello, I have often problems with the wallet (hobonickelsd, running on Ubuntu Server 14.04, compiled from latest git source). It is often stuck on something like this (snip from debug.log): 05/07/14 10:13:40 ProcessSyncCheckpoint: pending for sync-checkpoint 0000000002bde252b09a26e27d6c96d5594ca6340d6ff2de5138ca8a1f90d715 and it takes 100% CPU for a very long time or almost indefinitely without doing anything apparently useful. When I restart it, it can run for few hours or even days fine before this happens again. Any idea? Hello Carloss. Does this happen only during initial synchronization with the network? Or all the time. If all the time, there is a known bug in older version of boost, which can cause the wallet to go out of sync. I am using 1.55 without any issues. If it is only during the initial block chain download, then restarting once should be more then enough. I occasionally have to do this when doing the init sync. But even on my Pi, I didn't have to do it once. I just started it up and let it go.. |
|
|
|
I was going to say I seriously doubt they are keeping the bulk of the coins in a hot wallet. There have also been issues/exploits with malleability concerning POS coins... remember the whole blackcoin CryptoRush debacle?
Do you have a link to this? I'd like to read about it. This is the main thread that was started about it back in March, just keep in mind you have to filter through all the lies and bullshit that CR tried to push on people. https://bitcointalk.org/index.php?topic=529779.0There was a discussion of how the issue with malleability related to POS coins was updated by the major exchanges like Cryptsy early on so they didn't have any huge problems. Ok thanks for the information. So a the main issue was they were using the "accounting" system perhaps incorrectly, and not using any other method to double check inputs/outputs. In addition to that they were allowing the hot wallet to stake, thereby casing even more confusion about it's users balances. |
|
|
|
Hey guys,
The guy that was going to help me set up the new wallet has gone MIA, I'm setting up a new checkpoint server today.
I can't do the wallet work myself but if someone would like to help with that let me know.
I'll post the addnode for the checkpoint server as soon as it's ready.
I wouldn't post the IP of the CP server. Just asking to get hacked. If you are going to run it, keep it private. Just open it up to 20 connections and you should be in good shape. Did mullick give you the private key as well? |
|
|
|
I was going to say I seriously doubt they are keeping the bulk of the coins in a hot wallet. There have also been issues/exploits with malleability concerning POS coins... remember the whole blackcoin CryptoRush debacle?
Do you have a link to this? I'd like to read about it. |
|
|
|
I am also pleased to announce another merchant. A VPN Service: http://www.blueyvpn.com/At checkout just click "Pay with Alt Coin" and let them know you would like to pay with HBN. They will quote you a price and an address. I am not affiliated with them, but if you have any issues, please let us know. Thanks! |
|
|
|
Thanks King! This is free to play, just some adverts. |
|
|
|
What happens when I try to send coins to an address(for example cryptsy) but there are 0 confirms? The amount has been minused from my wallet but it didnt show in the other account? Is it possible to lose them?
Likely no. The wallet will try to resend again randomly here soon enough. If after a few hours you still don't have any confirmations you can try to run checkwallet, or perhaps start with -rescan a final method would be to try -salvagewallet. One of these should work. Is this still an issue? I just updated the rpc command rsendtx. https://github.com/Tranz5/HoboNickels/commit/a26f801dd4880a1c7a31c2fda9f821510adb3743It wasn't working, but now should be in good shape. |
|
|
|
I did try that one, same deal. Wherever the source is for this one from the original thread, that is what we need. |
|
|
|
|
Show Posts
