Author Topic: Is it possible for bitshares to become a sidechain of bitcoin?  (Read 25951 times)

0 Members and 1 Guest are viewing this topic.

Offline tbone

  • Hero Member
  • *****
  • Posts: 632
    • View Profile
  • BitShares: tbone2
By the way, it looks like you modified your post before I got a chance to respond.  But since you were wondering why I wasn't taking your explanation at face value, it's because you're not the expert.  So I continue to address @bytemaster with my questions since he IS the expert.  And I asked for @abit's opinion since he is a developer and, for all we know, he could be the one to code this up ultimately.  Surely you can understand where I'm coming from.

Thanks for trusting me, but sorry, I'm not a bitcoin expert, I don't know how to deal with the bitcoin multi-sig thing at all.

@abit:  This is a Bitshares question, not a bitcoin question.  It's also not a multi-sig question.  Let me ask in a different way.  Could you write code in Bitshares that calls an external API which returns a value that could then be stored securely (i.e. not accessible to any human) on the Bitshares blockchain to be used by the code at a later time?  I would imagine this is possible, but could you confirm?

Offline complexring

  • Full Member
  • ***
  • Posts: 66
    • View Profile
I meant a 2 out of 2 .. where one of the keys is actually not a key but a flag derived from the blockchain. Not sure how that helps

Well, it could work if each time a trade is made of side.btc that the corresponding collateral gets moved to a new multisig address.

Say I deposit 1 btc into a multisig address where the blockchain has one key (as a flag) and I have another key.

In return, I receive 1 side.btc (or appropriate amount after transaction fees).

Now, I put side.btc up for sale on the DEX.  In some way, I would need to pre-approve, i.e. sign, the transaction of moving from the multisig address to a new multisig address, where the buyer of the side.btc will then have the underlying btc collateral moved.

However, we'd have to do this in a two-step process since it is only known a posteriori what would be the new multisig address, that is, the pre-approved signing would have to be to a different address, controlled by the blockchain, which would then have to be immediately moved to the multisig address of the new holder of side.btc.


Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I meant a 2 out of 2 .. where one of the keys is actually not a key but a flag derived from the blockchain. Not sure how that helps

Offline complexring

  • Full Member
  • ***
  • Posts: 66
    • View Profile

I'm trying to get at a way to do this without human involvement, otherwise I think it just won't be trusted.  Plus how would it work, witnesses would have to manually approve each transaction?  I don't see that as a viable solution.  And I think there's a better way.


I agree that not having human involvement would be ideal and cracking the trustless sidechain problem will greatly enhance the BitShares platform.

So far, we have two solutions for the trustless problem that have been posed and a third if we allow for trusted parties:

1) Enigma-like implementation (and / or integration) -- in which we have another thread already
2) Dynamic addresses akin to smart contracts, with the ability to seamlessly to turn on and off 'spendability' of an address, depending on whether or not certain conditions are met.
3) Multisig solution with witnesses

1 and 3 have the same issues of collusion of k parties. 

1) suggests a penalty for such a collusion attack by requiring a deposit to perform the calculations.
3) there is no penalty for witnesses who collude, in so far as I can tell.

We haven't really discussed the possibility of 2.  Can someone explain if this is possible with smart contracts or can we have 'dynamic addresses' like this?  Would that solution essentially be the same as either 1 or 3 ?
For 2. We can probably have an account with a pubkey (or another account) together with the "flag" as another authority in a 2-1 multisig account.
Then you can only spend from that account, it the flag has a certain condition .. not sure about what such a flag would actually do.

Not sure what you mean by 2-1 multisig account.  Do you mean 2 of 3 or a 1 of 2? 

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc

I'm trying to get at a way to do this without human involvement, otherwise I think it just won't be trusted.  Plus how would it work, witnesses would have to manually approve each transaction?  I don't see that as a viable solution.  And I think there's a better way.


I agree that not having human involvement would be ideal and cracking the trustless sidechain problem will greatly enhance the BitShares platform.

So far, we have two solutions for the trustless problem that have been posed and a third if we allow for trusted parties:

1) Enigma-like implementation (and / or integration) -- in which we have another thread already
2) Dynamic addresses akin to smart contracts, with the ability to seamlessly to turn on and off 'spendability' of an address, depending on whether or not certain conditions are met.
3) Multisig solution with witnesses

1 and 3 have the same issues of collusion of k parties. 

1) suggests a penalty for such a collusion attack by requiring a deposit to perform the calculations.
3) there is no penalty for witnesses who collude, in so far as I can tell.

We haven't really discussed the possibility of 2.  Can someone explain if this is possible with smart contracts or can we have 'dynamic addresses' like this?  Would that solution essentially be the same as either 1 or 3 ?
For 2. We can probably have an account with a pubkey (or another account) together with the "flag" as another authority in a 2-1 multisig account.
Then you can only spend from that account, it the flag has a certain condition .. not sure about what such a flag would actually do.

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
By the way, it looks like you modified your post before I got a chance to respond.  But since you were wondering why I wasn't taking your explanation at face value, it's because you're not the expert.  So I continue to address @bytemaster with my questions since he IS the expert.  And I asked for @abit's opinion since he is a developer and, for all we know, he could be the one to code this up ultimately.  Surely you can understand where I'm coming from.

Thanks for trusting me, but sorry, I'm not a bitcoin expert, I don't know how to deal with the bitcoin multi-sig thing at all.
BitShares committee member: abit
BitShares witness: in.abit

Offline complexring

  • Full Member
  • ***
  • Posts: 66
    • View Profile

I'm trying to get at a way to do this without human involvement, otherwise I think it just won't be trusted.  Plus how would it work, witnesses would have to manually approve each transaction?  I don't see that as a viable solution.  And I think there's a better way.


I agree that not having human involvement would be ideal and cracking the trustless sidechain problem will greatly enhance the BitShares platform.

So far, we have two solutions for the trustless problem that have been posed and a third if we allow for trusted parties:

1) Enigma-like implementation (and / or integration) -- in which we have another thread already
2) Dynamic addresses akin to smart contracts, with the ability to seamlessly to turn on and off 'spendability' of an address, depending on whether or not certain conditions are met.
3) Multisig solution with witnesses

1 and 3 have the same issues of collusion of k parties. 

1) suggests a penalty for such a collusion attack by requiring a deposit to perform the calculations.
3) there is no penalty for witnesses who collude, in so far as I can tell.

We haven't really discussed the possibility of 2.  Can someone explain if this is possible with smart contracts or can we have 'dynamic addresses' like this?  Would that solution essentially be the same as either 1 or 3 ?




Offline complexring

  • Full Member
  • ***
  • Posts: 66
    • View Profile
potentially.  it's some pretty awesome math (and computer science) backing it up.  :o
it is essentially based on secret sharing and is well known from "shamir secret sharing" .. cool thing is that you can do calculations either with the full secret .. or with the individual parts of the secret ..

Sure.  From what I can tell, they're actually doing 'homomorphic secret sharing' in the enigma design.  I always liked Yao's solution to the millionaire problem.  He's a nice guy, btw ...

Offline tbone

  • Hero Member
  • *****
  • Posts: 632
    • View Profile
  • BitShares: tbone2
@bytemaster:

Just wanted to resurrect the sidechain thread with an idea/question.  Since there's risk (perhaps intolerable risk) of collusion  associated with witnesses signing off on transfers to a multi-sig BTC wallet, would it be possible for the BTS blockchain to hold the private key for such a BTC wallet and automatically make transfers out of it (and into a user's individual BTC wallet) whenever a user sells their SIDE.BTC on the DEX?

It is possible to do secure multi-party computation among the witnesses.  Doesn't prevent collusion of witnesses though.

https://en.wikipedia.org/wiki/Secure_multi-party_computation

So is it not possible for the Bitshares blockchain to hold the private key for the common wallet and automate the transfers so witnesses don't need to be involved?

You want to do it with witnesses since they are elected by shareholders.

There are ways that collusion could be minimized.

I'm trying to get at a way to do this without human involvement, otherwise I think it just won't be trusted.  Plus how would it work, witnesses would have to manually approve each transaction?  I don't see that as a viable solution.  And I think there's a better way.

@bytemaster:
Couldn't you write some code into graphene that would utilize, for example, the blockchain.info API to create a Bitcoin wallet for the DEX, and store the returned private key on the blockchain?  So first the straightforward part: when someone wants to transfer BTC to the DEX, they send BTC to a designated BTC address and then the blockchain automatically issues them the corresponding amount of SIDE.BTC on the DEX.  Then the trickier part, when they are ready to withdraw, they surrender their SIDE.BTC and the blockchain uses the private key it stored previously in order to send the appropriate sum of BTC to the user's designated external BTC wallet.  Is this not possible?   

@abit, do you have any thoughts about this?

It's trusted just fine with how other networks do this.. only they are using a handful of bitcoin exchanges .. far less secure that what we are proposing: http://www.coindesk.com/blockstream-commercial-sidechain-bitcoin-exchanges/

This is the only practical means to executing... that's what they came up with with $21 million to work with. You think we can do better? :)

What you described is essentially what the witnesses would be done.. but your recommendation introduces more threats.

It would not be manual it would all be automatic and would have witnesses ensuring that the nodes are operating as optimal as possible for Bitshares vs. other networks that wouldn't care, and might not have any redundancy like we would have with the witnesses.

DPOS means trusting humans to maintain and keep things working right. If they don't, they get voted out.

Multi-sig for bitcoin wallets is limited to a maximum of 15 I believe. If we had all witnesses participating but had an algo that changed the multi-sig assignments in some type of interval configuration it would require basically all witnesses to agree to steel all the bitcoin. Note that this would be far more secure than Liquid.. they got $21m for that.. we should at least get that in added valuation for Bitshares if not more. :)  I have said this all before, maybe it was in Telegram.

I'm sorry, but you can't compare this to Liquid.  Liquid is a federated sidechain of centralized services (BitFinex, Kraken, BTCC, Xapo, Unocoin).  To begin with, the users of these services have to trust those companies.  On top of that, the Liquid sidechain depends on the participating companies trusting each other.  So you really can't compare that to what we're trying to accomplish here.

By the way, it looks like you modified your post before I got a chance to respond.  But since you were wondering why I wasn't taking your explanation at face value, it's because you're not the expert.  So I continue to address @bytemaster with my questions since he IS the expert.  And I asked for @abit's opinion since he is a developer and, for all we know, he could be the one to code this up ultimately.  Surely you can understand where I'm coming from.

In any event, I'm really not sure, but something tells me that what I'm proposing is very much doable.  It would be great if @bytemaster would speak to it specifically.  If it can't be done, please explain why.  Thanks!
« Last Edit: February 13, 2016, 04:38:55 pm by tbone »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
potentially.  it's some pretty awesome math (and computer science) backing it up.  :o
it is essentially based on secret sharing and is well known from "shamir secret sharing" .. cool thing is that you can do calculations either with the full secret .. or with the individual parts of the secret ..


Offline BunkerChainLabs-DataSecurityNode

@bytemaster:

Just wanted to resurrect the sidechain thread with an idea/question.  Since there's risk (perhaps intolerable risk) of collusion  associated with witnesses signing off on transfers to a multi-sig BTC wallet, would it be possible for the BTS blockchain to hold the private key for such a BTC wallet and automatically make transfers out of it (and into a user's individual BTC wallet) whenever a user sells their SIDE.BTC on the DEX?

It is possible to do secure multi-party computation among the witnesses.  Doesn't prevent collusion of witnesses though.

https://en.wikipedia.org/wiki/Secure_multi-party_computation

So is it not possible for the Bitshares blockchain to hold the private key for the common wallet and automate the transfers so witnesses don't need to be involved?

You want to do it with witnesses since they are elected by shareholders.

There are ways that collusion could be minimized.

I'm trying to get at a way to do this without human involvement, otherwise I think it just won't be trusted.  Plus how would it work, witnesses would have to manually approve each transaction?  I don't see that as a viable solution.  And I think there's a better way.

@bytemaster:
Couldn't you write some code into graphene that would utilize, for example, the blockchain.info API to create a Bitcoin wallet for the DEX, and store the returned private key on the blockchain?  So first the straightforward part: when someone wants to transfer BTC to the DEX, they send BTC to a designated BTC address and then the blockchain automatically issues them the corresponding amount of SIDE.BTC on the DEX.  Then the trickier part, when they are ready to withdraw, they surrender their SIDE.BTC and the blockchain uses the private key it stored previously in order to send the appropriate sum of BTC to the user's designated external BTC wallet.  Is this not possible?   

@abit, do you have any thoughts about this?

It's trusted just fine with how other networks do this.. only they are using a handful of bitcoin exchanges .. far less secure that what we are proposing: http://www.coindesk.com/blockstream-commercial-sidechain-bitcoin-exchanges/

This is the only practical means to executing... that's what they came up with with $21 million to work with. You think we can do better? :)

What you described is essentially what the witnesses would be done.. but your recommendation introduces more threats.

It would not be manual it would all be automatic and would have witnesses ensuring that the nodes are operating as optimal as possible for Bitshares vs. other networks that wouldn't care, and might not have any redundancy like we would have with the witnesses.

DPOS means trusting humans to maintain and keep things working right. If they don't, they get voted out.

Multi-sig for bitcoin wallets is limited to a maximum of 15 I believe. If we had all witnesses participating but had an algo that changed the multi-sig assignments in some type of interval configuration it would require basically all witnesses to agree to steel all the bitcoin. Note that this would be far more secure than Liquid.. they got $21m for that.. we should at least get that in added valuation for Bitshares if not more. :)  I have said this all before, maybe it was in Telegram.

« Last Edit: February 13, 2016, 12:40:00 am by BunkerChain Labs »
+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | Decentralized Gaming Built with Graphene - Now with BookiePro and Sweeps!
+-+-+-+-+-+-+-+-+-+-+

Offline tbone

  • Hero Member
  • *****
  • Posts: 632
    • View Profile
  • BitShares: tbone2
@bytemaster:

Just wanted to resurrect the sidechain thread with an idea/question.  Since there's risk (perhaps intolerable risk) of collusion  associated with witnesses signing off on transfers to a multi-sig BTC wallet, would it be possible for the BTS blockchain to hold the private key for such a BTC wallet and automatically make transfers out of it (and into a user's individual BTC wallet) whenever a user sells their SIDE.BTC on the DEX?

It is possible to do secure multi-party computation among the witnesses.  Doesn't prevent collusion of witnesses though.

https://en.wikipedia.org/wiki/Secure_multi-party_computation

So is it not possible for the Bitshares blockchain to hold the private key for the common wallet and automate the transfers so witnesses don't need to be involved?

You want to do it with witnesses since they are elected by shareholders.

There are ways that collusion could be minimized.

I'm trying to get at a way to do this without human involvement, otherwise I think it just won't be trusted.  Plus how would it work, witnesses would have to manually approve each transaction?  I don't see that as a viable solution.  And I think there's a better way.

@bytemaster:
Couldn't you write some code into graphene that would utilize, for example, the blockchain.info API to create a Bitcoin wallet for the DEX, and store the returned private key on the blockchain?  So first the straightforward part: when someone wants to transfer BTC to the DEX, they send BTC to a designated BTC address and then the blockchain automatically issues them the corresponding amount of SIDE.BTC on the DEX.  Then the trickier part, when they are ready to withdraw, they surrender their SIDE.BTC and the blockchain uses the private key it stored previously in order to send the appropriate sum of BTC to the user's designated external BTC wallet.  Is this not possible?   

@abit, do you have any thoughts about this?

Offline BunkerChainLabs-DataSecurityNode

@bytemaster:

Just wanted to resurrect the sidechain thread with an idea/question.  Since there's risk (perhaps intolerable risk) of collusion  associated with witnesses signing off on transfers to a multi-sig BTC wallet, would it be possible for the BTS blockchain to hold the private key for such a BTC wallet and automatically make transfers out of it (and into a user's individual BTC wallet) whenever a user sells their SIDE.BTC on the DEX?

It is possible to do secure multi-party computation among the witnesses.  Doesn't prevent collusion of witnesses though.

https://en.wikipedia.org/wiki/Secure_multi-party_computation

So is it not possible for the Bitshares blockchain to hold the private key for the common wallet and automate the transfers so witnesses don't need to be involved?

You want to do it with witnesses since they are elected by shareholders.

There are ways that collusion could be minimized.
+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | Decentralized Gaming Built with Graphene - Now with BookiePro and Sweeps!
+-+-+-+-+-+-+-+-+-+-+