<p>An interesting idea, but I don't think it technically works out. </p>

<ol>
<li>Transactions include a digital signature of the set of inputs and outputs in a transaction. This signature could not be validated if the inputs and outputs where not linked. </li>
<li>Since signatures wouldn't be tied to specific outputs/inputs, what would stop a greedy miner from including your inputs but not your outputs? </li>
<li>Outputs can be created and spent in the same block. So you can't list all inputs, and then list all outputs, because some of those inputs depends on those outputs being known first. (There may be a work around for this, but it complicates things) </li>
</ol>

CC BY-SA 3.0
2015-07-27T11:42:43.030Z
2015-07-27T11:42:43.030Z
morsecoder
<p>Because when someone creates a transaction, they don't know what other transactions will be included in the same block... and it is the transactions that are signed by the sender, not the whole block.</p>

<p>There is a mechanism in between, namely CoinJoin, where multiple transaction creators/senders collaborate to create a joint transaction with multiple inputs and outouts from each of the participants, to increase privacy.</p>

CC BY-SA 3.0
2015-07-27T12:33:28.640Z
2015-07-27T12:54:02.707Z
2015-07-27T12:54:02.707Z
Pieter Wuille
<p>I'm just getting started looking at bitcoin and it's protocol, so this might be an incredibly stupid question. Why does bitcoin have a separate concept of transactions? Wouldn't it be better for each block to have a bunch of inputs and a bunch of outputs without separating them as individual transactions? This way it's more anonymous and private, since anyone trying to track an public key is stopped since their transactions are mixed with hundreds of others?</p>

<p>I guess technically, you could do that right now, by making one transaction with hundreds of inputs and outputs and mining that. I'm not asking why transactions are propagated by the nodes, I'm asking why are they stored separately in the final blocks?</p>

<transactions>
Why are transactions separate in a block?
seefour
# Why are transactions separate in a block?

(Asked by: username_0 on 2015-07-27)

I'm just getting started looking at bitcoin and it's protocol, so this might be an incredibly stupid question. Why does bitcoin have a separate concept of transactions? Wouldn't it be better for each block to have a bunch of inputs and a bunch of outputs without separating them as individual transactions? This way it's more anonymous and private, since anyone trying to track an public key is stopped since their transactions are mixed with hundreds of others?

I guess technically, you could do that right now, by making one transaction with hundreds of inputs and outputs and mining that. I'm not asking why transactions are propagated by the nodes, I'm asking why are they stored separately in the final blocks?

**Tags:** transactions


---

## 2 answers

### Answer by username_1 on 2015-07-27. Score: 3

An interesting idea, but I don't think it technically works out.

1. Transactions include a digital signature of the set of inputs and outputs in a transaction. This signature could not be validated if the inputs and outputs where not linked.
2. Since signatures wouldn't be tied to specific outputs/inputs, what would stop a greedy miner from including your inputs but not your outputs?
3. Outputs can be created and spent in the same block. So you can't list all inputs, and then list all outputs, because some of those inputs depends on those outputs being known first. (There may be a work around for this, but it complicates things)


---

### Answer by username_2 on 2015-07-27. Score: 1

Because when someone creates a transaction, they don't know what other transactions will be included in the same block... and it is the transactions that are signed by the sender, not the whole block.

There is a mechanism in between, namely CoinJoin, where multiple transaction creators/senders collaborate to create a joint transaction with multiple inputs and outouts from each of the participants, to increase privacy.


---

