please delete

[SapphireSpire]

nothing to see here 

[vjudeu]

Is it similar to BIP-300 and BIP-301?

[NotATether]

Is it similar to BIP-300 and BIP-301?

It does not seem similar to them at all because the Drivechain BIPs propose to make an on-chain "deposit" and "withdraw" feature from sidechains, where the confirmations for the withdrawal process at least totaling in more than a hundred thousand. While OP is proposing a singular blockchain running along side the mainnet with a (fixed?) block size limit.

[vjudeu]

If that's true, then why don't people just propose to increase block size?

Because that would be instantly rejected. Many times people hear "you cannot increase block size", but because they have no idea, how to scale things correctly, they cannot see any other solution, so they end up with "obscured block size increase".

We had 1 MB limit. It was reached.
Now we have 4 MB limit, and guess what, it was reached.
After Ordinals, developers will reject any proposal to increase block size, because that limit will also be reached, no matter how high it would be.

While OP is proposing a singular blockchain running along side the mainnet with a (fixed?) block size limit.

a second hashchain that runs in parallel with the blockchain

I cannot find any sentence, where OP would say it would be obligatory to run both chains. In sidechains, you can run mainchain-only, both chains, or even sidechain-only, it depends what type of client you need.

If i understand your idea correctly, 1 block on hashchain linked to 1 block on current Bitcoin blockchain.

There is a difference between obligatory link, and optional link. I think sidechains should be optionally linked, and also through commitments to make it more private. In case of obligatory link, it would be just de-facto block size increase, in the same way as Segwit commitment is.

[BlackHatCoiner]

A target transaction capacity must keep itself above the transaction rate by regulating both the block interval and the transaction count per block.

What's the point of having a "target transaction capacity"? You went to the technical part, of what it means, or how it's connected to the block interval, but you've skipped the "why" part. But just to catch you out, miners can bypass any "transactions required per block" requirement, as they can just create transactions where they send 0 coins to nowhere.

With a floating block interval, the rate of inflation will be less consistent.

This is extremely important. Most people I know, use bitcoin because the inflation schedule is known. You can tell what the inflation rate will be in 30 years, an invaluable property for money of that kind.

[BlackHatCoiner]

I'm still struggling to see the solution to the problem. So what you're proposing is:
- make the block interval variable.
- make the inflation rate variable.
- separate the blockchain into headchain, bodychain and crownchain (so SPV with extra steps?)

counterfeit blockchains

Define "counterfeit blockchain".

[NotATether]

1. Miners ping their peers to measure latency and adjust the target difficulty to keep the block interval as short as possible without forking.

Network latency should not be involved inside calculating the block difficulty, because that opens up a DDoS attack where the routers in front of the nodes can include an additional time "doing nothing" using flashed firmware, to artificially increase the ping and have an influence in lowering the block difficulty.

Latency should be used for just deciding which peers to connect to.

[Cricktor]

And i said that's not true. Maximum block size remain unchanged at 4 million weight unit and compact block doesn't change how weight size of transaction is calculated.

Exactly this. From my understanding compact block is a way to propagate new blocks with less data needed to transmit and thus likely resulting in speedier propagation with less latency. If the receiving node has all transactions of the new block in its mempool, then it can reconstruct the new block on its own and doesn't need to fetch the whole new block from another node which already has it.