2

Micropayment Channels (MPC) cannot be used currently because of transaction malleability, I hear.

AFAIK, people saying that have in mind that the refund & payment tx, which have as input the deposit tx (Dtx), could be invalid if the deposit's hash was changed. I m fine with this.

What I don't understand: if the attacker manages to modify Dtx' hash before it made it to the blockchain, I believe (s)he can equally manage to double spend the btcs supposed to go to Dtx. Thus, double spend seems as much a threat as malleability. Yet no one discusses it, so I suppose something is wrong with this reasoning. What?

Is the following correct:

whenever malleability attacks are possible, then so is double-spend attack. ?

Thanks

Improve this question

1 Answer 1

Reset to default
1

Great question. In order to understand how it works, you have to understand that opening a micro-payment channel (MPC) requires a commitment before you get started. That is, both parties have to show proof that they can't double-spend these transactions before they get started.

How is this possible? SCRIPT, of course. A transaction (2-of-2 output) that's dependent on other transactions is signed first, which opens up the MPC, and then, and only then, do both parties release the transactions that would make this other transaction valid. At that point, the funds are committed to the channel and cannot be double-spent since it's locked in a 2-of-2 output, which must be signed by both parties, hence eliminating the possibility of a double-spend.

A more thorough explanation can be found here.

Improve this answer
6
  • Thanks for this answer. I know the link you mentioned, it is helpful but things still arent 100 % clear to me. If by "the funds are committed to the channel" you mean the Deposit tx has made it to the blockchain, then this tx is not subject to malleability anymore. Yet if it has'nt and malleability is an issue, then double-spend seems to be just as possible as malleabiity to me. So why is the latter discussed while the former is not even mentionned?
    – hartmut
    Sep 1, 2016 at 10:05
  • A double-spend on the funding tx's would mean the channel never opens. There's no danger for either party since they then essentially signed an invalid commitment transaction which would never make it into the blockchain in the first place.
    – Jimmy Song
    Sep 1, 2016 at 13:51
  • hmm.. thanks... sorry to labor the point but: say Alice sells a streaming service to Bob and they use MPC. If they don't wait, then the transaction that funds the channel could be double spent by Bob. Then Alice will have sold streaming and not received bitcoins (classic double spend attack in zero-confirmation transactions). (and of course, If Bob does not double-spend, he can still use malleability). Say they decide to wait until the Deposit tx makes it to the chain, no double spending / malleability attack is possible. My point: malleability AND double spend || neither nor. Is this correct?
    – hartmut
    Sep 1, 2016 at 18:10
  • 1
    When establishing a MPC, you don't "buy" or "sell" anything until the funding transactions are confirmed. At that point, you pay for some small amount of service in a pay-as-you-go fashion. If the funding transaction doesn't confirm, you don't buy or sell the service. The ordering of what happens when is very important and eliminates the possibility that you can grab both the service and the cash except in tiny increments.
    – Jimmy Song
    Sep 1, 2016 at 18:29
  • 1
    Once the funding transactions are confirmed, there is no malleability attack. The malleability attack happens while the funding transactions are going into a block. It's possible for a malicious node to change the tx hash, making the commit transaction invalid. Once confirmed, the MPC works fine.
    – Jimmy Song
    Sep 2, 2016 at 0:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.