Subnostr

The difference is that this doesn’t cost the miner anything in addition, and the miner still can’t be censored form mining in the base chain despite being malicious against the DC.

And then of course the 3-6 months is a decent strategy for creating as much time as possible to enforce, but it still also relies on full validation of any affected DCs to be certain of maliciousness does it not? That’s what I mean when I say “moving the problem elsewhere.”

Cyber Seagull 2y ago

Validation of what ? Let's use the EthSide on Dc chain as an example. Let's say you the user wants to withdraw from ethside back to main. Ethside happens not to use BMM, in this example, so nothing has ever or will ever be validated by a miner on the sidechain for security or anything.

You initiate a withdraw. 3-6 months later the Bundle hash goes through. You get your utxo. Where along this path, this user journey, is a unique atrack vector to Drivechain that does not exist for any other aspect of bitcoin.

From Bip 300:

What are Bundles?

Sidechain withdrawals take the form of "Bundles" -- named because they "bundle up" many individual withdrawal-requests into a single rare layer1 transaction.

Sidechain full nodes aggregate the withdrawal-requests into a big set. The sidechain calculates what M6 would have to look like, to pay all of these withdrawal-requests out. Finally, the sidechain calculates what the hash of this M6 would be. This 32-byte hash identifies the Bundle.

This 32-byte hash is what miners will be slowly ACKing over 3-6 months, not the M6 itself (nor any sidechain data, of course).

A bundle either pays all its withdrawals out (via M6), or else it fails (and pays nothing out).

Reply to this note

Please Login to reply.

Discussion

Guy Swann 2y ago

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)

Guy Swann 2y ago

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.

Cyber Seagull 2y ago

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.

Cyber Seagull 2y ago

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 ?

Guy Swann 2y ago

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?

Cyber Seagull 2y ago

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.

Cyber Seagull 2y ago

For one potential scaling solution :

Truthcoin.info/blog/thunder

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