AGS potential security issue

[testz]

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

Look like new etherum use same idea 
https://bitcointalk.org/index.php?topic=563925.0

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.

[xeroc]

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

[toast]

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

[xeroc]

how can we protect our AGS private key while claiming shares from  3rd party DAC?

Aye.  There's the right question to be discussing.

We already do (obviously unnoticed):
https://bitsharestalk.org/index.php?topic=4737.msg61330#msg61330

Could you (@Stan or @Bytemaster) comment on Freetrades idea?

[Stan]

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.

Don't get us wrong.  As serious AGS holders we would benefit from having them be liquid.  But we stated multiple reasons, among which are regulatory considerations.

Watch for Parts 2 and 3 of "Happy Birthday BitShares."  You'll get more insights there.

In the mean time, I'll point out that, as a ProtoDAC, XTS will make AGS partly liquid, since all BitShares X variants will be derived from it.  Over time, other ProtoDAC families will do the same.  See our March Newsletter for detail on the concept of ProtoDAC families and DAC industry sectors.

[bitmeat]

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.

[sudo]

how about give a chance to  transfer AGS  such as  every other year?

[Stan]

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'.     

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?

Aye.  There's the right question to be discussing.

[sfinder]

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'.     

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?

[Stan]

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'.     

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.

[bytemaster]

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'.     

[blahblah7up]

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.

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.

I also like this idea but it still relies on a single point of failure.  In that case you better be sure you made your AGS donation with a signed tx from a paper wallet created on an air gapped computer.

Do you think most people did?

[bitmeat]

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.

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.

Right, but we wouldn't be changing the distribution amounts, just allowing ownership to be transferred, prior to launch. Anyways. We live and learn. I would do this if I know Invictus would honor it for BTSX otherwise I have no incentive at the moment.
And again, it seems they are much closer to release so defeats the purpose a bit. But had the idea met less criticism I could've had it up and running back in March.

Thanks for the positive feedback, toast!

[toast]

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.

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.

[bitmeat]

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.

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.

[bitmeat]

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.

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.

[blahblah7up]

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.

[blahblah7up]

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.

[bitmeat]

I disagree. Signing a message transfers over the responsibility to a new unexposed private key. How does that not solve the problem?

[blahblah7up]

I raised this question several months ago and still think it is very important to find a solution.

https://bitsharestalk.org/index.php?topic=3422.msg42965#msg42965

The idea about using a signed message to avoid exposing the private key doesn't solve the issue because of the ever present possibility of ERRANT HUMAN BEHAVIOR.  Once the keys are "accidentally" exposed, it should be possible to somehow correct the situation (like in any email program you can log in and change your password if for whatever reason you feel that you should).

Suppose for instance someone breaks into your house and you have your private keys stored somewhere.  Nothing is missing and you don't know if the keys were even discovered but you would just feel safer to change those private keys.  At the moment this isn't an option.

[bitmeat]

Or even simpler:

Scratch the Fees idea (originally I was looking for a design that would motivate Invictus to do this)

INPUT:
OLD_DONOR_ADDRES

OUTPUTS:
1_ANGEL_ADDRESS | AMT: 1 satoshi
1_NEW_DONOR_ADDRESS | AMT: 1 satoshi


If sent 1 satoshi to ANGEL address combined with 1 satoshi to another address, then that's the transfer of responsibility.

DONE - won't even need to create/parse new vanity address!

[bitmeat]

Then what overhead are you talking about?

[xeroc]

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.

True.

EDIT: I might have misunderstood. Did you mean we can't parse multiple output transactions?

Why should we not. Sure we can. Having multiple inputs might be an issue, but sending 1 satoshi can be done with one input easily :-)

[bitmeat]

We already have a tool that parses one address, that's the hard work 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?

[xeroc]

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 AGS

So you have

INPUT:
OLD_DONOR_ADDRES

OUTPUTS:
1_AGS_TRANSFER | AMT: FEE (say 0.01BTC)
1_NEW_DONOR_ADDRESS | AMT: 1 satoshi

This is totally doable. Parser generating genesis addresses would need to be adjusted to look for 1_AGS_TRANSFER as well.

Much like satoshi dice ...

Can work .. however. To generate a new genesis block for new DACs you now need to pars 2 addresses .. that is an overhead.

But still, nice solution!

[bitmeat]

I think BM could even do this for 1% fee of all transfers using this method. That way it is discouraged.

Or if he is feeling generous he could have all transfer fees be redistributed to the rest of the group. That way those who stick around get an even higher dividend.

[bitmeat]

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 AGS

So you have

INPUT:
OLD_DONOR_ADDRES

OUTPUTS:
1_AGS_TRANSFER | AMT: FEE (say 0.01BTC)
1_NEW_DONOR_ADDRESS | AMT: 1 satoshi

This is totally doable. Parser generating genesis addresses would need to be adjusted to look for 1_AGS_TRANSFER as well.

[xeroc]

Sending messages over bitcoin network is not possible.
Blockchain.info is just a centralized service that one can use to send a message. or are you proposing the use of OP_RETURN?

[bitmeat]

Final suggestion from me on making AGS liquid:

Why not make it so that if some minimal amount of BTC is sent to the ANGEL BTC address with a special message containing a valid BTC address, then it transfers over the AGS to the new address?

Then that amount can be kept as "transfer fee".

Of course, there could be complication for snapshots that are already taken. i.e. Feb 28 for the BTSX, would it still honor transfer AFTER the Feb 28 snapshot, or not, etc.
But nothing we couldn't implement easily. We already have tools to parse the transactions from AGS, just parse the messages as well.

Thoughts, comments?

UPDATE (examples):

FEB 1, 2014:
1SomeBTCAddressT56mDQzEdebQdibmigU-> 1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc | AMOUNT: 1 BTC

FEB 2, 2014:
1SomeBTCAddressT56mDQzEdebQdibmigU-> 1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc | AMOUNT: 1 BTC

APR 2, 2014:
1SomeBTCAddressT56mDQzEdebQdibmigU-> 1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc | AMOUNT: 3 BTC

JUNE 15, 2014:
1SomeBTCAddressT56mDQzEdebQdibmigU-> 1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc | AMOUNT: 0.02 BTC
MESSAGE: "TRANSFER TO 1AnotherBTCAddressGPZhHaYfLsMkiQcR"

JUNE 25, 2014:
1SomeBTCAddressT56mDQzEdebQdibmigU-> 1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc | AMOUNT: 1 BTC


Now this person gets to control his 2BTC worth of BTS X with his new address 1AnotherBTCAddressGPZhHaYfLsMkiQcR, even though transfer happened after the snapshot, it happened before BTSX went live. As well as 5 BTC of all future DACs honoring AGS. The 1BTC on JUNE 25, will still be controlled by original address since donation occurred after the transfer.

Or if BM thinks this seems too complicated, then we can just do it for future releases.

[bitmeat]

I see, then all the addresses use the SIG(pubkey, "BTSX"), right?

[toast]

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)

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?

>  only holders of AGS could generate the public address for each DAC.

Not true - you put the public keys in the genesis block like you do now, but to claim them you check the SIG(pubkey, "BTSX") instead of just SIG(pubkey).

We don't use OP_, we hard-code all needed transaction types for each DAC

[bitmeat]

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)

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?

[crazybit]

We disscused sth similar in the "Mirrorchain" thread .. you should take a look

Thx,i would take a look

[xeroc]

We disscused sth similar in the "Mirrorchain" thread .. you should take a look

[toast]

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)

Yep, we can have a dedicated tool just for this

[crazybit]

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)

[toast]

How about this?

https://bitsharestalk.org/index.php?topic=4737.0

How would that solve the problem?

[Overthetop]

How about this?

https://bitsharestalk.org/index.php?topic=4737.0

[bitmeat]

The more times a private key is used to sign, the easier it is to hack the address. That's why Satoshi in his original paper recommends creating a new change address every time a transaction is signed. Real security is achieved if you ONLY sign things ONCE per private key.

[crazybit]

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.

Yes,you got my point of the security issue part,but i am not talking about liquid AGS,just concern for the AGS Security issue.

[crazybit]

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

you have to admit that it is possible your private key might be exposed if it is imported to the customized or malicious DAC client with the purpose to steal your private key.we cannot review every DAC client source code(i think mainly the third party DAC) and build client by ourselves to make sure the client will not steal our private key.

[toast]

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.

[santaclause102]

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

[crazybit]

One thing sure is that more and more DAC will come out in future,but there is a potential security issue that the more times we import the AGS private key to claim the corresponding shares in the DAC,the more risk the private key might be exposed,under the current social contract without AGS Liquid,we even cannot transfer the AGS shares to other address if the private key exposed,is there any consideration or plan to improve the AGS security,please discuss.