Bitcoin Forum
October 22, 2017, 02:09:19 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Sidechains and malleability  (Read 604 times)
tomtomtom7
Jr. Member
*
Offline Offline

Activity: 38


View Profile
July 18, 2017, 09:32:29 AM
 #1

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

If so, why?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
skang
Sr. Member
****
Offline Offline

Activity: 451


from democracy to self-rule.


View Profile
July 18, 2017, 09:56:04 AM
 #2

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.

"India is the guru of the nations, the physician of the human soul in its profounder maladies; she is destined once more to remould the life of the world and restore the peace of the human spirit.
But Swaraj is the necessary condition of her work and before she can do the work, she must fulfil the condition."
tomtomtom7
Jr. Member
*
Offline Offline

Activity: 38


View Profile
July 18, 2017, 10:13:31 AM
 #3


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
Moderator
Legendary
*
qt
Offline Offline

Activity: 2324



View Profile
July 18, 2017, 06:28:25 PM
 #4

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.

Bitcoin will not be compromised
tomtomtom7
Jr. Member
*
Offline Offline

Activity: 38


View Profile
July 18, 2017, 08:51:33 PM
 #5

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
Full Member
***
Offline Offline

Activity: 218



View Profile
July 19, 2017, 08:17:26 AM
 #6

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?

▛ [ CENTRA ] Multi-Blockchain Worldwide Debit Card & Insured Wallet
▞▬▬▬▞▬▬▬▞▬▬▬▞▬▬▬▞▬▬▬▞▬▬▬▚▬▬▬▚▬▬▬▚▬▬▬▚▬▬▬▚▬▬▬▚
▙     FacebookSlackTwitterGithubMediumANN Thread     ▟
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2324



View Profile
July 19, 2017, 03:56:30 PM
 #7

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.

Bitcoin will not be compromised
TechPriest
Full Member
***
Offline Offline

Activity: 218



View Profile
July 19, 2017, 07:52:49 PM
 #8

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  Smiley 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  Wink

▛ [ CENTRA ] Multi-Blockchain Worldwide Debit Card & Insured Wallet
▞▬▬▬▞▬▬▬▞▬▬▬▞▬▬▬▞▬▬▬▞▬▬▬▚▬▬▬▚▬▬▬▚▬▬▬▚▬▬▬▚▬▬▬▚
▙     FacebookSlackTwitterGithubMediumANN Thread     ▟
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!