.

[catotune]

I think our problem was a lack of testing and an necessary rush to deploy a new version.  I never understood the urgency. Coordinating a fork takes time and requires community acceptance/cooperation.  

I agree completely with this statement, especially the part about a fork requiring community acceptance and cooperation.

I never got the sense that the entire CRAVE community supported, or even really knew about, this fork. I feel like someone (I won't say some "child", because I won't hold his age against him) just decided to make a bunch of crazy changes to a well-established, stable coin, and created a thread announcing he was going to take it over and everyone better upgrade to his version or else.

And like an idiot, I followed along. I lost dozens of hours trying to keep up with this nonsense, and I lost hundreds of coins in the transition between all the different versions (addresses with large balances whose private keys don't have any CRAVE when importing back into the old wallet).

If ICM updates his source, I will update my client. If this, or any other, random dev announces that he is going to "take over" this coin in the future, I am going to take it with a huge grain of salt. Lesson learned.

[CryptoVote]

I agree completely with this statement, especially the part about a fork requiring community acceptance and cooperation.

I never got the sense that the entire CRAVE community supported, or even really knew about, this fork. I feel like someone (I won't say some "child", because I won't hold his age against him) just decided to make a bunch of crazy changes to a well-established, stable coin, and created a thread announcing he was going to take it over and everyone better upgrade to his version or else.

And like an idiot, I followed along. I lost dozens of hours trying to keep up with this nonsense, and I lost hundreds of coins in the transition between all the different versions (addresses with large balances whose private keys don't have any CRAVE when importing back into the old wallet).

If ICM updates his source, I will update my client. If this, or any other, random dev announces that he is going to "take over" this coin in the future, I am going to take it with a huge grain of salt. Lesson learned.

Most of the changes made were meaningful but it wasn't well explained to the community.  Niitassin is a great developer but releasing a new version is not all dev work like end user acceptance.  Most the time the developer is way ahead of the end users at understanding the changes (because we have to code them) so explaining can be difficult.

If we gave folks a few MONTHS to test, upgrade and digest the changes, this would have been a much smoother transition.  ICM is likely gone forever so please don't scare away the devs that want to help. 

[CryptoVote]

Oops.

[catotune]

Most of the changes made were meaningful but it wasn't well explained to the community.  Niitassin is a great developer but releasing a new version is not all dev work like end user acceptance.  Most the time the developer is way ahead of the end users at understanding the changes (because we have to code them) so explaining can be difficult.

If we gave folks a few MONTHS to test, upgrade and digest the changes, this would have been a much smoother transition.  ICM is likely gone forever so please don't scare away the devs that want to help. 

Well said, and I agree that a well thought-out and communicated update to Crave would be fine, as long as the community is given enough time to understand, test, and give their consensus on it.

I just never felt right about this one, and my doubts were justified in the end. I am usually not this upset about anything that happens in the altcoin universe, but this "update" really cost me a lot of money and time that I should have instead spent with my family.

[cisahasa]

from console:

makekeypair

{
"PrivateKey" : "308201130201010420e62aa5c9c1f910ad9b0b8e2a1b1ccbb1f7a5fc6c5f03d3da603707610697b 385a081a53081a2020101302c06072a8648ce3d0101022100ffffffffffffffffffffffffffffff fffffffffffffffffffffffffefffffc2f300604010004010704410479be667ef9dcbbac55a0629 5ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b4 48a68554199c47d08ffb10d4b8022100fffffffffffffffffffffffffffffffebaaedce6af48a03 bbfd25e8cd0364141020101a144034200041cf40e6019ecfcf2f50ec953c1230c3acf6975eaeca1 4c373ee97d716a4d4b3606c0359c61f6bc4791aaa010229d3316b60194981e24f6c8cf968d13bbd 93120",
"PublicKey" : "041cf40e6019ecfcf2f50ec953c1230c3acf6975eaeca14c373ee97d716a4d4b3606c0359c61f6b c4791aaa010229d3316b60194981e24f6c8cf968d13bbd93120"
}

[JJ12880]

This is my mistake of doing forks that are just too much, so for now I will have to revert to the Adrenaline Version.... (With the Market and SHA256d Fork)

Everyone makes mistakes here and there. Ive had to learn the hard way too. There have been times ive pushed live code updates to projects that SHOULD have worked, but ended up breaking everything for one reason or another. Ive learned I have to make things iddiot proof, and test test test. If there is a way to break something, some knucklehead will find a way.


IMHO, this is a good place to start.  I wish i was more familiar with C++, I would offer to help.

revert code back to that market version.
update protocol every time you make a change.
you should revert version and pump protocol to 70001
atleast generate new key pairs to alert/checkpoint code.
(there are still 2 key pairs for spork and masternodes)

now the keys are in hands of icm, he can destroy the coin at this point if he wants.

JJ

[CryptoVote]

if you want to fix this
revert code back to that market version.
update protocol every time you make a change.
you should revert version and pump protocol to 70001
atleast generate new key pairs to alert/checkpoint code.
(there are still 2 key pairs for spork and masternodes)

now the keys are in hands of icm, he can destroy the coin at this point if he wants.

Interesting... Could you please explain what this means? What do the 2 key pairs for spork and masternodes signify?

If ICM destroying the coin is indeed the danger, then I think these keys are a million times more important than changing the algorithm and forking Crave to be PoW, which I think is completely unnecessary.

But what would make this dev more trustworthy than ICM if the problem is the same - one person holds all the keys to destroy a coin? ICM may or may not be gone, but he at least made me a lot of money and never wasted my time. This dev made me lose over 1 BTC worth of Crave and has shown extremely erratic judgment (Nothing personal, he is probably very intelligent, but it will take a lot to regain my trust).

My erratic judgement is due to my panic problem.... I tend to panic (a lot)

I will solemnly try to gain back your trust. The keys were not changed because we thought there was no immediate risk...

If we change key(s), who will hold and keep them safe?  Doesn't sound like a decentralized solution if one key holder can disrupt the system by activating an alert.  Maybe this alerting functionality should be disabled or limit its capacity to disrupt the system.  I don't think it was intended to keep this public alerting feature on or active after a coin matures but we have many version before Crave is mature.

I think adding the following functionality will help Crave:

1) Masternode consensus voting using a blockchain (like Dash).  Proceeds used for dev direction and funding foundation projects.
3) Reputation System for the Urge market.
2) User name generation for the Urge market (charge a fee to create a name and own the key)
4) VanityGen so we can prefix our wallet addresses
5) HTML5 UI for the entire wallet.

I will be implementing all these for another coin but it will take me a LONG time by myself. 

[cisahasa]

about alert keys, also bitcoin has them, but who holds the keys?
they say that they have a failsafe system if one of key holders will go mad.
what is that failsafe system, just cancelling alert by another holder?

[CryptoVote]

about alert keys, also bitcoin has them, but who holds the keys?
they say that they have a failsafe system if one of key holders will go mad.
what is that failsafe system, just cancelling alert by another holder?

I think the failsafe system is to ignore the alert. The purpose seems to push critical updates so I could see the alert showing up in the UI and debug.log with the option to shut it off with a command or crave.config setting.

[cisahasa]

about alert keys, also bitcoin has them, but who holds the keys?
they say that they have a failsafe system if one of key holders will go mad.
what is that failsafe system, just cancelling alert by another holder?

I think the failsafe system is to ignore the alert. The purpose seems to push critical updates so I could see the alert showing up in the UI and debug.log with the option to shut it off with a command or crave.config setting.

yes there is config optinon to ignore it.. but most people wont be able to do it(knowhow)

[Kamatezo]

Niitassin Before you take a break contact bittrex and help them with the wallet CRAVE. Because we do not have access to the wallet at CRAVE. It is DISABLED Bittrex.

[CryptoVote]

Niitassin Before you take a break contact bittrex and help them with the wallet CRAVE. Because we do not have access to the wallet at CRAVE. It is DISABLED Bittrex.

I agree.  Making sure Bittrex is okay should be priority #1.

[Delita Heiral]

[richiela]

Niitassin Before you take a break contact bittrex and help them with the wallet CRAVE. Because we do not have access to the wallet at CRAVE. It is DISABLED Bittrex.

I agree.  Making sure Bittrex is okay should be priority #1.

Whats the current consensus? Are we rolling back to the old wallet?  If someone can provide some guidance, i'll get everything back online here...

thanks,
richie@bittrex

[cisahasa]

Niitassin Before you take a break contact bittrex and help them with the wallet CRAVE. Because we do not have access to the wallet at CRAVE. It is DISABLED Bittrex.

I agree.  Making sure Bittrex is okay should be priority #1.

Whats the current consensus? Are we rolling back to the old wallet?  If someone can provide some guidance, i'll get everything back online here...

thanks,
richie@bittrex

i will answer this one
consensus is to revert code before oxything
https://github.com/laptoptip/crave/tree/f6b61d2a730828eb4644be52fb0e050e6933c570

but dev should pump the keys and version to that one.

[daveolake]

v1.4.5.0-g32a928e So is this the one we are going with? If so lets put it out there nice and clear. get it on front page and all the other forum threads cravers may be looking at.   

[Kamatezo]

Niitassin Before you take a break contact bittrex and help them with the wallet CRAVE. Because we do not have access to the wallet at CRAVE. It is DISABLED Bittrex.

I agree.  Making sure Bittrex is okay should be priority #1.

Whats the current consensus? Are we rolling back to the old wallet?  If someone can provide some guidance, i'll get everything back online here...



thanks,
richie@bittrex

Richiela - Yes . We go back to the old wallet. Wallets bittrex is OFFLINE and my CRAVE did not reach the bittrex 999.99998 crave the following address:
C2JhqhRdqHFT1HSQYqoQ8VjKU3Sz4sFMcx  Richela Pleas HELP ME

https://chainz.cryptoid.info/crave/tx.dws?468210.htm

[8-bit-Party]

Wallets bittrex is OFFLINE and my CRAVE did not reach the bittrex 999.99998 crave the following address:
C2JhqhRdqHFT1HSQYqoQ8VjKU3Sz4sFMcx  Richela Pleas HELP ME

Sorry, your coins are lost.


Just kidding!

[Kamatezo]

Wallets bittrex is OFFLINE and my CRAVE did not reach the bittrex 999.99998 crave the following address:
C2JhqhRdqHFT1HSQYqoQ8VjKU3Sz4sFMcx  Richela Pleas HELP ME

Sorry, your coins are lost.


Just kidding!

Why do you think so???

[cisahasa]

Wallets bittrex is OFFLINE and my CRAVE did not reach the bittrex 999.99998 crave the following address:
C2JhqhRdqHFT1HSQYqoQ8VjKU3Sz4sFMcx  Richela Pleas HELP ME

Sorry, your coins are lost.


Just kidding!

Why do you think so???

https://chainz.cryptoid.info/crave/tx.dws?468210.htm

there your coins are, dont listen bullshit