0 Members and 1 Guest are viewing this topic.
I feel like I've read that suggestion like 4 times already.Yes, having a tool to sign the transaction outside the 3rd party DAC is a good idea. I think nobody is discussing it because it seems obvious...
13. But I don’t trust you with my bitcoin private keys.There is no need to trust us. Simply sign an æther address under your control with a bitcoin private key using whatever wallet you are comfortable with (e.g., blockchain.info, Armory, etc.,) and paste the resulting signature into the æthereum client.
Quote from: sfinder on June 04, 2014, 02:53:35 amhow can we protect our AGS private key while claiming shares from 3rd party DAC?Aye. There's the right question to be discussing.
how can we protect our AGS private key while claiming shares from 3rd party DAC?
So help me understand - PTS doesn't have regulatory issues because it was mined, not issued? And in retrospect - AGS might have regulatory issues, because it was directly funded?I'm asking because from a technical perspective I don't see any issues implementing this. It seems that you guys are avoiding it like a hot potato, but if that's what your lawyers said then I guess it explains the resistance on your part.
Quote from: Stan on June 04, 2014, 02:23:05 amQuote from: bytemaster on June 04, 2014, 02:03:48 amMaking AGS liquid will have to be a community activity and is not something we can do. If AGS were tradable it would become property and this property could become a security with imaginative regulators. While AGS is not tradable it is not property nor an asset. It is merely a record of your donation that other DAC launchers may airdrop to. If someone wants to come along and create Liquid AGS and then market it as the better choice to airdop to then that is their business, but we cannot endorse it or 'bless it'. Precisely. Plus, you don't want us to:1. Its unique property is that it lets developers air-drop to proven donors - an awesome demographic.2. If you make it tradable, then it is no different from PTS.3. So a third party might ask, "Why is this one demographic worth 20%?"You want PTS and AGS to stay separate demographics, each worth honoring for its own reason.how can we protect our AGS private key while claiming shares from 3rd party DAC?
Quote from: bytemaster on June 04, 2014, 02:03:48 amMaking AGS liquid will have to be a community activity and is not something we can do. If AGS were tradable it would become property and this property could become a security with imaginative regulators. While AGS is not tradable it is not property nor an asset. It is merely a record of your donation that other DAC launchers may airdrop to. If someone wants to come along and create Liquid AGS and then market it as the better choice to airdop to then that is their business, but we cannot endorse it or 'bless it'. Precisely. Plus, you don't want us to:1. Its unique property is that it lets developers air-drop to proven donors - an awesome demographic.2. If you make it tradable, then it is no different from PTS.3. So a third party might ask, "Why is this one demographic worth 20%?"You want PTS and AGS to stay separate demographics, each worth honoring for its own reason.
Making AGS liquid will have to be a community activity and is not something we can do. If AGS were tradable it would become property and this property could become a security with imaginative regulators. While AGS is not tradable it is not property nor an asset. It is merely a record of your donation that other DAC launchers may airdrop to. If someone wants to come along and create Liquid AGS and then market it as the better choice to airdop to then that is their business, but we cannot endorse it or 'bless it'.
Quote from: blahblah7up on June 03, 2014, 06:31:28 pmAs I understood the suggestion, the signed message was to be used to collect the shares of the new DAC instead of the private key. But if the private key has already been exposed anyone who has it can create that signed message.As far as private key already exposed there is no good way to solve that with the current system. I did like the idea of using derived individual private key per DAC so that if one DAC software steals it, it doesn't compromise the rest of your apps.
As I understood the suggestion, the signed message was to be used to collect the shares of the new DAC instead of the private key. But if the private key has already been exposed anyone who has it can create that signed message.
Quote from: asenski on June 03, 2014, 06:56:40 pmQuote from: blahblah7up on June 03, 2014, 06:38:47 pmThat is how I interpreted CrazyBit's suggestion.You seem to be suggesting that AGS will be liquid but I still haven't heard anything that suggests that from anyone within Invictus.Yes, my proposal makes it liquid and is extremely easy to implement. Had I seen some support from Invictus I would even volunteer to implement it. But no dice. So we wait. Seems like we are close for the BTS X though.I think it's a pretty good idea, and anyone is free to implement it. Likewise anyone is free to just go ahead and implement a liquid version of AGS once the donation period ends.I just don't think anyone here wants to change the officially endorsed definition of AGS, don't want to make the "changing the deal" reputation worse.
Quote from: blahblah7up on June 03, 2014, 06:38:47 pmThat is how I interpreted CrazyBit's suggestion.You seem to be suggesting that AGS will be liquid but I still haven't heard anything that suggests that from anyone within Invictus.Yes, my proposal makes it liquid and is extremely easy to implement. Had I seen some support from Invictus I would even volunteer to implement it. But no dice. So we wait. Seems like we are close for the BTS X though.
That is how I interpreted CrazyBit's suggestion.You seem to be suggesting that AGS will be liquid but I still haven't heard anything that suggests that from anyone within Invictus.
We already have a tool that parses one address, that's the hard word and it's been done. Parsing a second one is trivial.
EDIT: I might have misunderstood. Did you mean we can't parse multiple output transactions?
I missed that detail, but my solution still works. Let me provide more info.Make a special 1_AGS_TRANSFER BTC address.When you want to send a "TRANSFER TO xxx" message as a transaction do this:Send 0.01 BTC (or whatever fee BM thinks is appropriate, or if generous make it 1 satoshi) to the 1_AGS_TRANSFER address.In the same transaction send 1 satoshi to the new BTC address that will control your AGSSo you haveINPUT:OLD_DONOR_ADDRESOUTPUTS:1_AGS_TRANSFER | AMT: FEE (say 0.01BTC)1_NEW_DONOR_ADDRESS | AMT: 1 satoshiThis is totally doable. Parser generating genesis addresses would need to be adjusted to look for 1_AGS_TRANSFER as well.
Quote from: CrazyBit on May 31, 2014, 05:04:20 amInspired by logxing's proposal, i come up with an idea which may completely solve this potential security issue. if we could use the signature which sign on the specified text(e.g the donation address) with private key, to claim the corresponding shares in different DACs,then we would not worry about private key stolen,as we do NOT need to expose our private key and use different signature to claim the shares in different DAC. e.g signature to claim the XTS shares =sign(“XTS”+Pts/BTC donation address, PrivateKey), signature to claim the DNS shares =sign(“DNS”+Pts/BTC donation address, PrivateKey)Awesome! I strongly prefer this method. This should be a standard tool in the toolkit. I would imagine we already have a tool that generates the genesis block.One problem I see with this method however, is that it generates a signature, not a public address. i.e. only holders of AGS could generate the public address for each DAC.Unless the DAC itself has a method of claiming by signature, but that may complicate the protocol.Does the Bitshares framework support the same transaction OP_ codes as Bitcoin?
Inspired by logxing's proposal, i come up with an idea which may completely solve this potential security issue. if we could use the signature which sign on the specified text(e.g the donation address) with private key, to claim the corresponding shares in different DACs,then we would not worry about private key stolen,as we do NOT need to expose our private key and use different signature to claim the shares in different DAC. e.g signature to claim the XTS shares =sign(“XTS”+Pts/BTC donation address, PrivateKey), signature to claim the DNS shares =sign(“DNS”+Pts/BTC donation address, PrivateKey)
We disscused sth similar in the "Mirrorchain" thread .. you should take a look
How about this?https://bitsharestalk.org/index.php?topic=4737.0
I think he means a malicious client stealing private keys. Of course this is a great reason to make AGS liquid.You can always sign transactions offline and refuse to use a client that doesn't allow you to construct unsigned transactions.
I don't think you expose your private keys to anyone else in the network. You just verify on your local machine to the network that you own the address that is granted shares...