{"action":"created","issue":{"url":"https://api.github.com/repos/bitcoin/bitcoin/issues/6992","labels_url":"https://api.github.com/repos/bitcoin/bitcoin/issues/6992/labels{/name}","comments_url":"https://api.github.com/repos/bitcoin/bitcoin/issues/6992/comments","events_url":"https://api.github.com/repos/bitcoin/bitcoin/issues/6992/events","html_url":"https://github.com/bitcoin/bitcoin/pull/6992","id":116414863,"number":6992,"title":"[WIP] [Mempool] Add space for priority transactions","user":{"login":"sdaftuar","id":7463573,"avatar_url":"https://avatars.githubusercontent.com/u/7463573?v=3","gravatar_id":"","url":"https://api.github.com/users/sdaftuar","html_url":"https://github.com/sdaftuar","followers_url":"https://api.github.com/users/sdaftuar/followers","following_url":"https://api.github.com/users/sdaftuar/following{/other_user}","gists_url":"https://api.github.com/users/sdaftuar/gists{/gist_id}","starred_url":"https://api.github.com/users/sdaftuar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sdaftuar/subscriptions","organizations_url":"https://api.github.com/users/sdaftuar/orgs","repos_url":"https://api.github.com/users/sdaftuar/repos","events_url":"https://api.github.com/users/sdaftuar/events{/privacy}","received_events_url":"https://api.github.com/users/sdaftuar/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2015-11-11T20:28:15Z","updated_at":"2015-11-11T22:27:33Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/bitcoin/bitcoin/pulls/6992","html_url":"https://github.com/bitcoin/bitcoin/pull/6992","diff_url":"https://github.com/bitcoin/bitcoin/pull/6992.diff","patch_url":"https://github.com/bitcoin/bitcoin/pull/6992.patch"},"body":"This is a work-in-progress that certainly needs more testing and cleanup -- sharing now in light of discussions happening elsewhere (#6972) about some of the drawbacks from introducing mempool limiting in #6722.\r\n\r\nOverall I agree with @sturles in that the existing notion of priority is largely a useful one to differentiate transactions that might be part of an attack from ones that likely are not.  On the other hand, coming up with a mempool limiting algorithm like #6722 that we believe is robust against attack was challenging enough without having to also try to maintain this particular existing policy.\r\n\r\nHowever after further thought I think we can restore some of the useful features of priority without major re-engineering of the mempool.  I propose to reserve some fraction of the mempool (defaults to the blockprioritysize/blockmaxsize) for transactions that have no unconfirmed parents.  Transactions in that space will be sorted by priority at the time of entry to the mempool.\r\n\r\nIf the priority space in the mempool exceeds its limit, priority transactions will be moved to the feerate portion of the mempool (where they will be sorted based on their feerate and the feerate of any descendants).  Once moved to the feerate area, transactions never move back to the priority area.\r\n\r\nNew transactions that don't meet the mempool reject fee must meet the new GetMinPriority(), which is increased when priority transactions are moved to the feerate part of the mempool, and decayed as time passes (just like the mempool's minimum fee).\r\n\r\nNote that this relies on the rate limiting of free transactions to prevent relay bandwidth DoS attacks using priority transactions.\r\n"},"comment":{"url":"https://api.github.com/repos/bitcoin/bitcoin/issues/comments/155929352","html_url":"https://github.com/bitcoin/bitcoin/pull/6992#issuecomment-155929352","issue_url":"https://api.github.com/repos/bitcoin/bitcoin/issues/6992","id":155929352,"user":{"login":"sipa","id":548488,"avatar_url":"https://avatars.githubusercontent.com/u/548488?v=3","gravatar_id":"","url":"https://api.github.com/users/sipa","html_url":"https://github.com/sipa","followers_url":"https://api.github.com/users/sipa/followers","following_url":"https://api.github.com/users/sipa/following{/other_user}","gists_url":"https://api.github.com/users/sipa/gists{/gist_id}","starred_url":"https://api.github.com/users/sipa/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sipa/subscriptions","organizations_url":"https://api.github.com/users/sipa/orgs","repos_url":"https://api.github.com/users/sipa/repos","events_url":"https://api.github.com/users/sipa/events{/privacy}","received_events_url":"https://api.github.com/users/sipa/received_events","type":"User","site_admin":false},"created_at":"2015-11-11T22:27:33Z","updated_at":"2015-11-11T22:27:33Z","body":"My idea was that we'd get rid of priority, and replace it with a small adjustment to the fee or size of a transaction.\r\n\r\nOne idea is to treat the total bitcoindays of the UTXO set as limited resource and treat it as currency, and that burning it should be treated like extra fee, with a small factor. Specifically:\r\n* for each transaction you compute the bitcoin-days-destroyed\r\n* divide it by the average UTXO entry age weighed by amount (around 800 days currently)\r\n* the result is a value in BTC; take some configurable fraction of it (0.5% for example)\r\n* treat the result as extra fee (which gets divided by the tx size to obtain the feerate).\r\n\r\nThis is simple (don't bother recalculating this equivalent fee on every mempool change; just infrequently in the background or even not at all and keep using the value from entry time), and using 0.5% as factor would give a 250-byte 1 BTC-day-destroyed transaction (the limit for high priority earlier) the equivalent of 2500 satoshi/kB feerate boost.\r\n\r\nThe downside is that it has no guarantees on how much a miner could lose by using this approach. For example, 100 BTC of 1 year old coins would be treated equal to a 1 BTC fee. We can cap the maximum amount of feerate replaced, but that may make the scheme pretty useless if the cap is easy to hit."}}