Hi, I've been looking at Gavin's blog updated a few days ago, hoping to learn more about the "fee model", so I've got some questions, critiquing, and a couple of ideas to run past everyone.
Goals
In rough order of priority:
Create a self-regulating market for transaction fees between miners and merchants/users
Smoothly transition from the rules we currently have in place to the new rules; transactions from users running old versions of Bitcoin should get confirmed reasonably quickly under the new rules.
Make sure transaction spam is expensive for would-be spammers
Replace compiled-in constants with dynamic, market-determined values
Pre-emptive intervention as a design goal? This may be nitpicking, but I would have thought that in a market where "supply meets demand", transaction spam would no longer be relevant. Miners would tend to simply sign "winning bids for transactions" in order of profitability and the problem would sort itself out. (Supply and demand might be chaotic but it's not Voodoo.)
Should the priority calculation be changed?
As the total number of transactions grows, transaction pruning schemes that "forget" old, completed transaction become more and more important. Pruning is possible when all of a transaction's outputs are spent, so a transaction that takes 10 inputs and combines them into 1 output is good for the network.
The transaction priority calculation could be modified to prefer transactions with a high ratio of inputs to outputs. However, we need to be careful and make sure that there is still an incentive to use 'sendmany' instead of creating dozens of single-in/single-out transactions; a 1-input-10-output transaction should not have one-tenth the priority of a 1-input-1-output transaction.
To give a mild preference to transactions with fewer/smaller outputs than inputs the priority formula could be modified to be:
priority = (sum(value*age)/size) * (1000 + size of previous txouts) / (1000 + size of this txn's txouts)
My question is: should priority calculation exist at all? Pruning generally seems like a sensible idea, but pre-emptively intervening and hard-coding the decision into the protocol seems like unnecessary bloat. Why not get rid of it altogether and provide miners with an economic incentive instead? E.g.: "reward miners who prune old blocks by giving them optional extra new blocks (without the coin reward of course)". Of course that might only work if block-space were already a reasonably
scarce resource. Anyway, just an idea -- no idea if it's feasible.
maximum block size : The maximum size block that can be created. If not set, it will default to the same as the target block size. Miners can increase this to make room for more fee-paying transactions.
--The controversy never ends
At the moment I'm favouring an algorithm where each time a block is discovered, the miner can reference the previous block's maximum size and vote it 'up', 'down', or 'no change'. The question is how much should the vote count? E.g.: a 2^(+-1/2016) change? (E.g.: doubling or halving every 2 weeks with that example). To me this seems like a relatively simple algorithm that alleviates 3 problems: 1) miners all having different opinions on exactly how much capacity blocks 'ought' to have, 2) minimising some potential problems with rogue miners/merchants/
anyone DOSing transaction requests, 3) of course scaling.
Lastly, one thing I'm unable to find anywhere, and perhaps someone could point me to it -- where are "unconfirmed transactions" kept? Presumably this memory heap is itself a scarce resource, and ought to be treated as such? It seems that some merchants et al. are using this memory heap in lieu of a low-cost messaging system. Does Bitcoin already have a messaging scheme for data other than transactions?
