I am kind of hoping it's a torrent type system where if I setup my Keyhotee on another system I'll have the option to sync messages from my other system with the same setup if it's online.  The idea of storing actual messages in the blockchain seems a bit crazy as the blockchain would require Gmail level storage requirements from everyone who syncs it.


Also I love the idea of a p2p raid via blockchain among trusted peers.  This sounds like a great idea for a DAC

I tried to sign up with my Founder ID and I don't have any connection to the bitshares network. In the terminal box It says no connection could be made because the target machine actively refused it. It won't let me send email the send icon is ghosted out and I can't use for anything, any Idea what I can do?

Give it some time.  It'll eventually register.  There is no mining currently but eventually you'll go green Registered with a gold Founder tag as well.

I think developers will use this launch pad because its the most cost effective way to accelerate their path to fame and glory.

And when it's not, they won't.

I think this in a nutshell is why PTS/AGS as a platform, infrastructure, and SDK - more than a single product, will be a huge success. In the same way the Apple and Android app stores exploded because there were already so many users on each platform and the tools to quickly get apps out the door made it very compelling and also difficult to justify developing something from the ground up.

Quote from: delulo on January 06, 2014, 12:16:01 am

I think the concept of Protoshares makes sense in that it makse sense for developers to honor Protoshares in their DAC and its a revolutionary and maybe THE way for funding DACs. But there is one case I can think of that that doesnt stimulate honoring of PTS: When a 3rd Party DAC is a direct competitor to any DAC released by I3 (in the future). This is not a definite reason to igrnore Protoshares but it might play a role because credit and attention is given to a direct competitor this way....

Just the opposite...

If I were a determined competitor of Invictus, I sure wouldn't let the fact that they fielded a particular DAC first deter me from courting all the PTS and AGS holders out there for my competing DAC.  I'd want all the advantages Invictus has, so I'd try to outdo them in making an even better deal for the PTS/AGS stakeholders of the community. 

If Invictus offered 10%, I'd offer 20%...  no?

 

As a PTS holder I'd have a stake in both (10% in one, 20% in the other) so I don't think I'd feel courted away...unless you mean I'd be more likely to use/support/endorse the 20% service because I have double the interest in it succeeding?

Better yet, reply to the email we sent you with your PTS/BTC address and all the above info.  This will help me keep things better organized than using PMs.  contact.us@invictus-innovations.com.

Appreciate that guys but I know you're swamped with more pressing things. 

Once I figure out how to back up my private key I'm cool with what I have.  My brain passphrase is good and all the fields I did fill in were with correct data so there shouldn't be a reason for you to manually recreate my ID.

Update: Found where it is.  %AppData% defaults to AppData\Roaming but it's in AppData\Local

Quote from: HackFisher on January 05, 2014, 06:12:44 am

3 quick questions:

1. Has the pubkey of my Keyhotee Found ID been sent to bind in genius block later? Suppose I have finished the alpha register process.

2. Do I need to backup my Keyhotee private key now?

3. If need, How should I backup it?

If you remember all the information you entered in your profile form, then there is nothing else you need to remember.   If you DO want to back things up then your stretched_seed file which is encrypted with your password is what you want to backup. 

As this is an alpha test, it would be nice to know if people can successfully recreate their profile from memory alone.

Since this is an Alpha test I wasn't too critical about what I put into the fields.  All the data was real and I can go forward with it but as it's an Alpha I figured we'd get a chance for a do over or five .

So is it true that the wallet.dat file contains your public and your private key as well as the encryption you used? <- I am thinking that because you said the only thing that has to be done is to encrypt wallet (within the client) and then only safe the wallet.dat file. So the encryption must be stored in the wallet.dat file?

The wallet.dat file contains everything specific to the addresses you claim as yours.  The public/private key pairs, some transaction information, etc.  It is encrypted using your passphrase.  What the wallet.dat file specifically contains and how it is encrypted (using I believe AES-256-CBC) is well documented elsewhere.  The important takeaway from this thread is that the wallet.dat file is all you need.  Everything else is generic software that everyone has.

Also if I rename the wallet.da file I would have to re-rename it to "wallet.dat" again when I want to do a transaction with it, right?

Yes.  The renaiming is only for your personal reference.  The client looks for a wallet.at file in the specific location (%AppData%/Protoshares for example) and creates one if it doesn't find one.  When restoring your wallet from your pts_wallet.dat backup you'd need to rename it back to wallet.dat for the client to recognize and load it.

After having done a transaction there is nothing that changed within the wallet.dat file, right (its still just the public and the private key and the encryption)? So I don't have to replace this wallet.dat file that I just used with the one that I originally made a copy of, right?

The wallet.dat file holds a bit more information than that however the most import part, you are correct, is the public/private key pool.  This pool has a default of 100 key pairs and gets another 100 added once they are used up.

My solution would look like this: I have one Computer with a hot wallet for daily transactions. From this wallet I send all the PTS/Coins I want to store to an address that is generated by a client on a computer with a fresh OS (this Computer has no other function; surely maleware free). Then I encrypt this wallet and safe only the wallet.dat file on a USB Stick that is encryped with TrueCrypt.
When I want to use coins I copy the wallet.dat file on the USB stick to the maleware free computer  (to appdata/protoshares) and send my coins either to the hot wallet address or directly to whoever I want to send coins to... Then I erase the wallet.dat file on the maleware free computer again without saving it.

This works well.  Just keep in mind that unless you send ALL your coins from your address the coins you do not send get returned to a hidden change address.  So if your "fresh os" wallet has 100 PTS and you send 10 PTS to another address the remaining 90 PTS will get sent to a Change Address in your wallet - burning one of the 100 pub/priv keys in your pool.  It's for this reason you need to refresh your backups every 100 transactions.

I am pretty sure I doent have maleware on my laptop because no coins have been stolen yet. But by the solution with the additional computer that has a fresh OS I can make sure that I dont copy and maleware onto the USB where I also safe my wallet.dat. Does that make sense ?! 

Any flaws in there?

Other people suggest to install an OS (Linux) on an USB Stick. What advantage would that have?

Sounds like you have a good strategy.  The one nice thing about Linux on a USB stick is that you can pretty much boot it with any computer and have access to an already downloaded blockchain, client, etc. in a malware/virus free environment.  The client AES-256-CBC encryption for the wallet.dat is pretty good, especially if you use a good pass phrase, so you don't need to get too paranoid .

Quote from: bitcool on January 05, 2014, 02:57:46 pm

Windows build, on my PC,  it doesn't seem be able to complete the profile creation step, always tuck at Creating Profile (100%).

Ctr-C closing the command line session resulted in invalid login when relauch.

Yes, this is the exact same problem that I have. On entering password, the Login dialog wobbles, then clears password box. The command window that appears show and error ending with: th_a  application.cpp:341 bts::application::load_profile

I got this when I put in the wrong password.  I had to exit Keyhotee client completely.  It worked when restarted and the correct password was put in the first attempt.