I made a post a few days ago where I laid out a scheme for implementing "coalescing transactions" using a new opcode. I have since come to the realization that an opcode is not the best way to do this. A much better approach I think is a new "transaction type" field that is split off from the version field. Other uses can come out of this type field, wildcard inputs is just the first one.
There are two unresolved issues. First, there might need to be a limit on how many inputs are included in the "coalesce". Lets say you have an address that has 100,000,000 inputs. If you were to coalesce them all into one single input, that means that every node has to count of these 100,000,000 inputs, which could take a long time. But then again, the total number of inputs a wildcard can cover is limited to the actual number of UTXOs in the pool, which is very much a finite/constrained number. One solution is to limit all wildcard inputs to, say, 10,000 items. If you have more inputs that you want coalesced, you have to do it in 10,000 chunks, starting from the beginning. I want wildcard inputs to look as much like normal inputs as much as possible to facilitate implementation, so embedding a "max search" inside the transaction I don't think is the best idea. I think if there is going to be a limit, it should be implied. The other issue is with limiting wildcard inputs to only inputs that are confirmed into a fixed number of blocks. Sort of like how coinbase has to be a certain age before it can be spent, maybe wildcard inputs should only work on inputs older than a certain block age. Someone brought up in the last thread that re-orgs can cause problems. I don't quite see how that could happen, as re-orgs don't really affect address balances, only block header values, which coalescing transactions have nothing to do with. Here is the draft: https://github.com/priestc/bips/blob/master/bip-coalesc-wildcard.mediawiki _______________________________________________ bitcoin-dev mailing list email@example.com https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev