Drivechain critiques by gmaxwell revisited, maybe you changed your mind?

[squatter]

If you're going to hodl for 6+ months anyways, then why not collect some fees on top of that like a JoinMarket maker?

Is there any recent discussion of how much JoinMarket makers can expect to earn? It's crossed my mind, but I'd like to gauge the expected gains vs. the risk of keeping private keys online.

Paul Sztorc admits it is true here... increasing the withdrawal requirement to 13,150 ACKs.

No, he doesn't and it wouldn't matter if he does. But you are misreading his faq comment.  I'm not discussing Drivechain project or its devs' opinions, anyway. As of 13,150 ACKs, they became poisoned by the "51% theft security whole" hoax and ruined their project by such stupid decisions. My proposal: let's put it on 200 ACKs and observe that there will be no theft for the next couple of decades.

I would love to see that. Chances are that the sidechain would end up holding very little value, commensurate with the mining security. There's no point attacking a worthless chain.

Nobody really cares about the viability of sidechains. Unlike Bitcoin, miners don't have strong incentives against attacking them.

And FYI, from a game-theoretic perspective, it is a hell "harder" to steal a penny from sidechains compared to the mainnet. Double-spending is a covert operation and mainnet full-nodes are absolutely blind about it, but sidechain full nodes will detect the theft at the moment it is happening.

Just like merge-mined altcoins, the only people who would care are holders of the altcoin. The Bitcoin mainnet doesn't care. That's why it's easier -- miners can openly attack the sidechain without anybody really caring.

BTC.com colluded in a 51% attack on Bitcoin Cash last year. As one of the largest Bitcoin mining pools, their reputation doesn't seem to have suffered all that much.

[1714849093]

1714849093

[1714849093]

1714849093

[Explodicle]

If you're going to hodl for 6+ months anyways, then why not collect some fees on top of that like a JoinMarket maker?

Is there any recent discussion of how much JoinMarket makers can expect to earn? It's crossed my mind, but I'd like to gauge the expected gains vs. the risk of keeping private keys online.

<1%, it's very competitive. But that's a feature not a bug, users shouldn't have to pay a lot for privacy, or to move money to/from a sidechain quickly. Drivechain withdrawals don't share this hot wallet requirement so the return would be abysmal.

The Bitcoin mainnet doesn't care. That's why it's easier -- miners can openly attack the sidechain without anybody really caring.

We'd care if there was an attack on a sidechain because then we'd lose useful functionality that makes bitcoin worth more, even if you or I don't use that feature. BCH isn't pegged to BTC and it's anything but useful.

[Wind_FURY]

And FYI, from a game-theoretic perspective, it is a hell "harder" to steal a penny from sidechains compared to the mainnet. Double-spending is a covert operation and mainnet full-nodes are absolutely blind about it, but sidechain full nodes will detect the theft at the moment it is happening.

The full nodes would reject invalid transactions, and/or the blocks that contain them.

Newbies, if two transactions spend the same inputs, in the same block, then both will be rejected. If the other one makes it to a block, than the other, then the first one is accepted, the other rejected.

[squatter]

Is there any recent discussion of how much JoinMarket makers can expect to earn? It's crossed my mind, but I'd like to gauge the expected gains vs. the risk of keeping private keys online.

<1%, it's very competitive. But that's a feature not a bug, users shouldn't have to pay a lot for privacy, or to move money to/from a sidechain quickly.

I assumed the margin wouldn't be high from looking at the order book. I wonder more about the volume one can expect.

The Bitcoin mainnet doesn't care. That's why it's easier -- miners can openly attack the sidechain without anybody really caring.

We'd care if there was an attack on a sidechain because then we'd lose useful functionality that makes bitcoin worth more, even if you or I don't use that feature.

Perhaps, but the fundamental value of having minimal base layer functionality is that it insulates Bitcoin from attacks on the upper layers. There is always an implicit security trade-off when you use an off-chain or sidechain mechanism because they aren't secured by the Bitcoin mainchain consensus. We should keep that in mind when considering the value these upper layers represent, especially in their early alpha/beta phases.

[Wind_FURY]

Bump.

"Adam Back, Co-Founder and CEO of Blockstream
""Drivechains...are pretty cool...and arguably could have been more important or useful than let’s say Taproot.""
""props to @Truthcoin and team for implementing and validating drivechain design.”"

"Olaoluwa Osuntokun, CTO of Lightning Labs
""In the past year, the drivechain specs seem to have come a long way."""

"Sergio Demian Lerner, Chief of Innovation at IOV Labs and Designer of the RSK Rootstock Bitcoin sidechain
""[...] migrate Rootstock to a drivechain when it is softforked into Bitcoin [...] the destiny is to become fully decentralized.""
""[...] sidechains are the natural extension of the Bitcoin finance stack [...]. A sidechain is a blockchain that is highly incentive-aligned with the Bitcoin community."""

https://docs.google.com/spreadsheets/d/1m4PpNIdBKuLC6FzLOoIfvHXcnrSh6dnOqPrqKg-zJEw/edit#gid=0

There's a spreadsheet containing some quotes, with links, from people who are probably "Friends of Drivechain". Three years later from the creation of the topic, what's everyone's updated opinions about BIP-300 now that Ordinals are starting to become an inconvenience for Bitcoin users who simply want to use the blockchain for financial transactions?

[vjudeu]

Bump.

My opinion didn't change since last time I talked about it. The community will probably reject sidechains in the current form. That means, it cannot be deployed as a soft-fork, because it will not reach that level of support. I also wrote about deploying that as a no-fork, you can read some discussions there: https://www.truthcoin.info/blog/sc-vision/

It is quite simple: to deposit coins, you sign them without moving. To withdraw them, you move them on the mainchain. Then, it is all about making output scripts, and dealing with them in some encrypted form inside the sidechain, for example by using homomorphic encryption.

what's everyone's updated opinions about BIP-300 now that Ordinals are starting to become an inconvenience for Bitcoin users who simply want to use the blockchain for financial transactions?

Again, you can also read my posts about it in another topic: https://bitcointalk.org/index.php?topic=5437464.msg61692197#msg61692197

In short, there is no need to use any chain for Ordinals at all. But if you really need it, then you can make a separate chain, that will commit to Bitcoin inside transactions' signatures.

Because you really don't need those data on-chain, attached explicitly into Bitcoin transactions. It is expensive, it is incompatible with what Satoshi said about BitDNS (thank you garlonicon for mentioning that), and there are better ways to achieve the same security level. Because if your concern is Proof of Work protection, then using commitments is sufficient to achieve that, even if your data will be stored on a separate chain, because SPV proof to a Bitcoin transaction, and another SPV proof to your commitment inside your signature, can easily cover that, and prevent reorgs as well as Bitcoin.

[d5000]

I also wrote about deploying that as a no-fork, you can read some discussions there: https://www.truthcoin.info/blog/sc-vision/

It is quite simple: to deposit coins, you sign them without moving. To withdraw them, you move them on the mainchain. Then, it is all about making output scripts, and dealing with them in some encrypted form inside the sidechain, for example by using homomorphic encryption.

I've looked at your idea in the mailing list, and it would of course be phenomenal if it was possible already with today's Bitcoin Script abilities. It looks a bit similar like rollups, but without posting always updates to the main chain. The use of homomorphic encryption looks also interesting.

But there are some things I don't understand. Mainly the following point:

How does your last transaction on the main chain look like, before moving to the sidechain? You wrote that when you move to the sidechain, you sign a new transaction but broadcast it only inside the sidechain network (and encrypted, so it can't be broadcast to the mainchain by other sidechain observers). But which is the Script you use in your last transaction to avoid that yourself move the coins while they're happily living on the sidechain? There has be some kind of lock (probably to a P2SH-style hash), but what exactly would unlock it? If unlocking it would need a kind of ZK proof, wouldn't this lock need a new opcode? (From the discussion with Paul Sztorc I interpret there would also be some kind of timelock.)

It's a bit of a pity that neither your discussion with Paul Sztorc nor the one on the mailing list progressed more because the topic is very interesting ...

(As this is not a Drivechain proposal but another kind of sidechain, it would perhaps be worth an own thread.)

[vjudeu]

How does your last transaction on the main chain look like, before moving to the sidechain?

It depends on the user. You just choose some UTXO, and sign it. As long as this UTXO is not moved on the mainchain, it is valid on the sidechain. So, in this way you, as a user, can choose any locking script. If you want to just test sidechains, then you can do that alone, by using any single-key address. If you use some 2-of-2 multisig, behind raw multisig, P2SH or P2WSH, then you need two signatures to move coins on-chain (that would remove them from the sidechain). You can also add any conditions, like OP_CHECKLOCKTIMEVERIFY, or any Script you want. That means, all conditions to move funds back from the sidechain to the mainchain, are entirely chosen by users, and all transactions look the same as usual, so you don't know that funds are locked on the sidechain, unless you connect to that network.

You wrote that when you move to the sidechain, you sign a new transaction but broadcast it only inside the sidechain network (and encrypted, so it can't be broadcast to the mainchain by other sidechain observers).

Yes, encryption is the hardest thing, but it is definitely possible. It is needed to ensure that sidechains will not make things worse (if you would send unencrypted transactions that would be instantly valid on the mainchain, then the whole sidechain history could be pushed on the mainchain, so the situation would be the same, as without any sidechains).

But which is the Script you use in your last transaction to avoid that yourself move the coins while they're happily living on the sidechain?

The Script is whatever will be accepted by receivers. The simplest script is N-of-N multisig, where N is the number of parties interested in a particular UTXO. In the Lightning Network, you have 2-of-2 multisig, as a basic script. Here, it goes further, so you can use for example P2TR with N-of-N multisig on a spend-by-key path, and then you can add any TapScript you want to this basic setup.

If unlocking it would need a kind of ZK proof, wouldn't this lock need a new opcode?

As long as there is lack of necessary opcodes, some tricks are needed: you encrypt your TapScript, and you work on your encrypted version, that will finally be decrypted by the last user, and will form a valid on-chain transaction. It is possible to prove that your data has a given format, in the same way as it is possible to prove in Monero that your amount of coins is in a given range, or as it is possible to prove that some addresses in a given set were selected, when some transaction moved the coins.

The use of homomorphic encryption looks also interesting.

In general, you can encrypt your Script first, then execute it without decrypting (homomorphic encryption), and then you can ensure that the final result evaluates to OP_TRUE, without revealing your script. You don't need to know the content, you only have to ensure that it is correct, it meets standardness rules, it won't give another party a way to sneak OP_SUCCESS somewhere in the TapScript etc. (in general, you need to check the format, and make it strict).

[d5000]

It depends on the user. You just choose some UTXO, and sign it. As long as this UTXO is not moved on the mainchain, it is valid on the sidechain. So, in this way you, as a user, can choose any locking script.

I may be overlooking something, but the problem I see here is that these sidechains would be difficult to use, as they themselves would not give any guarantee that the funds on the mainchain wouldn't be moved and thus the coins on the sidechain would have a tendency to be "unstable". Any time you accept a sidechain transfer, you would have to check if its origin is based on a mainchain UTXO which is properly locked.

The difficulty for me is to imagine a kind of hashlock for this last mainchain tx, which fulfills the following conditions:

1) prevents the originator of the sidechain coins (let's call it Alice, like in the example used in your discussion with Paul Sztorc) to move the coins for the whole time the coins "live" on the sidechain
2) prevents all intermediate receivers of sidechain coins of this origin (Bob in Paul Sztorc's example) to withdraw coins and unlock/move these mainchain coins,
3) can be unlocked only by the last user of the chain of sidechain payments whose origin are Alice's mainchain coins (Dave in Sztorc's example),
4) that the withdrawal/unlocking (Dave) can be performed by any Bitcoin/sidechain user, not only one who is part of a "federation" of multisig participants (otherwise the whole federation may become unavailable and then the sidechain coins float in a "limbo" maybe forever)
5) is possible to construct with standard Bitcoin Script / TapScript.

Could you provide an example for such a lock? I'm not familiar with TapScript so I don't know if it's expressive enough.

I don't know if OP_CHECKLOCKTIMEVERIFY would have any use in this scenario. We could imagine an example where Alice owns a business who sells goods accepting the sidechain coins, but she also buys regularly things there. So she could move some coins temporarily to the sidechain to profit from lower fees with the idea to move them back near the expiration of the timelock. But the lock problem persists, as she's not forced to "take back" the coins, and could make some payments, and then simply wait until expiration to move the mainchain coins.

Maybe a solution to the problem could come from the Optimistic Rollup technique? I.e. one could imagine a sidechain where an user who proved having received the sidechain coins could pay a "penalty fee" and then perform a withdraw which will be frozen for some blocks. If there is another user later in the chain, who has proved that he also has received the coins (i.e. in Sztorc's example this would be Dave, and the "scamming" user may be Alice or Bob) then he would be able to send a "fault proof" and receive not only the coins, but also the penalty fee from Bob. If nobody opposes in this fashion, Bob gets back the penalty fee and also can move the coins on the mainchain. Still this would need probably new opcodes (?).

you can use for example P2TR with N-of-N multisig on a spend-by-key path, and then you can add any TapScript you want to this basic setup.

If I interpret it right, this would be very similar to the classic "federated" sidechain (RSK, Liquid). Or are there any improvements on it that I'm overlooking?

I think you may be onto something, this looks like like a possible improvement on rollups, but I still think it would need things like recursive covenants and zk proof or "fault proof" opcodes. The model may be possible on chains with turing-complete script languages though.

[vjudeu]

Any time you accept a sidechain transfer, you would have to check if its origin is based on a mainchain UTXO which is properly locked.

The same is true inside Lightning Network: each time you check that it is 2-of-2 multisig, even if it could be different. So, here it will be similar: typical scripts will be accepted instantly, but other, less typical scripts, can be also supported if everyone agrees, so that the network could be upgraded if needed. For example, if some TapScript opcode will be re-enabled by some kind of soft-fork, then there should be a way to upgrade sidechains accordingly. So, when it comes to network acceptance, then any script is accepted. But when it comes to clients, then they can do a pattern matching, and accept only specific type of scripts, in the same way as miners include transactions, based on their standardness rules, while also accepting non-standard transactions in other blocks.

The difficulty for me is to imagine a kind of hashlock for this last mainchain tx

You can imagine the last Lightning Network transaction quite easily: it is theoretically possible that something could go wrong, but there are ways to prevent cheating. One of those ways is creating some kind of penalty transaction. Another way is to add some timelock, enforced directly, or relatively. In the sidechain proposal, even in the one proposed in BIPs, there are cases, where sidechain funds can be stolen. The same is true in LN. And here it is not different, because you can always create a double-spend inside, no matter what kind of Script will be used. Even in the mainchain, there are ways to steal funds, by creating a chain reorganization.

1) prevents the originator of the sidechain coins (let's call it Alice, like in the example used in your discussion with Paul Sztorc) to move the coins for the whole time the coins "live" on the sidechain

In the Lightning Network, there are penalty transactions. Also, funds are timelocked, so if they will go on-chain, they cannot be moved instantly. For sidechains, it was proposed to freeze them for three months. So, Alice can go on-chain, and then sidechain users will have a lot of time to react. In general, on-chain interaction will be for peg-ins and peg-outs, any other cases will be handled by swaps, in the same way as it was proposed in Drivechain.

2) prevents all intermediate receivers of sidechain coins of this origin (Bob in Paul Sztorc's example) to withdraw coins and unlock/move these mainchain coins,

They are in the same situation as Alice. And this way is compatible with Drivechain: it is not about preventing that from happening at all (because if some previous owner had those coins, then you cannot fully invalidate them, without moving any funds on-chain). It is rather about disincentivizing cheating by saying: "yes, you can always peg-out directly to the mainchain, but no matter if you are the last owner of those coins or not, this is not the fastest way, better swap your coins, instead of going through peg-ins and peg-outs".

3) can be unlocked only by the last user of the chain of sidechain payments whose origin are Alice's mainchain coins (Dave in Sztorc's example),

Only the last user can be 100% sure that any attempt to go through peg-out will be successful, and nobody will release any penalty transaction in the meantime.

4) that the withdrawal/unlocking (Dave) can be performed by any Bitcoin/sidechain user, not only one who is part of a "federation" of multisig participants (otherwise the whole federation may become unavailable and then the sidechain coins float in a "limbo" maybe forever)

It can be performed by any sidechain user, because Bitcoin users know nothing about the last owner. They don't have the chain, they don't talk to that network. It is the same case as with BitDNS, or with commitments: if you only use Bitcoin, then you can see only Bitcoin transactions, not sidechain transactions, not LN transactions, not commitments, etc. Also, there is no federation needed, unless users explicitly want that (because scripts should be accepted by the network, but selected by the clients).

5) is possible to construct with standard Bitcoin Script / TapScript.

Yes, it is possible. If you have N parties, then you can always start with N-of-N multisig. Then, if your TapScript will be unspendable for any reason, the cooperation between all parties will recover those funds. This recovery mode is highly recommended in case of emergency, it is better than making key-path unspendable by committing to provably unknown public keys. And then, if you assume that your TapScript can be really big (as huge as the maximum block size, which we saw recently, but in standard cases it is limited by transaction size), and if you also assume that it can be expanded into multiple transactions, then yes, you can execute any script. It is cheaper to just execute it in encrypted form, without pushing it on-chain, but yes, if you really want to enforce zk-snark on-chain, then you can, but it will be very expensive). The typical way will be to use N-of-N multisig as a protection, and then execute anything in encrypted form (and after successful execution, a single signature is all we need to make it cheap, three months is a plenty of time to prepare it).

Could you provide an example for such a lock? I'm not familiar with TapScript so I don't know if it's expressive enough.

If you want to know, how it will look on-chain, then any Taproot output looks the same: it is just a public key with 02 prefix enforced. Behind that, you can have N-of-N multisig, that can be done by a single Schnorr signature (you can use any multisig scheme, there are some of them proposed, I don't know what will be finally deployed in the Bitcoin Core descriptors). And behind that, you have TapScript, that is simply a tree. You can use any scripts there, you can encrypt them, and then execute in encrypted form, between sidechain users. Also, you don't have to store everything in your transactions, you only need to keep that part, which was not yet executed, and simplified into OP_TRUE. As long as those parts will be executed faster than in three months, it is cheaper to keep them in the sidechain.

I don't know if OP_CHECKLOCKTIMEVERIFY would have any use in this scenario.

There is also OP_CHECKSEQUENCEVERIFY, that could be a better match, because it will be relative to the time of enforcing things on-chain.

If I interpret it right, this would be very similar to the classic "federated" sidechain (RSK, Liquid).

No, because in this case, sidechain miners are not the ones engaged in the multisig. They are needed to mine both mainchain and the sidechain at the same time, so the same computing power can protect the sidechain from chain reorganizations. In this way, double spends inside the sidechain are resolved, so miners are needed to make sure that new users will get the right sidechain transactions in the right order. Miners are not there to protect the scripts, they are there to enforce the order in which they were created on the sidechain. And then, if someone will push something on-chain, to start a peg-out, then any sidechain user can decrypt penalty transactions (if any), and act as a global watchtower, preventing the cheater from getting the coins.

[d5000]

It took me some days to analyze your answer, but I've still problems to understand the solution to the (crucial) question "how must the last transaction on the mainchain look like" to be able to peg-in on the sidechain, which prevents me (=Alice, the "originator" of some sidechain funds) moving the funds causing chaos on the chain, invalidating tons of transactions, etc.

The crucial part where I fail to see a solution using Bitcoin Script is the penalty mechanism. In an "open" sidechain, where you transact directly with all users, it can't be like with Lightning, because you're not updating a state with a single multisig partner and could thus invalidate previous states like in LN.

I also looked at an "overcollaterized sidechain" model, where extra funds for penalties are required in addition to the funds used for peg-ins, but this didn't solve my problem - to ensure, via a mainchain contract, that only the last person in a chain of payments can peg-out (and previous intents are properly penalized).

The only model which is not close to a "federation" (see below) but may be possible (from my understanding) is a 1:1 clone of LN on a sidechain. This would need all sidechain participants being connected via "channels" made by multisig transactions with penalty transactions sent in an encrypted fashion to the counterparty and stored on the blockchain.

This of course has the disadvantage that the sidechain cannot "onboard" new participants who never used Bitcoin, all have to have funds locked on the mainchain, otherwise the penalty mechanism would not work. This is of course a very limited sidechain which would maybe have the advantage of more flexibility with respect of the requirement of a merchant to be 24/7 online to receive payments, but instead partly sacrifices LN's privacy (although maybe not all of it, due to homomorphic encryption).

So for me, the Optimistic Rollup model seems the path to follow. Something like this could maybe be achieved with covenants (I'm not expert enough to know if OP_CHECKTEMPLATEVERIFY like proposed in BIP-119 would be enough).

I may however be overlooking something ... if you can give me a concrete example how such a penalty mechanism could work exactly (i.e. with at least descriptions of the needed locking scripts) maybe I can imagine better


By the way, to most of the answers of the last post I agree and some were already clear for me. In some cases however I disagree:

In the Lightning Network, there are penalty transactions. Also, funds are timelocked, so if they will go on-chain, they cannot be moved instantly. For sidechains, it was proposed to freeze them for three months. So, Alice can go on-chain, and then sidechain users will have a lot of time to react.

The "reaction" is the problem here (see what I wrote about penalties above). If we use a simple timelock (CLTV/CSV) for the last mainchain tx before the peg-in, then there remains the problem that we can't create a timelock which only affects Alice. It would affect all other sidechain participants which want to peg-out with these funds. So this would create a race condition at the end of the timelock. There is no contract condition I can imagine that only Dave can fulfill (the last participant of the chain) but not Bob (intermediate) nor Alice (always talking about Bitcoin Script).

The "overcollateralized sidechain" idea I briefly mentioned before would separate a peg-in UTXO and a penalty-utxo for each Alice instance, and only the penalty would be timelocked on the mainchain, so peg-outs before the timelock ends would work. But I realized we're here only moving the problem to the penalty output.

[Intermediate receivers before Dave, i.e. Bob/Charlie] are in the same situation as Alice. And this way is compatible with Drivechain: it is not about preventing [a peg-out conducted by an user who's not the last in the chain] from happening at all (because if some previous owner had those coins, then you cannot fully invalidate them, without moving any funds on-chain). It is rather about disincentivizing cheating by saying: "yes, you can always peg-out directly to the mainchain, but no matter if you are the last owner of those coins or not, this is not the fastest way, better swap your coins, instead of going through peg-ins and peg-outs".

This security model would be flawed, I hope I (or you) misunderstood here You can't prevent someone who wants to steal coins convincing him that there is some way to peg-out "faster".

Only the last user can be 100% sure that any attempt to go through peg-out will be successful, and nobody will release any penalty transaction in the meantime.

Again, how exactly would this penalty mechanism work? The "Lightning way" only seems to work (imo) for payment channels and maybe the "LN on a sidechain" model I outlined above.

If you have N parties, then you can always start with N-of-N multisig. Then, if your TapScript will be unspendable for any reason, the cooperation between all parties will recover those funds.

Wouldn't that mean that payments could only be done between of the members of this multisig contract? This would of course work, but would be even more limited than the "LN on sidechain" model.

If not, how does the connection (and the "penalty/risk transfer") to other sidechain users work?

You're right, this is not the same thing as a federation, but it's quite similar in that only the users participating in this multisig contract have control over peg-outs.

[vjudeu]

"how must the last transaction on the mainchain look like" to be able to peg-in on the sidechain, which prevents me (=Alice, the "originator" of some sidechain funds) moving the funds causing chaos on the chain, invalidating tons of transactions, etc.

There is no strict enforcement, because there are many options:
1) You can use P2PK. Then, to make it safe, you have to create it with someone else in a way, where you know the public key, but nobody alone knows the private key. Multiplication of ECDSA points is a partial answer, because then nobody can sign it. A full answer is for example 2P-ECDSA, described here: https://duo.com/labs/tech-notes/2p-ecdsa-explained
2) You can use P2PKH. It is possible to encrypt things first, then compute the key as in P2PK case, and then hash it. After encrypted hash will be computed, it can be decrypted and sent to the network, then even nobody knows the combined public key behind this hash, because it was available only under homomorphic encryption. Note that having unencrypted signature will reveal that key, but you can also accept other proofs inside your sidechain, and then keep it hidden.
3) You can use P2SH. Then, if both parties know that things are standard, and evaluate into OP_TRUE, they can send it on-chain. In that case, the whole script is unknown. Also, OP_CODESEPARATOR can be used to sign only part of the script, and accept anything that comes before that opcode, but in this case it is better to use P2WSH or P2TR, because P2SH with OP_CODESEPARATOR inside will be non-standard.
4) You can use P2WSH. Then, it is similar case as with P2SH, but you can create more scripts, and keep it standard. Also, it is cheaper, because of witness discount, but the whole way of encrypting things first, executing them in encrypted form, getting needed proofs, and then decrypting and sending on-chain, is still the same.
5) You can use P2WPKH. Then, to make it standard, you can always use compressed public key.
6) You can use P2TR. Then, you can prepare N-of-N multisig as a base, and then you can safely experiment with TapScript.

A lot of flexibility is needed, because people will not accept sidechains as a soft-fork, and because they should be upgradeable, when other features will be enabled on-chain. Also, it increases privacy, so it is a good thing to allow broadcasting all current standard scripts, because a no-fork way means that in the best case, nobody should exactly know, when it started, and if those things were active in the past. For example, what if there were active sidechains, and if some users joined them, and then all of them moved their coins back to the mainchain or lost them? If possible, the starting point should be unknown, and it should remain as "always was possible, always was active, since 2009". I think that kind of sidechain will have no Genesis Block, it could always start earlier than all nodes assume, but all proofs were simplified into OP_TRUE and discarded.

The crucial part where I fail to see a solution using Bitcoin Script is the penalty mechanism.

Look at Drivechain proposal, and try to figure it out, how sidechain miners can always steal funds by constantly signalling the wrong state of the sidechain, continuously for many months. If you compare LN user broadcasting some previous closing transaction, with sidechain user doing the same, it looks very similar. The main difference is timing: in LN it could be two weeks, in sidechains it could be three months.

In an "open" sidechain, where you transact directly with all users, it can't be like with Lightning, because you're not updating a state with a single multisig partner and could thus invalidate previous states like in LN.

Why not? On-chain interactions are prepared in advance. It is not like in LN, where you can open a channel instantly with anyone. Here, in sidechains, on-chain updates can happen only from time to time, it was proposed to happen every three months. So, if you have on-chain coins now, and want to move them into the sidechain, you join a larger group by connecting to the sidechain network, and adding your signature. It will not be instantly visible on-chain as a new transaction with zero confirmations. It will go through a long batching process, and will be finally published as a single, large, on-chain transaction, where many coins will be pegged in, many coins will be pegged out, and a single sidechain output will represent those who will stay inside the sidechain. Also note that if you choose Taproot, then signatures can be batched, so a single signature can represent many users. And note that things will be executed in encrypted form, so you will not know exactly, how many people are inside, because nodes can reveal proofs provided by other nodes, and because partial scripts that will evaluate into OP_TRUE can be discarded. Also, only some users will go through this on-chain process, because most will use swaps.

I also looked at an "overcollaterized sidechain" model, where extra funds for penalties are required in addition to the funds used for peg-ins, but this didn't solve my problem - to ensure, via a mainchain contract, that only the last person in a chain of payments can peg-out (and previous intents are properly penalized).

If you have a CoinJoin transaction, then what is the cost to penalize misbehaving node? There is a choice between time-based cost, and satoshi-based cost. I think sidechains will reach some equilibrium somewhere in the middle, because using coins is one way, but you can use less coins if you want to wait longer. I don't know exactly how large will be sidechain transactions, and how many signatures will be joined in a multisig, or how many coins will be allocated for penalties, it has to be tested in practice.

This of course has the disadvantage that the sidechain cannot "onboard" new participants who never used Bitcoin, all have to have funds locked on the mainchain, otherwise the penalty mechanism would not work.

Why not? If that penalty will be satoshi-based, then it can affect those who have some satoshis. But for those who don't, there is still a time-based penalty. For example, I can safely sign a transaction that will give you all my coins, and will be valid after 10 years. Because I am almost 100% sure that I will move those coins by then, and the transaction I gave you will be invalid, when that timelock will expire.

So yes, you can send someone some coins inside the sidechain, when that person will have no on-chain coins. They will be quickly valid inside the sidechain, but to get any mainchain coins, that person will need to go through peg out, that is difficult, it consumes a lot of time, and then sidechain miners will have a lot of time to get all of those coins from that person.

There is no contract condition I can imagine that only Dave can fulfill (the last participant of the chain) but not Bob (intermediate) nor Alice (always talking about Bitcoin Script).

You assume that earlier participants know the script that was used, and you assume that they have all needed keys, so they can move those funds alone. There is no need to strictly require that. Because to make it generic enough, it is needed to accept things in a form they exist on the sidechain. So, Alice joining the sidechain from the mainchain directly is not the only use case. Another valid way is to leave one sidechain, and join another sidechain. As long as proofs are compatible, they can be accepted. So, if Alice can provide a proof that she is going to leave sidechain A, and join sidechain B, then Bob from sidechain B can check that proof, and accept it. Also, proofs from other kinds of swaps can be accepted, so a swap can be batched into the sidechain transaction, that will be finally visible on-chain. There are many possibilities, someone going from LN into the sidechain by forming a different channel closing transaction is also an option.

You can't prevent someone who wants to steal coins convincing him that there is some way to peg-out "faster".

You also cannot prevent some malicious miner who wants to steal coins, convincing him that mining on top of some earlier block is not going to work. And you cannot prevent some LN user from broadcasting some earlier closing channel transaction. All systems have their assumptions: Bitcoin assumes that the heaviest Proof of Work chain is formed by honest nodes, break that assumption, and Bitcoin no longer works. LN assumes that the honest participants will grab the coins, before expiration of the timelock of some earlier closing channel transaction. And sidechains assume that their users will inform the mainchain with sufficient proofs about the correct state of the sidechain, before the thief will grab those on-chain coins (but again: assume that someone created a malicious Drivechain, and read what Paul Sztorc said about sidechain miners stealing those coins).

Again, how exactly would this penalty mechanism work?

1) Alice will encrypt her penalty transaction, and send to the sidechain, with sufficient proofs.
2) Malice will send some earlier transaction, trying to steal the coins.
3) Every sidechain user will have a proof that Malice published transaction that should be invalidated.
4) Only if absolutely no sidechain user will react, or if all Bitcoin miners will decide to accept malicious transaction, those funds can be stolen.

Wouldn't that mean that payments could only be done between of the members of this multisig contract?

No, it only means that their action is needed to initiate it, but later it can be passed to anyone. If someone will decide to leave the sidechain, then that transaction will be a typical Bitcoin transaction, so it can contain any outputs. If you have Alice and Bob in transaction input, you can still have Charlie in transaction output. Also, if Dave wants to join the sidechain, while Charlie wants to leave it, then Dave will provide some on-chain transaction input, that can be used to create transaction output for Charlie. In the end, everything will be batched, so all sidechain interactions can be cut-through in the final on-chain transaction.

You're right, this is not the same thing as a federation, but it's quite similar in that only the users participating in this multisig contract have control over peg-outs.

Not only, because people entering the sidechain can also provide their inputs, so those who want to exit, can use those coins.

[d5000]

Thanks for your long response, I have not forgot this discussion And even if I may sound sceptic I would love to see this implemented if it works.

I am still however struggling with understanding still some basic concepts of your sidechain. Maybe I'm too dumb for it If you have detailed the general concept in a whitepaper or on a website (apart from the bitcoin-dev posts which I already read) it would be helpful if you provide a link ... (It would also be cool if someone with more cryptography knowledge could comment on this).

In the meantime I have read two concepts of sidechains which are an improvement on federated sidechains but still not completely decentralized (and unfortunately rely on premined sidechain altcoins, so they would probably not convince a large part of the Bitcoin user base):

- Nomic
- Stacks (formerly Blockstack)

Both employ a kind of "dynamic" federation where thanks to Taproot the federation can consist of hundreds of multisig partipants, and federation members can change in regular intervals.

Is it possible that there are some similarities between what you've in mind and these models?

My general understanding of your sidechain concept, according to my interpretation of your answers, is this:

1) it is initiated often by some multisig contract between a subset of the later participants, but they don't constitute a "static" federation. (There is however "no strict way" to initiate a peg-in.)
2) Peg-ins and peg-outs occur in batches in regular, but relatively long intervals (e.g. 3 months), if new participants provide mainchain inputs (which can be used for penalties and/or new funds) or inputs from other sidechains. (may be similar to the "dynamic federations" of the Stacks/Nomic concepts).
3) Peg-ins use advanced (e.g. homomorphic) encryption techniques to calculate the output scripts and the needed keys to move the attached coins/utxos for the "last mainchain transaction" (i.e. the part of the peg-in residing on the mainchain) which can provide some security for the case 4, in cooperation with miners.
4) if there is a wrongful peg-out attempt of a cheater ("Malice") who wants to peg-out with an earlier sidechain state, then all sidechain users who have observed a later (regular) state of the sidechain can provide a proof that this state exists, and overrule "Malice's" peg-out. (quite similar to the Optimistic rollup approach).
5) Bitcoin Miners participate in the control of the peg-outs.

I may have later some comments about your answers in the latest post, but I first want to ensure that the understanding of your concept is correct.

[vjudeu]

If you have detailed the general concept in a whitepaper or on a website (apart from the bitcoin-dev posts which I already read) it would be helpful if you provide a link

The general concept is very simple: if you have on-chain coins, you can move them to the sidechain by signing them. And if you move them on the mainchain, then they are removed from the sidechain.

This general concept is enough to create any sidechain-based test network. You want to get some test coins? Just sign them, and you will get sidechain coins. Then, if you move them on-chain, they will be removed from the sidechain, and then new sidechain users could skip them entirely during initial sidechain download.

And then, everything else is about making things safe to use if there are more users, and if coins are not worthless, like in testnet.

Is it possible that there are some similarities between what you've in mind and these models?

It depends. Because if those proposals require any kind of soft-fork, then there is a high chance that they will be rejected. The only way we could have sidechains activated by some kind of soft-fork is when other features will be introduced, and then sidechains will be enabled as a side-effect (in a similar way as NFTs were activated as a side-effect of Taproot, for example people could introduce new sighashes, and then they will notice after activation that it can be also used to activate sidechains). Because some users don't want to create any strong link between Bitcoin and altcoins, and sidechains can provide that, no matter which proposal will be chosen. Also, introducing sidechains is that kind of change, which could be the last soft-fork we will ever need, because since then, all other features can be turned on and off, without any need to create another soft-fork for that.

1) it is initiated often by some multisig contract between a subset of the later participants, but they don't constitute a "static" federation. (There is however "no strict way" to initiate a peg-in.)

Yes, because multisig is the simplest thing you can do, to avoid loss of funds. If you have N people, then N-of-N multisig will guarantee that if you will use some wrong script, that will be unspendable, then you can always contact with everyone, and reach a signature that will allow moving those coins. So, using multisig as a base is highly recommended, even if your plan is to use custom scripts. However, allowing peg-ins from any scripts is also needed, because people should be able to test those features alone, and because by doing that, people can check, what kind of output is the most popular, and increase their privacy by using the same address types (in a similar way as Tor Browser picked Firefox for Windows, to hide the real User Agent behind the most popular choice).

2) Peg-ins and peg-outs occur in batches in regular, but relatively long intervals (e.g. 3 months), if new participants provide mainchain inputs (which can be used for penalties and/or new funds) or inputs from other sidechains. (may be similar to the "dynamic federations" of the Stacks/Nomic concepts).

Yes. Also note that a single transaction can be used for many peg-ins and peg-outs at the same time (it is similar to coinjoin in this case, if something will fail, then the new state will not be reached). Some users provide their inputs, others provide their outputs, and a single sidechain UTXO can be moved from one address to another, to commit that state to the mainchain, and that will make things harder to reverse later (because then, reorging the sidechain behind that point will require reorging the Bitcoin blockchain).

3) Peg-ins use advanced (e.g. homomorphic) encryption techniques to calculate the output scripts and the needed keys to move the attached coins/utxos for the "last mainchain transaction" (i.e. the part of the peg-in residing on the mainchain) which can provide some security for the case 4, in cooperation with miners.

Yes, peg-ins are encrypted, there is a proof that your signature is attached to some existing mainchain coins, but all things cannot be revealed, because then anyone could connect to the sidechain network, and push everything on-chain, and then the whole point of using sidechains is destroyed if things will not be batched.

4) if there is a wrongful peg-out attempt of a cheater ("Malice") who wants to peg-out with an earlier sidechain state, then all sidechain users who have observed a later (regular) state of the sidechain can provide a proof that this state exists, and overrule "Malice's" peg-out. (quite similar to the Optimistic rollup approach).

Yes. Cheating is hard, because you cannot instantly move your coins on-chain. It is like leaving LN channel alone: possible, but hard to do, and it is better to cooperate with the network. Also, because things have to be batched in advance, you cannot just leave the sidechain alone, and be unnoticed. Sidechain full nodes can track all penalties, so a single honest node can simply check if someone tried to move those coins, and then a single honest node can act as a global watchtower.

5) Bitcoin Miners participate in the control of the peg-outs.

It depends. If some miner is not attached to the sidechain, then that miner knows nothing about the state of the sidechain. But there are sidechain miners, that can use Merged Mining, and protect sidechain from chain reorganizations. Miners are needed, because without them, new users joining the sidechain will have no idea, what happened in the meantime, and which sidechain history is correct. So, sidechain miners participate in transaction batching, and they are those who can mine mainchain and sidechain, using the same amount of work, and they put things in the right order. If their power is sufficient, then they can mine mainchain blocks, and get fees from the sidechain, and from the mainchain. If not, then they can get only sidechain fees, gained from batching, in a similar way as LN nodes are rewarded.

I may have later some comments about your answers in the latest post, but I first want to ensure that the understanding of your concept is correct.

Mostly yes, the basic concept is quite simple, and I think it will not change: signing is enough to create coins on sidechains, and moving them on the mainchain is enough to bring them back. This is the fundamental concept, and everything else is about making things safe beyond some test network. Because that concept alone should be sufficient to test sidechains, you can just sign your coins alone, then test all sidechain features you want, and then, after testing, you can safely move your coins on-chain, then nobody else will ever need to download those historical sidechain transactions.

Since then, I think about putting my theory into practice. The basic concept shows us how sidechains could be introduced in a no-fork way, when all soft-fork proposals will be rejected, one-by-one. I assume people won't accept soft-forks for sidechains, because then it will be the last soft-fork, and because it could have undesired side-effects, so sidechain enthusiasts will not reach consensus in this case. And then, the hardest part is making things safe enough, so that I, as a sidechain user, could accept someone else's proof, and be convinced enough, that such person cannot simply move those coins alone.

And even if I may sound sceptic I would love to see this implemented if it works.

I am also quite skeptical, because I can still see some problems in the details, for that reason you cannot see some working examples yet, because I don't want to release a system, where I could still find ways to break it. However, I am pretty sure that it is possible to build a working system on top of this basic concept. I am 100% sure that building such testnet is possible, but then, building a mainnet is needed, and things should be mature enough when publicly released (because I don't want to release some half-baked code, and see some altcoin that will start doing it in a wrong way on the mainnet, and will discourage people from sidechains).

Also, I will look at some other proposals, then maybe some of my problems could be solved. Because things evolved over time, when I thought about it for the first time, I didn't think about Taproot, and there were issues related to large multisigs, but since we have Schnorr signatures, it can be easily solved. So, there is a chance that some details related to storing things on the sidechain will change, but the main idea of signing coins to create them, and moving them on the mainchain to remove them, will probably remain unchanged.

[garlonicon]

The general concept is very simple: if you have on-chain coins, you can move them to the sidechain by signing them. And if you move them on the mainchain, then they are removed from the sidechain.

Recently, I read something similar about BitDNS: https://bitcointalk.org/index.php?topic=1790.msg28917#msg28917

If you're still worried about it, it's cryptographically possible to make a risk free trade.  The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both.  The second signer can't release one without releasing the other.

If I understand it correctly, we will have two or more signatures on the mainchain (except solo testing by single users). And then, "the second signer's signature triggers the release of both" seems to be true in that case: if the last signature will be released on the sidechain, then it will burn those sidechain coins, and will be automatically propagated to the mainnet by any node. And if it will be released on the mainchain, then it will be observed by all sidechain nodes, so they will instantly fetch it, and act in the same way, by burning those sidechain coins.

So, even if we don't have OP_CHECKDATASIG or similar things on the mainchain, then still, if all sidechains will observe the mainchain, we will reach that feature indirectly (because then, sidechain coins would be effectively locked with OP_CHECKDATASIG, limited to the mainchain, instead of OP_CHECKSIG, which would be valid only on the sidechain). I also wonder if using sidechains as a "global watchtower" can enable other features, like automatically executed contracts (because then, by manipulating the conditions for decrypting and releasing some penalty transaction, it is possible to enforce other things, and probably push any transaction, not only related to getting coins from some attacker).

In the meantime I have read two concepts of sidechains which are an improvement on federated sidechains but still not completely decentralized (and unfortunately rely on premined sidechain altcoins, so they would probably not convince a large part of the Bitcoin user base):

I added my comment to one of those proposals, maybe I will check the second one later: https://gist.github.com/mappum/da11e37f4e90891642a52621594d03f6?permalink_comment_id=4487165#gistcomment-4487165

[internetional]

Would it be possible to run DAG-like chains as Bitcoin sidechains with BIP-300 and BIP-301 implemented? On drivechain.info, Paul says about different possible things like PoS etc., but not about DAG.

[vjudeu]

Would it be possible to run DAG-like chains as Bitcoin sidechains with BIP-300 and BIP-301 implemented?

It is possible here and now, without those BIPs. If I understand correctly, DAG means Directed Acyclic Graph. If so, then look at transactions, and try to represent inputs and outputs in a graph. Voila, you have a DAG. Not to mention that TapScript itself can represent it as well inside MAST.

On drivechain.info, Paul says about different possible things like PoS etc., but not about DAG.

If you want Proof of Stake, then it is possible here and now. Take signet for example. It can be fully connected with mainchain, all you need is just taking those signet challenges, and place them inside transaction outputs. In general, if you have any altcoin, that is here and now a federation, then you can have 1:1 peg with Bitcoin, without any soft-forks.

Also, that question reminds me about this topic, and my answer, that is also applicable here: https://bitcointalk.org/index.php?topic=5452759.0

Technically, you can do that. Even more: you can go far beyond that. I think we are lucky that most people don't know, how many things are possible...

[garlonicon]

What about creating a separate chain, that will be used to peg coins in and out, and will have its own blockchain, outside Bitcoin? In that case, Bitcoin could be just one of the sidechains, instead of being the central point, where other sidechains are created.

I guess that approach will lead us faster to some working implementation, because creating some soft-fork, or no-fork, to peg things into Bitcoin, would probably be too controversial to be merged.

So: the new chain could start with zero coins, and could have consensus rules to allow tracing other blockchains, and creating pegs, but that chain will create no new tokens by itself. We don't need more coins, we need more functionalities.

[d5000]

What about creating a separate chain, that will be used to peg coins in and out, and will have its own blockchain, outside Bitcoin? In that case, Bitcoin could be just one of the sidechains, instead of being the central point, where other sidechains are created.

This could of course be possible, I have also heard proposals about such a "metachain", but the problem of the peg between Bitcoin and the new "main chain", or other chains, would remain.

If we want the Bitcoin to be moved to a sidechain for scalability reasons, i.e. have a token on any chain which has exactly the same value than 1 BTC to be able to make payments without congesting the BTC chain, then we must have a mechanism to block Bitcoins on the Bitcoin chain, and be moved if a very specific set of requirements is fulfilled. And that is the central problem as far as I understand, we need mechanisms such as covenants which are controversial in the developer community. Or rely on multisig-based techniques like on Nomic (which already exists but is semi-centralized; I'm of course ignoring traditional federated chains here). A metachain wouldn't change that.

In addition, a metachain without any tokens would be difficult - how would you create consensus without having any monetary incentives to maintain it? I see more chances if an already existing altcoin (for example LTC) could implement a mechanism like Drivechain. Of course EVM chains provide already some sidechain capabilities (Optimism, Polygon ...) but no one I've heard of is really decentralized.

[garlonicon]

but the problem of the peg between Bitcoin and the new "main chain", or other chains, would remain

Why do you think so? It is just all about deploying existing Drivechain implementation on a different chain, that will initially have zero coins. Nothing else is really needed, because Proof of Work can be imported through Merged Mining (and Proof of Stake can be directly pegged here and now, just by sending coins to the addresses, owned by validators).

then we must have a mechanism to block Bitcoins on the Bitcoin chain, and be moved if a very specific set of requirements is fulfilled

Not necessarily. The only needed thing is to move coins on both chains simultaneously. Which means, on Bitcoin, you can have even P2PK, because it can be useful in some situations, and it will be more private.

This "very specific set of requirements" is just defined by the output Script. And if it is not sufficient, then guess what:
1) N-of-N multisig can be always used when needed.
2) Transactions can be encrypted with Homomorphic Encryption, and then processed on the sidechain in a new way.

how would you create consensus without having any monetary incentives to maintain it?

Sidechain can be pushed forward, by collecting commitments from other chains. Which means, the difficulty of the sidechain, will be equal to the combined difficulty of all chains in existence (they may be sorted by hash function, or in any other way).

I see more chances if an already existing altcoin (for example LTC) could implement a mechanism like Drivechain.

That would solve the problem only for this single altcoin, and Bitcoin, nothing else. But the area of similarity between altcoins is much wider, for example, there are not that many altcoins, which don't use secp256k1. I know the exact area of coverage should be examined individually in each case, but if sidechains will not be imported by any altcoin, then people should probably start thinking about a separate chain, designed specifically for that purpose.

Also, because this chain would produce no coins, it could be possible to "go back to zero" on a regular basis. Which means, that Initial Blockchain Download will not be a big deal, because coins can be pegged out, finalized on each chain, and we can start over, when the metachain will be too big. So, it would act like a trustless batching of the history, that would have to otherwise land on each individual chain.