That's what I don't know/ seeking insight on. Whether it'd be a consensus implementation in the upgrade cycle, or if it'd be a voluntary node type implementation... But it would increase security from spam 1 sat/tx atks like Bchautist was mentioning, and in-so-doing increase fees the miners would get in such circumstances... Seems more like a consensus/ CHIP proposal- but i don't know 4 sure, there may be reasons it's not feasible that I'm blind to. I'm just coming at it from a math logic/problem solving perspective
In short, you cant. If I mine a block that violates the rule, because I haven't received some lowpaying transaction, I would be orphaned, for the rule to be enforced. No one can prove I had not received said transaction, tho. For this to work, there would need to be some kind of mempool-syncing mechanism, or some kind of preconsensus. There already is a way for miners to sync their transactions, and that thing is mining. The network works in its unstructured simplicity.
Apparently, there is already a mechanism, that's what lead to this discussion. Currently, the mechanism raises the fee and drops transactions during times of congestion. This discussion is about changing that mechanism so transactions aren't dropped.
I'm not fully up to speed w/ all that, so maybe what I'm proprosing isnt helpful in that light... or maybe it's a missing piece to the puzzle 🤷♂️
Transactions are dropped at random, so if the three of us have the mempool filled, we all will wipe different transactions, so that all transactions (hopefully) live
You should instead adovocate for an increase in default mempool. Right now it is static, while with ABLA the blocksize will be dynamic. Also it is small, it can contain some 2 blocks worth of transactions at most, by default.
I've been saying I think maybe the default mempool size is too small since this came up.
I think it was mentioned earlier, but is it possible to have multiple mempools? Or is that just crazytalk?
Bitcoin is an open system, with the rate of traffic generation controlled by forces outside of the system. Software and hardware performance had a finite possible throughput. Such systems have the potential to build up unbounded queues. The resources in the network have a finite storage capacity to hold unserviced transactions. This implies that transactions will have to be dropped on occasion. There are two ways to avoid excessive dropped transactions: reduce the demand by discouraging usage or increase capacity. There are only two ways to increase capacity: add additional resources or improve efficiency of system operation. If fees can cover the cost of increased capacity then the system can thrive and grow. So long as the fees can migrate to the providers of useful network resources there need not be concerned about “spam” usage. However, this is not a simple task, because it involves economic and social questions, not just distributed system technology. Therefore, it seems best to concentrate on efficiency and simplicity.
Обсуждают сегодня