MirrorChain--to solve the security threat during the new DACs distribution

[monsterer]

I don't think everyone would wish to release the source to their DACs.

They might as well, since the DAC will run on anyone's machine it will just get disassembled anyway if there's no source.

[Gentso1]

Any way to implement these directly into the toolkit? Any thoughts on when this ideas might be able to be looked at?

[Overthetop]

It seems DPOS really works, maybe it is time to think about security issues.

:)

[sfinder]

Might be possible to have the PTS client sign the first transaction to release funds from the genesis block.

Steps:
1: Enter public key into new DAC client
2: New DAC client creates unsigned transaction
3: PTS/Trusted client signs transaction
4: Signed transaction posted into new DAC client

Can I apply the same steps to btc wallet which been used for AGS donation? 

[cass]

Only thing that hurdles me is that the user needs to create 3 files. Much like signing offline txs with bitcoin using Armory :-)
But ... secure!

Yes, very similar.

Also the process could alternately be handled on a webpage similar to brainwallet so that no software need be installed -

Steps:

1. Enter public key(s) / upload file of public keys to web form
2. Generate unsigned transaction
3. copy/paste unsigned transaction into trusted client (eg PTS client)
4. copy/paste signed transaction back into web form

+5% | interesting discussion

[xeroc]

@crazybit: thats the whole idea of freetrades proposal a few post earlierer

[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)

my idea, please discuss if it is feasible.

https://bitsharestalk.org/index.php?topic=4732.msg62135#msg62135

[Troglodactyl]

Only thing that hurdles me is that the user needs to create 3 files. Much like signing offline txs with bitcoin using Armory :-)
But ... secure!

Yes, very similar.

Also the process could alternately be handled on a webpage similar to brainwallet so that no software need be installed -

Steps:

1. Enter public key(s) / upload file of public keys to web form
2. Generate unsigned transaction
3. copy/paste unsigned transaction into trusted client (eg PTS client)
4. copy/paste signed transaction back into web form

I think this is a good problem to solve with the toolkit.  The toolkit could have an associated standalone trusted tool that reads a new DAC's genesis block and the wallet generated for that DAC, then imports all snapshot wallets and creates signed transactions to move your stake to your new wallet.

[Overthetop]

Only thing that hurdles me is that the user needs to create 3 files. Much like signing offline txs with bitcoin using Armory :-)
But ... secure!

Yes, very similar.

Also the process could alternately be handled on a webpage similar to brainwallet so that no software need be installed -

Steps:

1. Enter public key(s) / upload file of public keys to web form
2. Generate unsigned transaction
3. copy/paste unsigned transaction into trusted client (eg PTS client)
4. copy/paste signed transaction back into web form

It is great!
+5%

[FreeTrade]

Only thing that hurdles me is that the user needs to create 3 files. Much like signing offline txs with bitcoin using Armory :-)
But ... secure!

Yes, very similar.

Also the process could alternately be handled on a webpage similar to brainwallet so that no software need be installed -

Steps:

1. Enter public key(s) / upload file of public keys to web form
2. Generate unsigned transaction
3. copy/paste unsigned transaction into trusted client (eg PTS client)
4. copy/paste signed transaction back into web form

[xeroc]

Steps:
1: Enter public key into new DAC client
2: New DAC client creates unsigned transaction
3: PTS/Trusted client signs transaction
4: Signed transaction posted into new DAC client

That sounds VERY nice! Also PTS wallet should already be installed by most investors!

+5% for this approach!!!

So basically to make things easy for the user we should go like

1.) PTS-wallet: store Pubkeys in a file
2.) DAC-wallet: import Pubkeys from file
3.) DAC-wallet: create transaction(s) to redeem genesis transaction(s) (who exactly? send everything to a single new address or go for a splitting into pieces?)
3.) DAC-wallet: write raw transaction(s) into file
4.) PTS-wallet: Load the file and sign the tx(s)
5.) PTS-wallet: store signed tx(s) into file (third file for those who didn't count :-) )
6.) DAC-wallet: load signed tx(s) from file
7.) DAC-wallet: broadcast tx(s)

Only thing that hurdles me is that the user needs to create 3 files. Much like signing offline txs with bitcoin using Armory :-)
But ... secure!

[Overthetop]

Maybe we can use some ellyptic curve magic to solve the issue ... much like what TITAN does?

I think the way we can get around this is to have a separate 'trusted' process that can sign arbitrary data for a new chain.  This process would report to the new DAC all of the addresses it can sign for.

This way the new DAC never sees your private key, but can still use it for signing transactions *FOR THAT DAC ONLY*. 

Yes , I think  that way makes sense.  :)

It  is called a "Firewall" .

[xeroc]

Steps:
1: Enter public key into new DAC client
2: New DAC client creates unsigned transaction
3: PTS/Trusted client signs transaction
4: Signed transaction posted into new DAC client

That sounds VERY nice! Also PTS wallet should already be installed by most investors!

+5% for this approach!!!

[FreeTrade]

Might be possible to have the PTS client sign the first transaction to release funds from the genesis block.

Steps:
1: Enter public key into new DAC client
2: New DAC client creates unsigned transaction
3: PTS/Trusted client signs transaction
4: Signed transaction posted into new DAC client

[xeroc]

Maybe we can use some ellyptic curve magic to solve the issue ... much like what TITAN does?

The problem is that without the actual public key of the account holder you cannot do any operation other than signature verification and that requires the private key. 

If we had the public key for every address in the snapshot then it would be possible to separate out the tool that imports the private keys for each chain from the chain itself. 

I think the way we can get around this is to have a separate 'trusted' process that can sign arbitrary data for a new chain.  This process would report to the new DAC all of the addresses it can sign for.

This way the new DAC never sees your private key, but can still use it for signing transactions *FOR THAT DAC ONLY*. 

I dont understand much of the ECC magic but couldn't we go for a hybrid, such that if the pubkeys is known we can do ECC magic .. if not the owner needs to work on the actual privkey ..

we could then update the pubkeys for new DACS on a regular bases using most recent blockchain (assuming no one really can break ripmed150(sha256(pubkey)))

Just asking

[bytemaster]

Maybe we can use some ellyptic curve magic to solve the issue ... much like what TITAN does?

The problem is that without the actual public key of the account holder you cannot do any operation other than signature verification and that requires the private key. 

If we had the public key for every address in the snapshot then it would be possible to separate out the tool that imports the private keys for each chain from the chain itself. 

I think the way we can get around this is to have a separate 'trusted' process that can sign arbitrary data for a new chain.  This process would report to the new DAC all of the addresses it can sign for.

This way the new DAC never sees your private key, but can still use it for signing transactions *FOR THAT DAC ONLY*. 

 

[toast]

I am a bit skeptical that the more profitable DACs would release their source and allow their whole business to be instantly cloned. 

I see you are not familiar with Stan's classic "10 laws" post:

So here is our list of the rather obvious Ten Natural Laws of the Crypto-Asset Universe.  All wise developers should be aware of these unspoken rules of competition and plot their private business strategies accordingly:

1.   All software must be open source to be trusted.
2.   It is ethically acceptable to clone alt-coins from anybody else's open source.
3.   If you demonstrate a good idea, others will clone it – without market objection.
4.   They will clone it if just to give it a better name.
5.   They will clone it to slightly modify one of its parameters.
6.   They will clone it to better appeal to another group of stakeholders.
7.   They will clone it to make it more profitable (and therefore more appealing).
8.   These clones will compete in the free market.
9.   The clone that appeals to the biggest and most influential crowd wins.
10.   The clone that achieves the Network Effect first may ultimately get to ignore the first 9 rules.

[xeroc]

Maybe we can use some ellyptic curve magic to solve the issue ... much like what TITAN does?

[gamey]

I am a bit skeptical that the more profitable DACs would release their source and allow their whole business to be instantly cloned. 

Really the only solution will be a hot/cold wallet as far as I can see.

[xeroc]

Oh .. i am afraid my capabilities in reading and securing code are somewhat limited

[Overthetop]

To me that sounds like a business opportunity, checking DAC sources :-)

Yeah ,sure.

You deserve it ,and maybe one day we can have a deal.

:P

[xeroc]

To me that sounds like a business opportunity, checking DAC sources :-)

[Overthetop]

I don't think everyone would wish to release the source to their DACs.

Those probably wont make me to post my angelshare private key into. Not gonna happen!

Even with source code, I do not think it is safe enough .

Because more and more Dacs are coming out and they  become more and more complex .

So it is not easy to review each of them clean or not  .

[xeroc]

I don't think everyone would wish to release the source to their DACs.

Those probably wont make me to post my angelshare private key into. Not gonna happen!

[gamey]

So, I suggest to setup one Mirrorchain by 3i offically to maintain the PTS,AGS etc data.
[...]
How about this ?

Decentralized!

You can always diff the official bitshares_toolkit against the new DAC and see for you self what changes they did. If you cannot read code, let others do the work for you!

We might need a trusted compile platform for the binaries

I don't think everyone would wish to release the source to their DACs.

[xeroc]

So, I suggest to setup one Mirrorchain by 3i offically to maintain the PTS,AGS etc data.
[...]
How about this ?

Decentralized!

You can always diff the official bitshares_toolkit against the new DAC and see for you self what changes they did. If you cannot read code, let others do the work for you!

We might need a trusted compile platform for the binaries

[Overthetop]

At present,more and more new DACs will come out and use Free distribution promotion strategy.

However ,there are always security threat during the process of importing the private keys of PTS/AGS/BTX ...  to new DACs.

So, I suggest to setup one Mirrorchain by 3i offically to maintain the PTS,AGS etc data.

The mirrorchain has no business function only performs as a data-provider for new DACs.

With the "MirrorChain", we get a firewall between our assets and strange new DACs.

The mirrochain can refresh the data frequently to keep up the new data ,and will always be ready for new DACs distribution.

How about this ?

:)