rich1.0npub1du3xh5wgds32a5fweqkd9k45kh30wl7kv2kyu8ugz9c2ztdg00tqqvyg93https://nostr.ae/npub1du3xh5wgds32a5fweqkd9k45kh30wl7kv2kyu8ugz9c2ztdg00tqqvyg93njumphttps://nostr.ae📅 Original date posted:2015-08-09 📝 Original message: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. > 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. Actually, we didn't teach people anything, we told wallet developers to do it. Most actual users were completely ignorant of the problem. Full blocks will then stop being a supported usecase when real humans are trying to buy a beer or a coffee. Waiting for a confirmation won't work either for the vast majority of the current usages of Bitcoin in the real world. > I am comfortable leaving those zero-conf people in a little bit > of trouble. 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. -- Thomas Zander