Yes that advantage which you mention comes to mind.

The only exchange that might want to do that which I can think of is campbx, which sets expiration dates on deposit addresses, which I think is ridiculous and foolhardy--there's a risk that users will deposit to expired addresses regardless. (And does campbx destroy their copy of the associated private key?) However, maybe they wouldn't want to set any expiration on deposit addresses if users provide their own public keys for deposit.

I think it would be really cool to create a secure, convenient way to generate public/private key pairs (and by secure, I mean that it ensures an exchange/pool/other third party absolutely doesn't have access to the generated private key). I know of a vanity address mining service that does this, but the process seemed too convoluted/technical to me. Maybe that's just the nature of it (or it can't really be any other way); I don't know.

I believe I'm going to start lobbying exchanges to allow me to give them my own public keys for deposit. The only thing is they'd have to do some re-programming not only for the feature, but for how they take their cut (commissions).

Aside: something else I want is a private/public key generator for virtually every cryptocurrency. I'm not a fan of downloading the entire blockchain of New Cryptocurrency Z in order to secure everything I mine at multipool.us :/ although as things are now, that's what I have to do if I want to personally secure funds.

Y'all who've made pretty and more detailed front ends for this, I'd like to tip you (in addition to donschoe).

Where should I send the tips?

donschoe, if they provide addresses, will you please update your OP with info to tip to them as well?

One other thing: it'd be nice if these listed the time zone and time at which a donation period resets (for example, in donschoe's version, this could be given in parenthesis after the time countdown). I forget when that daily reset is . . . is it midnight Greenwich Mean Time?

Thanks!

I think this may be a potentially very lucrative DAC, both for its own merits and for another possibility it opens up:

Once this is developed and proven (tested both on a widespread testnet and then also a live market), it could probably relatively easily be adapted to create another DAC which would bring other DACs to market by the same mechanism. People place long or short bets the same way as for news articles (in Associated Press DAC), but instead of writers submitting articles to bet on, coders submit DACs, and people place long and short bets on which DACs will perform the best.

It would put into play all of the same mechanisms bytemaster describes to advance more excellent DACs (instead of more excellent news articles), in addition to making the process of creating DACs more lucrative for coders who create DACs that happen to generate a lot of interest.

(Also, as others have noted, the model could be adapted for other kinds of media, or it could be coded as one DAC which brings multiple forms of media--music, art, books, ringtones, software--to market. Associated Media DAC?

I don't know what I'd call the DAC that brings new DACs to market. DAC IPO DAC?

I've tried sending test messages to every public key I've seen posted here, from my Founder ID and also from a test ID; I'll wait for any replies.

The public key of my test ID is:

6wnrX9pWu8BojZoGNVD9TzH4DM9aiAPuUDk819gQ8CUbvW8HZk

I would be curious to know whether the private key for this can be acquired and imported into anyone elses' profile, to make an impromptu test list (shared ID).

So I know it says that at midnight today (new years day/eye) the forking occurs but what time is this exactly?

Need to make sure I have my PTS in my wallet by that time, cheers

EDIT: I mean timezone wise

There is a potential solution to this problem, but it would take some development:

https://bitsharestalk.org/index.php?topic=1997.msg23020#msg23020

An excellent observation about a problem was raised in the thread "Transition from PTS [ProtoShares] to BitShares." The problem is that anyone who does not directly control private keys for their ProtoShares funds cannot inherit the percent of those funds which is clones to any new DAC which honors the BitShares (?) Social Contract. A related problem is that users cannot directly control funds at exchanges, pools etc. when the hosts of the same possess the private keys (and users do not). If you understand these problems already, you can skip the PROBLEM section, and go straight to the SOLUTION section.

PROBLEM: LOSS OF DIRECT CONTROL OF CRYPTOCURRENCY FUNDS WHEN THE PRIVATE KEYS ARE HELD BY OTHERS:

https://bitsharestalk.org/index.php?topic=779.msg9109

-- which problem is also underscored in the thread "Exact time of forking from protoshare to BitShares:

https://bitsharestalk.org/index.php?topic=1804.msg20310

The problem surrounds the following situation. Suppose a developer makes a new DAC, let's just call it DAC X, and she decides to honor the BitShares (?) Social Contract in doing so. Therefore, to initialize the genesis block of DAC X, she developer takes a snapshot of e.g. ProtoShares at the time of block Y. This shapshot is of all the stakes (addresses) in the ProtoShares blockchain at a given time. She uses this snapshot as a basis of DAC X, instantly allocating ten percent of all stakes in DAC X proportionally to every stakeholder of ProtoShares at that time. The way that these stakes are awarded is that all ProtoShares stakeholders import their private keys from ProtoShares to their new wallets in DAC X; they thus claim their control of their new inheritance in DAC X.

A problem that arises in this is that anyone whose stakes in ProtoShares are controlled by a third party (at the time the DAC X genesis block is initialized) risks missing inheritance of their stakes in DAC X. For example, every ProtoShares stakeholder who has funds stored at an exchange or at a mining pool does not have direct control over those funds: they entrust the private keys which control those funds to others. Only the exchange or pool operators control the private keys associated with their funds. When the DAC X genesis block is initialized, these stakeholders therefore lose even peripheral control of their stakes. To claim their stakes, they will need to ask the exchange or pool operators to copy the private keys to them, and then transfer those funds to some private/public key pair which they fully control. This situation also runs the risk that the exchange or pool operators could refuse to honor their trust, and simply steal the funds by importing the private keys into their own new wallet for DAC X (without honestly giving the private keys to the proper owner).

This is also the general problem with hosted wallets: users trust third parties to not abuse the private keys. Heist after heist has originated in people either abusing that trust or outright cracking into virtual spaces, unwelcome, and abusing the keys to move cryptoccurency to their own wallets.

SOLUTION: STANDARDIZED USE OF INTERMEDIATE PASSPHRASE CODES:

I've run across a "Bitcoin Address Utility," which is apparently both free and open-source:

http://casascius.wordpress.com/2013/01/26/bitcoin-address-utility/

-- which utility makes use of a mechanism, which I can only suppose was created by others in order to address this very type of situation. What this utility reveals is solution called Intermediate Passphrases.

The tool itself explains:

Enter a passphrase, and [click the "Encode passphrase" button, and an Intermediate Passphrase Code will be generated. You can give this code to someone else, and they can use it to create encrypted Bitcoin addresses that require your original passphrase to spend. The other party can add funds to the addresses but cannot spend funds from them.

So, for example, I can bring up this tool and enter the following in the Passphrase field:

youtube spawns ineloquent buffoons
-- and then click the "Encode Passphrase" button, and it spits out something like this:

passphraseb9XBYGJvQ7P9BtHcESYP4Hr6gz8V52AkHKhwfut6edA1ebZHpyrANYSBWj1zty
Apparently, it is possible to code a mechanism which can use that (long, wonderfully garbled nonsense of a) passphrase, which would allow a user to have third parties deposit funds on their behalf, at the same time that it would only be possible for the user (not the third party, nor any other party) to spend the funds. I don't understand it myself, but here is the technical proposal, and apparently also an outline of how to achieve this:

https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki

Implementing this with a standardized codebase, and maybe even an API to execute this--this would solve one Huge problem and another (at least) Big Problem. The Huge Problem is the risk of losing funds which cannot always be secured by third parties (for example, cryptocurrency history is so far littered with so many terrible heists--from exhanges, web wallets, and even mining pools--which the practice of using Intermediate Passphrase Codes could have avoided). The Big Problem it would solve is that anyone who holds ProtoShares at exchanges, pools etc. which were deposited at addresses derived of Intermediate Passphrase Codes--holders of ProtoShares at such addresses would be able to control the funds of a new DAC which gives them an inheritance from a ProtoShares blockchain snapshot, immediately, without having to bother at all with whether the inherited funds derive from wallets at exchanges vs. a wallet they personally, directly control.

Please, will someone brilliant (or some brilliant team) code a standardized toolset which would make implementation of this relatively easy for both web-based and client-based wallet developers? I could suggest, even, that this would be a very worth Bounty for Invictus to throw out there; they would benefit from it a lot . . .

[At the risk of being overly blathering]

!

I'd like to add that the approach I speculate (hard-coded donation mining), if done for, say, six months, would probably net reorder far more than a salary and/or voluntary donations (depending on how widely the re-coded miner is adopted).

!

OR:

reorder, you could open-source it under those terms: with a statement that it will mine for 1.25 hours to your donation address every day, and code it to do so. I'd totally mine with that. "breaking" proof-of-work momentum for GPUs had a high bounty associated with it, and this miner if widely adopted will probably produce a lot of value for everyone . . . it would also make it easier for the PTS devs to adjust the algorithm against whatever advantages you discovered . . .