|
Quick update on trying to get my Cache withdrawn from exchanges after the fork:
* Poloniex did the right thing and reissued my withdrawal on the correct chain.
* Cryptsy I've chased for over a month, they're not returning my ~500 coins (just keep pointing to the transaction on the old chain)
Life lesson, Cryptsy and forks do not mix (seems to be a good excuse for them to steal coins with a plausible reason for not returning them), thankfully the loss is only a couple hundred bucks.
YMMV.
Cheers
|
|
|
|
Just for clarity though, does "something completely new" mean a new coin, and Cachecoin (and thus our holdings) become deprecated I guess was my question. P.S. just noticed your tag (Its as easy as 0, 1, 1, 2, 3) that's an awesome nod to Fib  |
|
|
|
We are closing a deal with another dev we are working to join our team who has already completed decentralized storage. This was the last piece of the puzzle, cache now has everything we will need to achieve all the goals of cache. The clean rewrite and features are all lined up now, just a matter of finishing the code now.
Since cache is an old (relative to other coins) coin and doesn't have that much attention, maybe you should consider re-branding the coin on bitcointalk. Update the OP by introducing the team and updating the developments. I know I'm new here but most people don't know anything about cache. The coin needs some attention or it doesn't matter how great the technical developments are. Might be a good idea after the rewrite. To introduce something completely new. Not a fork like all the rest of the coins Could I ask what you mean here? If you introduce something completely new, what does that mean for the future of Cachecoin and current holders? Cheers |
|
|
|
~~~... As for autoupdate, that is what we are most focused on. We are working on an implementation that would cleanly and painlessly update the wallet automagically at once. and do all the mumbojambo
Please do think this through carefully - whilst there are technical solutions to auto-update (eg code signing & having the client validate signatures on update packages etc), pools & exchanges must have the ability to disable it and it is very hard to defend against the "one man controls the network" argument - if we want Cache to succeed (and I very much do!) we have to be careful about the perception of centralization. Here's an interesting post from Greg addressing this topic in the Bitcoin context as food for thought "Auto update" is categorically not the same as manual updates.
Bitcoin is an autonomous peer to peer system. It's security, its promises of non-inflation, everything that makes it valuable depends on someone not being able to just flip a switch and redefine it. As you say, "there's no excuse" to introduce that kind of vulnerability. Bitcoin was invented to remove the requirement for that kind of trust, and if you're willing to have that kind of trust you can build systems which are much more efficient than Bitcoin.
Someone with the ability to just push auto updates would be an extreme danger to the network, and that ability would be a potential danger to those who possess it by virtue of making them an attractive target. If the core developers start telling you that you need developer controlled automatic update you can assume that we've somehow been compromised.
There are certainly things that can be done to facilitate smoother updates and we should do them: For example, deploying the gitian updater tool for users to use which checks the gitian signatures and saves them some website clicking would be a nice improvement and would strictly reduce vulnerability. (since not that many users bother to check the signatures today when they update)
Any system which would run _automatically_ if any were to exist at all, however, should only work on a long randomized time delay to allow review and alarm if there is a problem and should support negative acknowledgements, the keys for which could be spread fairly liberally.
So go ahead with your "16 coins" run autoupdates for 15 of them. Bitcoin is a decenteralized system and is staying that way.
Auto update will be optional. You'd be able to disable it. Also, auto update won't just update your wallet straight away, it will notice the update and notify you. If, you won't push the allow update button until the time when your wallet will be rejected from the network by newer wallet, it will update automatically (this won't happen if you have autoupdates off). So the auto update is somewhat not very auto. It's manual until required. And there will be an option to roll back. The packages will be signed and checked upon the auto update, and rejected if found invalid. Also, the wallet will have self diagnostic upon startup, veryfing signatures before loading itself. This would ensure that your wallet hasn't been infected by viruses or compromised. I'm pleased to see you guys have obviously put some thought into it I'd be interested in your thoughts around the 'traditional' model (ie broadcasting an alert in cases of required updates with integrators (pools/exchanges etc) polling the errors attribute from getinfo). Is the general feeling that it's insufficient, or that integrators do not follow this model even when available, or other factors? Or is the target audience for auto-updates primarily the end user? Hope I'm not distracting you with this discussion, just throwing in feedback where I think you may get value from it Cheers |
|
|
|
~~~... As for autoupdate, that is what we are most focused on. We are working on an implementation that would cleanly and painlessly update the wallet automagically at once. and do all the mumbojambo
Please do think this through carefully - whilst there are technical solutions to auto-update (eg code signing & having the client validate signatures on update packages etc), pools & exchanges must have the ability to disable it and it is very hard to defend against the "one man controls the network" argument - if we want Cache to succeed (and I very much do!) we have to be careful about the perception of centralization. Here's an interesting post from Greg addressing this topic in the Bitcoin context as food for thought "Auto update" is categorically not the same as manual updates.
Bitcoin is an autonomous peer to peer system. It's security, its promises of non-inflation, everything that makes it valuable depends on someone not being able to just flip a switch and redefine it. As you say, "there's no excuse" to introduce that kind of vulnerability. Bitcoin was invented to remove the requirement for that kind of trust, and if you're willing to have that kind of trust you can build systems which are much more efficient than Bitcoin.
Someone with the ability to just push auto updates would be an extreme danger to the network, and that ability would be a potential danger to those who possess it by virtue of making them an attractive target. If the core developers start telling you that you need developer controlled automatic update you can assume that we've somehow been compromised.
There are certainly things that can be done to facilitate smoother updates and we should do them: For example, deploying the gitian updater tool for users to use which checks the gitian signatures and saves them some website clicking would be a nice improvement and would strictly reduce vulnerability. (since not that many users bother to check the signatures today when they update)
Any system which would run _automatically_ if any were to exist at all, however, should only work on a long randomized time delay to allow review and alarm if there is a problem and should support negative acknowledgements, the keys for which could be spread fairly liberally.
So go ahead with your "16 coins" run autoupdates for 15 of them. Bitcoin is a decenteralized system and is staying that way.
|
|
|
|
hey guys...thanks for the quick reply. Much appreciated and shows the level of support the cachecoin community has. Unfortunately I'm afraid I've hit the worst case scenario mentioned by kalgecin. An updated & sync 5.3 wallet still shows zero balance. Looks like I've lost my entire balance of around 177 cachcoins to old fork staked limbo. <rant> I've missed updating my wallet by 2 days. I've heard many times "Dont invest what you cannot afford to lose". I invested in cache to capitalize on the scrypt ASIC deal put on by FIB, and believing in jasinlee and the involvement FIB and others (such as an active dev) had in this community was happy to keep what little I had left to stake in hopes cache prices would rise again. As a paycheck to paycheck fellow, I am no means a big time investor with money to play around, so every lost dollar does hurt. I cannot say I am not both saddened/upset and a bit angry at losing my coins. Bad luck I suppose. I've lost fiat dollars due to cryptocoin instability and poor choices in the exchanges, I've lost amounts of coins in the past due to local/online wallets being hacked (good old pre-wallet encryption days), exchanges being hacked, exchanges closing, etc....but never from a wallet update. I am not overly familiar with POS coins, so I am not sure why having a staked balance during a fork would force the coins into limbo. I assume there are others in my position who have left their boxes happily humming away staking coins only ending up to lose coins in stake due to an update...IMO this isn't really acceptable. there should have been a way to unstake coins in an unsync'd wallet to enable import into a new version....but my technical knowledge is far from knowing anything. sorry for my venting. I'm not sure if I will continue on or support any other POS coins any longer due to this reason... </rant> jasinlee ask for any future updates in the future - please include an auto-updating wallet and protection on staked balances. IF the cryptocoin community is to survive, issues like this must be addressed as merchants and other users will not adopt a payment system that necessitates constant vigilance to protect themselves from these circumstances. popup box indicating new wallet and time frame to update perhaps? pls donate to: CACH: CdnDi8pY5ieNG5GNC2sXd5oHhygQU3AoYG LTC: LPsonzJwQL94JN6ggGUM5c9z7zQaeewHuA BTC: 1HDRVsxQh8PntXCxFAUQ36uiTtojWop3TQ wallet 5.0.2  wallet 5.3  Please rescan Append --rescan to the end of your shortcut and re-open your wallet, please let us know how you get on. Cheers |
|
|
|
Tried to buy some CACHecoin from both Poloniex and Cryptsy. Withdrew both last night, neither has appeared in my wallet (running 5.3). Got the TXID from Poloniex - 6ba3ac3cdfbbbd7e37c031287b65f778a007748db81d62b81a9ff5b7b9629d76 Can't seem to find the TXID for the withdrawal on Cryptsy.  Just wondering, is it possible these exchanges are still running the old versions, would that cause my withdrawals to be sent on the wrong chain? Appreciate any ideas/suggestions to give the exchanges? Will raise a couple support tickets I guess. Cheers |
|
|
|
Think I'm gonna throw up a little bit...    Credit Spondoolies for the pics.. |
|
|
|
Bitstamp are reversing verification for already verified members. I have a deal lined up that I was trying to pay for (several thousand dollars, a deal which I must now miss out on (few choice words come to mind Bitstamp) - logged into Bitstamp to grab some bitcoin to send and received a message saying my verification was not approved and I would need to resubmit documents. Note this was not even emailed to me, just waiting until I log in (why wait until I actually need to use your service to start remediation???)  I've been verified since last year and have done plenty of depositing, trading and withdrawing in that time.  So - WTF? No notice or warning, just all my funds are frozen until I can verify AGAIN. Serves me right for having funds on an exchange I guess. I thought Stamp were supposed to be one of the better exchanges, but outright freezing withdrawals (bitcoin included) of already verified members with NO NOTICE is just f*cking disgusting behaviour. Apologies for the language, just angry at having some 3rd party cost me a business deal for some arbitrary reason of their choice. TL:DR; 1) Bitstamp may freeze your funds regardless of if you are already verified, assuming because of some new documentary requirement 2) You won't know it's happened until you log into your account (they won't email you) 3) You must re-verify before you can access any bitcoin held at Stamp Hope it's just me but somehow I doubt it. |
|
|
|
|
Sorry to all those who lost on this - I actually spoke with the guy about a 100pcs order and was offered a great price a couple days ago.
Did some research (his post history from before a few weeks ago is all junk) and spoke to a contact about the wholesale price Gridseed were providing and this guy was $40 per unit under wholesale. Dodgy as.
Really hope you guys get your money back or your miners.
|
|
|
|
|
Just thought I'd post to say that I actually got my 5 BTC back (deposited just after the announcement). I was surprised, but I'm satisfied - sorry to everyone else having trouble but since I called them dirty scumbag thieves in my last post, since they gave me my money back only fair to post a retraction.
Best of luck to the rest of you.
|
|
|
|
I don't know how they're claiming to be anything but a bunch of dirty scumbag thieves.
About two hours after they announced this, I made the mistake of depositing around 5 BTC to Vircurex. There was not a single notice, warning or any other notification anywhere on the login, deposit, or trading pages. Even checked the FAQ about deposit times, no warnings in there either. They created a new deposit address for me, please deposit away! Because I don't sit researching crypto news 24/7 I had no idea.
Then the money never shows up, I go researching, and see they've made this announcement, just not put any warnings on their own site (I did find an announcements page after the fact, but you have to look for it).
They've said customer deposits just won't be credited? Then in the same statement they say future deposits won't be affected?
? ? ? ? ? ? ? ? ? ? ?
Well that's almost 3 grand down the tube for me. After Gox as well - is anyone else getting sick of this? I'm seriously considering starting a bounty on the heads of these exchange guys. NOTHING ILLEGAL - just a bounty to use all LEGAL (common law) means to bring these guys to task for the money they are stealing. Mark 'finds' quarter of a million bitcoins? Vircurex take a new customers deposit and give it to old customers? It's our own fault as a community - I genuinely believe that - we have no 'teeth' & are all so concerned with making the next dollar that we allow people to manipulate and steal from us without making any effort to ensure those party to these things take responsibility for their actions.
Crypto will die because of these guys - and we all bear just as much responsibility for allowing it to happen.
It's not more than 4 month ago BIPS "lost" 1295 BTC - today I am still not convenience that it was a hack, how can you both loose everything in hot-wallets and cold-storage at in a "top modern high secure datacenter"... lot of talk about lawsuits back then... but nothing really happened, the owner walks away. Btw. I am sorry for your loss, I know how it feels, I have lost way to many bitcoins myself due to all these thieves. Thanks Yeah that's kind of my point - we all b*tch and moan but we're all talk (not pointing fingers, just stereo-typing our entire community  ). Nothing ever gets done and that's half the problem - if you take away the fear of being punished then it's just easy money for those with shall we say a less than ideal conscience. I was incredibly surprised how silent the Bitcoin Foundation was in the whole Gox debacle, I was expecting public advisories etc but they also just sat back chilling while many of their supporters money went up in flames. I do strongly believe in Crypto, but the last couple of months have been a huge eye opener in watching what people can get away with and how impotent the responses are  |
|
|
|
|
I don't know how they're claiming to be anything but a bunch of dirty scumbag thieves.
About two hours after they announced this, I made the mistake of depositing around 5 BTC to Vircurex. There was not a single notice, warning or any other notification anywhere on the login, deposit, or trading pages. Even checked the FAQ about deposit times, no warnings in there either. They created a new deposit address for me, please deposit away! Because I don't sit researching crypto news 24/7 I had no idea.
Then the money never shows up, I go researching, and see they've made this announcement, just not put any warnings on their own site (I did find an announcements page after the fact, but you have to look for it).
They've said customer deposits just won't be credited? Then in the same statement they say future deposits won't be affected?
? ? ? ? ? ? ? ? ? ? ?
Well that's almost 3 grand down the tube for me. After Gox as well - is anyone else getting sick of this? I'm seriously considering starting a bounty on the heads of these exchange guys. NOTHING ILLEGAL - just a bounty to use all LEGAL (common law) means to bring these guys to task for the money they are stealing. Mark 'finds' quarter of a million bitcoins? Vircurex take a new customers deposit and give it to old customers? It's our own fault as a community - I genuinely believe that - we have no 'teeth' & are all so concerned with making the next dollar that we allow people to manipulate and steal from us without making any effort to ensure those party to these things take responsibility for their actions.
Crypto will die because of these guys - and we all bear just as much responsibility for allowing it to happen.
|
|
|
|
|
Pre-orders are opening in an hour or two and with them accepting CACH at 0.01BTC I think it'll be sold out in minutes
|
|
|
|
I've got it working now I'm using powered hubs - 20 gridseeds on the one Pi controller.
The crashes have gone away, the problem now is cgminer will stop submitting work after about ten minutes (the miners keep hashing, just no shares submitted for 30mins+). Killing it and starting a new process doesn't help. Rebooting the USB hub doesn't help. Power cycling the miners doesn't help.
Cycling the Pi seems to fix it temporarily until the next time.
I'm running with 12, so it's possible 20 is too much. Might want to also verify that the PSU is still ok by using a multimeter to check 12V rail when cgminer stops submitting shares. Interestingly I've noticed there is actually a slow decline in work utility until it hits a threshold where it just stops submitting shares at all. Work utility degradation starts after about 1 minute. Going to get the multimeter out now. Doesn't seem to be a power issue, 12v stable. Will cut down the number of miners and test. |
|
|
|
I've got it working now I'm using powered hubs - 20 gridseeds on the one Pi controller.
The crashes have gone away, the problem now is cgminer will stop submitting work after about ten minutes (the miners keep hashing, just no shares submitted for 30mins+). Killing it and starting a new process doesn't help. Rebooting the USB hub doesn't help. Power cycling the miners doesn't help.
Cycling the Pi seems to fix it temporarily until the next time.
I'm running with 12, so it's possible 20 is too much. Might want to also verify that the PSU is still ok by using a multimeter to check 12V rail when cgminer stops submitting shares. Interestingly I've noticed there is actually a slow decline in work utility until it hits a threshold where it just stops submitting shares at all. Work utility degradation starts after about 1 minute. Going to get the multimeter out now. |
|
|
|
Any chance of a Pi image with compiled binary? Here's a compiled binary built on raspbian: https://db.tt/UygLkqwdHi, I already had it compiled but downloaded yours nevertheless... I get A:0 R:0 HW:0 WU:0.0/m THe command line I'm using is: ./cgminet -o: pooladress -u user -p password --griseed-options=freq=850 Even address the baudrate to option but it sill doesn't work. THe Debug info states the following: LIBUSB_ERROR_TIMEOUT It seems that it fails to initialize the GridSeed Miners. regards, P. P.S. - Minerd works ok. You're missing --scrypt from your cgminer command |
|
|
|
|
I've got it working now I'm using powered hubs - 20 gridseeds on the one Pi controller.
The crashes have gone away, the problem now is cgminer will stop submitting work after about ten minutes (the miners keep hashing, just no shares submitted for 30mins+). Killing it and starting a new process doesn't help. Rebooting the USB hub doesn't help. Power cycling the miners doesn't help.
Cycling the Pi seems to fix it temporarily until the next time.
|
|
|
|
Any chance of a Pi image with compiled binary? Here's a compiled binary built on raspbian: https://db.tt/UygLkqwdThanks heaps - is the MHz set as compile time? Anyway to get 850mhz? --gridseed-options=baud=115200,freq=850 still no work utility d'oh forgot the --scrypt Also this seems to work OK for 10 miners but over that kernel panics the Pi.
EDIT: Nope crashes with 10 also, tried with two different sets of 10 miners  Also seems that no work is getting submitted and work utility is zeroAdded a powered hub into the mix, looking much better Fingers crossed it stays like this GSD 0: 850 MHz | 361.7K/360.4Kh/s | A: 889 R: 0 HW:0 WU: 3.0/m
GSD 1: 850 MHz | 361.8K/362.2Kh/s | A: 381 R: 0 HW:0 WU: 1.3/m
GSD 2: 850 MHz | 361.7K/362.7Kh/s | A:1270 R:127 HW:0 WU: 4.7/m
GSD 3: 850 MHz | 361.7K/361.4Kh/s | A:1397 R: 0 HW:0 WU: 4.7/m
GSD 4: 850 MHz | 361.7K/362.6Kh/s | A: 762 R: 0 HW:0 WU: 2.6/m
GSD 5: 850 MHz | 361.7K/361.0Kh/s | A: 127 R: 0 HW:0 WU: 0.4/m
GSD 6: 850 MHz | 361.7K/360.6Kh/s | A: 889 R: 0 HW:0 WU: 3.0/m
GSD 7: 850 MHz | 361.8K/362.7Kh/s | A: 889 R: 0 HW:0 WU: 3.0/m
GSD 8: 850 MHz | 361.7K/360.7Kh/s | A: 889 R: 0 HW:0 WU: 3.0/m
GSD 9: 850 MHz | 361.7K/360.6Kh/s | A: 508 R: 0 HW:0 WU: 1.7/m
GSD 10: 850 MHz | 361.7K/360.8Kh/s | A: 577 R: 0 HW:0 WU: 1.7/m
GSD 11: 850 MHz | 361.7K/362.7Kh/s | A: 508 R: 0 HW:0 WU: 1.7/m
GSD 12: 850 MHz | 361.7K/362.0Kh/s | A: 958 R: 0 HW:0 WU: 3.0/m
GSD 13: 850 MHz | 361.7K/362.7Kh/s | A: 635 R: 0 HW:0 WU: 2.1/m
GSD 14: 850 MHz | 361.7K/362.6Kh/s | A: 381 R: 0 HW:0 WU: 1.3/m
GSD 15: 850 MHz | 361.7K/362.3Kh/s | A: 381 R: 0 HW:0 WU: 1.3/m
GSD 16: 850 MHz | 361.8K/362.8Kh/s | A:1016 R: 0 HW:0 WU: 3.4/m
GSD 17: 850 MHz | 361.7K/362.2Kh/s | A: 762 R: 0 HW:0 WU: 2.6/m
GSD 18: 850 MHz | 361.7K/361.6Kh/s | A:1524 R: 0 HW:0 WU: 5.1/m
GSD 19: 850 MHz | 361.8K/362.2Kh/s | A: 958 R: 0 HW:0 WU: 3.0/m
|
|
|
|
|
Show Posts
