{"type":"rich","version":"1.0","author_name":"npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzl","author_url":"https://nostr.ae/npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzl","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-16\n📝 Original message:Thanks Alex, the work you've pointed out is helpful. Limiting mempool size\nshould at least prevent nodes from crashing. When I looked a few days ago I\nonly found a few old PRs that seemed to have fallen by the wayside, so this\nnew one is encouraging.\n\nI can respond in the PR comments if it's more appropriate there, but I\nbelieve ejecting tx from mempools rather than preemptively refusing them\naccording to standard network wide propagation rules will result in spotty,\ninconsistent tx propagation, and possibly a large increase in tx\nre-broadcasts, so if those haven't been addressed they will need to be. It\nwould also be prudent to run some simulations to see what other issues are\ngoing to pop-up.\n\nWe're currently using CPFP already in breadwallet when spending unconfirmed\nnon-change inputs. A small percentage of hashing power is using it, but\nenough to get a transaction unstuck assuming breadwallet's fee calculation\nis better than the sender's.\n\nThe problem with RBF is that there's currently no way to tell if your tx\nhas been picked up by miners or not in order to know if you need to replace\nit. Miners broadcasting partial block solutions would be helpful in this\nregard, but only for tx in the currently-being-worked-on block, not for tx\nthat won't be picked up until the block after. If miners were to eject tx\nthat were previously being worked on in favor of higher fee tx, then that\ncauses another set of problems for wallets that thought their tx was going\nto get in but then it doesn't. The other problem with RBF is that users\ndon't know up front what fee they're actually going to pay which is a big\nblow to real world usability. Also mobile wallets will have to sign lots of\ntx up front and rely on a service to replace as necessary. And this is all\njust on the send side. On the receive side it's much worse since you can't\nrely on the sender to do the replacing. The real problem seems to be the\nfact that RBF is an interactive iterative process rather than a\nsend-and-forget one.\n\nWhat you really need is some way to tell up-front, is a transaction going\nto get mined with a high probability? That problem seems really difficult\nto solve with fixed-size blocks that are full. If the goal is simply to\nreduce or limit the growth of the blockchain, then there are much simpler\nsolutions, which is why I've advocated for the blocksize increase, followed\nby tx selection and propagation rule changes to create fee pressure.\n\nAaron Voisine\nco-founder and CEO\nbreadwallet.com\n\nOn Mon, Jun 15, 2015 at 6:17 PM, Alex Morcos \u003cmorcos at gmail.com\u003e wrote:\n\n\u003e Aaron,\n\u003e\n\u003e My understanding is that Gavin and Mike are proceeding with the XT fork, I\n\u003e hope that understanding is wrong.\n\u003e\n\u003e As for improving the non-consensus code to handle full blocks more\n\u003e gracefully.  This is something I'm very interested in, block size increase\n\u003e or not. Perhaps I shouldn't hijack this thread, but maybe there are others\n\u003e who also believe this would ameliorate some of the time pressure for\n\u003e deciding on a block size increase.\n\u003e\n\u003e What is it that you would like to see improved?\n\u003e The fee estimation code that is included for 0.11 will give much more\n\u003e accurate fee estimates, which should allow adding the correct fee to a\n\u003e transaction to see it likely to be confirmed in a reasonable time.  For\n\u003e further improvements:\n\u003e - There has recently been attention to overhauling the block creation and\n\u003e mempool limiting code in such a way that actual outstanding queues to be\n\u003e included in a block could also be incorporated in fee estimation.  See\n\u003e https://github.com/bitcoin/bitcoin/pull/6281.\n\u003e - CPFP and RBF are candidates for inclusion in core soon, both of which\n\u003e could be integrated into transaction processing to handle the edge cases\n\u003e where a priori fee estimation fails. See\n\u003e https://github.com/bitcoin/bitcoin/pull/1647 and\n\u003e https://github.com/bitcoin/bitcoin/pull/6176\n\u003e\n\u003e I know there has been much discussion of fee estimation not working for\n\u003e SPV clients, but I believe several independent servers which were serving\n\u003e the estimates from full nodes would go a long way towards allowing that\n\u003e information to be used by SPV clients even if its not a completely\n\u003e decentralized solution.  See for example\n\u003e http://core2.bitcoincore.org/smartfee/latest.json\n\u003e\n\u003e\n\u003e\n\u003e On Mon, Jun 15, 2015 at 8:08 PM, Aaron Voisine \u003cvoisine at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e Wasn't the XT hard fork proposed as a last resort, should the\n\u003e\u003e bitcoin-core maintainers simply refuse to lift the 1Mb limit? No one wants\n\u003e\u003e to go that route. An alternate hard-fork proposal like BIP100 that gets\n\u003e\u003e consensus, or a modified version of gavin's that ups the limit to 8Mb\n\u003e\u003e instead of 20Mb, or hell even some major changes to the non-consunsus code\n\u003e\u003e to make it adequately handle the situation when blocks fill up, and allow\n\u003e\u003e wallet software to continue working with a send-and-forget use pattern, any\n\u003e\u003e of these would be enough to avoid the need for an XT only hard-fork.\n\u003e\u003e\n\u003e\u003e So far BIP100 is the only one that seems to actually be getting any sort\n\u003e\u003e of momentum toward consensus, and it was proposed... 2 days ago? When the\n\u003e\u003e XT fork was proposed as a last resort, it was when the opponents were (to\n\u003e\u003e my understanding) suggesting we just let blocks fill up, and hopefully\n\u003e\u003e things would just work out on their own.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Aaron Voisine\n\u003e\u003e co-founder and CEO\n\u003e\u003e breadwallet.com\n\u003e\u003e\n\u003e\u003e On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman \u003cbrianchoffman at gmail.com\u003e\n\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Who is actually planning to move to Bitcoin-XT if this happens?\n\u003e\u003e\u003e\n\u003e\u003e\u003e Just Gavin and Mike?\n\u003e\u003e\u003e\n\u003e\u003e\u003e [image: image1.JPG]\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Jun 15, 2015, at 6:17 PM, Faiz Khan \u003cfaizkhan00 at gmail.com\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e I'm quite puzzled by the response myself, it doesn't seem to address\n\u003e\u003e\u003e some of the (more serious) concerns that Adam put out, the most important\n\u003e\u003e\u003e question that was asked being the one regarding personal ownership of the\n\u003e\u003e\u003e proposed fork:\n\u003e\u003e\u003e\n\u003e\u003e\u003e \"How do you plan to deal with security \u0026 incident response for the\n\u003e\u003e\u003e duration you describe where you will have control while you are deploying\n\u003e\u003e\u003e the unilateral hard-fork and being in sole maintainership control?\"\n\u003e\u003e\u003e\n\u003e\u003e\u003e I do genuinely hope that whomever (now and future) wishes to fork the\n\u003e\u003e\u003e protocol reconsider first whether they are truly ready to test/flex their\n\u003e\u003e\u003e reputation/skills/resources in this way... Intuitively, to me it seems\n\u003e\u003e\u003e counterproductive, and I don't fully believe it is within a single\n\u003e\u003e\u003e developer's talents to manage the process start-to-finish (as it is\n\u003e\u003e\u003e non-trivial to hard-fork successfully, others have rehashed this in other\n\u003e\u003e\u003e threads)...\n\u003e\u003e\u003e\n\u003e\u003e\u003e That being said I think it appropriate if Adam's questions were\n\u003e\u003e\u003e responded in-line when Mike is feeling up to it. I think that the answers\n\u003e\u003e\u003e are important for the community to hear when such a drastic change is being\n\u003e\u003e\u003e espoused.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Faiz\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop \u003ckanzure at gmail.com\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e Re: anyone who agrees with noted non-programmers Mike\u0026Gavin must be\n\u003e\u003e\u003e\u003e\u003e non-technical, stupid, uninformed, etc .... OK, go ahead and show them the\n\u003e\u003e\u003e\u003e\u003e error of their ways. Anyone can write blogs.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e I worry that if this is the level of care you take with reading and\n\u003e\u003e\u003e\u003e (mis)interpreting Adam's messages, that you might not be taking extreme\n\u003e\u003e\u003e\u003e care with evaluating consensus changes, even while tired or sleeping. I\n\u003e\u003e\u003e\u003e encourage you to evaluate both messages and source code more carefully,\n\u003e\u003e\u003e\u003e especially in the world of bitcoin. However, this goes for everyone and not\n\u003e\u003e\u003e\u003e just you. Specifically, when Adam mentioned your conversations with\n\u003e\u003e\u003e\u003e non-technical people, he did not mean \"Mike has talked with people who have\n\u003e\u003e\u003e\u003e possibly not made pull requests to Bitcoin Core, so therefore Mike is a\n\u003e\u003e\u003e\u003e non-programmer\". Communication is difficult and I can understand that, but\n\u003e\u003e\u003e\u003e we really have to be more careful when evaluating each other's messages;\n\u003e\u003e\u003e\u003e technical miscommunication can be catastrophic in this context. On the\n\u003e\u003e\u003e\u003e topic of whether you are a programmer, I suspect that ever since you built\n\u003e\u003e\u003e\u003e CIA.vc we have all known you're a programmer, Mike.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e - Bryan\n\u003e\u003e\u003e\u003e http://heybryan.org/\n\u003e\u003e\u003e\u003e 1 512 203 0507\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e --\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e My regards,\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Faiz Khan\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e  \u003chttps://lists.sourceforge.net/lists/listinfo/bitcoin-development\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/cb4817fe/attachment.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image1.JPG\nType: image/jpeg\nSize: 22107 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/cb4817fe/attachment.jpe\u003e"}