Idea: Compact Transactions and Predicatable Fees

General
1

One problem with bitcoin-based cryptocurrencies is the variability of transaction size and fees according to the number of inputs. If someone receives many small amounts to the same address and then wishes to spend many of these at once, the transaction and fee will be large due to many inputs.

Instead of having one output correspond to one input, all outputs with the same scriptPubKey (and thus address) could correspond to a single input. This means that any number of outputs to a particular address would be redeemable using a single input. Sending from a single address would have a transaction size and fee that is only proportional to the outputs. Transactions would be smaller; fees would be lower, more predictable and intuitive to the user. Redeeming small tips to an address would be more economical.

This could be accomplished by introducing a new transaction type that adds a flag to each input. If this flag is true, then the input would be a “new-type” input. These new-type inputs would contain an output tx hash and output index like the old-type but they would select all unspent outputs that contain the same scriptPubKey up-to and including the referenced output. In addition, the new-type input would contain an nValue member which must equal the value of the selected outputs or validation will fail. This would combine all outputs with the same scriptPubKey to the same input up-to a certain point in the blockchain without risking a change in the total value via reorgs.

These transactions could only spend outputs that have been confirmed. That shouldn’t be a problem in most cases. The old style transactions and inputs would still remain valid for backwards compatibility.

I had this idea for a long time but I happened to think about it again today. This time I decided to share it. I’m certain it must have been considered by others. I’ve not thought about it in massive detail so does anyone have any thoughts about whether or not this is a good idea?

3 Likes
2

This is a powerful idea for minters with many outputs, and could reduce input spam when sending from an active minter.

3

It should be pointed out that when sending a smaller amount via this method, it could unnecessarily spend outputs that have accumulated coin age that would otherwise be possible to mint. A possible solution would be to restrict the number of selected outputs so that they aren’t all spent at once. The input would only select how many outputs are needed.

Another input member could be added called nOutputs which would provide a number of outputs to select going backwards from the referenced output (COutPoint). Then it would be possible to leave older outputs alone and select a given number of newer outputs with lower age.

Alternatively, the hashes and indices of each desired output could be included with a shared signature but this would make the size of the inputs variable which negates a major benefit of this idea.

4

@MatthewLM do you mind writing up the RFC? I wonder if you can present the pros/cons of this approach.

5

Sure, I’ll have to see if I get some spare time. I might be able to write a rough draft for consideration and flesh it out later.