Author Topic: Neither Dice nor Lottery are producing results  (Read 35707 times)

0 Members and 1 Guest are viewing this topic.


Offline kanes

  • Jr. Member
  • **
  • Posts: 31
    • View Profile

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
The PoW was merged mining anyways

Offline barwizi

  • Hero Member
  • *****
  • Posts: 764
  • Noirbits, NoirShares, NoirEx.....lol, noir anyone?
    • View Profile
    • Noirbitstalk.org
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.
--Bar--  PiNEJGUv4AZVZkLuF6hV4xwbYTRp5etWWJ

The magical land of crypto, no freebies people.

Offline CLains

  • Hero Member
  • *****
  • Posts: 2606
    • View Profile
  • BitShares: clains
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

Offline Riverhead



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


Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
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%

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
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.

Offline biophil

  • Hero Member
  • *****
  • Posts: 880
  • Professor of Computer Science
    • View Profile
    • My Academic Website
  • BitShares: biophil
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.
« Last Edit: October 10, 2014, 08:36:06 pm by biophil »
Support our research efforts to improve BitAsset price-pegging! Vote for worker 1.14.204 "201907-uccs-research-project."

Offline biophil

  • Hero Member
  • *****
  • Posts: 880
  • Professor of Computer Science
    • View Profile
    • My Academic Website
  • BitShares: biophil
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.
Support our research efforts to improve BitAsset price-pegging! Vote for worker 1.14.204 "201907-uccs-research-project."

Offline Gentso1

  • Hero Member
  • *****
  • Posts: 931
    • View Profile
  • BitShares: gentso
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?



Offline Riverhead

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.
« Last Edit: October 10, 2014, 04:11:50 pm by Riverhead »

Offline Gentso1

  • Hero Member
  • *****
  • Posts: 931
    • View Profile
  • BitShares: gentso

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. 

Offline Riverhead

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.

merockstar

  • Guest
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?