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.msg20310The 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.mediawikiImplementing 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 . . .