The Two Way Peg Problem: how do we construct a protocol so that a participant can convert some amount of bitcoin to a side coin *and back* at a fixed rate? It is assumed no new coins are issued on the side chain. If you can solve this problem without unreasonable sacrifices, scaling is as good as solved, because you could create as many side chains as transaction volume necessitate. I started thinking about this problem long ago, but recently this very long article helped me to organize some of my thoughts: http://www.truthcoin.info/blog/drivechain/ . I appreciate the way this long article begins, articulating the problem and its many complications.
The critical difficulty is how to safely 'withdraw' funds back to the main chain after they have been passed around the side chain. The drivechain proposal is essentially to trust miners not to collude to steal the funds mid-withdrawal, which they could very easily do. In other words, we all completely trust SPV validation.This solution, I think, flies a little too close to the sun; requiring this much trust in miners would, for me, break bitcoin.
However I think this discussion leads us to the Real Solution.
Let's think about what we know: The Drivechain folks tell us we can have a peg if we just trust miners. But this isn't the only way. Take a look, if you haven't already, at NXT/Supernet. Based on what I've heard in interviews (I haven't tried it myself), they have a different 2 way peg, in which withdrawals back to the main chain are protected by a federated network of trusted servers. O ho! So now we must trust federated servers. I feel like I keep being asked to trust someone in this supposedly trustless system. No sale! But I can't be too hard on them. At least they're trying.
But later it occurred to me, that there's a workable example of something that's not federated, but that resembles a federation enough to make collective decisions. You might even say it's already proven somewhat successful. I'm referring to the super node/master node concept, generically, collateralized nodes. The super nodes decide things in similar way to members of a federation, but membership is fluid. Anyone with enough collateral will be accepted into the federation as a matter of protocol. I'm more comfortable with this model; it makes the system open. Anyone materially invested in the chain can run a node and get a vote. Does the system have vulnerabilities? Maybe, but having participated in working examples (Dash, Vcash) myself gives me confidence that such a system be stable and robust against potential attack vectors. Bitcoin itself had to stand the test of time before people became confident that it was safe.
The next question: could collateralized super nodes on a side chain function to approve those critical Withdrawal Transactions? I think they could, and in a straightforward manner, too. Main chain coins could be held in safekeeping collectively in a multisig address, just as they are in the federated approach. (m of n) keys would be required to move coins out of that address. Each super node holds a key. As super nodes go offline and come online, the remaining nodes sign transactions to move all funds into new (m1 of n1) addresses. It is not necessary to submit these to the blockchain immediately, as long as any single super node remains that has the potential to submit, the funds cannot be lost. It should be more than sufficient to submit the latest one every 10 minutes or once per Bitcoin block. The ratio of m to n should be as high as necessary to prevent a single actor or coalition from controlling m supernodes, but be low enough to be reasonably certain that (n-m) / n of the nodes will not go offline simultaneously. We can look at empirical data from Dash to debate and determine an ideal ratio.
Thoughts?
The critical difficulty is how to safely 'withdraw' funds back to the main chain after they have been passed around the side chain. The drivechain proposal is essentially to trust miners not to collude to steal the funds mid-withdrawal, which they could very easily do. In other words, we all completely trust SPV validation.This solution, I think, flies a little too close to the sun; requiring this much trust in miners would, for me, break bitcoin.
However I think this discussion leads us to the Real Solution.
Let's think about what we know: The Drivechain folks tell us we can have a peg if we just trust miners. But this isn't the only way. Take a look, if you haven't already, at NXT/Supernet. Based on what I've heard in interviews (I haven't tried it myself), they have a different 2 way peg, in which withdrawals back to the main chain are protected by a federated network of trusted servers. O ho! So now we must trust federated servers. I feel like I keep being asked to trust someone in this supposedly trustless system. No sale! But I can't be too hard on them. At least they're trying.
But later it occurred to me, that there's a workable example of something that's not federated, but that resembles a federation enough to make collective decisions. You might even say it's already proven somewhat successful. I'm referring to the super node/master node concept, generically, collateralized nodes. The super nodes decide things in similar way to members of a federation, but membership is fluid. Anyone with enough collateral will be accepted into the federation as a matter of protocol. I'm more comfortable with this model; it makes the system open. Anyone materially invested in the chain can run a node and get a vote. Does the system have vulnerabilities? Maybe, but having participated in working examples (Dash, Vcash) myself gives me confidence that such a system be stable and robust against potential attack vectors. Bitcoin itself had to stand the test of time before people became confident that it was safe.
The next question: could collateralized super nodes on a side chain function to approve those critical Withdrawal Transactions? I think they could, and in a straightforward manner, too. Main chain coins could be held in safekeeping collectively in a multisig address, just as they are in the federated approach. (m of n) keys would be required to move coins out of that address. Each super node holds a key. As super nodes go offline and come online, the remaining nodes sign transactions to move all funds into new (m1 of n1) addresses. It is not necessary to submit these to the blockchain immediately, as long as any single super node remains that has the potential to submit, the funds cannot be lost. It should be more than sufficient to submit the latest one every 10 minutes or once per Bitcoin block. The ratio of m to n should be as high as necessary to prevent a single actor or coalition from controlling m supernodes, but be low enough to be reasonably certain that (n-m) / n of the nodes will not go offline simultaneously. We can look at empirical data from Dash to debate and determine an ideal ratio.
Thoughts?
