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