BitShares Forum
Main => General Discussion => Topic started by: bitder on July 14, 2014, 02:25:29 pm
-
When will claiming genesis balances without importing private keys be supported in the toolkit?
i.e. claiming by signing with private keys (proof of ownership) instead of having to trust every single DAC with your private keys.
IMHO, we can't launch anything without this since once there's a trojan DAC binary and it has compromised some private keys then it could kill the whole bitshares ecosystem.
-
When will claiming genesis balances without importing private keys be supported in the toolkit?
i.e. claiming by signing with private keys (proof of ownership) instead of having to trust every single DAC with your private keys.
IMHO, we can't launch anything without this since once there's a trojan DAC binary and it has compromised some private keys then it could kill the whole bitshares ecosystem.
Ill think about the best way to implement this.
-
Can't we just integrate this through offline transaction signing? If support for exporting unsigned transactions and importing signed ones is added to the toolkit, that should solve the problem. Then you just need a single trusted tool to sign the transactions.
-
personally I claim whatever shares I deserve on DACs only after an implementation in this direction...
-
When will claiming genesis balances without importing private keys be supported in the toolkit?
i.e. claiming by signing with private keys (proof of ownership) instead of having to trust every single DAC with your private keys.
IMHO, we can't launch anything without this since once there's a trojan DAC binary and it has compromised some private keys then it could kill the whole bitshares ecosystem.
+5% Very good point. We'll need some better, simpler solutions moving forward anyway for those less technically savvy.
-
I worry about this issue too. If you only hold PTS, it's OK, because we can send our PTS to another address after claiming our shares in new DAC, but for AGS, since it's not liquid, we have to be very careful.
-
Is it possibile using ags and pts keys as "master keys" and using new generated keys in the genesis block for each dacs?
-
Is it possibile using ags and pts keys as "master keys" and using new generated keys in the genesis block for each dacs?
No, because we don't know the AGS and PTS public key, just the address (hash of public key). This allows us to verify signatures but not perform other useful tasks.
-
Is it possibile using ags and pts keys as "master keys" and using new generated keys in the genesis block for each dacs?
No, because we don't know the AGS and PTS public key, just the address (hash of public key). This allows us to verify signatures but not perform other useful tasks.
Ok, it is clear. thanks!
-
I just added support in the blockchain necessary to create a trusted wallet migration tool that will do the following:
1) Take a Chain ID + BTC Wallet/Password
2) Create a new public key for each address in the BTC wallet
3) Sign the new public key & chain ID with the private key belonging to the BTC/PTS address.
4) Export a new wallet file that contains the new private keys + signatures from the BTC keys.
The new wallet file can then be imported into a wallet for Chain ID and used without risking the theft of your BTC/PTS keys.
-
+1
-
+5% +5% +5% +5% +5% +5%
-
I just added support in the blockchain necessary to create a trusted wallet migration tool that will do the following:
1) Take a Chain ID + BTC Wallet/Password
2) Create a new public key for each address in the BTC wallet
3) Sign the new public key & chain ID with the private key belonging to the BTC/PTS address.
4) Export a new wallet file that contains the new private keys + signatures from the BTC keys.
The new wallet file can then be imported into a wallet for Chain ID and used without risking the theft of your BTC/PTS keys.
wow sounds really awesome :) eager to see +5%
-
3) Sign the new public key & chain ID with the private key belonging to the BTC/PTS address.
4) Export a new wallet file that contains the new private keys + signatures from the BTC keys.
So just so I understand it, does that mean that your shares in the new DAC are sent from the old BTC address which was written into the genesis block, to the new addresses that you just generated with this export feature? i.e. you are using your AGS private key to sign a transaction sending your shares to this new address?
Can I try this out in the next dry run?
-
3) Sign the new public key & chain ID with the private key belonging to the BTC/PTS address.
4) Export a new wallet file that contains the new private keys + signatures from the BTC keys.
So just so I understand it, does that mean that your shares in the new DAC are sent from the old BTC address which was written into the genesis block, to the new addresses that you just generated with this export feature? i.e. you are using your AGS private key to sign a transaction sending your shares to this new address?
Can I try this out in the next dry run?
We don't have the wallet-side tools available to do this yet, but the blockchain is able.
-
Do I understand correctly that its basically a new wallet with new keys plus already signed transactions from the old addresses to the new addresses?
-
Not sure I follow entirely either - Are you using a method here similar to deterministic wallets?
http://bitcoinmagazine.com/8396/deterministic-wallets-advantages-flaw/
If so, is the basic overview usage . .
Chain creator uses:
PublicKeyB = somefunction1(PublicKeyA,chainID);
Sharedrop recipient uses:
PrivateKeyB = somefunction2(PrivateKeyA,chainID);
We're getting some flak and caution (rightly so) for requiring private keys to claim LTS . . reconsidering alternatives.
-
Not sure I follow entirely either - Are you using a method here similar to deterministic wallets?
http://bitcoinmagazine.com/8396/deterministic-wallets-advantages-flaw/
If so, is the basic overview usage . .
Chain creator uses:
PublicKeyB = somefunction1(PublicKeyA,chainID);
Sharedrop recipient uses:
PrivateKeyB = somefunction2(PrivateKeyA,chainID);
We're getting some flak and caution (rightly so) for requiring private keys to claim LTS . . reconsidering alternatives.
Remember, we don't have PublicKey/PrivateKey of the AGS/PTS... just the hash of said key. So I generate a random new public key, then sign it with the private key of the PTS address.
With TITAN we do use this kind of derivation, except in a way that doesn't support auditors/observers and we never intentionally allow users to share a child private key with anyone.