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

0 Members and 1 Guest are viewing this topic.

merockstar

  • Guest
shit.

I waited so long to claim LTS because I was worried about giving up my private keys.

finally I did it after the first bubble.

shit...

Offline Riverhead

It would be tough because a likely code hack like that would be in the binaries and not checked into GitHub (reason md5 is so important).

Also I can't comment on how ags is stored but since claiming requires a private key i3 doesn't have I doubt anything can be done. Only future snapshots would benefit and since ags snapshot is long in the books....

Maybe I am misunderstanding you. I am worried about anyone who trusted this software or dev with their ags private key.If FT has the private keys of many users who had to use them to claim LTS, it would be a race to claim future DAC's. I don't really care about lts, I didn't have any stake in it other then my ags donation. I am concerned about FT having access to private keys via LTS claiming and his work on future projects.
I hear ya. What I'm saying is the ags private keys are set. Since pts is liquid they can be moved to new keys for future snapshots (like music on the 10th) but any previous snapshots (DNS, BTSX) are cast in stone now so best to claim and move to new keys their respective blockchains so if private keys are compromised the addresses are empty.

I don't think there is anything that can be done for ags holders. However I really doubt the keys are compromised. FT has his issues but I don't believe he'd pull off a massive heist.


Offline Gentso1

  • Hero Member
  • *****
  • Posts: 931
    • View Profile
  • BitShares: gentso
It would be tough because a likely code hack like that would be in the binaries and not checked into GitHub (reason md5 is so important).

Also I can't comment on how ags is stored but since claiming requires a private key i3 doesn't have I doubt anything can be done. Only future snapshots would benefit and since ags snapshot is long in the books....

Maybe I am misunderstanding you. I am worried about anyone who trusted this software or dev with their ags private key.If FT has the private keys of many users who had to use them to claim LTS, it would be a race to claim future DAC's. I don't really care about lts, I didn't have any stake in it other then my ags donation. I am concerned about FT having access to private keys via LTS claiming and his work on future projects. 

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani

None of the devs have built such a tool yet because we trust ourselves. It is simple to implement in the toolkit right now but then you either have to strip it down until it's small enough to audit (the hard part) or you'd just be trusting us anyway.

No one is questioning you. However I prefer to sign on a machine that is offline. Produce the signature there. Then transfer via USB and then import it. This is the safest.

Even if your software is trusted most people's machines aren't!

With AGS not being liquid this is a big deal.

And I beg you to add this to the code it is relatively easy to do. And should have been the default way to import keys in the toolkit.

Going forward this is a must for BTS DACs

 +5% +5% +5% +5%

Offline GaltReport


None of the devs have built such a tool yet because we trust ourselves. It is simple to implement in the toolkit right now but then you either have to strip it down until it's small enough to audit (the hard part) or you'd just be trusting us anyway.

No one is questioning you. However I prefer to sign on a machine that is offline. Produce the signature there. Then transfer via USB and then import it. This is the safest.

Even if your software is trusted most people's machines aren't!

With AGS not being liquid this is a big deal.

And I beg you to add this to the code it is relatively easy to do. And should have been the default way to import keys in the toolkit.

Going forward this is a must for BTS DACs

 +5%


Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile

None of the devs have built such a tool yet because we trust ourselves. It is simple to implement in the toolkit right now but then you either have to strip it down until it's small enough to audit (the hard part) or you'd just be trusting us anyway.

No one is questioning you. However I prefer to sign on a machine that is offline. Produce the signature there. Then transfer via USB and then import it. This is the safest.

Even if your software is trusted most people's machines aren't!

With AGS not being liquid this is a big deal.

And I beg you to add this to the code it is relatively easy to do. And should have been the default way to import keys in the toolkit.

Going forward this is a must for BTS DACs

Offline carpet ride

  • Hero Member
  • *****
  • Posts: 544
    • View Profile
It's a failed startup.  Just like the real world, beware what you invest in


Sent from my iPhone using Tapatalk
All opinions are my own. Anything said on this forum does not constitute an intent to create a legal obligation between myself and anyone else.
Check out my blog: http://CertainAssets.com
Buy the ticket, take the ride.

Offline Riverhead

It would be tough because a likely code hack like that would be in the binaries and not checked into GitHub (reason md5 is so important).

Also I can't comment on how ags is stored but since claiming requires a private key i3 doesn't have I doubt anything can be done. Only future snapshots would benefit and since ags snapshot is long in the books....

Offline Gentso1

  • Hero Member
  • *****
  • Posts: 931
    • View Profile
  • BitShares: gentso
Guys, "tool" just means whenever someone releases a DAC to check for signed message instead of asking for private key when importing. That's it! Possibly even a one line change in the code. I am really shocked DNS didn't implement that. Should be extremely easy to do.
Interesting. Wonder if cob will do this. If not we can ask for it in the wallet [ANN] thread. In the meantime may be best for pts holders to transfer holdings to a new address before Oct 10th. That will prevent any past leaks from claiming your Notes.

Nothing can be done about ags holders though correct?
None of the devs have built such a tool yet because we trust ourselves. It is simple to implement in the toolkit right now but then you either have to strip it down until it's small enough to audit (the hard part) or you'd just be trusting us anyway.
Can you comment if it would be possible for LTS or any DAC to use ags private keys to claim future distributions?
How hard would it be for a dev to take a look at LTS code to confirm or deny the above flaw, not fix just confirm to see if it was intentional or truly bad timing?

Offline Riverhead

It is simple to implement in the toolkit right now but then you either have to strip it down until it's small enough to audit (the hard part) or you'd just be trusting us anyway.


Seems like a good use of dev funds for a 3rd party DAC to strip down and have audited such an import mechanism. Their DAC would then be more appealing to the PTS/AGS crowd.

Offline callmeluc

  • Hero Member
  • *****
  • Posts: 552
    • View Profile
Update:

I've been trying to resolve two problems with LottoShares but have not managed to do so.

The first is a forking problem when the checkpointing server is running. The checkpointing server allows draws to take place but causes forks to take place when checkpoints aren't accepted by some clients.

The second is decentralizing the draw/random number generation. Using the block hash and a private key to generate unpredictable randomness is centralized and ultimately unsatisfactory. I think the second problem may only be resolvable in the context of a (bitshares style) delegate model.

Unfortunately I've been unable to resolve these problems in LTS despite a huge amount of effort. I have now decided to redirect my efforts to other projects.

Thanks to everybody who took part and I'm sorry it didn't turn out as well as we had all hoped.

Why give it up so easy? Did you realize that it's a destruction to the reputation of I3 and yourself? Because of the connection between you, PTS, I3 and this community, and your "generosity" to AGS/PTS, lots of people thought it's a I3 product.

Or maybe we can just call it mmc 3.0
BTS_自扯自淡

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
None of the devs have built such a tool yet because we trust ourselves. It is simple to implement in the toolkit right now but then you either have to strip it down until it's small enough to audit (the hard part) or you'd just be trusting us anyway.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline Riverhead

DNS is falling because there's no product yet :-). Toast is trusted and is using the Bitshares toolkit. Signed blocks vs import private key is still doable before a product is released.

Offline mf-tzo

  • Hero Member
  • *****
  • Posts: 1725
    • View Profile
Interesting...so that might be the reason why DNS keeps falling...Some people have realized that and sell them maybe?

I think we should discuss this in the relevant thread...

Offline Riverhead

Guys, "tool" just means whenever someone releases a DAC to check for signed message instead of asking for private key when importing. That's it! Possibly even a one line change in the code. I am really shocked DNS didn't implement that. Should be extremely easy to do.
Interesting. Wonder if cob will do this. If not we can ask for it in the wallet [ANN] thread. In the meantime may be best for pts holders to transfer holdings to a new address before Oct 10th. That will prevent any past leaks from claiming your Notes.