Reducing transaction size by merging signatures

[jl2012]

A standard 1-input 2-outputs takes around 258Bytes (e.g. http://blockexplorer.com/tx/8c58943f54a68c58a4ccb7038cb7fe0fc71d921082c932f81aaf723a045f9916). A multiple inputs transaction will take much more space (e.g. http://blockexplorer.com/tx/32dbc162003949c2a8eb494606f143c776b263bfec3dbfc59dff6e0dceb4fe51 ). In this transaction, however, all inputs are coming from the same address. Instead of using 12 signatures, is it possible to use one signature for 12 inputs? That would save a lot of space in long term.

[1715282141]

1715282141

[1715282141]

1715282141

[1715282141]

1715282141

[1715282141]

1715282141

[caveden]

I wasn't event aware that the same input could show up multiple times in the same transaction.

You're forced to point out, in your transaction, which was the transaction that credited your input? And you have to make a signature for every "previous output"?

If that's the case, it indeed looks as waste of space.

[Pieter Wuille]

In practice, this would indeed help a bit. But I hope that someday in the future, when addresses are used exactly once only (ideal for both security and privacy), this becomes irrelevant.

[jl2012]

I want to bring this up again as we have lots of discussion on block size.

There are two major benefits for using one signature of multiple inputs of the same address:

1. Reduce size: allow more transactions in one block

2. Reduce UTXO: it is not economical to redeem sand outputs with a few satoshis because the signatures take a lot of space and the transaction fee required is much higher than the sand outputs. If people could redeem thousands of sand outputs in the same address with only one signature, this will reduce the size of  UTXO set

This is a new transaction structure so I think this is a hard fork. I don't think this is high priority but should be considered when a hard fork is needed.

[Nagato]

I think this is a great idea!

In my opinion, anything that makes blocks smaller without compromising functionality should be implemented first before raising the max block size.

[jl2012]

I think this is a great idea!

In my opinion, anything that makes blocks smaller without compromising functionality should be implemented first before raising the max block size.

For people without privacy concern, this will also encourage them using a single address to receive payment. Therefore, they can sweep the address every time they spend.

[Mike Hearn]

It'd be a hard-forking change for little/no benefit when Bitcoin is used correctly. It'd also require changing all existing software that speaks the protocol. Agree with Pieter, this isn't worthwhile.

[jl2012]

It'd be a hard-forking change for little/no benefit when Bitcoin is used correctly. It'd also require changing all existing software that speaks the protocol. Agree with Pieter, this isn't worthwhile.

When transaction fee goes up, people without privacy concern would prefer a solution like this, while you can still use bitcoin in the "correct" way. This could be done with other important hardforks.

[Nagato]

It'd be a hard-forking change for little/no benefit when Bitcoin is used correctly. It'd also require changing all existing software that speaks the protocol. Agree with Pieter, this isn't worthwhile.

If there is going to be a hard fork for the max block size, what harm is there in implementing this? And how do we ensure Bitcoin will be used "correctly" in future?

[Mike Hearn]

Because people actually have to do the work to implement the hard-forking changes, across all software that might matter? Some changes are easier than others, so each one has to be worth it.

Re: ensuring it's used correctly, the payment protocol work is a big step for that, as are implementing deterministic wallets.