<p>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.</p>

<p>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.</p>

<p>A more thorough explanation can be found <a href="https://21.co/learn/intro-to-micropayment-channels/" rel="nofollow">here</a>.</p>

CC BY-SA 3.0
2016-09-01T10:05:44.097Z
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
CC BY-SA 3.0
2016-09-01T13:51:00.303Z
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
CC BY-SA 3.0
2016-09-01T18:10:36.470Z
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
CC BY-SA 3.0
2016-09-01T18:29:59.403Z
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
CC BY-SA 3.0
2016-09-01T21:54:08.457Z
But if the funding transactions are confirmed, how can they still be amended (and their hashes changed)? How can a malleability attack take place after the funding transactions are confirmed (I have the MPC in mind)?
hartmut
CC BY-SA 3.0
2016-09-02T00:56:23.237Z
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
CC BY-SA 3.0
2016-08-31T21:56:02.840Z
2016-08-31T21:56:02.840Z
Jimmy Song
<p>Micropayment Channels (MPC) cannot be used currently because of transaction malleability, I hear. </p>

<p>AFAIK, people saying that have in mind that the refund &amp; 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. </p>

<p>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? </p>

<p>Is the following correct:</p>

<p><strong>whenever malleability attacks are possible, then so is double-spend attack.</strong> 
?</p>

<p>Thanks</p>

<doublespend><transaction-malleability><micropaymentchannels>
why is double-spend not an issue for payment channels?
hartmut
# why is double-spend not an issue for payment channels?

(Asked by: username_0 on 2016-08-31)

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

**Tags:** doublespend, transaction-malleability, micropaymentchannels


---

## 1 answers

### Answer by username_1 on 2016-08-31. Score: 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](https://21.co/learn/intro-to-micropayment-channels/).

> **Comments:**
> **username_0**: 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?  
> **username_1**: 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.  
> **username_0**: 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?  
> **username_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.  
> **username_0**: But if the funding transactions are confirmed, how can they still be amended (and their hashes changed)? How can a malleability attack take place after the funding transactions are confirmed (I have the MPC in mind)?  
> **username_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.  

---

