Quote from: brg444 on November 13, 2014, 03:15:14 PM

Quote from: cypherdoc on November 13, 2014, 02:46:28 PM

Quote from: brg444 on November 13, 2014, 02:21:58 PM

Quote from: cypherdoc on November 13, 2014, 11:12:18 AM

I watched that twitter dialog. They sure got grumpy quickly.
Only two chains are required. It can be more chains, and more transactions but the minimum would be:

1) a transaction on the MC locking the assets
2) a transaction on the SC whose inputs contain a cryptographic proof that the lock was done correctly (and thereby creating the SC asset).

So, BTC--->scBTC --->CC is the correct way to think about it as we have consistently been doing here for the last 200 pages?

No, not in the way you suggest where everyone on a sidechain could either hold scBTC or CC.

In our long used sequence as above, perhaps I should have clarified that the scBTC that emerges from the peg can ride the TC SC for as long as it wants before converting in some unknown ratio to CC? That makes it conceptually correct, right?

But I don't think that is the case no. I believe the process NL is describing above :

Quote

1) a transaction on the MC locking the assets
2) a transaction on the SC whose inputs contain a cryptographic proof that the lock was done correctly (and thereby creating the SC asset).

..is completed automatically in a "seamless" matter. What I mean by that is I don't believe the user gets to choose whether the SC asset is created or not. Maybe I'm wrong and then someone can correct me..
[/quote]

well, we know i must be correct about this b/c the whitepaper talks specifically about how other assets can be created on the SC that are independent to the scBTC emerging from the peg but are not interchangeable for scBTC (which would allow them to leak back into BTC).