Sidechains and malleability

[tomtomtom7]

Are there any sidechain ideas or proposals that depend on the ability to create non-malleable transactions?

If so, why?

[1715574674]

1715574674

[1715574674]

1715574674

[1715574674]

1715574674

[skang]

Are there any sidechain ideas or proposals that depend on the ability to create non-malleable transactions?

If so, why?

Because to peg a sidechain to the mainchain, someone, centralised or in a decentralised manner, must verify that transaction met some conditions (e.g.,to lock the coins on mainchain and is certain levels deep). If the transaction is malleable, it is difficult to programatically achieve this since txid could change. I think depending on the design of the sidechain, this can be taken care of, BUT although the solution might be programmable, it would most probably be centralised.

[tomtomtom7]

Because to peg a sidechain to the mainchain, someone, centralised or in a decentralised manner, must verify that transaction met some conditions (e.g.,to lock the coins on mainchain and is certain levels deep). If the transaction is malleable, it is difficult to programatically achieve this since txid could change. I think depending on the design of the sidechain, this can be taken care of, BUT although the solution might be programmable, it would most probably be centralised.

But the transaction is no longer malleable when it is on chain. Are you referring to a sidechain design which relies on maintaining off-chain pegging transactions? And if so, who maintains it? Do you have any references for such design?

[gmaxwell]

Are there any sidechain ideas or proposals that depend on the ability to create non-malleable transactions?

Nope. Malleability isn't an issue for well confirmed transactions, which is all that any sidechains proposals work with-- often 100 blocks or more. But that hasn't stopped people you associate with from dishonestly claiming that segwit exists to enable sidechains. I doubt having this further confirmed will suddenly spur you on to calling out their incorrect claims, since you don't for anything else.

[tomtomtom7]

Are there any sidechain ideas or proposals that depend on the ability to create non-malleable transactions?

Nope. Malleability isn't an issue for well confirmed transactions, which is all that any sidechains proposals work with-- often 100 blocks or more. But that hasn't stopped people you associate with from dishonestly claiming that segwit exists to enable sidechains. I doubt having this further confirmed will suddenly spur you on to calling out their incorrect claims, since you don't for anything else.

That is also what I thought. I am sorry if I am not calling people out. That is not my purpose.

I asked this because I was curious whether any connection between the two was defensible because that seemed unlikely to me.

I am not going to "call people out" and I do not understand why you expect me to or why you seem to have problems with me not doing so.

[TechPriest]

Nope. Malleability isn't an issue for well confirmed transactions, which is all that any sidechains proposals work with-- often 100 blocks or more.

Why malleability is still problem in someone opinion? Through it we can change only TXID of transaction not her outputs or inputs. After some time wallet will show this transaction with new TXID. So, what a problem?

[gmaxwell]

Why malleability is still problem in someone opinion? Through it we can change only TXID of transaction not her outputs or inputs. After some time wallet will show this transaction with new TXID. So, what a problem?

There are many problems because people do more with unconfirmed transactions then send them and wait for them to confirm before doing anything else.

For example, you may want to spend the change resulting from an unconfined transaction-- so that the rest of your coins are not held hostage until the next block-- but if the transaction ID is changed the child transactions are invalidated. You couldn't even reissue the replacement until you come back online and learn the new ID, and then imagine that the private keys are kept offline in a safe.

If you make only the most boring kinds of transactions, never deal with anything unconfirmed (including making more payments until confirmation, or replacing transactions) and use carefully and competently written wallet software then malleability is at worst a minor nuisance.  If you are trying to do anything fancy with smart contracts, unconfirmed transactions (including just chaining them), or are _writing_ wallet software that has to handle malleation happening, then it's a burden and footgun.  

CLTV and CSV were introduced to recover some of the worst of the damage done by malleability-- without them you couldn't safely do multiparty escrows with timeouts... but even with them the fact that malleation invalidates subsequent spends makes life hard in many ways.

You can also think of it as changing the outputs: an output  is a txid, index, scriptPubkey, and an amount.  The malleation doesn't change the index, pubkey, or amount... but it does change the txid of the output; and this is precisely the problem that segwit solves.

[TechPriest]

There are many problems because people do more with unconfirmed transactions then send them and wait for them to confirm before doing anything else.

Why it's problem?
I send transaction 1 from address 2. So, before transaction will be confirmed (or deleted from mempool) i can't do anything with this address (except my wallet has opportunity to spend unconfirmed change). But i can to use another addresses.
Problem could happen only if i try to spend outputs of transaction 1 while it uncofirmed.

For example, you may want to spend the change resulting from an unconfined transaction-- so that the rest of your coins are not held hostage until the next block-- but if the transaction ID is changed the child transactions are invalidated. You couldn't even reissue the replacement until you come back online and learn the new ID, and then imagine that the private keys are kept offline in a safe.

Yes, i know about it. But in new wallets like Electrum or blockchain info it isn't a problem. After confirmation wallet will show new TXID.

If you make only the most boring kinds of transactions, never deal with anything unconfirmed (including making more payments until confirmation, or replacing transactions) and use carefully and competently written wallet software then malleability is at worst a minor nuisance.  If you are trying to do anything fancy with smart contracts, unconfirmed transactions (including just chaining them), or are _writing_ wallet software that has to handle malleation happening, then it's a burden and footgun.  

CLTV and CSV were introduced to recover some of the worst of the damage done by malleability-- without them you couldn't safely do multiparty escrows with timeouts... but even with them the fact that malleation invalidates subsequent spends makes life hard in many ways.

Of course i talk about bitcoin, not Ethereum network and smart contracts 'cause i know too few about them   Thank you for information.

You can also think of it as changing the outputs: an output  is a txid, index, scriptPubkey, and an amount.  The malleation doesn't change the index, pubkey, or amount... but it does change the txid of the output; and this is precisely the problem that segwit solves.

I know it, but changed TXID it's not a big problem for people who have patience and some technical skills