Quote from: Peter Todd on April 01, 2014, 12:21:36 AM

Well if we're not going to call what I was talking about as a
side-chain, what term do we want to use for the notion of a chain that
consists of hashes embedded in one blockchain, that refer to data that
we're not storing on that blockchain?

I don't know, maybe child or dependent chains?

Quote from: Peter Todd on April 01, 2014, 12:21:36 AM

Do you want to reserve the term side-chain for only a specific way of moving value from one to the other?

I wasn't implying 2-way peg, I didn't even said side-chain, just said "your own chain" to point out the technical advantages of having your own chain validating your own rules.
In any case, using "side chains" to refer to independent chains with
2-way peg (independently of their pow system) makes sense to me.
We already have "altchains" or just "chains" for more general things,
like what I was saying.

Quote from: Peter Todd on April 01, 2014, 12:21:36 AM

Because from the user's point of view handling that by atomic purchases of shares for coins or whatever doesn't look much different from the SPV proofs model.

The atomic cross chain swap is faster than the SPV 2-way peg and will probably used more often than the SPV redemption even in chains with 2-way peg.
What's more interesting are atomic trades in the same chain.
You could have BTC gateways on the chain specialized for p2p trade, but then you would need to trust them. That trust is what 2-way peg removes.

This makes me think...btc and mastercoin/counterparty user issued assets already live in the same chain. Why is a new host currency needed then?
To me is like if colored coins developers would have issued and sold "examplecoins" or distributed them upon proof of destruction.
Examplecoins wouldn't be special in any way compared to other colored coins, well, just that no one is promising any kind of redemption.
If I understood it correctly, MSC were necessary to fuel the economic perpetuum mobile that synthetics assets are.
Counterparty doesn't seem to promise any synthetically stable nonsense and assets are just user issued assets, just like in colored coins or freimarkets.
How are XCP treated different than jtimonCredits in the protocol and
why couldn't you use bitcoins directly given that you're already on
the same chain?

Quote from: Peter Todd on April 01, 2014, 12:21:36 AM

You also have to ask if a side-chain refers to a specific proof-of-work consensus, or things like proof-of-sacrifice apply as well - and as I argued above, if the "hashes that refer to data stored elsewhere" has any hope of being secure you need actual incentives to publish and thus something like proof-of-sacrifice and a chain-style structure.

I refer to proof of work chains. Other times I refer to chain secured
with signatures, but then I explicitly say "private chains".
But I guess many things would apply to proof of sacrifice chains as
well, honestly I haven't thought much about them.
On your point on incentives to publish I think we agree.
It is important to separate "proof of publication" from "proof of permanent storage".
If you need the former but not the later (like in your colored coin order publication example), you could use maaku's soft-fork proposal I explained you on the bitcoin mailing list:

"Store hashes, or a hash root, and soft-fork that blocks are only
accepted if (a) the data tree is provided, or (b) sufficient work is
built on it and/or sufficient time has passed"

This way full nodes can ignore the published data after it is sufficiently buried.
This way you can have infinite room for proof of publication without storing more than a hash in perpetuity.

It's not the same to ask for just proof of publication, than to advocate for non-bitcoin-data perpetual storage.

What's the problem with this solution?
Would this be enough for "embedded consensus systems" like counterparty?