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 ... 57 58 59 60 61 62 63 [64]
Keyhotee / Re: How will founder IDs be distributed?
« on: December 24, 2013, 03:49:26 pm »
Hi Zeus,

I understand the difficulty.  It's good that Invictus is busy preparing for the launch, but support and education for the less crypto experienced investors does suffer for it.

First off, you have not missed MemoryCoin, as long as you still have access to the same Protoshares wallet you had when it was launched.  The MemoryCoins you got for holding Protoshares will be there waiting for you whenever you get around to it.  There should be a stickied thread on how to do this eventually, I'll see what I can do...

My understanding of Founder's ID distribution is that Invictus will provide us with a program (the alpha version of Keyhotee) available for download in the next few days, we will each run it and fill in our profile information, and it will either generate a file which we will then send back to Invictus for inclusion in Keyhotee at launch, or we'll create identities in the alpha chain and they'll copy them from there.

Hope this helps...

Keyhotee / Re: did NOT receive email after donation submission
« on: December 22, 2013, 12:46:02 am »
Same here, but I believe they're doing them manually in batches, so it may be a day or two.

Keyhotee / Re: Better pick up the pace, we got competition.
« on: December 21, 2013, 10:11:16 pm »
I've been following this project for a while, and it's definitely closely related:

Hopefully Keyhotee will eventually have distributed forums, or even a fully distributed social network to rival Facebook...

Keyhotee / Re: How will Keyhotee guard the usage of private key for ID?
« on: December 21, 2013, 09:58:54 pm »
What if each key had a parent key, a list of subkeys, a list of supported application GUIDs and a human readable subtitle string?  All reputation alterations and checks would propagate up to the root.  Either a key's own signature or that of a parent would be necessary for revocation, and both signatures would be required to form new subkey relationships.  Subkeys could be used on lower security devices when necessary to avoid risking the primary, particularly if it were a founder's ID.  The GUID list would inform others of what currencies could be received by the particular key, as well as what other applications the key supported.  The subtitle string could be used to label a key as home, work, or mobile, or to label a key for contributions to a particular project.

Subkeys wouldn't need names registered in the blockchain, since they don't have their own reputation.

Keyhotee / Re: Mobile Keyhotee
« on: December 21, 2013, 09:07:47 pm »
I suspect a full node mobile client with proof of work for messaging is going to drain batteries very quickly.  How difficult and energy efficient would it be to use the Keyhotee network to establish a single direct connection to a home PC which could be used as a server?  With the home PC handling the full blockchain and proof of work processing the mobile app I would think wouldn't have to use any more battery and bandwidth than traditional centralized server based solutions.

This could also integrate well with the subkey proposals.

Keyhotee / Re: Keyhotee Launch Parties
« on: December 09, 2013, 12:17:30 am »
I plan on setting up Keyhotee while watching the three stooges marathon with family, none of whom really understand keyhotee or anything related to cryptocurrencies. Beyond that, no real plans for a keyhotee party

Most people who use email don't understand how it works, and that isn't really a problem.  From what I've seen, it appears that Keyhotee abstracts away PKI more elegantly than any other similar system available, and thus may be the first real shot and getting secure communication and reasonable identity management accessible to the masses.

Keyhotee / Keyhotee Launch Parties
« on: December 08, 2013, 08:56:20 pm »
As a communication system, probability of success scales with the size and interconnectedness of the early user base.  I've already been working on getting my friends and family interested in getting involved early, but I'm wondering if others are planning any Keyhotee launch parties for New Year's, or what other ideas people have for getting it viral from the start.

General Discussion / Re: DAC simplified explanation
« on: December 08, 2013, 08:42:24 pm »

1) Global Consensus vis Ledger (Ripple, Bitcoin, etc)
2) All nodes must be able to verify ledger and the validity of the ledger must not depend upon secrets
3) No central points of failure.

Initial definitions are always messy, but this seems somewhat limiting to me.  A blockchain or distributed ledger of some type is certainly a good way to implement many types of DACs, but I'd prefer to define it in such a way that it's not an essential component.  It seems to me that the essential defining characteristic is generating and maintaining contractual consensus in a decentralized fashion.

So in a nutshell I'd say a DAC is a scalable organic contract perpetually fulfilled for each of its adherents individually by all of its adherents collectively.

BitShares PTS / Re: [Megabounty Thread] Help Us Write the Protoshares Copy
« on: December 08, 2013, 04:53:59 am »
[$50] Describe DACs in 3 short, ~2 sentence descriptions.
This should give you a good start( If have a good image to show your point, I will add $25 to the bounty.
DACs are like languages: they are virtual entities given form and life by the consensus of their users.  As long as consensus among users exists, a language or DAC will have utility to those who participate.

A DAC is a voluntary social contract defining protocols the use of which will benefit those who practice them.  A DAC is created when a protocol is defined and attracts enough practitioners to give it life.

DACs are organic sets of conventions that streamline human interaction in a given domain.  Using them increases efficiency because procedures are already clearly defined, leaving no room for deception or error.

^ Are those too abstract?

BitShares PTS / Re: [ANN] - Protoshares mining sub-pool
« on: December 04, 2013, 02:01:58 pm »
More orphans. What causes these?

yes what does this mean 0 PTS / 0 PTS -> ORPHAN :(


That means we mined that block, but someone else mined a block as a child to the same parent as ours close to the same time, and the network accepted the other child and thus rejected ours.  Since our block didn't make it into the final chain, we get nothing for it.

BitShares PTS / Re: [ANN] - Protoshares mining sub-pool
« on: December 03, 2013, 02:05:02 pm »
Clone from here and it will failover from beeeeer to rpool.

Sounds good. Did you change anything else besides the auto failover?

I just added the additional pool to a list, and have it waiting for 3 seconds for work when it tries to connect.  If the pool doesn't give it work it disconnects and tries connecting to the next pool.  Kind of ugly with the hard coded pool list, but it was a quick hack to get my miners back up and hopefully keep them up.

BitShares PTS / Re: [ANN] - Protoshares mining sub-pool
« on: December 03, 2013, 06:04:27 am »
Clone from here and it will failover from beeeeer to rpool.

BitShares PTS / Re: [ANN] - Protoshares mining sub-pool
« on: December 02, 2013, 11:58:31 pm »

no connection to the server, reconnecting in 10 seconds
connecting to

Same here.

Keyhotee / Re: Screen Shot
« on: December 01, 2013, 07:16:05 am »
Are there plans for Keyhotee to support plugins?  My understanding is that a key feature of Keyhotee is directly establishing PKI secured TCP connections between users either through a blockchain or DHT for IP lookups, which could be readily usable for many features, some of which are undoubtedly too obscure to clutter the standard application by default.

Also, has Invictus had any contact with the RetroShare ( team?  The identity and reputation management seems much more elegant in Keyhotee, but I'd love to see forums and even a full p2p social network in Keyhotee eventually.

Nice guide, but I'd like to point out that you don't have to type all those commands in PUTTY.  Copy to clipboard, then right click in PUTTY to paste.  Also, once you have one set up, save the image from that instance and select it from "My AMI's" for the next instances so you don't have to install everything again.  This works even better if you add the run miner commands to a startup script, as that way you don't even have to connect to new instances, they'll just put themselves to work.

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