Author Topic: AGS potential security issue  (Read 13187 times)

0 Members and 1 Guest are viewing this topic.

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile

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.


Offline blahblah7up

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

Offline blahblah7up

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

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
I disagree. Signing a message transfers over the responsibility to a new unexposed private key. How does that not solve the problem?

Offline blahblah7up

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

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
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! :)

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
Then what overhead are you talking about? :)

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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.
Quote
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 :-)

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
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? :)
« Last Edit: June 02, 2014, 07:23:35 am by asenski »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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!

Offline bitmeat

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

Offline bitmeat

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

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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?

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
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.
« Last Edit: June 02, 2014, 05:30:47 am by asenski »

Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile
I see, then all the addresses use the SIG(pubkey, "BTSX"), right?