Please let me try again to spread my ignorance about sidechains.
Perhaps the sidechains project could be renamed "ways in which the bitcoin network (BCN) can interact with other internet services, and how the bitcoin protocol (BCP) would have to be modified to allow them". These "other services" being the "sidechains".
Different people have different ideas of what sort of services would qualify for "sidechains", but let's not focus on that, focus instead on the interactions. In order to exclude those variable assumptions, I will use the term "bitcoin-dependent service" (BDS) instead of "sidechain".
I gather that there are at least three kinds of interactions that are being discussed:
1. Bitcoins may be somehow be "moved" from the BTC blockchain to the BDS, who would handle them in some way, and eventually "return" them to the BTC blockchain.
This kind of interaction does not seem to require any change in the BCP
or the BCN, and in fact is routinely used by exchanges
and other similar services. It would suffice to move the coins
to BTC addresses whose private keys are known and
managed by the BDS. To "return" the coins, the BDS
would have only to sign transactions out of those
addresses.
The BDS is free to manage the private keys of its
addresses any way it sees fit. The BDS may allow its
users to generate those addresses and keep the keys, or
it may keep the keys in its central servers, or it may
use the standard bitcoin multisig mechanism, etc.
Thus the bitcoin network does not even need to know that
the BDS exists; and this use of the BCN by the BDS is
"fair use" by tradition and design.
2. The BDS may exploit the power of the BCN to secure its data structures against tampering or rewind
This interaction too does not seem to require any
additional mechanism in the BCN or the BCP. The BDS
computes a SHA hash of the data it wants to secure, and
sends to the BCN a transaction request containing that
hash, possibly disguised. Once the transaction is
included in the bitcoin blockchain, anyone can detect if
the original data is posted by the BDS and has
not been tampered with.
The BDS could do this operation at a rate higher than the
bitcoin block rate, in which case each bitcoin block will
contain several of those hashes. However, BDS users wishing
to verify the hashes would still have to wait for the
next bitcoin block, and possibly several blocks. These
BDS hashes may be Merkle-chained and combined with any
Byzantine generals mechanism by the BDS to achieve other
kinds of security. The BCN does not need to know that.
One thing "morally wrong" with this solution is that it
is "parasitic": the BDS would enjoy, almost for free,
the same level of security against tampering that would
otherwise require a separate network with the same power
of the BCN. The BDS would have to pay a transaction fee
to the BCN for each stamp, but the fees currently are
negligible compared to the cost of the BCN. That is an
unfortunate consequence of the BCP, that offloads
the cost of the BCN to the the buyers of new bitcoins.
3. The BDS could use the full power of the BCN to implement its own PoW mechanisms by merged mining
I don't understand enough of the discussion to tell
whether this kind of interaction would provide more
utility to the BDS than item 2 above, but let's suppose
it does. On the other hand, it would provide more
incentives to the BCN, though which may be important
if the rewards and fees derived from bitcoin mining
were to dwindle.
If I understood correctly, in the simplest scheme each
node in the BCN would collect work requests from the
affiliated BDSes. Each request would contain a hash of some
arbitrary data that the BDS wants to secure. The node
assembles a bitcoin block containing some bitcoin
transactions and those BDS hashes, and then tries to solve
the PoW puzzle for that block, as in the current
protocol.
Each work request would also specify an
associated difficulty level and a reward value, either in
bitcoins or in some tokens defined by the BDS. The bitcoin block
itself would be one of those requests. As the node keeps
working, its best solution will satisfy an increasing
subset of the work requests. At any moment the node may
decide to stop, collect the rewards it has won, and start
all over, or continue trying to find a better solution.
To claim the rewards the node sends the whole bitcoin
block, with the best nonce, to each BDS in that subset.
Is this a vaguely correct description of merged mining?
If so, I suppose that some nontrivial mechanism/protocol
would be needed to ensure that the affiliated BDSes pay
the promised rewards, either in BTC or in their own
tokens. Would this require a change in the BCP?
Merged mining would proveide an incentive for miners to service
all BDSes that pay enough rewards. The BDSes, in turn, would again
get the power of the full BCN for a fraction of the cost.
Indeed, merge mining would support a larger network than
could be supported by bitcoin alone.
A BDS could get faster turnaround than bitcoin's (say 1 request
every 10 seconds) by specifying a lower difficulty and
proportionally lower reward.
A possible "danger" that I see in this idea is that
bitcoin itself would be just a BDS like any other
(except that it dictates the format of the solved block,
which the other BDSs would have to accept). Thus the
miners may eventually abandon bitcoin if it is not
profitable enough compared with the other BDSes.
Does this make any sense?