Quote from: kanes on November 06, 2014, 11:58:34 AM
Is the coin dead?

Yes: https://bitsharestalk.org/index.php?topic=8916.msg127027#msg127027

Is the coin dead?

The PoW was merged mining anyways

I forked the lotto part and have integrated it into NoirShares. The first issue I'll point out is that after perusing LTS code, I have not seen anything that points to key theft.

Second, I think for a failed attempt this was good. I intend to keep trying on my fork. He has already done most of the work and pointed out the issues so if someone was really interested, they could continue the LTS chain.

Not sure if I am on the right track but I've already begun discussing ways around the forking issues. Since NRS already uses a seperate random seeding method to randomize PoW , perhaps it can work dual purpose and maybe function with the lotto.

I say let Freetrade go and focus on something else, people love to point at him in a dark light but has anyone ever really considered the amount of innovation he does? I follow his work, I can tell you , he does not deserve any of this negativity.

And on that note, I see no reason why a developer must be tied to a project, if they feel they should move on , it is their choice. Apart from the PoW, keep in mind that these were basically free shares.

Quote from: FreeTrade on October 09, 2014, 12:55:42 PM
My view is that dev talent is scare and best redirected away from failed projects rather than throwing new effort at it.

I tried my best and ultimately failed.

What is more scarce than dev talent is groups of talented devs working together with an eye for future scaling and economic viability. There are plenty of rewarding projects if you move forward, learn DPoS and aim for Virginia Tech..  ;D

Quote from: bitmeat on October 11, 2014, 06:46:09 AM

Quote from: Riverhead on October 10, 2014, 04:10:08 PM
Keep in mind a non compromised wallet stores an ENCRYPTED copy of your private keys. That's why you need to unlock your wallet with a good passphrase. It's effectively 2-Factor Authentication. They need both the .dat file AND your pass phrase for it to be useful.

Look, it's not a true 2-factor, unless it uses a separate device to decrypt.

I don't think FT has stolen keys,

Sorry for the rant, but this is disaster in the makings. I hope I'm wrong, I really do.

Agree on all points. Referring to it as 2FA was incorrect.




Sent from my SM-G900T using Tapatalk

Quote from: bitmeat on October 11, 2014, 06:46:09 AM

Quote from: Riverhead on October 10, 2014, 04:10:08 PM
Keep in mind a non compromised wallet stores an ENCRYPTED copy of your private keys. That's why you need to unlock your wallet with a good passphrase. It's effectively 2-Factor Authentication. They need both the .dat file AND your pass phrase for it to be useful.

Look, it's not a true 2-factor, unless it uses a separate device to decrypt. If there is a key-logger, it doesn't matter how strong your second password on top of the private key is. This is true for all crypto projects. It's scary full of amateur decisions.

Even the "non-hobby" projects like DNS and BTSX have that flaw. And as I mentioned a billion times, it is extremely easy to fix. Heck even Bytemaster mentioned somewhere he added it to the toolkit as method somewhere, but nobody is using it.

I don't think FT has stolen keys, if he did, he'd have more than just personal issues.

However in this day and age you can NEVER be sure what's running on your desktop. Given that it's a huge incentive, you know someone, somewhere will exploit the attack vector.

I would not import any keys until this issue is resolved. And I say that even for the existing DACs.

Sorry for the rant, but this is disaster in the makings. I hope I'm wrong, I really do.

+5%

Quote from: Riverhead on October 10, 2014, 04:10:08 PM
Keep in mind a non compromised wallet stores an ENCRYPTED copy of your private keys. That's why you need to unlock your wallet with a good passphrase. It's effectively 2-Factor Authentication. They need both the .dat file AND your pass phrase for it to be useful.

Look, it's not a true 2-factor, unless it uses a separate device to decrypt. If there is a key-logger, it doesn't matter how strong your second password on top of the private key is. This is true for all crypto projects. It's scary full of amateur decisions.

Even the "non-hobby" projects like DNS and BTSX have that flaw. And as I mentioned a billion times, it is extremely easy to fix. Heck even Bytemaster mentioned somewhere he added it to the toolkit as method somewhere, but nobody is using it.

I don't think FT has stolen keys, if he did, he'd have more than just personal issues.

However in this day and age you can NEVER be sure what's running on your desktop. Given that it's a huge incentive, you know someone, somewhere will exploit the attack vector.

I would not import any keys until this issue is resolved. And I say that even for the existing DACs.

Sorry for the rant, but this is disaster in the makings. I hope I'm wrong, I really do.

Has anybody made some kind of best-practices manual for claiming stakes in new DACs? There are a couple no-brainer things one could do, such as moving your PTS to a new address after every snapshot (and certainly before importing PTS keys), keeping your AGS donation wallets locked at all times (i.e., never use those wallets for BTC or PTS transactions), etc. Has anybody already written up such guidelines?

Oh, another thing: immediately after importing AGS, move your newly-claimed shares to a completely different wallet.dat file; that way your AGS key is not permanently in your LTS wallet.dat file.

Quote from: Gentso1 on October 10, 2014, 06:34:57 PM

Quote from: Riverhead on October 10, 2014, 04:10:08 PM
Keep in mind a non compromised wallet stores an ENCRYPTED copy of your private keys. That's why you need to unlock your wallet with a good passphrase. It's effectively 2-Factor Authentication. They need both the .dat file AND your pass phrase for it to be useful.

Naturally with a compromised wallet they get the plane text version. However if you imported your keys into a non compromised wallet a developer is no further ahead of anyone else who has just a locked .dat file. They'd still need to get you to install and unlock a compromised wallet to get the keys in plane text. Try dumping your private keys in a QT wallet with it locked. Doesn't work.

As far as needing a mechanism to claim AGS without a plane text key import it seems that's on each DAC developer to implement but from what Toast said the expensive part is getting it audited because otherwise you're still just trusting the developer.

I learned something new here.
So using lts as a example
I dumped my  un encrypted text based ags key from the wallet I made my donation from into the lts wallet.
In order to access  the ags donation wallet they would need the password for the ags donation wallet and the private key?

No, all they need is the private key. Your AGS key is now in two places: your AGS wallet.dat, and the LTS wallet.dat. If your LTS wallet is encrypted with a strong passphrase, then you're good. If you imported your AGS key into the LTS wallet without encrypting the LTS, then your AGS is wide open and exposed to anybody with access to your computer.

Quote from: Riverhead on October 10, 2014, 04:10:08 PM
Keep in mind a non compromised wallet stores an ENCRYPTED copy of your private keys. That's why you need to unlock your wallet with a good passphrase. It's effectively 2-Factor Authentication. They need both the .dat file AND your pass phrase for it to be useful.

Naturally with a compromised wallet they get the plane text version. However if you imported your keys into a non compromised wallet a developer is no further ahead of anyone else who has just a locked .dat file. They'd still need to get you to install and unlock a compromised wallet to get the keys in plane text. Try dumping your private keys in a QT wallet with it locked. Doesn't work.

As far as needing a mechanism to claim AGS without a plane text key import it seems that's on each DAC developer to implement but from what Toast said the expensive part is getting it audited because otherwise you're still just trusting the developer.

I learned something new here.
So using lts as a example
I dumped my  un encrypted text based ags key from the wallet I made my donation from into the lts wallet.
In order to access  the ags donation wallet they would need the password for the ags donation wallet and the private key?

Keep in mind a non compromised wallet stores an ENCRYPTED copy of your private keys. That's why you need to unlock your wallet with a good passphrase. It's effectively 2-Factor Authentication. They need both the .dat file AND your pass phrase for it to be useful.

Naturally with a compromised wallet they get the plane text version. However if you imported your keys into a non compromised wallet a developer is no further ahead of anyone else who has just a locked .dat file. They'd still need to get you to install and unlock a compromised wallet to get the keys in plane text. Try dumping your private keys in a QT wallet with it locked. Doesn't work.

As far as needing a mechanism to claim AGS without a plane text key import it seems that's on each DAC developer to implement but from what Toast said the expensive part is getting it audited because otherwise you're still just trusting the developer.

Quote from: tonyk on October 10, 2014, 05:06:30 AM

Quote from: Riverhead on October 10, 2014, 05:02:30 AM

Quote from: tonyk on October 10, 2014, 04:56:43 AM

Quote from: Brekyrself on October 10, 2014, 04:36:20 AM

Better to try and fail then to never try in the first place, thanks for the fun.

Any insight into the next project?

That is very counter intuitive statement... read my posts in this sub-forum... how could this project be a success?

Now back to the priv keys of mine that I imported... they are forever in jeopardy of someone deciding that stealing/using them is the better way to go...

On that note - Is not this easy enough to transfer the AGS donations from the original 'donation from' to a new one?

Your keys aren't "out there" unless this client was compromised and I don't think it was. A malicious dev can't somehow get your private keys unless they release a compromised version and you open your wallet.dat with it and unlock it.

Good to know Riverhead!
I imported just a few keys but still prefer not to give my AGS to somebody for no reason at all...

maybe I am wrong but when any of us input our private key (ags, pts, whatever) anyone who has that key can claim to be the owner of said address. Now in wallets anyone who has that private key has complete access to said wallet. So for a pts wallet for example  if you think your key is compromised you simply transfer your pts to a new wallet with a new addy and you have a new private key that you can use to claim your stake.

With ags it goes by the addy the donation came from. So their is no way to substitute another addy unless it is manually done in the genesis block of every new DAC(like what they did with some of the keyID addys).

I for one should have known better and just not imported my private ags key and just "passed" on what ever lts had to offer, its just to much risk if a dev is bad intentions. This isn't anything against FT but any dev.  We want a trust less system but the irony is with ags we have to trust every dev for every DAC as the only way to currently claim shares. keyID, LTS, what about the music one or vote, how about PLAY. We must have another option for ags holders to claim shares other then private keys or simply not support DACS that will not implement another method. As more devs start becoming interested in the bitshares toolkit we have more player's in the game and it only takes one to have bad intentions. Lets be pro active instead of reactive. 

Quote from: merockstar on October 10, 2014, 05:11:14 AM

Quote from: Riverhead on October 10, 2014, 05:02:30 AM
Your keys aren't "out there" unless this client was compromised and I don't think it was. A malicious dev can't somehow get your private keys unless they release a compromised version and you open your wallet.dat with it and unlock it.

That makes perfect sense.

I forgot the wallet.dat itself is encrypted. The client still could have been compromised when the keys were actually imported though, right?

Yes. The client knows your private key at import and could, in theory, encrypt the plain text key with a public key they own and send it to themselves. The destination would then have a script decrypt the private key, import it into a burner wallet and transfer the money. It would all be over in seconds.

Quote from: Riverhead on October 10, 2014, 05:02:30 AM
Your keys aren't "out there" unless this client was compromised and I don't think it was. A malicious dev can't somehow get your private keys unless they release a compromised version and you open your wallet.dat with it and unlock it.

That makes perfect sense.

I forgot the wallet.dat itself is encrypted. The client still could have been compromised when the keys were actually imported though, right?