[ANN][CACH] CACHeCoin released based on scrypt-jane - page 43.

kalgecin

hero member

Activity: 819

Merit: 1000

Quote from: mojojojo173 on June 08, 2014, 01:22:59 AM

Quote

You may send me a copy of the wallet.dat to [email protected]. I'll take a look at it and see what i might be able to do

email sent. thank you so much for your efforts.

I'll get back to you by monday evening. Gotta spend weekend with family Wink

Edit:
found a fix for you. open the wallet, go to help -> debug window : select the console tab and type repairwallet. it should say that it found 1 tx and recovered. then restart the wallet. or i can send you your 176.600441 coins if you wish

jasinlee

hero member

Activity: 742

Merit: 500

Its as easy as 0, 1, 1, 2, 3

I duplicated the bug, back to work.

mojojojo173

newbie

Activity: 5

Merit: 0

Quote

You may send me a copy of the wallet.dat to [email protected]. I'll take a look at it and see what i might be able to do

email sent. thank you so much for your efforts.

gentamicin

full member

Activity: 161

Merit: 100

wallet crashes when cachecoin channel opens

jasinlee

hero member

Activity: 742

Merit: 500

Its as easy as 0, 1, 1, 2, 3

Still needs some more work, but thats a good start/glimpse.

kalgecin

hero member

Activity: 819

Merit: 1000

Quote from: Burninj on June 07, 2014, 07:09:38 PM

Quote from: jasinlee on June 07, 2014, 12:10:42 PM

If someone wants to test the social tab for us.

How I would do that?

you can get it here ;-)
https://github.com/kalgecin/CACHeCoin_binaries/blob/master/cachecoin-5.3.2.exe

jasinlee

hero member

Activity: 742

Merit: 500

Its as easy as 0, 1, 1, 2, 3

We will post it soon.

Burninj

legendary

Activity: 1148

Merit: 1000

Quote from: jasinlee on June 07, 2014, 12:10:42 PM

If someone wants to test the social tab for us.

How I would do that?

kalgecin

hero member

Activity: 819

Merit: 1000

https://plus.google.com/u/0/b/103230638407423201229/103230638407423201229/about

kalgecin

hero member

Activity: 819

Merit: 1000

Quote from: lishbtc on June 07, 2014, 07:48:01 AM

Quote from: kalgecin on June 07, 2014, 06:43:03 AM

Quote from: lishbtc on June 07, 2014, 03:51:24 AM

Quote from: kalgecin on June 07, 2014, 02:01:22 AM

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

Quote from: gmaxwell on September 13, 2013, 07:39:10 PM

"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

Actually, primary target are the exchanges. They simply cannot keep track of all the wallets they host. It really is difficult, even through alerts. Having worked on an exchange, I know. Thus it'll be much easier for the owners of exchange to enable the auto update, and always be sure to be on the right track. In the end, the coin protocol is always centralized by the core dev team. A coin cannot have a decentralized protocol, since everyone must follow the same rules. I tend to listen to my users and make modifications based on their majority request. We've incorporated many of the requested features and keep listening to you guys.

kalgecin

hero member

Activity: 819

Merit: 1000

Quote from: mojojojo173 on June 07, 2014, 12:25:55 PM

Quote from: kalgecin on June 07, 2014, 02:01:22 AM

Yes, append --rescan. that should give you back coins you had before the fork.

nope...didn't work. still a zero balance. I've also tried re-deleting the cachecoin folder in %appdata% and resyncing along with appending -rescan.

Just out of curiosity...would the nodes in cachcoin.conf make any difference?

thanks again for all the help.

You may send me a copy of the wallet.dat to [email protected]. I'll take a look at it and see what i might be able to do

jasinlee

hero member

Activity: 742

Merit: 500

Its as easy as 0, 1, 1, 2, 3

Quote from: mojojojo173 on June 07, 2014, 12:25:55 PM

Quote from: kalgecin on June 07, 2014, 02:01:22 AM

Yes, append --rescan. that should give you back coins you had before the fork.

nope...didn't work. still a zero balance. I've also tried re-deleting the cachecoin folder in %appdata% and resyncing along with appending -rescan.

Just out of curiosity...would the nodes in cachcoin.conf make any difference?

thanks again for all the help.

The exchange should be able to delete the tx too, thus restoring your balance on the exchange.

kenboy

sr. member

Activity: 378

Merit: 250

is it the alo same as vtc?

mojojojo173

newbie

Activity: 5

Merit: 0

Quote from: kalgecin on June 07, 2014, 02:01:22 AM

Yes, append --rescan. that should give you back coins you had before the fork.

nope...didn't work. still a zero balance. I've also tried re-deleting the cachecoin folder in %appdata% and resyncing along with appending -rescan.

Just out of curiosity...would the nodes in cachcoin.conf make any difference?

thanks again for all the help.

jasinlee

hero member

Activity: 742

Merit: 500

Its as easy as 0, 1, 1, 2, 3

If someone wants to test the social tab for us.

lishbtc

full member

Activity: 184

Merit: 100

Quote from: kalgecin on June 07, 2014, 06:43:03 AM

Quote from: lishbtc on June 07, 2014, 03:51:24 AM

Quote from: kalgecin on June 07, 2014, 02:01:22 AM

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

Quote from: gmaxwell on September 13, 2013, 07:39:10 PM

"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

kalgecin

hero member

Activity: 819

Merit: 1000

Quote from: lishbtc on June 07, 2014, 03:51:24 AM

Quote from: kalgecin on June 07, 2014, 02:01:22 AM

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

Quote from: gmaxwell on September 13, 2013, 07:39:10 PM

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

lishbtc

full member

Activity: 184

Merit: 100

Quote from: kalgecin on June 07, 2014, 02:01:22 AM

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

Quote from: gmaxwell on September 13, 2013, 07:39:10 PM

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

kalgecin

hero member

Activity: 819

Merit: 1000

Quote from: mojojojo173 on June 07, 2014, 12:53:06 AM

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.

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

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

Yes, append --rescan. that should give you back coins you had before the fork. 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

lishbtc

full member

Activity: 184

Merit: 100

Quote from: mojojojo173 on June 07, 2014, 12:53:06 AM

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.

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

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

Topic: [ANN][CACH] CACHeCoin released based on scrypt-jane - page 43. (Read 224435 times)