3

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. 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?

3
  • Could you please amend the title to summarize the gist of your question?
    – Murch
    Commented May 8 at 15:37
  • 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
    Commented May 29 at 15:50
  • @fjahr sure no problem Commented Jun 2 at 11:44

1 Answer 1

1

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

Your Answer

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

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