Graphene: Data security and verification on the chain

[complexring]

@complexring  @BunkerChain Labs
Your question is: when SIDEBTC is transferred the previous owner will still have the public key so its not secure.

This is how it works, there a 3 types of BTC
1. real BTC
2. SIDEBTC
3. BITBTC (like current bitbtc but collatralised 1:1 with side btc)

So SIDEBTC cannot be transfered ever. The owner of it uses it as collateral to create BITBTC which can be transfered.

So SIDE.BTC (or SIDEBTC, or whatever) will be non-transferrable and will be the underlying collateral for BITBTC.  But then, there could be instances of the original depositor not logging in and not being able to approve a transaction, or just choosing not to do that (for whatever nefarious reason).  Sure, this attack causes them to lose out on the btc that was originally deposited, but they sold for some other asset, say maybe bitEURO, bitCNY, or bitUSD, and are able to withdraw out of the DEX in this manner.  The person who now owns BITBTC will be out if that user ever wants to withdraw bitcoin and hold in their own long-term wallet.

`Transferring` of the private keys must be done in some manner.  Either by moving the bitcoin to a new multisig address each time for each new holder of the underlying asset (inefficient) or, better yet, a(n improved notion of a) smart contract, that is like a dynamic multisig and can be turned on or off when certain conditions are met, i.e. think of it as approving or revoking the signing of a transaction in a regular multisig transaction, but that is done in a trustless manner via the code.  Essentially, program in 'dynamic' addresses where they are spendable if a certain condition is met even if you have the 1 private key that can be used to unlock it, you can't transfer out since you haven't met the appropriate conditions.

This latter solution, if possible, would be great!  I'm not entirely sure how the implementation of smart contracts or the design of them is actually done.  But if this type of dynamic solution isn't already considered, this is a huge improvement!

The bitbtc can move freely and doesn't need the original depositors signature. just like bitbtc currently works.
The new holder of bitbtc will not be able to force settle the bitbtc for real btc but they will be able to sell to someone else 1:1
i see what you mean though. You could discourage this by demanding collateral of 105% instead of 100%

Sure.  I understand bitbtc can be freely moveable and sidebtc is not.  However, the issue still remains if a user who owns bitbtc (or bit(altnamehere)) wants to move out of the system and have the actual cryptotoken in their possession.  We can't rely on the original depositor to always be online to approve a transaction and or to always be honest.

Even if they have an extra 5% collateral that would be needed, I still don't think that this solves the problem.

I concede that the scenario of a dishonest depositor seems unlikely due to the additional 5% penalty and I wouldn't expect a 'rational agent' to behave in that manner.  People are rarely rational, unfortunately, and (most) game theory assumes agents will act in a manner that promotes their own self-interest. 

Even in the case of an honest depositor, what happens when the original depositor is dead and / or loses their private key ? That collateral is locked up forever and there is no way of removing it from the system.  In addition, since the collateral can't actually move, can it really be seen as collateral anymore? I would think not.

Your question asks will the collateral be worthless due to the original depositor losing or purposefully discarding the keys to their account.

Yes this could be an issue. How about you add a condition that all SIDEBTC will expire and be sent back to a BTC address automatically after 5 years of creation date. Same as now how all order cancel after 5 years.

But then what happens with the bitbtc that has the sidebtc as collateral?  The problem still exists that the collateral is really not that if there is a dishonest depositor and / or someone who doesn't log in to sign a transaction.

[JonnyB]

@complexring  @BunkerChain Labs
Your question is: when SIDEBTC is transferred the previous owner will still have the public key so its not secure.

This is how it works, there a 3 types of BTC
1. real BTC
2. SIDEBTC
3. BITBTC (like current bitbtc but collatralised 1:1 with side btc)

So SIDEBTC cannot be transfered ever. The owner of it uses it as collateral to create BITBTC which can be transfered.

So SIDE.BTC (or SIDEBTC, or whatever) will be non-transferrable and will be the underlying collateral for BITBTC.  But then, there could be instances of the original depositor not logging in and not being able to approve a transaction, or just choosing not to do that (for whatever nefarious reason).  Sure, this attack causes them to lose out on the btc that was originally deposited, but they sold for some other asset, say maybe bitEURO, bitCNY, or bitUSD, and are able to withdraw out of the DEX in this manner.  The person who now owns BITBTC will be out if that user ever wants to withdraw bitcoin and hold in their own long-term wallet.

`Transferring` of the private keys must be done in some manner.  Either by moving the bitcoin to a new multisig address each time for each new holder of the underlying asset (inefficient) or, better yet, a(n improved notion of a) smart contract, that is like a dynamic multisig and can be turned on or off when certain conditions are met, i.e. think of it as approving or revoking the signing of a transaction in a regular multisig transaction, but that is done in a trustless manner via the code.  Essentially, program in 'dynamic' addresses where they are spendable if a certain condition is met even if you have the 1 private key that can be used to unlock it, you can't transfer out since you haven't met the appropriate conditions.

This latter solution, if possible, would be great!  I'm not entirely sure how the implementation of smart contracts or the design of them is actually done.  But if this type of dynamic solution isn't already considered, this is a huge improvement!

The bitbtc can move freely and doesn't need the original depositors signature. just like bitbtc currently works.
The new holder of bitbtc will not be able to force settle the bitbtc for real btc but they will be able to sell to someone else 1:1
i see what you mean though. You could discourage this by demanding collateral of 105% instead of 100%

Sure.  I understand bitbtc can be freely moveable and sidebtc is not.  However, the issue still remains if a user who owns bitbtc (or bit(altnamehere)) wants to move out of the system and have the actual cryptotoken in their possession.  We can't rely on the original depositor to always be online to approve a transaction and or to always be honest.

Even if they have an extra 5% collateral that would be needed, I still don't think that this solves the problem.

I concede that the scenario of a dishonest depositor seems unlikely due to the additional 5% penalty and I wouldn't expect a 'rational agent' to behave in that manner.  People are rarely rational, unfortunately, and (most) game theory assumes agents will act in a manner that promotes their own self-interest. 

Even in the case of an honest depositor, what happens when the original depositor is dead and / or loses their private key ? That collateral is locked up forever and there is no way of removing it from the system.  In addition, since the collateral can't actually move, can it really be seen as collateral anymore? I would think not.

Your question asks will the collateral be worthless due to the original depositor losing or purposefully discarding the keys to their account.

Yes this could be an issue. How about you add a condition that all SIDEBTC will expire and be sent back to a BTC address automatically after 5 years of creation date. Same as now how all order cancel after 5 years.

[complexring]

A new thread should be made for the sidechain stuff I guess.

I know people trust a single entity (exchanges) to hold their bitcoins, but what if the witnesses get to manage huge volumes, like in the millions? Would witnesses accept doing this job? What if this was done, instead of witnesses, with many exchanges? Would that be riskier? What about other coins, imagine in the future we have 10 coins, each one with big volumes, can witnesses even handle that? Should we have a new account type for that? That's why I asked if exchanges should do that since they're more into that stuff, but I think it's more risky if you can't vote them out of their position. Maybe we could have an account type "Exchange" that could be voted in/out like witnesses and the top ones could be responsible for this process?

Imagine, for the sake of BitShares a large Bitcoin holder decides to do this with many Bitcoins, would there be a way for him to get dividends out of this? As an incentive to lock up Bitcoins? Like getting a percentage of the fees of those new SideChain Backed Bitcoins or whatever they are called? Not saying this is necessary because if this would work out, assuming it's a 1:1 ratio it should be enough by itself but it's always better if we can provide more incentives for other people to park their Bitcoins here and increase liquidity even more. Assume that new account type "exchange" is created, they could be the ones getting these dividends to get paid for their job instead of diluting?

I like this idea, the 1:1 ration sounds awesome and I expect it would increase the amount of assets we have.

The only thing I don't like is having dozens of different asset types. Too confusing. We have UIAs, MPAs now these SBAs (sidechain backed assets)... I'd say stick with either MPAs or SBAs, not both, it's always good to have a choice and versatility but I believe in this case it will only confuse people more. Unless services built on top of BitShares would make their users see only their SBAs for example to avoid all of this complexity.

There is already a sidechain thread.  The OP alluded to the enigma platform as a potential solution.

Let's try to discuss the  merits of that design.

First off:

Can we implement this?  Pseudo-code algorithms have all been given in the paper -- although I don't see if it has been formally peer-reviewed.  At least, google scholar searches in the standard academic journals doesn't seem to show anything.

I would expect this to be accepted fairly soon, circa 6-8 months.  Assuming they already submitted to a journal when they first put the paper on the ArXiV, that'd be about right for mathematics and computer science papers.  The process normally takes anywhere from 8 months to 18 months, which includes the peer review process.

Anyway, the question even beyond this is, do we want to implement this or integrate with their system?

I am all for leveraging existing code, however, I also think independent implementations of algorithms is necessary, too.

Maybe we integrate first, in order to have a solution, and then independently code this ourselves?

[Akado]

A new thread should be made for the sidechain stuff I guess.

I know people trust a single entity (exchanges) to hold their bitcoins, but what if the witnesses get to manage huge volumes, like in the millions? Would witnesses accept doing this job? What if this was done, instead of witnesses, with many exchanges? Would that be riskier? What about other coins, imagine in the future we have 10 coins, each one with big volumes, can witnesses even handle that? Should we have a new account type for that? That's why I asked if exchanges should do that since they're more into that stuff, but I think it's more risky if you can't vote them out of their position. Maybe we could have an account type "Exchange" that could be voted in/out like witnesses and the top ones could be responsible for this process?

Imagine, for the sake of BitShares a large Bitcoin holder decides to do this with many Bitcoins, would there be a way for him to get dividends out of this? As an incentive to lock up Bitcoins? Like getting a percentage of the fees of those new SideChain Backed Bitcoins or whatever they are called? Not saying this is necessary because if this would work out, assuming it's a 1:1 ratio it should be enough by itself but it's always better if we can provide more incentives for other people to park their Bitcoins here and increase liquidity even more. Assume that new account type "exchange" is created, they could be the ones getting these dividends to get paid for their job instead of diluting?

I like this idea, the 1:1 ration sounds awesome and I expect it would increase the amount of assets we have.

The only thing I don't like is having dozens of different asset types. Too confusing. We have UIAs, MPAs now these SBAs (sidechain backed assets)... I'd say stick with either MPAs or SBAs, not both, it's always good to have a choice and versatility but I believe in this case it will only confuse people more. Unless services built on top of BitShares would make their users see only their SBAs for example to avoid all of this complexity.

[betax]

Fox you are right,  but lets not kill the BTC / Witness discussion, but also continue with the idea of storing data in Graphene.

@bytemaster I am also interested on how can we utilise Graphene as the core of other business domains, and as way of storing structured and tamperproof private data. At the moment all data is public, regardless of the type of chain public / private. Enabling this we can introduce enable domains like Insurance, Police records, Health, Voting, etc, which they have a need to private (only certain people can access it), tamperproof, but also moving forward as blockchain based oracles for smart contracts in public chains.

[Fox]

The OP invites discussion of storing private data within a blockchain, permissions to view this data and modifying those rights thereafter.  The OP is directed at the core technology Graphene and references the Enigma project as a possible model.  This thread has, understandably, morphed to discuss applicable applications within the BitShares blockchain. 

May I ask for some technical guidance from @arhag @bytemaster and others with knowledge to discuss the applicability of the Enigma concepts to Graphene?

Specifically, I'm interested to learn more about the key generation process by a witness set (and secondarily, the long term retention thereof).  In the interest of fail fast, please ignor for the moment the fact that the witness set within Graphene is dymaic, both in composition and quantity over time, rather focus on the (shared?) key generation protocol Graphene may ustilize. 

[complexring]

@complexring  @BunkerChain Labs
Your question is: when SIDEBTC is transferred the previous owner will still have the public key so its not secure.

This is how it works, there a 3 types of BTC
1. real BTC
2. SIDEBTC
3. BITBTC (like current bitbtc but collatralised 1:1 with side btc)

So SIDEBTC cannot be transfered ever. The owner of it uses it as collateral to create BITBTC which can be transfered.

The user doesn't need a private key.. thats where everyone seems stuck.

Just for a simple example it can be done where there is a BTC address for Bitshares with a required memo of your username in Bitshares.

Once the deposit is confirmed by the witnesses and secured among them with multi-sig then the user account is credited SIDEBTC SBA identical to what was deposited. At that point it is just like any other asset on the system but of course with the 100% collateral backing of the BTC that is now locked in the Bitshares network.

If someone wants to transfer their BTC OUT of Bitshares, well there are a few existing bridges already available, but if we want to, we can simply allow any holder of the SBA to be able to send it from our ledger which will then send a transfer cmd to the witnesses to then send X amount of the bitcoin to the address specified and once confirmed burn the SIDEBTC SBA.

That's about all these is too it.

Sure.  I am not stuck on the concept of a pseudo-sidechain with the witnesses having the necessary private keys to unlock a multisig address.  I think that this is a fairly decent solution if we want to go that route.

The original post was linking to the Enigma article about using a decentralized homomorphic encryption scheme and it was suggested in this article that it would be possible to store a private key on the blockchain (in some manner).  This would move us from having centralized trusted parties, i.e. the witnesses, to a true trustless sidechain possibility.

The other option, which goes along nicely with @bytemaster's blog on why he likes Ethereum, is to have a smart contract in such a way that allows for a 'dynamic' address, as mused in a previous post.

[complexring]

@complexring  @BunkerChain Labs
Your question is: when SIDEBTC is transferred the previous owner will still have the public key so its not secure.

This is how it works, there a 3 types of BTC
1. real BTC
2. SIDEBTC
3. BITBTC (like current bitbtc but collatralised 1:1 with side btc)

So SIDEBTC cannot be transfered ever. The owner of it uses it as collateral to create BITBTC which can be transfered.

So SIDE.BTC (or SIDEBTC, or whatever) will be non-transferrable and will be the underlying collateral for BITBTC.  But then, there could be instances of the original depositor not logging in and not being able to approve a transaction, or just choosing not to do that (for whatever nefarious reason).  Sure, this attack causes them to lose out on the btc that was originally deposited, but they sold for some other asset, say maybe bitEURO, bitCNY, or bitUSD, and are able to withdraw out of the DEX in this manner.  The person who now owns BITBTC will be out if that user ever wants to withdraw bitcoin and hold in their own long-term wallet.

`Transferring` of the private keys must be done in some manner.  Either by moving the bitcoin to a new multisig address each time for each new holder of the underlying asset (inefficient) or, better yet, a(n improved notion of a) smart contract, that is like a dynamic multisig and can be turned on or off when certain conditions are met, i.e. think of it as approving or revoking the signing of a transaction in a regular multisig transaction, but that is done in a trustless manner via the code.  Essentially, program in 'dynamic' addresses where they are spendable if a certain condition is met even if you have the 1 private key that can be used to unlock it, you can't transfer out since you haven't met the appropriate conditions.

This latter solution, if possible, would be great!  I'm not entirely sure how the implementation of smart contracts or the design of them is actually done.  But if this type of dynamic solution isn't already considered, this is a huge improvement!

The bitbtc can move freely and doesn't need the original depositors signature. just like bitbtc currently works.
The new holder of bitbtc will not be able to force settle the bitbtc for real btc but they will be able to sell to someone else 1:1
i see what you mean though. You could discourage this by demanding collateral of 105% instead of 100%

Sure.  I understand bitbtc can be freely moveable and sidebtc is not.  However, the issue still remains if a user who owns bitbtc (or bit(altnamehere)) wants to move out of the system and have the actual cryptotoken in their possession.  We can't rely on the original depositor to always be online to approve a transaction and or to always be honest.

Even if they have an extra 5% collateral that would be needed, I still don't think that this solves the problem.

I concede that the scenario of a dishonest depositor seems unlikely due to the additional 5% penalty and I wouldn't expect a 'rational agent' to behave in that manner.  People are rarely rational, unfortunately, and (most) game theory assumes agents will act in a manner that promotes their own self-interest. 

Even in the case of an honest depositor, what happens when the original depositor is dead and / or loses their private key ? That collateral is locked up forever and there is no way of removing it from the system.  In addition, since the collateral can't actually move, can it really be seen as collateral anymore? I would think not.

[BunkerChainLabs-DataSecurityNode]

@complexring  @BunkerChain Labs
Your question is: when SIDEBTC is transferred the previous owner will still have the public key so its not secure.

This is how it works, there a 3 types of BTC
1. real BTC
2. SIDEBTC
3. BITBTC (like current bitbtc but collatralised 1:1 with side btc)

So SIDEBTC cannot be transfered ever. The owner of it uses it as collateral to create BITBTC which can be transfered.

The user doesn't need a private key.. thats where everyone seems stuck.

Just for a simple example it can be done where there is a BTC address for Bitshares with a required memo of your username in Bitshares.

Once the deposit is confirmed by the witnesses and secured among them with multi-sig then the user account is credited SIDEBTC SBA identical to what was deposited. At that point it is just like any other asset on the system but of course with the 100% collateral backing of the BTC that is now locked in the Bitshares network.

If someone wants to transfer their BTC OUT of Bitshares, well there are a few existing bridges already available, but if we want to, we can simply allow any holder of the SBA to be able to send it from our ledger which will then send a transfer cmd to the witnesses to then send X amount of the bitcoin to the address specified and once confirmed burn the SIDEBTC SBA.

That's about all these is too it.

[JonnyB]

@complexring  @BunkerChain Labs
Your question is: when SIDEBTC is transferred the previous owner will still have the public key so its not secure.

This is how it works, there a 3 types of BTC
1. real BTC
2. SIDEBTC
3. BITBTC (like current bitbtc but collatralised 1:1 with side btc)

So SIDEBTC cannot be transfered ever. The owner of it uses it as collateral to create BITBTC which can be transfered.

So SIDE.BTC (or SIDEBTC, or whatever) will be non-transferrable and will be the underlying collateral for BITBTC.  But then, there could be instances of the original depositor not logging in and not being able to approve a transaction, or just choosing not to do that (for whatever nefarious reason).  Sure, this attack causes them to lose out on the btc that was originally deposited, but they sold for some other asset, say maybe bitEURO, bitCNY, or bitUSD, and are able to withdraw out of the DEX in this manner.  The person who now owns BITBTC will be out if that user ever wants to withdraw bitcoin and hold in their own long-term wallet.

`Transferring` of the private keys must be done in some manner.  Either by moving the bitcoin to a new multisig address each time for each new holder of the underlying asset (inefficient) or, better yet, a(n improved notion of a) smart contract, that is like a dynamic multisig and can be turned on or off when certain conditions are met, i.e. think of it as approving or revoking the signing of a transaction in a regular multisig transaction, but that is done in a trustless manner via the code.  Essentially, program in 'dynamic' addresses where they are spendable if a certain condition is met even if you have the 1 private key that can be used to unlock it, you can't transfer out since you haven't met the appropriate conditions.

This latter solution, if possible, would be great!  I'm not entirely sure how the implementation of smart contracts or the design of them is actually done.  But if this type of dynamic solution isn't already considered, this is a huge improvement!

The bitbtc can move freely and doesn't need the original depositors signature. just like bitbtc currently works.
The new holder of bitbtc will not be able to force settle the bitbtc for real btc but they will be able to sell to someone else 1:1
i see what you mean though. You could discourage this by demanding collateral of 105% instead of 100%

[complexring]

@complexring  @BunkerChain Labs
Your question is: when SIDEBTC is transferred the previous owner will still have the public key so its not secure.

This is how it works, there a 3 types of BTC
1. real BTC
2. SIDEBTC
3. BITBTC (like current bitbtc but collatralised 1:1 with side btc)

So SIDEBTC cannot be transfered ever. The owner of it uses it as collateral to create BITBTC which can be transfered.

So SIDE.BTC (or SIDEBTC, or whatever) will be non-transferrable and will be the underlying collateral for BITBTC.  But then, there could be instances of the original depositor not logging in and not being able to approve a transaction, or just choosing not to do that (for whatever nefarious reason).  Sure, this attack causes them to lose out on the btc that was originally deposited, but they sold for some other asset, say maybe bitEURO, bitCNY, or bitUSD, and are able to withdraw out of the DEX in this manner.  The person who now owns BITBTC will be out if that user ever wants to withdraw bitcoin and hold in their own long-term wallet.

`Transferring` of the private keys must be done in some manner.  Either by moving the bitcoin to a new multisig address each time for each new holder of the underlying asset (inefficient) or, better yet, a(n improved notion of a) smart contract, that is like a dynamic multisig and can be turned on or off when certain conditions are met, i.e. think of it as approving or revoking the signing of a transaction in a regular multisig transaction, but that is done in a trustless manner via the code.  Essentially, program in 'dynamic' addresses where they are spendable if a certain condition is met even if you have the 1 private key that can be used to unlock it, you can't transfer out since you haven't met the appropriate conditions.

This latter solution, if possible, would be great!  I'm not entirely sure how the implementation of smart contracts or the design of them is actually done.  But if this type of dynamic solution isn't already considered, this is a huge improvement!

[JonnyB]

@complexring  @BunkerChain Labs
Your question is: when SIDEBTC is transferred the previous owner will still have the public key so its not secure.

This is how it works, there a 3 types of BTC
1. real BTC
2. SIDEBTC
3. BITBTC (like current bitbtc but collatralised 1:1 with side btc)

So SIDEBTC cannot be transfered ever. The owner of it uses it as collateral to create BITBTC which can be transfered.

[complexring]

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

OK.  So here we have a 2 of 2 multisig address.  Witnesses collectively control 1 of the 2 keys and the original depositor controls the other.

Where is this other private key held?  Locally on the other users HD space or do we suggest using an implemented form of Enigma's design for decentralized operations on encrypted data?

What happens when the user sells his BITBTC asset?  The user still has access to the private key, which is fine, since it should be noted by the network that he no longer has that asset anymore and the witnesses won't grant him withdrawal access if he attempts to do so using the command line operations.

But, we still have an issue if the original depositor is one of the witnesses (as was noted earlier in the thread).  I suppose that this could be noted in the code if a depositor is a witness, they don't get that 2nd key access.  However, this doesn't prevent a witness from creating a different account and performing this type of attack.

In addition, when the original depositor sells his token, the user in some way needs to pass the private key to the next holder of that asset.  How is this done ? 

Maybe there's a way to do this in a 'smart contract' manner.  The smart contract could be executed when the underlying asset is sent to a particular address.  In the memo could be the address where the underlying collateral should be sent.  Then, the smart contract is executed when this happens and releases the funds to the right address.

Can this be done in a way that is still trustless? 

[mike623317]

I do think we could become a preferred goto not just for BTC trade but for storage.

Yeah... people like to keep their bitcoins on the exchange... and with DEX this will be secure... finally

Now that sounds like a profitable niche we've carved out for ourselves   

[noisy]

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

I understand, but I am not sure, whether bitcoin supports "k+1/n of m multisig", where transaction can be made when some of n agree (at least one), and all of k (where k can be 1, a user).

I do think we could become a preferred goto not just for BTC trade but for storage.

Yeah... people like to keep their bitcoins on the exchange... and with DEX this will be secure... finally