Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Troglodactyl

Pages: 1 ... 55 56 57 58 59 60 61 [62] 63 64
916
General Discussion / Re: militia DAC
« on: January 23, 2014, 03:20:28 am »
We don't need an army, the way crypto currencies and DAC are designed, things will kind of sort out by themselves without violence.

Well, there's still the Genghis Khan issue, but it's conceivable that not all of the world's problems can be solved through clever coding.

917
General Discussion / Re: Coinjoin implementation
« on: January 22, 2014, 01:35:03 am »
More methods are good.  It still seems as though there are significant advantages to the Coinjoin approach for certain scenarios, but if this is confirmed, someone will add it into the Keyhotee wallet later.

918
Keyhotee / Re: Keyhotee and security
« on: January 19, 2014, 03:50:02 pm »
2FA (assuming you mean one time passwords like Google Authenticator or something) only makes sense for authenticating to a trusted third party, which isn't how Keyhotee authentication works.  OTP demonstrates that you know a shared secret without revealing the secret to anyone listening in, but it can't be used to directly secure files, just to convince someone else to give you access to something secured through other means.

Keyhotee security will depend on the complexity of your passwords and on the security of the computer from which you use it.  Because you don't have to trust your passwords to any third parties for authentication, this is much more secure than password only authentication for a web based account.

EDIT:  On second thought Keyhotee does have 2FA, the first factor being the profile file generated with your brain wallet key and profile information, and the second factor being the password required to decrypt it.

919
Keyhotee / Re: Keyhotee wallet and support for altcoins
« on: January 19, 2014, 03:35:46 pm »
Just importing a wallet.dat would not yield a functional blockchain.  Hopefully it will be modular so people can basically add additional alts as plugins though.

920
I'll have to look into KIDARC.  My reservation though is that I have enough storage to store my data and maybe a friend or two's data but not the entire user bases' data and I'm sure most people would object to a 100PB+ blockchain.  But like I said, I'll need to look into KIDARC to see how they got around this.

KIDARC is just content so far, I don't think they have a distributed hosting system for it yet.  For the content distribution and backups I'm talking about look at BitTorrent Sync and at RetroShare file sharing and forum hosting.  The idea is that each user only stores what he is personally subscribed to.  For forums, this means popular content will propagate and be preserved and that spam will not.  For encrypted backups, this means if no one loves you you may have to pay someone for storage.

Also, (because I'm evil) it occurred to me that integrating the encrypted backup system into a social network and showing publicly to your contacts what storage quota you're granting to each of your other contacts would be entertaining.  It could be an economic solution to the "Friend Inflation" you see with Facebook.

Anyway, kind of off-topic...

921
Keyhotee / Re: Keyhotee "migrate ID" feature? Keyhotee "derived key" IDs?
« on: January 12, 2014, 03:27:04 am »
I would be interested in offline master key support also.  If that's not an option, a migrate transaction would be good also.

922
Keyhotee / Re: Alpha Keyhotee Bug Reporting in this thread.
« on: January 12, 2014, 03:09:47 am »
Code: [Select]
No connection could be made because the target machine actively refused it
    {"message":"No connection could be made because the target machine actively refused it"}
    asio  asio.cpp:55 fc::asio::detail::error_handler
error connecting to 162.243.67.4:9876
    {"ep":"162.243.67.4:9876"}
    th_a  connection.cpp:194 bts::network::connection::connect
unable to connect to 162.243.67.4:9876
    {"ep":"162.243.67.4:9876"}
    th_a  server.cpp:257 bts::network::server::connect_to application.cpp:113
2588898ms       th_a   displayFailureInfo ] assert
c != current:
    {}
    th_a  thread_d.hpp:433 fc::thread_d::check_for_timeouts KeyhoteeApplication.cpp:212
2588899ms       th_a   displayFailureInfo ] fatal error assert
c != current:
    {}
    th_a  thread_d.hpp:433 fc::thread_d::check_for_timeouts KeyhoteeApplication.cpp:214

The client crashed after leaving it running for a while.  There's the end of the diagnostic log.

EDIT: Sorry, this is on the 0.5.2 release running on 64bit Windows 7.

923
General Discussion / Re: Coinjoin implementation
« on: January 11, 2014, 01:25:49 am »
Couldn't this be added into the Keyhotee integrated wallets rather than the protocol?


924
General Discussion / Re: BitShares Status Update
« on: January 11, 2014, 12:32:04 am »
Today I completely reworked the bid/ask/short matching system to address the issues discovered yesterday and the result appears to be working as expected except for an integer rounding error which is proving to be very challenging to address.  The problem is that all prices are 'ratios' and if you use bids or asks with a price of '3 usd/bts' then you end up with numbers like 3333.33333 and 6666.66666 which when rounded turn into 6667 and when multiplied by say 2, propagates the error resulting in 13334 rather than the expected 13333 and if you truncate it then you get 13332.   

What is an extra satoshi lost or gained here and there between friends?   

I am having to perform a careful audit of the code to make sure that these kinds of rounding errors are properly avoided.  Isn't fixed point 128 bit math fun!

Would it be a problem to express prices as satoshis/satoshis and only complete trades in full increments of the price?

925

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 ;)

We have plans for direct connect which would allow your home computer to be the trusted server for all of your other devices.

This is great, but it solves a separate issue.  The p2p RAID addresses data recovery, not multi location access.  It's certainly lower priority and should be workable as a later Keyhotee plugin.  Lack of automatic backups is a significant negative to a lot of people though, especially if Keyhotee is competing with Gmail, which is not out of the question once it reaches maturity.

Storage should be encrypted unless intended to be public, so the peers wouldn't have to be trusted, and it could start with basic mirroring of contact lists and messages, and scale up to support hosting a full Keyhotee social network like KIDARC.  This could be pretty similar to how Retroshare manages decentralized forums.

926
Keyhotee / Re: New way to be sure your Founder ID and Key are Registered
« on: January 07, 2014, 02:10:56 am »
There isn't a deadline set on this yet, but it will be several weeks away, correct?

927
I did the same thing today, I was glad I got the same public key, I am guessing that means I set the second computer up correctly. I am guessing with no blockchain, there is no way for it to sync messages?

Both computers will receive messages.  And messages are not stored in a blockchain.  We are working on a solution that would allow both machines to get old messages as well. 

Are current IPs of individual users stored in a blockchain, or does it use distributed hash tables or something else for this?

In either case I expect you're looking at a solution rather like BitTorrent Sync with all data encrypted to yourself.  Can this be generalized so Keyhotee provides a synchronized general storage directory rather than just syncing emails, messages, and contacts?  Also, could Keyhotee allow users to grant friends a storage quota?

Just brainstorming, so this may be overcomplicated, but if you apply a RAID-like system across your network of friends, it could handle automatic message recovery in case of system failure, as well as syncing between machines without having to leave both powered on simultaneously.

In this case you could also rank friends by how much storage space they're worth, allowing some interesting and potentially dramatic social price discovery...

928
Marketplace / Re: Selling PTS for Paypal - $40.00
« on: January 04, 2014, 07:41:08 am »
No long  available at that price. Also I wouldn't have sent them first because its paypal so I take the risk with you disputing a transaction.

Can you update the price or lock the thread?

929
Thank you very much!

Pt2FcsBjnnbjAuVLghytyYmeKyqykVZhf5

930
Keyhotee / Re: Update on Keyhotee?
« on: January 03, 2014, 05:09:15 am »
Keyhotee is making a lot of progress as you can see in the github logs, but we are aiming for quality over speed right now.   

We are about 1 month behind schedule which puts us at the end of Jan and of course we are rushing to get out the Alpha test code to register your Keyhotee IDs.

Excellent.  I'm definitely willing to wait for a solid release.  If it takes long enough I might even finally get around to trying to contribute.  :P

Pages: 1 ... 55 56 57 58 59 60 61 [62] 63 64