<p>The problem with this approach is that it subsidizes address reuse and therefore hurts privacy.</p>

CC BY-SA 4.0
2024-05-08T08:33:02.083Z
2024-05-08T08:33:02.083Z
Otto Allmendinger
<p>One possible optimization to compress bitcoin transaction size is avoiding repetition of redundant data between inputs.</p>
<p>As a consensus change, a new transaction type could allow signing a list of <code>txid:vout</code> pairs if they all share the same output script.</p>
<p>To pick an extreme example, there are 1.6 million outputs with script <a href="https://blockstream.info/address/1HckjUpRGcrrRAtFaaCAUaGjsPx9oYmLaZ" rel="nofollow noreferrer">1HckjUpRGcrrRAtFaaCAUaGjsPx9oYmLaZ</a>. Spending one of these P2PKH outputs costs 40+72 vBytes (prevOut + scriptSig) per input. By aggregating the scriptSig across inputs, the transaction could omit 72 per input and only include it once per transaction. When consolidating all these outputs, an optimization like this could save network data on the order of 115 MvBytes. (At a fee rate of 10sat/b, this would translate into 11.5 BTC, which is about 80% of the aggregate value of those outputs)</p>
<p>What are the trade-offs and hidden problems of this sort of optimization?</p>

CC BY-SA 4.0
2024-05-08T15:37:57.390Z
Could you please amend the title to summarize the gist of your question?
Murch
CC BY-SA 4.0
2024-05-29T15:50:54.720Z
May I ask you to adapt the name of this idea? I haven't heard it previously, so I assume you thought of it yourself. The problem with "Cross-Input Script Aggregation" is that A LOT of people will confuse it with Cross-Input Signature Aggregation which has been around for a while (the idea and name). I would also say that you are not describing aggregation, rather de-duplication. May I suggest "Input Script Deduplication"? I think ISD is not a reserved abbreviation in this space :)
fjahr
CC BY-SA 4.0
2024-06-02T11:44:17.353Z
@fjahr sure no problem
Otto Allmendinger
<privacy><input-script><address-reuse><output-script>
What are the Trade-offs for Input Script Deduplication?
Otto Allmendinger
# What are the Trade-offs for Input Script Deduplication?

(Asked by: username_0 on 2024-05-08)

One possible optimization to compress bitcoin transaction size is avoiding repetition of redundant data between inputs.

As a consensus change, a new transaction type could allow signing a list of `txid:vout` pairs if they all share the same output script.

To pick an extreme example, there are 1.6 million outputs with script [1HckjUpRGcrrRAtFaaCAUaGjsPx9oYmLaZ](https://blockstream.info/address/1HckjUpRGcrrRAtFaaCAUaGjsPx9oYmLaZ). Spending one of these P2PKH outputs costs 40+72 vBytes (prevOut + scriptSig) per input. By aggregating the scriptSig across inputs, the transaction could omit 72 per input and only include it once per transaction. When consolidating all these outputs, an optimization like this could save network data on the order of 115 MvBytes. (At a fee rate of 10sat/b, this would translate into 11.5 BTC, which is about 80% of the aggregate value of those outputs)

What are the trade-offs and hidden problems of this sort of optimization?

**Tags:** privacy, input-script, address-reuse, output-script

> **Comments:**
> **username_1**: Could you please amend the title to summarize the gist of your question?  
> **username_2**: May I ask you to adapt the name of this idea? I haven't heard it previously, so I assume you thought of it yourself. The problem with "Cross-Input Script Aggregation" is that A LOT of people will confuse it with Cross-Input Signature Aggregation which has been around for a while (the idea and name). I would also say that you are not describing aggregation, rather de-duplication. May I suggest "Input Script Deduplication"? I think ISD is not a reserved abbreviation in this space :)  
> **username_0**: @username_2 sure no problem  

---

## 1 answers

### Answer by username_0 on 2024-05-08. Score: 1

The problem with this approach is that it subsidizes address reuse and therefore hurts privacy.


---

