Ok, let me ask about more specific scenarios then and we can see which pieces of this I’m missing:

Let’s start with a really simple one to make sure we are on the same page:

Let’s assume a mining pool with 70% of the hashrate, but no mining users in the pool with the DC full node, the pool OP writes a transaction that includes a bunch of honest transactions, but one malicious one that pays out of the DC like 10k BTC to themselves. Then they put it in the mining pool’s blocks and everyone starts blindly ACKing it without realizing.

What is it about the transaction/nodes/etc that prevent this transaction from either being written, or prevents it from being confirmed?

(I realize this is unlikely and I don’t want the normal “it won’t happens because” arguments, I want this played out so I can understand how it works)

Reply to this note

Please Login to reply.

Discussion

I realize I didn’t stipulate that the transaction here is one that pays out of the DC hash rate escrow, if that wasn’t obvious.

Nothing is payed out of the DC hashrate escrow, besides regular main chain fees for a regular utxo. Fees payed to miners in Bip 301 (the other DC bip, NOT hash escrow) are different. I will not describe them here as this clarification reply from you question is not related.

Basicly you mean: what if a mining pool has 70% control of a specific sidechain using bip 301 to secure its sidechain transactions.

And then that pool starts validating false transactions on the sidechain that pay them more fees.

Correct ?

Ok let’s start a step earlier then:

How does the peg out work? Nobody on BTC main chain can verify that the transaction submitted to peg out is actually valid ownership, because all that activity happens off chain. So what “keys” are required to write a peg out, and what stops a miner from writing one that has nothing to do with the sidechain?

There are several ways. On the Sidechain side of things, scripting can assign a token or set amount of tokens that the project and users agree is part of the design, to whoever signed the peg-in. This creates a sidechainnside user and account with forward rights to those tokens.

If some specific set of sidechain scripting favored miners, and thus made users vulnerable, everyone would know and reject the project OR accept it as part of some larger benefit. Let the market decide. Our main contention is that the market and market competition is a greater innovative force than the vitcoin devs and priesthood that have directed it up to now. It's essentially an argument between a communist or capitalist bitcoin future. Are things like RGB, Lightning, ect, market driven innovation or dev (politburo) driven.

The point is, as a user of bitcoin, none of this affects your normal use. You benefit from a means to adopt any potential challenger to bitcoin technology that might arise in the unknowable future, voluntarily. You benefit from a more secure network, through a more decentralized and incentivised miner environment. But if you want to just keep using bitcoin the way you have and never risk it in a sidechain you can.

But i think what interests you is the scaling ability, while maintaining the security and sovereignty features of main bitcoin.

For one potential scaling solution :

Truthcoin.info/blog/thunder

Basicly, Where big blocks are bad on L1 they can be good on a L2.