[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitcoin-ml
Subject:    [Bitcoin-ml] Transaction Malleabilily Fixes
From:       lvella () gmail ! com (Lucas Clemente Vella)
Date:       2017-11-13 18:16:12
Message-ID: CAGCathx=r176gBoSjq5cJeeg5_pNbVT1=43JtA3D8rjm6LiZKA () mail ! gmail ! com
[Download RAW message or body]

2017-11-13 15:59 GMT-02:00 Jared Lee Richardson <jaredr26 at gmail.com>:

> > And how transaction malleated by the signing party is worse from an
> ordinary double spend? It is only a bigger problem if any signer can do it
> independently from the other in a multisig transactions, is this the case?
> 
> Breaks Lightning's two way channels.  I'm not exactly sure of the
> reason - I know lightning maintains a huge tree of previous states and
> if a previously invalidated state gets mined, the lightning client
> must respond with the correctly signed invalidation transaction
> matching it, so perhaps it relates to that.
> 
> But there's got to be other use cases that haven't been invented yet.
> The fundamental property that makes lighting possible is that you
> create a series of signed transactions that each party can trustlessly
> rely on that don't need to be broadcast to the chain, possibly that
> never need to be broadcast to the chain.  To be able to do certain
> things with that concept, you need a way to guarantee that the
> transaction ID referencing the shared state between you doesn't
> change.
> 

That is what I understand as well. But unless your pair in the multisig
channel can unilaterally alter the signed transaction TXID, I don't see how
that is a problem. Can someone who understand better transaction
malleability and Lightning Networks can comment?

-- 
Lucas Clemente Vella
lvella at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171113/deac51a3/attachment.html>



[prev in list] [next in list] [prev in thread] [next in thread]