Author Topic: How to claim inherited ProtoShares -> DAC X funds when they sit at exchanges  (Read 3330 times)

0 Members and 1 Guest are viewing this topic.

Offline Primecoindude

  • Jr. Member
  • **
  • Posts: 25
    • View Profile
One interesting point is if that if f:ex Cryptsy dont honor PTS>BTS for their users, will they still claim "their" BitShares!?
Did they claim "their" Memorycoins!?
How many "orphaned" BitShares will there be out there!?

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
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.

You shouldn't ever have to download the blockchain just to generate a keypair. I use the QT bitcoin client to generate keys all the time.
Also vanitygen can generate arbitrary keys if you know the network byte, it's as simple as "vanitygen -X <byte> <initial network letter"
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline earthbound

  • Full Member
  • ***
  • Posts: 120
    • View Profile
    • earthbound.io
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.
I think I'm not alone when I say I'd like to see more and more planets fall under the ruthless dominion of our solar system. -Jack Handey

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Well assuming I understand the OP correctly and that new mechanic only allows for exchanges to add funds to a wallet without being able to spend it, it seems like we would be more likely to get exchanges to accept public-key-direct-deposits than implement the feature you mentioned.

The only advantage the link in the OP has is that it allows the exchange to generate new addresses for each deposit. I have a suspicion the type of user we'd be targeting are much more likely to go along with "paste 10 public keys you own here to activate / continue using your account" rather than "learn yet another piece of technology to generate a deterministic wallet thing".


Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline earthbound

  • Full Member
  • ***
  • Posts: 120
    • View Profile
    • earthbound.io
Ah, that's an excellent point. It would be much simpler to have a centralized exchange allow users to specify a public key (address) for all deposits (for which only the user controls the private keys).

However, I do have a rebuttal to that.

First, why are you assuming there cannot be any good reason to ever entrust accrual of funds to third parties? There are many situations where doing that is beneficial (and I don't even want to get into that). Second, saying "we need" to do X is one thing; doing it is another. The fact is, users and exchanges are not doing this, and simply instructing them that they need to do otherwise isn't a solution. Many will choose not to.

But going back to the first point, there are legitimate situations where people have legitimate reasons to delegate control of their funds to others. The solution I found a specification for (and for which you propose a simpler solution) could be a good compromise. But there may also be other uses for the specification I found.
I think I'm not alone when I say I'd like to see more and more planets fall under the ruthless dominion of our solar system. -Jack Handey

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Quote
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.

Does this solve anything that sharing your public keys with the exchange doesn't?
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Quote
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.

If you do not control the (unique) private keys, you do not control the protoshares. End of story. We need to teach people about key management and stop the idea that something that someone else controls is "yours".

When you send PTS to an exchange, you no longer own PTS. You own CryptsyPTS, which Cryptsy promises to exchange for real PTS when you click "withdraw".

We need to skip this and go straight to decentralized exchanges.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline earthbound

  • Full Member
  • ***
  • Posts: 120
    • View Profile
    • earthbound.io
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:

Quote
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:

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

Code: [Select]
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 . . .
« Last Edit: January 04, 2014, 09:25:55 pm by McGreedy »
I think I'm not alone when I say I'd like to see more and more planets fall under the ruthless dominion of our solar system. -Jack Handey