{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-17\n📝 Original message:On Mon, Jun 15, 2015 at 09:00:19PM -0700, Aaron Voisine wrote:\n\u003e Thanks Alex, the work you've pointed out is helpful. Limiting mempool size\n\u003e should at least prevent nodes from crashing. When I looked a few days ago I\n\u003e only found a few old PRs that seemed to have fallen by the wayside, so this\n\u003e new one is encouraging.\n\nBTW it's worth working out how many $ in fees you need for a given\namount of MB worth of mempool.\n\nAt the current 10uBTC/KB minimim relay fee 1MB of txs requires just $2.5\nworth of fees - kinda ridiculous when a block earns a miner $6250 in\nrevenue. Pretty much all txs pay significantly higher rates - more like\n100uBTC/KB, or $25/MB. At that rate the 288MB max mempool size proposed\nby Patrick Strateman's pull-req requires at least $7.2k worth of BTC to\nfill to pay the fees, and in practice will probably quickly get higher.\n\nhttps://github.com/bitcoin/bitcoin/pull/6281\n\n\u003e I can respond in the PR comments if it's more appropriate there, but I\n\u003e believe ejecting tx from mempools rather than preemptively refusing them\n\u003e according to standard network wide propagation rules will result in spotty,\n\u003e inconsistent tx propagation, and possibly a large increase in tx\n\u003e re-broadcasts, so if those haven't been addressed they will need to be. It\n\u003e would also be prudent to run some simulations to see what other issues are\n\u003e going to pop-up.\n\nSee above - filling the mempool like that will be both a slow process,\nand require lots of funds. Equally, once full, the sensible thing to do\nis raise the minimum relay fee appropriately, so those transactions that\npay too low a fee will simply be rejected.\n\nIt'd be reasonable to tell peers that, and what the minimum fee needed\nfor acceptance would be for that particular node.\n\n\u003e We're currently using CPFP already in breadwallet when spending unconfirmed\n\u003e non-change inputs. A small percentage of hashing power is using it, but\n\u003e enough to get a transaction unstuck assuming breadwallet's fee calculation\n\u003e is better than the sender's.\n\n\u003e The problem with RBF is that there's currently no way to tell if your tx\n\u003e has been picked up by miners or not in order to know if you need to replace\n\u003e it. Miners broadcasting partial block solutions would be helpful in this\n\u003e regard, but only for tx in the currently-being-worked-on block, not for tx\n\u003e that won't be picked up until the block after. If miners were to eject tx\n\u003e that were previously being worked on in favor of higher fee tx, then that\n\u003e causes another set of problems for wallets that thought their tx was going\n\u003e to get in but then it doesn't. The other problem with RBF is that users\n\u003e don't know up front what fee they're actually going to pay which is a big\n\u003e blow to real world usability. Also mobile wallets will have to sign lots of\n\u003e tx up front and rely on a service to replace as necessary. And this is all\n\u003e just on the send side.\n\nFor an interactive, mobile wallet, the best thing to do is estimate the\nfee correctly the first time, using RBF as a follow up mechanism only if\nneeded. For other users - e.g. exchanges handling customer withdrawals -\nusing RBF more agressively to get the minimum possible fee may make\nsense.\n\n\u003e On the receive side it's much worse since you can't\n\u003e rely on the sender to do the replacing. The real problem seems to be the\n\u003e fact that RBF is an interactive iterative process rather than a\n\u003e send-and-forget one.\n\nIn any case, the *existance* of RBF makes no difference to any of these\nproblems; RBF does make solving the easier. You can always choose to not\nuse it after all, resulting in the same \"send-and-forget\" process.\nHaving it available allows mistakes to be fixed after the fact, always\nan improved user experience over not being able to re-bid for block\nspace.\n\n\nIncidentally, if my FSS-RBF bug bounty isn't collected in the next week\nor two, we'll likely have a major double-digits % of hashing power\nmining FSS-RBF soon after.\n\nhttp://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08122.html\n\n\u003e What you really need is some way to tell up-front, is a transaction going\n\u003e to get mined with a high probability? That problem seems really difficult\n\u003e to solve with fixed-size blocks that are full.\n\nHave you looked at the fee estimation code in Bitcoin Core? I have no\nreason to think it doesn't basically speaking work. Of course, SPV\nwallets will need a semi-trusted third party to securely get that data,\nbut this seems to be a fundemental problem in a decentralized network -\nthe purpose of the blockchain itself is to prove that some data was\npublished to some audience, an analogous problem to proving to the SPV\nwallet that their transaction actually reached miners and they actually\nare considering it for inclusion.\n\nGuaranteed reliable transaction processing is only possible in\ncentralized environments that can make service guarantees.\n\n\u003e If the goal is simply to\n\u003e reduce or limit the growth of the blockchain, then there are much simpler\n\u003e solutions, which is why I've advocated for the blocksize increase, followed\n\u003e by tx selection and propagation rule changes to create fee pressure.\n\nFew if any of those mechanisms can be deployed in a consensus-critical\nway that is resistant to attack; the blocksize limit is needed to -\namong other things - resist attacks by one miner on another to reduce\nthe competitors profitability. Without an explicit limit tx selection\nand propagation rule changes can be gamed.\n\n-- \n'peter'[:-1]@petertodd.org\n0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150617/46d63a0f/attachment.sig\u003e"}