BitShares Forum
Main => General Discussion => Topic started by: betax on February 12, 2016, 06:42:09 pm
-
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/
-
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.
-
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 (https://bitsharestalk.org/index.php/topic,21263.msg278771.html#msg278771)? :D
Is that mean, that witnesses could also sign a transaction without knowing a key? :D
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
-
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 (https://bitsharestalk.org/index.php/topic,21263.msg278771.html#msg278771)? :D
Is that mean, that witnesses could also sign a transaction without knowing a key? :D
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.
-
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?
-
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 (https://bitsharestalk.org/index.php/topic,21263.msg278771.html#msg278771)? :D
Is that mean, that witnesses could also sign a transaction without knowing a key? :D
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？
-
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?
-
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 ....
-
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....
-
@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.
-
@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.
-
@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?
-
@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.
-
@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.
-
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 :)
-
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 +5% +5%
-
@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?
-
@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 @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!
-
@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 @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.
-
@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.
-
@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.
-
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.
-
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.
-
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.
-
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?
-
@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 @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.