<p>In order to create an input, you need to be able to prove that you have the right to spend the those coins, usually by possessing the corresponding private key for their address.</p>

<blockquote>
  <p>For example, suppose Alice has a coin of value 50 and spends 100, while Bob has a coin of value 100 and spends 50. Both of these are in the same transaction.</p>
</blockquote>

<p>To make a transaction as you describe, both Alice and Bob's private keys must be available at the same time. This is conceptually equivalent to Alice and Bob using the same wallet. In practice, Alice and Bob would have to use seperate transactions if their wallets were different.</p>

CC BY-SA 3.0
2017-11-13T15:51:41.750Z
Yes, both Alice and Bob's private keys are used to create the respective signatures. For example, Alice can use her private key to create the signature, send the corresponding input and output to Bob, and then Bob completes creation of the transaction by creating signatures for his input and output coins.

Are you saying that this is a possible exploit in theory, but implementation-wise we disallow this because a single transaction must use input addresses from a single wallet?
simpleton
CC BY-SA 3.0
2017-11-13T15:54:46.517Z
That's not possible while keeping the keys secret. The author of the transaction must know all the keys. So in your example, Alice and Bob are the same person. You can't create a single transaction containing different people's keys.
Adam Millerchip
CC BY-SA 3.0
2017-11-13T15:59:58.777Z
Sorry I pressed enter and accidentally sent my reply before it was complete.

In my updated reply, I described a way to collude and construct such a transaction without leaking private keys. Is there anything in the protocols or validations that disallow this?
simpleton
CC BY-SA 3.0
2017-11-13T16:08:46.750Z
Yes I hadn't noticed your edit. I'm not completely sure if what you describe regarding sharing the signature is possible, but since we're talking theoretically let's assume it is. The result of creating such a transaction would be that 50 of Bob's coins are used to pay Alice's benefactor. A transaction works by summing the inputs then distributing to the outputs. The spending signature does not specify the output destination, that is defined at the transaction level. Bob would have to create this transaction, and has no motivation to do so.
Adam Millerchip
CC BY-SA 3.0
2017-11-13T16:19:27.177Z
So I guess this is possible? I agree there may be little motivation. I was thinking that maybe due to outside forces Alice and Bob are prohibited from sending money to each other and this allows them to hide the fact. Then again, I just realized there are several other ways for Alice and Bob to achieve the same objective.

Thank you for the discussion!
simpleton
CC BY-SA 3.0
2017-11-13T13:54:10.177Z
2017-11-13T13:54:10.177Z
Adam Millerchip
<p>It doesn't matter whose coins are funding (inputs) for the transaction the validation check still works.</p>

<blockquote>
  <p>(sum of input values) - (sum of output values) >= 0</p>
</blockquote>

<p>There's nothing that states sum of input values on a per user basis. As long as the total value of the inputs, no matter who or where they come from, exceeds or equals the total value of the outputs the transaction passes the check.</p>

<p><strong>Update</strong>: It's not an exploit. Each transaction input is treated separately and the condition to spend each input must be met separately. If Alice supplies an input tx then she'll also have to supply a scriptSig for that single input to prove she's entitled to spend it. Likewise with Bob's transaction, he'll have to supply a completely separate scriptSig that proves he's entitled to spend his input transaction.</p>

<p>Alice can't spend Bob's transaction and vice-versa (unless it's a multisig, spend by anyone etc) no matter how they are combined as inputs.</p>

CC BY-SA 3.0
2017-11-13T12:34:52.027Z
Yes, I am asking why the validation is designed this way and whether this can be exploited. And I gave an example of a possible exploitation (or maybe this is not considered an exploitation).
simpleton
CC BY-SA 3.0
2017-11-13T15:49:22.777Z
Reply to update: I believe a single transaction can contain multiple inputs and multiple outputs. See https://en.bitcoin.it/wiki/Transaction#Explanation. Each input has its own separate signature and the validation condition is applied to all inputs and all outputs. Thus, unless I am missing something it seems to me that I can construct such a transaction and make the network accept it.
simpleton
CC BY-SA 3.0
2017-11-13T12:18:51.643Z
2017-11-13T13:03:02.267Z
2017-11-13T13:03:02.267Z
sipsorcery
<p>Your misunderstanding is here:</p>

<blockquote>
  <p>For example, suppose Alice has a coin of value 50 and spends 100, while Bob has a coin of value 100 and spends 50. </p>
</blockquote>

<p>That is not possible. When an output is spent by an input, it is always spent entirely. You don't get to say how much of that output is left in place - the amount you are getting from that input is exactly the amount created by the previous amount.</p>

<p>If Bob has a coin of value 100, and only wants to spend 50, all he can do is spent his coin of 100, and add an extra output to the transaction that sends 50 back to himself (typically to a new address of his, for privacy reasons).</p>

CC BY-SA 3.0
2017-11-13T16:05:56.507Z
I wasn't clear. What I meant is.

Alice spends coin of 50, sends coin of value 100 to some address X.
Bob spends coin of 100, sends coin of value 50 to some address Y.

Both of these happen in the same transaction. Thus, in this transaction, we see inputs with value {50, 100}, and outputs with value {50, 100}.
simpleton
CC BY-SA 3.0
2017-11-13T16:07:42.760Z
What you meant is what?
Pieter Wuille
CC BY-SA 3.0
2017-11-13T15:38:32.730Z
2017-11-13T15:38:32.730Z
Pieter Wuille
<p>In the Coursera course "Bitcoin and Cryptocurrency Technologies" course, a coin called ScroogeCoin was introduced. </p>

<p>This coin is similar to bitcoin in that each transaction consists of a set of inputs and outputs. Inputs point to outputs from previous transactions with corresponding signatures, and outputs contain the value and address the value is applied to.</p>

<p>The protocol checks that (sum of input values) - (sum of output values) >= 0, and this difference is the transaction fee. </p>

<p>I feel that this condition is too loose and there may be a potential problem. For example, suppose Alice has a coin of value 50 and spends 100, while Bob has a coin of value 100 and spends 50. Both of these are in the same transaction. Then the protocol would allow this to pass. </p>

<p>I feel that the protocol should check instead</p>

<p>For all addresses, (sum of input values from address) - (sum of output values that is spending from address) >= 0</p>

<p>This is because the original protocol allows spending from someone else's address. This sounds like something that can be exploited e.g. an implicit money transfer from Bob to Alice is hidden. We can assume Alice and Bob are colluding to achieve this.</p>

<p>Is this benign?</p>

CC BY-SA 3.0
2017-11-13T13:58:32.167Z
I don't think I really understand what you are concerned about.  As long as Alice and Bob both consent to the spending of their coins, then there is no problem, right?  Are you worried that the rest of the network can't tell how Alice's and Bob's coins were allocated between the two outputs?  Well, why should they be able to tell?  It isn't anyone's business except Alice and Bob's.
Nate Eldredge
<transactions><transaction-verification>
Bitcoin Transaction Protocol Question (maybe specific to Coursera Bitcoin Lecture)
simpleton
# Bitcoin Transaction Protocol Question (maybe specific to Coursera Bitcoin Lecture)

(Asked by: username_0 on 2017-11-13)

In the Coursera course "Bitcoin and Cryptocurrency Technologies" course, a coin called ScroogeCoin was introduced.

This coin is similar to bitcoin in that each transaction consists of a set of inputs and outputs. Inputs point to outputs from previous transactions with corresponding signatures, and outputs contain the value and address the value is applied to.

The protocol checks that (sum of input values) - (sum of output values) >= 0, and this difference is the transaction fee.

I feel that this condition is too loose and there may be a potential problem. For example, suppose Alice has a coin of value 50 and spends 100, while Bob has a coin of value 100 and spends 50. Both of these are in the same transaction. Then the protocol would allow this to pass.

I feel that the protocol should check instead

For all addresses, (sum of input values from address) - (sum of output values that is spending from address) >= 0

This is because the original protocol allows spending from someone else's address. This sounds like something that can be exploited e.g. an implicit money transfer from Bob to Alice is hidden. We can assume Alice and Bob are colluding to achieve this.

Is this benign?

**Tags:** transactions, transaction-verification

> **Comments:**
> **username_1**: I don't think I really understand what you are concerned about.  As long as Alice and Bob both consent to the spending of their coins, then there is no problem, right?  Are you worried that the rest of the network can't tell how Alice's and Bob's coins were allocated between the two outputs?  Well, why should they be able to tell?  It isn't anyone's business except Alice and Bob's.  

---

## 3 answers

### Answer by username_2 on 2017-11-13. Score: 0 | Accepted answer

In order to create an input, you need to be able to prove that you have the right to spend the those coins, usually by possessing the corresponding private key for their address.

> For example, suppose Alice has a coin of value 50 and spends 100, while Bob has a coin of value 100 and spends 50. Both of these are in the same transaction.

To make a transaction as you describe, both Alice and Bob's private keys must be available at the same time. This is conceptually equivalent to Alice and Bob using the same wallet. In practice, Alice and Bob would have to use seperate transactions if their wallets were different.

> **Comments:**
> **username_0**: Yes, both Alice and Bob's private keys are used to create the respective signatures. For example, Alice can use her private key to create the signature, send the corresponding input and output to Bob, and then Bob completes creation of the transaction by creating signatures for his input and output coins.  Are you saying that this is a possible exploit in theory, but implementation-wise we disallow this because a single transaction must use input addresses from a single wallet?  
> **username_2**: That's not possible while keeping the keys secret. The author of the transaction must know all the keys. So in your example, Alice and Bob are the same person. You can't create a single transaction containing different people's keys.  
> **username_0**: Sorry I pressed enter and accidentally sent my reply before it was complete.  In my updated reply, I described a way to collude and construct such a transaction without leaking private keys. Is there anything in the protocols or validations that disallow this?  
> **username_2**: Yes I hadn't noticed your edit. I'm not completely sure if what you describe regarding sharing the signature is possible, but since we're talking theoretically let's assume it is. The result of creating such a transaction would be that 50 of Bob's coins are used to pay Alice's benefactor. A transaction works by summing the inputs then distributing to the outputs. The spending signature does not specify the output destination, that is defined at the transaction level. Bob would have to create this transaction, and has no motivation to do so.  
> **username_0**: So I guess this is possible? I agree there may be little motivation. I was thinking that maybe due to outside forces Alice and Bob are prohibited from sending money to each other and this allows them to hide the fact. Then again, I just realized there are several other ways for Alice and Bob to achieve the same objective.  Thank you for the discussion!  

---

### Answer by username_3 on 2017-11-13. Score: 1

It doesn't matter whose coins are funding (inputs) for the transaction the validation check still works.

> (sum of input values) - (sum of output values) >= 0

There's nothing that states sum of input values on a per user basis. As long as the total value of the inputs, no matter who or where they come from, exceeds or equals the total value of the outputs the transaction passes the check.

**Update**: It's not an exploit. Each transaction input is treated separately and the condition to spend each input must be met separately. If Alice supplies an input tx then she'll also have to supply a scriptSig for that single input to prove she's entitled to spend it. Likewise with Bob's transaction, he'll have to supply a completely separate scriptSig that proves he's entitled to spend his input transaction.

Alice can't spend Bob's transaction and vice-versa (unless it's a multisig, spend by anyone etc) no matter how they are combined as inputs.

> **Comments:**
> **username_0**: Yes, I am asking why the validation is designed this way and whether this can be exploited. And I gave an example of a possible exploitation (or maybe this is not considered an exploitation).  
> **username_0**: Reply to update: I believe a single transaction can contain multiple inputs and multiple outputs. See https://en.bitcoin.it/wiki/Transaction#Explanation. Each input has its own separate signature and the validation condition is applied to all inputs and all outputs. Thus, unless I am missing something it seems to me that I can construct such a transaction and make the network accept it.  

---

### Answer by username_4 on 2017-11-13. Score: 0

Your misunderstanding is here:

> For example, suppose Alice has a coin of value 50 and spends 100, while Bob has a coin of value 100 and spends 50.

That is not possible. When an output is spent by an input, it is always spent entirely. You don't get to say how much of that output is left in place - the amount you are getting from that input is exactly the amount created by the previous amount.

If Bob has a coin of value 100, and only wants to spend 50, all he can do is spent his coin of 100, and add an extra output to the transaction that sends 50 back to himself (typically to a new address of his, for privacy reasons).

> **Comments:**
> **username_0**: I wasn't clear. What I meant is.  Alice spends coin of 50, sends coin of value 100 to some address X. Bob spends coin of 100, sends coin of value 50 to some address Y.  Both of these happen in the same transaction. Thus, in this transaction, we see inputs with value {50, 100}, and outputs with value {50, 100}.  
> **username_4**: What you meant is what?  

---

