Further analysis of various issues and solutions:

Many worries about drivechain design involved them being required to process and mine it for fees to compete against other miners who are getting that side income without expending additional work, some even called it "attack on miners" for incentivising bandwidth costs of being sidechain aware. Since there's no federation to worry about, their ability to steal isn't there. Alternative threats to consider are possibly censorship and taking over the childchains. Let's examine taking over the childchains threat first.

Miners could desire those additional fee revenues and take over chilchains. Since this process relies on burning Bitcoin, it applies to miners like everyone else, and thus has high costs. The only real unique discount they can get is the mainchain fees back, but not the burnt Bitcoin which is most important. Perhaps, since this would still bring some fees to mainchain from burn commits and the childchain tx are likely there in first place to avoid high fees, those accumulated fees on childchain were unlikely to bring revenue to miners either way and the fees that do end up on mainchain are paid for indirectly by the effective batching of childchain fees that attracts burners. Furthermore, if the childchain tx are used for unique rules the child chain has (like virtual machines or stateful smart contracts), that's just another source of demand for mainchain this allows it to get.

Miners could see childchain as a threat to take away their fees, but would only be significant at high rate of childchain use and thus high rate of Bitcoin burn. Fee specific rules are dangerous if they become predictable for miners to detect in case of censorship attack by miners (like if rule is 10% of burn is fee, and miner detects output that paid 10% in fees of its value, they can try to censor all such tx to kill childchain). In fact, hiding childchain interactions with Bitcoin is important and fees are likely to be taken care of by demand.

Here's a strategy to hide childchain transactions on mainchain, use outputs that appear like many others.

For previous examples I suggested using OP_RETURN to be provably unspendable for commits and simple send to address for withdrawal fills.

Hiding from miners like in BMM could be more secure so similar can be achieved in theory by P2SH where all you see is a hash of a script in ScriptPubKey of 1+ outputs in mainchain tx that looks like any other P2SH. (I'll use P2SH terminology but P2WSH would work as well)
That hash could hide all kinds of information.

Burners are best expected to commit to Bitcoin before broadcasting the childchain block. The burn and the withdrawal filling tx could be hidden as P2SH. Withdrawal P2SH would allow recipient to spend it after the childchain block is propagated. When recipient withdraws from that output they would reveal a secret that could be used to determine that the burn output is provably unspendable as script always evaluates to false. To avoid detection by miners via known ratio of burned Bitcoin to withdrawal BItcoin, the exactly 20% example rule diverted to withdrawals should be a flexible range like 10%-20%. The total amount burner spends doesn't change but burner is free to pick a random ratio within a popular range to hide himself. When withdrawal happen and redeemscript and secret are fed into it, secret becomes public knowledge, and it could be a notice that the other is the standard burn output that could be verified with the known secret as unspendable.


P2SH script for withdrawal output:


P2SH script for burning


The secret in burning script helps randomize the hash of that script that's visible in its burn output script, but it always ends up with a false at top of stack and fails.
Feeding withdrawal p2sh the secret makes second derivable based on standards childchain uses. sha256 I believe is less costly than signature validation so it is checked first to save on computation if it fails.
Nodes would still need to know to check for this childchain burn script but they don't have to monitor the childchains to find the secret to prove the burn utxo prunable (so no higher bandwidth use requirement).

What if fees on mainchain are larger than income from fees on childchain?

- Childchain is likely to have capped blocksize or gas limit of some kind, but would allow miners to pick best paying tx to fill childchain blocks. Burners could wait until childchain fees accumulate or rise high enough to make burning worth it - could be 1000s of childchain tx fees to cover the single bitcoin fee and compensating bitcoin burners. Ideally childchain would also have mechanisms to replace fees to let them grow if necessary.

What about issue with some blocks with too many burners and some blocks with too few as it's hard to predict others behavior before the block is mined?

- The fees payouts can be averaged out slightly with a simple formula. All the fees from each block could go into a childchain fee pool state from which payouts to burners are made. The total of 50% of current fee pool can be paid out total each block creating a predictable minimum payout schedule even if all childchain tx were to suddenly stop. Instead of only paying out to the burners in each block, the payout could be to amount burnt by A in previous N (e.g. 6) blocks. At steady state pool consumed would be same as new fees gained.

The payout to burner A for example would be calculated like this each block:


What about projects that already use another coin other than Bitcoin but want to migrate and switch to pure Bitcoin childchain?

- could do a design where you let let's say 20% of fees be paid by the altcoin where it's burnt to phase it out but allows a max of same 20% capacity per block so the additional capacity doesn't take fees away from miner. The value of altcoin could be set to be a specific amount of sBTC, bytes, or gas for those fee considerations depending how chain measures it. Most important is that it doesn't take away from miner sBTC fees hence added capacity just for those tokens. It's more work to pay with it but it's also helpful for those already with them. As they are burnt they become less important on transition to pure sBTC use. This could be used to transition away from unsecure premined coins to trust minimized supply.


I'm not sure this will be a good idea, but if pure fee only childchain scares people, there are things they can do w/o compromising the mainchain - benefit of a well defined base mainchain to add onto:

Let's call this hypothetical coin "Inflation Bitcoin" "IBC" (to avoid confusing people that it's same as non inflationary bitcoin, this doesn't exist, I just made it up for this example).
You can create a block reward that pays in IBC, let's say 0.0002% of total IBC supply per block which should roughly be equal to about 10% inflation per year.
You create those IBC out of nothing (gasp) to give to burners (e.g. via fee pool) which devalues all other IBC. The network tracks total Bitcoin still deposited vs total IBC that exists.
While it starts with those equal, slowly over time total ICB becomes larger, and the ratio between those values can be used for conversion on withdrawals and deposits.
Effectively it simulates the dilution you see from block rewards but that's limited to only the childchain. And while the value of the pegged coin is still proportional to Bitcoin, it's offset by ever changing inflation factor.
I think it's a bit confusing to call it anything resembling Bitcoin when it has permanent inflation but this demonstrates the flexibility with the peg childchains can have if they choose to.
Technically, it might even work in the opposite direction where the peg is changed to increase in value over time (e.g. 5% per year like HERO) with main issue being the withdrawals would take longer to fill.
I haven't thought all the possibilities for this through yet but I welcome discussions.

---
If I forget to credit you after a discussion or forget or don't realize I have to credit someone else, lmk.