{"type":"rich","version":"1.0","author_name":"npub1lwrwp8dzn9x5nqc7d735e0nuwxh0nyz5ezkfpjzr332efdxw9asq4z8zjm","author_url":"https://nostr.ae/npub1lwrwp8dzn9x5nqc7d735e0nuwxh0nyz5ezkfpjzr332efdxw9asq4z8zjm","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-07-18\n📝 Original message:Peers exchanging mempool priority policies is great; that accomplishes\nthe flexibility in what txes to remember that I was going for with the\nforget-filters, but much more neatly, with less overhead and some side\nbenefits.\n\nHere's what I'm picturing now:\n- exchange priority policies in peer introductions\n- assign unique sequential IDs in the order the transactions were\ninved (per peer)\n- receiving a getdata for a tx updates last-known-peer-received inv to\nall invs up to the one referenced\n- include ID-last-received, last-known-peer-received in sparse block\n- reference txes in sparse block by index in receiver's\nprioritiziation with peer's sent invs up to ID-last-received and\nsender's prior invs up to last-known-peer-received\n\nPossible new messages:\n- sparseblock\n- invack message a node can send at times when it's received a bunch\nof invs it already has, so it hasn't acked with a getdata in a while\n- gettx: getdata, but using new sequential ID to save 28 bytes per tx\n\nIt seems important for ordering policies to be able to be specified in\nas much detail as possible. Parameters that should be available:\n- total inputs\n- total outputs\n- bytes\n- coin days destroyed\n- net UTXO size change\n- sigops\n- is data carrier\n- is output raw multisig\n- age in mempool\n- what else?\nThis parameter set should be extensible to allow for unforeseen future factors.\n\nOrdering policies should allow arbitrary algebraic combinations of\ntheir parameters, as well as thresholds. Boolean combinations of\nsub-policies would also be desirable. This could be implemented with a\ntx-script-like stack-based language, in which each supported tx\nproperty is pushed onto the stack by a particular opcode, and\n+-*//min/max/boolean operators combine them to yield the sort key.\n\nDifficult parameters:\n* Coin-days-destroyed: changes, peers need agreement on when (if?)\nit's recalculated. Probably can just not recalculate, but peers still\nneed agreement on \"time seen\" to get CDD.\n* Age in mempool: seems intractable in terms of time, but could be\ndone easily in terms of \"how many txes old is this sequential ID\"\n\nOne potential pitfall: this allows for an environment of completely\nheterogeneous mempool policies. I think that's a good thing, but we\nneed to avoid a situation where only least-common-denominator\ntransactions make it farther than a hop or two, and we don't want\nnodes to have a strong preference for connecting to like-minded peers\nsince clustering reduces overall connectivity. It may be worthwhile to\nadd a parallel mechanism for relay policies, to differentiate between\nwhat a node would keep in its mempool vs. what it wouldn't even relay\nand doesn't want to see at all. Relay policies could be specified just\nlike prioritization policies, but with the final stack value evaluated\nin a boolean context.\n\nAn interesting additional use of policy-scripts would be a\nstandardized way for miners to include a policy script in a coinbase,\nallowing miners a mechanism to advertise things like their relative\nprice of sigops vs bytes. Nodes may then choose to take this\ninformation into account in order to optimize their mempool policies\nfor likelihood of consistency with future blocks. Since policy scripts\nprovide only relative information on prices of different transaction\nproperties rather than an absolute fee, this should not allow miners\nto \"vote fees up\", although care would need to be taken they wouldn't\nbe able to drive up prices by claiming common transaction types are at\nthe high end of the fee scale."}