Graphene: Data security and verification on the chain

[BunkerChainLabs-DataSecurityNode]

@noisy I have taken what i think you are getting at and changed it a bit. I think this could work?? @xeroc  @tbone @complexring @abit @JonnyBitcoin @brainbug @Shentist @Akado @TravelsAsia @BunkerChain Labs @merivercap @btswildpig @fuzzy @bytemaster

Bitshares generates a 2 of 2 multisig bitcoin address. 1 of these signitures is held by the witnesses. The other signature is held by the bitshares users account.
The user deposits bitcoin to this new btc account and will only be able to retrieve it when the witnesses provide the other key.
Bitshares then generates a sideBTC token for the user.
The user can then use this SIDEBTC as collateral to create BITBTC.  but they will only need 100% collateral and have zero risk of margin call or force settlement.

To regain access to his realbtc he will need to repay all debts. Bitshares the destroys  the SIDEBTC token and allows access to the real BTC by getting the witnesses to sign with the second key.

As you noted this would be a different class of asset. I think not to long ago I dubbed it SBA (Sidechain Backed Asset). If we do this successfully with BTC it could be done with some others worth transacting.

You want more than just the 2 signatures though. You want multiple signatures between the witnesses to maintain security.

All the bitcoin get pooled the same way they do in exchanges in the witnesses. No matter where the SIDEBTC gets transferred in bitshares then there will always be the exact same amount in holding by the witnesses.

Let's be clear though, this is going to increase the expenses of the witnesses significantly. This means we need to look at increasing the rate of pay for them to support an additional bitcoin node each. On the flip side though, I do think we could become a preferred goto not just for BTC trade but for storage.

[JonnyB]

@noisy I have taken what i think you are getting at and changed it a bit. I think this could work?? @xeroc  @tbone @complexring @abit @JonnyBitcoin @brainbug @Shentist @Akado @TravelsAsia @BunkerChain Labs @merivercap @btswildpig @fuzzy @bytemaster

Bitshares generates a 2 of 2 multisig bitcoin address. 1 of these signitures is held by the witnesses. The other signature is held by the bitshares users account.
The user deposits bitcoin to this new btc account and will only be able to retrieve it when the witnesses provide the other key.
Bitshares then generates a sideBTC token for the user.
The user can then use this SIDEBTC as collateral to create BITBTC.  but they will only need 100% collateral and have zero risk of margin call or force settlement.

To regain access to his realbtc he will need to repay all debts. Bitshares the destroys  the SIDEBTC token and allows access to the real BTC by getting the witnesses to sign with the second key.

So witnesses are not allowed to deposit? Since they know the private key. They can even tell the key to others.

Witnesses only have half the private key (1 of 2).   Witnesses will have to create new personal accounts if they want to deposit btc in this way.

[tonyk]

@noisy I have taken what i think you are getting at and changed it a bit. I think this could work?? @xeroc  @tbone @complexring @abit @JonnyBitcoin @brainbug @Shentist @Akado @TravelsAsia @BunkerChain Labs @merivercap @btswildpig @fuzzy @bytemaster

Bitshares generates a 2 of 2 multisig bitcoin address. 1 of these signitures is held by the witnesses. The other signature is held by the bitshares users account.
The user deposits bitcoin to this new btc account and will only be able to retrieve it when the witnesses provide the other key.
Bitshares then generates a sideBTC token for the user.
The user can then use this SIDEBTC as collateral to create BITBTC.  but they will only need 100% collateral and have zero risk of margin call or force settlement.

To regain access to his realbtc he will need to repay all debts. Bitshares the destroys  the SIDEBTC token and allows access to the real BTC by getting the witnesses to sign with the second key.

Interesting. So you are saying at worst the witnesses can collude to not allow the actual BTC withdrawal(get her BTC out off the 2 of 2 BTC account, but cannot steal the funds for themselves... this sounds enough for me ... enough for someone having something to lose from such action, to say nothing it is a group of them.

@abit I believe it is a separate account for each deposit/transaction. so the issue becomes they faking a deposit by themselves in such 2 of 2 miltisig and issuing bitBTC based on nothing. Is that what you mean?

[abit]

@noisy I have taken what i think you are getting at and changed it a bit. I think this could work?? @xeroc  @tbone @complexring @abit @JonnyBitcoin @brainbug @Shentist @Akado @TravelsAsia @BunkerChain Labs @merivercap @btswildpig @fuzzy @bytemaster

Bitshares generates a 2 of 2 multisig bitcoin address. 1 of these signitures is held by the witnesses. The other signature is held by the bitshares users account.
The user deposits bitcoin to this new btc account and will only be able to retrieve it when the witnesses provide the other key.
Bitshares then generates a sideBTC token for the user.
The user can then use this SIDEBTC as collateral to create BITBTC.  but they will only need 100% collateral and have zero risk of margin call or force settlement.

To regain access to his realbtc he will need to repay all debts. Bitshares the destroys  the SIDEBTC token and allows access to the real BTC by getting the witnesses to sign with the second key.

So witnesses are not allowed to deposit? Since they know the private key. They can even tell the key to others.

[JonnyB]

@noisy I have taken what i think you are getting at and changed it a bit. I think this could work?? @xeroc  @tbone @complexring @abit @JonnyBitcoin @brainbug @Shentist @Akado @TravelsAsia @BunkerChain Labs @merivercap @btswildpig @fuzzy @bytemaster

Bitshares generates a 2 of 2 multisig bitcoin address. 1 of these signitures is held by the witnesses. The other signature is held by the bitshares users account.
The user deposits bitcoin to this new btc account and will only be able to retrieve it when the witnesses provide the other key.
Bitshares then generates a sideBTC token for the user.
The user can then use this SIDEBTC as collateral to create BITBTC.  but they will only need 100% collateral and have zero risk of margin call or force settlement.

To regain access to his realbtc he will need to repay all debts. Bitshares the destroys  the SIDEBTC token and allows access to the real BTC by getting the witnesses to sign with the second key.

[JonnyB]

What if we combine this idea with 2 of 2 multisig, and multisig address for each deposit?


1. User want to deposit a BTC in bitshares blockchain.
2. he generate a public key with bitshares wallet, where private key is stored into blockchain with our brand new "Enigma: Decentralized Computation Platform".

Even if all witnesses collude, this doesn't matter, because..

3. user generate own public and private key. He use his public key and key provided by bitshares network, to create a bitcoin 2 of 2 address.
4. he deposit bitcoins, and now bitshares netowork now, that bitBTC can be created with 100% collateral  in real BTC .
5. when user want to withdraw his bitBTC and turn them into real BTC, he has to initiate this with bitshares wallet.
6. proper amount of bitBTC are destroyed, and then and only then bitshares network signs transaction.
7. user have to sign this withdraw with his private key.

Previously I had an idea, that private keys, could be spread among all witnesses. This actually would almost not make a difference, because even if the witnesses collude, they cannot do nothing without second private key, which user has. With this approach problem is with situation, where witness actually has a second private key, because he made a deposit. In that case, he could withdraw bitcoins, without destroying bitBTC.

So, if witnesses can together sign a transaction, without knowing a 1st private key, which were used, this would mean, that ... this could work?

This makes sense to me @noisy @bytemaster
however it would only work as collateral because you wouldnlt be able to transfer your bitbtc to someone else. because old owner would still have bitbtc key.

but this is perfect solution for collateralising btc to create bitassets.   I think....

[complexring]

i am unsure how one can effectively store a private key on a permissioned blockchain.  someone has to have access to this at some level.  or am i missing something? whomever would have this access would be able to read the private key and thus have access.  i suppose, you could do the 2 of 2 multisignature address option.  but, each time that the associate sidechain's asset is sold on the dex, you'd have to move it to another multisig address where the new holder of the asset would have the new private key.  if you do this often enough (and why wouldn't you?), then the amount will be eaten by the btc transaction fee, which could presumably be passed to the buyer each time ... but the whole process becomes cumbersome.

also, the whole notion of being able to do effective computations on encrypted data is a very hot topic in the mathematics and computer science academic world and the notion is known as homomorphic encryption.  the main disadvantage of homomorphic encryption is that it's uber-slow, i.e. the number of computations that it takes for any known scheme so far is infeasible for real world applications.  this is getting better, since hardware is improving, but applications that will be able to do computations in real-time are in the (near?) future.

that is a great paper that you referenced!  basically, it does the homomorphic encryption, but in a decentralized manner and then uses the spdz protocol to ensure an audit trail of the computations in a public manner, unless i misunderstood the whole point of it.  i need to read it again (probably 5 or 6 times) before i grasp the entirety of the algorithms. 

very nice ... very nice indeed ....

[noisy]

 What if we combine this idea with 2 of 2 multisig, and multisig address for each deposit?


1. User want to deposit a BTC in bitshares blockchain.
2. he generate a public key with bitshares wallet, where private key is stored into blockchain with our brand new "Enigma: Decentralized Computation Platform".

Even if all witnesses collude, this doesn't matter, because..

3. user generate own public and private key. He use his public key and key provided by bitshares network, to create a bitcoin 2 of 2 address.
4. he deposit bitcoins, and now bitshares netowork now, that bitBTC can be created with 100% collateral  in real BTC .
5. when user want to withdraw his bitBTC and turn them into real BTC, he has to initiate this with bitshares wallet.
6. proper amount of bitBTC are destroyed, and then and only then bitshares network signs transaction.
7. user have to sign this withdraw with his private key.

Previously I had an idea, that private keys, could be spread among all witnesses. This actually would almost not make a difference, because even if the witnesses collude, they cannot do nothing without second private key, which user has. With this approach problem is with situation, where witness actually has a second private key, because he made a deposit. In that case, he could withdraw bitcoins, without destroying bitBTC.

So, if witnesses can together sign a transaction, without knowing a 1st private key, which were used, this would mean, that ... this could work?

[chono]

Is that mean, that we could keep private keys in blockchain, like private key to BTC account, which is used to create a bitcoin sidechain? 

Is that mean, that witnesses could also sign a transaction without knowing a key?

Please say yes, please say yes.

[EDIT]

...
Bitcoin Wallet
1. Decentralized private key generation – Multiple Enigma nodes locally create a segment of
the key, whereas the full key is only ever assembled by the user. No trail of evidence is left
anywhere.
2. Decentralized transaction signing – Transactions signed without ever exposing the private
key or leaving a trail.
....

@bytemaster @bytemaster @bytemaster

Using the salaries example... every witness knows their own but collectively they compute the average without revealing their
individual salaries.   This is similar to collectively calculating a signature without any one party knowing the private key. 

The problem is that the parties can still collude to calculate the private key and share it.  Furthermore, they could collude to calculate the signature on an arbitrary transactions.  In effect, it reduces to multisig.

what can prevent collude？

[noisy]

Using the salaries example... every witness knows their own but collectively they compute the average without revealing their
individual salaries.   This is similar to collectively calculating a signature without any one party knowing the private key. 

The problem is that the parties can still collude to calculate the private key and share it.  Furthermore, they could collude to calculate the signature on an arbitrary transactions.  In effect, it reduces to multisig. 

but if I understood correctly we are no longer limited to maximum number of signers - 15, max MSIG allowed by BTC, right?

[bytemaster]

Is that mean, that we could keep private keys in blockchain, like private key to BTC account, which is used to create a bitcoin sidechain? 

Is that mean, that witnesses could also sign a transaction without knowing a key?

Please say yes, please say yes.

[EDIT]

...
Bitcoin Wallet
1. Decentralized private key generation – Multiple Enigma nodes locally create a segment of
the key, whereas the full key is only ever assembled by the user. No trail of evidence is left
anywhere.
2. Decentralized transaction signing – Transactions signed without ever exposing the private
key or leaving a trail.
....

@bytemaster @bytemaster @bytemaster

Using the salaries example... every witness knows their own but collectively they compute the average without revealing their
individual salaries.   This is similar to collectively calculating a signature without any one party knowing the private key. 

The problem is that the parties can still collude to calculate the private key and share it.  Furthermore, they could collude to calculate the signature on an arbitrary transactions.  In effect, it reduces to multisig. 

[noisy]

Is that mean, that we could keep private keys in blockchain, like private key to BTC account, which is used to create a bitcoin sidechain? 

Is that mean, that witnesses could also sign a transaction without knowing a key?

Please say yes, please say yes.

[EDIT]

...
Bitcoin Wallet
1. Decentralized private key generation – Multiple Enigma nodes locally create a segment of
the key, whereas the full key is only ever assembled by the user. No trail of evidence is left
anywhere.
2. Decentralized transaction signing – Transactions signed without ever exposing the private
key or leaving a trail.
....

@bytemaster @bytemaster @bytemaster

[xeroc]

A peer-to-peer network, enabling different parties to jointly store and run compu-
tations on data while keeping the data completely private. Enigma’s computational
model is based on a highly optimized version of secure multi-party computation,
guaranteed by a verifiable secret-sharing scheme. For storage, we use a modi-
fied distributed hashtable for holding secret-shared data. An external blockchain
is utilized as the controller of the network, manages access control, identities and
serves as a tamper-proof log of events. Security deposits and fees incentivize oper-
ation, correctness and fairness of the system. Similar to Bitcoin, Enigma removes
the need for a trusted third party, enabling autonomous control of personal data.
For the first time, users are able to share their data with cryptographic guarantees
regarding their privacy.

This is big .. and not even close to what I mentioned to @bytemaster in a skype session.
Maybe we can elaborate this technology a little.

[betax]

Hi,


This is not a Bitshares but a Graphene question, I am interested to know what are the options using Graphene to store data which cannot be tampered but also private, and only nominated people can view it maintaining an audit of access.

Also what are the options to revoke access to the data and / or change nominated people.

More context something like this:

http://enigma.media.mit.edu/enigma_full.pdf

or this:

http://www.newsbtc.com/2015/07/23/using-blockchain-technology-for-secure-data-encryption/