{"type":"rich","version":"1.0","author_name":"npub15wz8j5cse6sexlw6f5q7arc5efe5hxn6kcxxyy222et8qms4u3lsemaru8","author_url":"https://nostr.ae/npub15wz8j5cse6sexlw6f5q7arc5efe5hxn6kcxxyy222et8qms4u3lsemaru8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-09\n📝 Original message:On Sun, Aug 9, 2015 at 3:42 AM, Thomas Zander via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev wrote:\n\u003e \u003e Someone mentioned that when the backlog grows faster than it shrinks,\n\u003e that\n\u003e \u003e is a real problem.  I don't think it is.  It is a problem for those who\n\u003e \u003e don't wait for even one confirmation\n\u003e\n\u003e The mention you refer to was about the fact that the software doesn't cope\n\u003e well with a continuously growing mempool.\n\u003e If Bitcoind starts eating more and more memory, I expect lots of people\n\u003e that\n\u003e run it now to turn it off.\n\u003e\n\nThat is a real problem then.  While emptying the mempool faster with bigger\nblocks will help to reduce the occurrence of that problem, I propose a\nuser-configurable default limit to the size of the mempool as a permanent\nsolution regardless of block size.  \"This software has stopped consuming\nmemory necessary to validate transactions.  You can override this by ...\"\nIf anyone feels that protecting those running full nodes from bitcoind\neating more and more memory this way is a good idea, I can make a BIP out\nof it if that would help.\n\n\n\u003e \u003e but backlogs in the past have already\n\u003e \u003e started training users to wait for at least one confirmation, or go\n\u003e \u003e off-chain.\n\u003e\n\u003e I am wondering how you concluded that? The only time we saw full blocks\n\u003e for a\n\u003e considerable amount of time was when we had a spammer, and the only thing\n\u003e we taught people was to use higher fees.\n\u003e\n\nI concluded that because I don't think I'm all that different than others,\nand that is what I have done.  The \"training\" of which I speak is not\nalways recognized by the bitcoiner on whom it operates.  A similar\n\"training\" is how we all learn to ignore teachers because governments force\nour attendance at school.\n\n\n\u003e \u003e Everyone else can double-spend (perhaps that's not as easy as\n\u003e \u003e it should be in bitcoin core) and use a higher fee, thus competing for\n\u003e \u003e block space.\n\u003e\n\u003e This is false, if you want to double spent you have to do a lot of work and\n\u003e have non-standard software.  For instance sending your newer transaction\n\u003e to a\n\u003e random node will almost always get it rejected because its a double spent.\n\u003e Replace by fee (even safe) is not supported in the vast majority of Bitcoin\n\u003e land.\n\u003e\n\nI don't know what you meant to say is false.  I agree with the other stuff\nyou wrote.  Thanks for confirming that it is difficult.\n\nI did some research on replace by fee (FSS-RBF) and on\nChild-pays-for-parent (CPFP).  You point out that these solutions to paying\ntoo-low fees are \"not supported in the vast majority...\".  Do you mean\nphilosophically or programmatically?  The trend seems to me toward\nimprovements, just as I insinuated may be necessary (\"perhaps that's not as\neasy as it should be in bitcoin core\"), so, once again, I have to reiterate\nthat transaction backlog has valuable solutions other than increasing the\nblock size.\n\nI also realized that we have already been through a period of full blocks,\nso that tremendously reduces the value I see in doing it again.  It was\nthat \"spam\" test someone ran that did it for us, and I love that.  It seems\nto have kicked the fee-increasability efforts in the butt, which is great.\n\nI now place a higher priority on enabling senders to increase their fee\nwhen necessary than on increasing the Txns per second that the network can\nhandle.  The competition between these two is rather unfair because of how\neasy it is to apply the \"N MB-blocks bandaid\".\n\nDave\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150809/01523c01/attachment-0001.html\u003e"}