firstly trying to get mempools synced is meant to be about if everyone has the same tx set before a pool mines a block, then all that needs to be sent as a confirmed block is the headers and list of txid's. thus reducing the data needed to be sent when a confirmed block is created.
Our work is not related to making "mempools synced", though they are naturally similar.
Our work is exclusively related to eliminating the massive overheads from relaying transactions the first time through as they go around the network.
to then suddenly need to grab hundreds of transactions from X and hundreds of tx from Y AGAIN
That doesn't happen in the Bitcoin protocol, no one has proposed for it to happen, and it isn't needed.
It's really a shame that people are forced to waste their time correcting you simply because you are so persistent and voluminous in your inaccuracies that you manage to confuse many people even though your posts are not very convincing.
i do find it funny that it was these very same devs that wanted a fee freemarket by removing a fee priority mechanism to make individualising mempools, that are now seeing the flaw in it..
Your statement here makes no sense. Nodes prioritize transactions by feerate, none of that has been removed. The only "individualizing" in practice is that a low memory host might reduce their mempool size. This is, in any case, totally unrelated to removing the relay inefficiencies.
but allowing nodes to relay tx's and drop them due to "fee free market" but then have to interrogate nodes to list their entire mempools(actually causing more bandwidth) and pick up the tx's AGAIN(more bandwidth again).. is silly..
Again, Bitcoin nodes don't interrogate nodes to list mempools nor pick up transactions again, no one has proposed they do, because there is no reason to do that.
Just pre-empting another confused tangent: There is a "mempool" p2p message which was added to the protocol by bitpay for the purpose of surveilling the network under a dishonest justification, which was later realized to be a privacy problem and the privacy leak was removed (and after that bitpay's staff recommended removing it from the protocol). Bitcoin Core has no ability to send a mempool p2p request and never has had the ability to do so. It might be interesting to do so at initial startup to quick start the mempool and give miners something to mine after being offline for a while, but at the moment no one is working on that, AFAIK.
they all initially did get 1,2,3,4,a,b,c,d at initial relay..
The problem we are addressing is that if you have 100 peers, each of your hundred peers will advertise (or have advertised to them) each of those 8 transactions, using 100x the bandwidth on those advertisements as if you had only one peer.
the solution is much more simple.. get rid of the free market that lets nodes drop tx's in the initial relay. thus they would ALL have them all first go-around. without having to interrogate EACH connected node, after dropping.. because their would be no drop in the first place.
The need for nodes to potentially drop transactions has nothing to do with free market behaviour and everything to do with nodes not having infinite storage to keep the transactions. But there is,
again, no interrogation-- they don't need to go refetch them again.
X)now the first node has to ask the third node for the list.. 1,a,b,c,d (more data than initial relay)
y)now the first node has to ask the third node for the missing.. d (more data than initial relay)
You've misunderstood what we've accomplished here.
If at some point during the initial relay of transactions, you receive from your other peers TX A, B, C, D, E, F and I get TX B, C, D, E, F In the historical Bitcoin protocol each of those 6 values would be sent across the link between us (potentially twice).
Instead, you could send me the single value X = A xor B xor C xor D xor E xor F, or I could send you the single value Y = B xor C xor D xor E xor F.
After the single value is exchanged whomever received it computes X xor Y = A -- the missing transaction, even though neither of us knew in advance which transaction was missing.
Minisketch generalizes this to support any number of differences. The data sent is exactly equal to the number of different values, regardless of how big the original sets are. (In fact, the first value in a minisketch is exactly what I described above: the xor of all the elements in your set).
So, if you have received in relay A, B, C, D ... X and I have already received B, C, D ... X, Y, Z; Then I need send you only three values (or you me): The xor of all my values, the xor of all my values cubed, and the xor of all my values to the fifth power... and then you will know that I am missing A from you, and you are missing Y, Z from me. And by doing this we send only three values on the link between us in the initial relay instead of 26 - 52 (depending on how much duplication there is from concurrent sends).
by getting rid of the "free market" and getting back to a consensus fee priority formulae/structure that everyone follows means
There has never been and can never been a "consensus priority formula", because priority by its very definition is external to consensus. But the behaviour of existing nodes is consistent-- they keep and drop the same transactions, subject to having them in the first place, and subject to the restriction that anything configured to use less memory obviously can't keep as much.
to then not need to re-interrogate nodes and re-relay transactions.. then you will get to conect to 16-24 nodes as oppose to 8. and no need extra bandwidth and commands/sums playing around.
There is no re-interrogation, no-rerelay in Bitcoin, nor is any proposed. It exists only in the imaginary protocol that you spend your days attacking and confusing people with. The inefficiency in Bitcoin that we're working to resolve exists in the initial relay itself, and would still exists even if nodes had no mempools at all.
Poll
