The Bitshares blockchain as the first public sidechain for Bitcoin

[Erlich Bachman]

check this out

rootstock is doing this too:

https://medium.com/@CryptoIQ.ca/rootstock-smart-contracts-on-the-bitcoin-blockchain-e52b065421a8#.mkv9x51zt

and this sidechain conversation at bitcointalk:

Next Paradox:

Rootstock comes up with smart contacts using bitcoin: ( I do not see any Casper in yet... and no PoS  :-)   )

https://medium.com/@CryptoIQ.ca/rootstock-smart-contracts-on-the-bitcoin-blockchain-e52b065421a8#.npkfpas4w

Side-chains are insecure. DOA.

To the BTC chain itself? IMO it lowers the complexity,...

The security is reduced to that of the weakest side chain.

So the pegging needs to be transient !

I have no idea what you mean. Chain reorganizations in the weaker chain can cause people to lose their Bitcoins. The chains can get out-of-sync. There is no way for a block chain to securely reference any data point outside of itself. This is fundamentally why Augur and BitUSD can't function without centralization.

Yes - agreed, but I mean rather it has no negative effect to the main chain, if you don't care using the side chain.

I think the insecurity of the side chain can wreck the Bitcoin block chain. If I am mistaken, I request someone to point out why.

Please see pages 8, 9, and 12 of the Blockstream side chains white paper. It says that the coins on the Bitcoin block chain can be unlock by presenting a proof-of-work from the side chain, but that this can be invalidated by a longer proof-of-work. So this means that a lie-in-wait attack on the side chain could allow someone to unlock coins on Bitcoin's block chain, spend them, let others spend them in a fanout of derivative transactions, then reverse the Bitcoin transactions by presenting a longer proof-of-work from the side chain invalidating all those Bitcoin block chain transactions. In short, it seems to me a chain reorganization on the side chain can cause a chain reorganization on the Bitcoin block chain.

I am ready to go to sleep, so I am just skimming quickly with my re-reading of that white paper, so perhaps I missed something?

[TravelsAsia]

From the Mumble, it sounds like the next step is to get BlockTrades.

[abit]

I would suggest something like the top 15 witnesses in something like a 10 of 15 multi sig, and then script it so that the btc account is updated if any 3 of those witnesses are voted out of the top 15.  This would add the requirement for those witnesses to run a btc chain and we could pay the top 15 slots more per block for this.

Good idea. I'm also thinking about this.

[puppies]

Its too bad cryptofresh.com/u/witness-account doesn't have a private key we could use on the btc network.  If we could just use that account it would solve a lot of our problems. 

I would suggest something like the top 15 witnesses in something like a 10 of 15 multi sig, and then script it so that the btc account is updated if any 3 of those witnesses are voted out of the top 15.  This would add the requirement for those witnesses to run a btc chain and we could pay the top 15 slots more per block for this.

[complexring]

Is there a way to use the bitcoin scripting language (see https://en.bitcoin.it/wiki/Script) to have an unknown address for the destination address?

That is, some mechanism where the user who holds the side.btc asset on the bts blockchain also holds a master private key for a transaction (in addition to a M of N signature) and then allow for a dynamic address, i.e. one that is only known a posteriori, say when a trade executes.

I dunno all the details of the script language or what is available or even if this is useful.

[dannotestein]

Private keys for BTC can't be held in the blockchain. They need to be "owned" by someone, hence the need for custodians for these keys.

[abit]

how to control btc address  decentralized？
can Intelligent contract run a robot？
receive  btc ---send sidebtc
receive sidebtc--send real btc
make profit  send to shareholders
no risk

You're right. How?
If such intelligent contract can be done easily, why not make one in Ethereum?

[sudo]

how to control btc address  decentralized？
can Intelligent contract run a robot？
receive  btc ---send sidebtc
receive sidebtc--send real btc
make profit  send to shareholders
no risk

[abit]

I've been thinking some on this subject and had a thought maybe worth discussing?
What if we introduced "forging" on client side wallets that was designed to randomly pass the multi sig keys to users (using user cpu when their wallet is open, in a stealth way) and not witnesses?
So the witnesses run the nods/chain but only active/online user wallets control the keys for the BTC wallet?
Would this be possible?

To implement the so called side-chain feature, we need to make sure: when a user requested a withdrawal of SIDE.BTC (or whatever name), the key holders are online and aware of the request, and sign a transfer transaction in bitcoin network accordingly. How to make sure a random node is always online?

Not sure I understand what you mean by "random node"? BTC random node, Witness or Wallet?

Some have mentioned that person A who deposits the real BTC should hold one of the keys, so if person A ends up selling/transferring their SIDE.BTC to person B or value got trade in the exchange, then  if person B wanted to withdraw real BTC back out of Dex, then obviously person A is not around to sign with their key if they have to be active/online. 
The other issue with witnesses having full control of the keys (though trustworthy) can collude to wreak havoc as other have mentioned earlier.
So my thought process was, what if witnesses just ran/update the BTC node and published transfers with out seeing the actual keys? If this is even possible, don't know?
If that could be done then a typical transfer would go something like this...

- Person A deposits BTC to the Dex BTC deposit address with their user name in memo field...
- Witnesses see that Tx in the linked BTC wallet and credits the username (from the memo field) the corresponding SIDE.BTC,  1:1 after 6 confirmations on the BTC network (btw, I personally like DeX.BTC)....
- Person A can now use the DeX.BTC to trade, transfer or create UIA within the Dex...
- If Person B ends up getting Person A's  DeX.BTC and wants to withdraw back into BTC, then Person B creates a withdraw request
- Witnesses see withdraw request
- Witnesses broadcast to any "open/active" BTS wallets to request mutisig keys
- online Client wallets start to  "forge/mine"  for the BTC mutisig keys
- Winning "forgers" sign off for the BTC Tx (and possibly get paid a "mining" reward) and give Witnesses the thumbs up to transfer
- Witnesses then broadcast Tx from Dex BTC wallet to Person B BTC wallet.

or something to that effect..lol

It's perfect if the private keys of the multi-sig BTC address can only be used to sign special transactions (real withdrawal requests) but cannot be printed out or be compromised to sign other unwanted transactions (attacks). However I suspect it would be technical very hard if not impossible. I don't know. Wish @bytemaster @pc @dannotestein can help. Unless it's possible, any random mining/forging would probably cause compromise/leak of keys then fund losing.

If 10 multisig keys, or more are needed then I'd assume it would be safe to say there will be 10 or more active wallets online when the withdraw Tx was broadcast. Especially if users can earn money by keeping active wallets online and help "forge/mine" the keys... there could easily be 100's or thousands of up and running wallets at any given point in time.
BTS network already runs enough witnesses (if there needs to be more than 10 online at same time) so that shouldn't be an issue either.

To incentive witnesses to run BTC nodes, those that do run them, could get a tx fee of the withdrawals to the BTC network.
I wouldn't advise any fees charged for BTC deposits into the Dex.

Like I said, this may not work... pie in the sky thought/scheme, but maybe will spark some other creative ideas to make BTC deposits possible.

[giant middle finger]

I agree.

Like BM said:

We need to showcase what makes us "unique"

in this case, Sidechaining is not being successfully done by anyone yet. Showcasing our DPOS consensus successful history is also unique to us.

On the other hand, bond markets have been established for centuries.  They are not unique or progressively exciting at all.

[donkeypong]

The technical details are beyond my level of understanding, but in terms of the concept, I'm interested. If being a sidechain improves our liquidity and market cap with few negative consequences, then I say 'go for it.' At this point, we should be bold.

[BunkerChainLabs-DataSecurityNode]

The original suggestion of using 15 witnesses to be holders of the private key of a multisig address seems simplest and best. 

Although, I am still unconvinced that bytemaster's suggestion of the top 15 is the best option.  bytemaster seems to think that it's not an issue, due to historical data, that a voting-out event could occur.  That's fine; however, we should always recall that past results are not indicative of future results.

The better solution (and I refuse to call any possible solution the best) is to randomly select 15 of the witnesses to be private key holders, with possibly a slightly weighted distribution towards the top ones.  This way, even if there is a switch between the 15th and 16th witness, we wouldn't have to constantly move to a new multi-sig address for the collateral. 

Best block producers of BitShares are probably not the best signers of BTC address. Imo we need another voting algorithm for the BTC multi-signers, for better security, for example one stake can only vote for one signer, so BTC38 can't control all signers. We can probably ask the signers to put some collateral in BitShares, for example to an account under the control of the committee (the voting algorithm of committee should also be revised), to make sure they won't steal customers' funds.

Randomness is evil. Stake talks.

This extra transaction seems cumbersome and also is more costly, in terms of transaction fees on the bitcoin network.  If you foresee this sidechain business as something that could happen with any altcoin (which I do), then mitigating additional and unnecessary transactions by properly creating a sidechain protocol for any alt on bitshares is the proper way forward.

This is good will. But I don't think BitShares is powerful enough to let other chains adapt BitShares's protocol.

tl;dr -- side.btc seems superfluous and has potential issues.  Simpler solution is the original one offered, i.e. 15 of the witnesses hold the private keys to a multisignature address that contains the collateral of the bitcoin.

I understand the security concern regarding the witnesses. However I think if we sidestep them as our infrastructure of trust, we are losing the opportunity for them to grow.

At present the level of trust given to them is relative to the stakeholders regard for BTS block witnessing.

It's interesting that now that we would add BTC to the witnesses suddenly there is all this security concern... the same concerns that exist 'now'.

I think going through this process will cause the voting stake holders to become more active if not take the process of voting more seriously.

It will also force witnesses to step up their game or be voted out... I know we have similar witnesses to what we had as delegates in the past largely due to associations with known large stake holders, but with something like this that brings in whole new holders that are going to look at every witness with a far more objective eye and judge them on their presentation, credentials, and their infrastructure.. we are going to see that whole arm of our TBD (three branches of delegation) mature.

If we side step them with something like this though... they stay the same and don't improve.

There is the other issue of expense you mentioned though.

We can have a greater degree of security, however multisig transactions in the bitcoin network are more expensive.. and that will get passed on to the end users... I suppose that is not a bad thing.. it might actually encourage some to get people signing up to bitshares to get their BTC sent to them... in record time at that!

Great discussions over all from everyone.

[emailtooaj]

I've been thinking some on this subject and had a thought maybe worth discussing?
What if we introduced "forging" on client side wallets that was designed to randomly pass the multi sig keys to users (using user cpu when their wallet is open, in a stealth way) and not witnesses?
So the witnesses run the nods/chain but only active/online user wallets control the keys for the BTC wallet?
Would this be possible?

To implement the so called side-chain feature, we need to make sure: when a user requested a withdrawal of SIDE.BTC (or whatever name), the key holders are online and aware of the request, and sign a transfer transaction in bitcoin network accordingly. How to make sure a random node is always online?

Not sure I understand what you mean by "random node"? BTC random node, Witness or Wallet?

Some have mentioned that person A who deposits the real BTC should hold one of the keys, so if person A ends up selling/transferring their SIDE.BTC to person B or value got trade in the exchange, then  if person B wanted to withdraw real BTC back out of Dex, then obviously person A is not around to sign with their key if they have to be active/online. 
The other issue with witnesses having full control of the keys (though trustworthy) can collude to wreak havoc as other have mentioned earlier.
So my thought process was, what if witnesses just ran/update the BTC node and published transfers with out seeing the actual keys? If this is even possible, don't know?
If that could be done then a typical transfer would go something like this...

- Person A deposits BTC to the Dex BTC deposit address with their user name in memo field...
- Witnesses see that Tx in the linked BTC wallet and credits the username (from the memo field) the corresponding SIDE.BTC,  1:1 after 6 confirmations on the BTC network (btw, I personally like DeX.BTC)....
- Person A can now use the DeX.BTC to trade, transfer or create UIA within the Dex...
- If Person B ends up getting Person A's  DeX.BTC and wants to withdraw back into BTC, then Person B creates a withdraw request
- Witnesses see withdraw request
- Witnesses broadcast to any "open/active" BTS wallets to request mutisig keys
- online Client wallets start to  "forge/mine"  for the BTC mutisig keys
- Winning "forgers" sign off for the BTC Tx (and possibly get paid a "mining" reward) and give Witnesses the thumbs up to transfer
- Witnesses then broadcast Tx from Dex BTC wallet to Person B BTC wallet.

or something to that effect..lol

If 10 multisig keys, or more are needed then I'd assume it would be safe to say there will be 10 or more active wallets online when the withdraw Tx was broadcast. Especially if users can earn money by keeping active wallets online and help "forge/mine" the keys... there could easily be 100's or thousands of up and running wallets at any given point in time.
BTS network already runs enough witnesses (if there needs to be more than 10 online at same time) so that shouldn't be an issue either.

To incentive witnesses to run BTC nodes, those that do run them, could get a tx fee of the withdrawals to the BTC network.
I wouldn't advise any fees charged for BTC deposits into the Dex.

Like I said, this may not work... pie in the sky thought/scheme, but maybe will spark some other creative ideas to make BTC deposits possible.








 

[abit]

I've been thinking some on this subject and had a thought maybe worth discussing?
What if we introduced "forging" on client side wallets that was designed to randomly pass the multi sig keys to users (using user cpu when their wallet is open, in a stealth way) and not witnesses?
So the witnesses run the nods/chain but only active/online user wallets control the keys for the BTC wallet?
Would this be possible?

To implement the so called side-chain feature, we need to make sure: when a user requested a withdrawal of SIDE.BTC (or whatever name), the key holders are online and aware of the request, and sign a transfer transaction in bitcoin network accordingly. How to make sure a random node is always online?

[emailtooaj]

I've been thinking some on this subject and had a thought maybe worth discussing?
What if we introduced "forging" on client side wallets that was designed to randomly pass the multi sig keys to users (using user cpu when their wallet is open, in a stealth way) and not witnesses?
So the witnesses run the nods/chain but only active/online user wallets control the keys for the BTC wallet?
Would this be possible?