Quote from: gmaxwell on July 07, 2015, 02:41:27 AM

Quote from: solex on July 07, 2015, 12:49:01 AM

Clean and synched mempools makes for a cleaner blockchain, else garbage in - garbage out. Most mempools are synched because node owners don't usually mess with tx policy. They accept the defaults.

The blockchain itself constain substantial counter-eficidence. Any block over 750k is running with changed settings; as are a substantial chunk of the transactions. I think this is all well and good, but it's not the case that its all consistent.

Quote

Quote from: gmaxwell on July 06, 2015, 06:49:46 PM

IBLT doesn't currently exist, and other mechenisms like the relay network protocol don't care about mempool synchronization levels.

IBLT does exist as it has been prototyped by Kalle and Rusty. It is just nowhere near ready for a pull request.

It has never relayed a _single_ block, not in a lab, not anywhere. It does _not_ exist. It certantly can and will exist-- though it's not yet clear how useful it will be over the relay network-- Gavin, for example, doesn't believe it will be useful "until blocks are hundreds of megabytes".

While you are bumming around here, Greg, perhaps you could comment on the first thing which hit me when I looked into IBLT. Nobody else has. The thought hit my partially because of who seemed to be promoting it.

1) w/ question

Solex posits the 'garbage in/garbage out' principle which IBLT is supposed to be able to address by helping everyone's mempool be syncronized. It imediately struck me that some (if not most) people would consider blacklisted or non-whitelisted UTXOs as being 'garbage'. It struck me that IBLT could be used as an efficient way for miners to be sure that they had 'properly' cleared their transaction list of 'garbage' transactions so they didn't 'waste their time' mining the 'wrong' transactions. Has that danger/potential been explored by the techies?

2) w/o question

From my time as a mechanic and having a life-long interest in mechanical things, I will state that for optimizing efficiency and power, tight tolerances and precision are the way to go. The trouble is that fairly small things that go wrong (say, a partial blockage of the radiator) can cause them to seize up. When I raced motorcycles, the high performance ones were expected to be re-built after each race and the performance decline if one did not do this, or if any little thing went wrong was very noticeable and always fatal if one was performing near the top of the field (I was not.)

For rugged dependability one wants sloppy clearances, way over-designed parts, etc. They don't run efficiently, but a lot of time that does not matter. The most important thing is that the performance is predictable.

Trying valiantly to achieve high precision synchronization of every miner's mempools in nearly real-time across a network which is (hopefully) deliberately distributed seems like a bad idea. Loose 'blocked' tolerances in transaction sequencing leaving construction completely up to individual miners just somehow 'feels' to me to be the way to go from a defensibly standpoint. (Of course I don't give two shits about 0-conf transactions and consider them a negative, so it's easier for me to feel this way.)

Quote from: gmaxwell on July 07, 2015, 02:41:27 AM

But don't you think that I'm saying anything bad about it-- I'm not. Cypherdoc was arguing that mempools were (and had) to be the same, and cited IBLT as a reason---- but it cannot currently be a reason, because it doesn't exist. Be careful about assigning virtue to the common fate aspect of it-- as it can make censorship much worse. (OTOH, rusty's latest optimizations reduce the need for consistency; and my network block coding idea-- which is what insired IBLT, but is more complex-- basically eliminates consistency pressure entirely)
...

Praise God!