Hallo,
haben alle mempools aller Nodes eigentlich den selben Inhalt oder braut jede Node Ihr eigenes Süppchen und die Miner bedienen sich an allen mempools um Blöcke mit Zahlungen zu füllen ?
Dieses Detail habe ich noch nicht so genau verstanden.
VG
Bitcoin ist dezentral. Es gibt nicht „den Mempool“.
Jede Node verwaltet ihren eigenen Mempool. Bei Nodes die sich auf die gleichen Regeln geeinigt haben ist dieser Mempool dann (von Zeitverzögerungen abgesehen und vereinfacht) immer identisch. Nodes brauen nicht ihr eigenes „Süppchen“ sondern sie verifizieren Transaktionen nach den ihnen bekannten Regeln.
„Die Miner“ sind Nodes. Jeder Miner hat natürlich seinen eigenen Mempool, oder den einer anderen Node der er vertraut, welchen er benutzt um einen Block Kandidaten zu bauen.
Das kann man übrigens auch selbst ausprobieren mit:
bitcoin-cli getblocktemplate '{"rules": ["segwit"]}'
Du solltest dir mal genauer anschauen wie das Netzwerk an sich überhaupt funktioniert. Also wie Transaktionen veröffentlicht und verifiziert werden, wie Blöcke veröffentlicht werden, woher eine Node weiß wann eine Information „verifiziert“ ist, und so weiter.
Also um die ursprüngliche Frage im Titel zu beantworten: Das „oder“ ist etwas irreführend. Beides ist irgendwie zutreffend.
Wenn sich jeder strikt an die Regeln (der Mathematik) halten würde wären alle Klausuren identisch, obwohl alle unabhängig voneinander durch gerechnet wurden. Wenn dann der Prof basierend auf den Ergebnissen, die jeder selbst ausrechnen kann, eine Aussage macht, kann jeder Student diese Aussage verifizieren, ohne dem Prof vertrauen zu müssen.
An einer Universität kann man sich das nur wünschen, Bitcoin macht genau das. 
Noch als kleine Ergänzung zu dem was @sutterseba sagt:
Es gibt durchaus Fälle, bei denen es plausibel ist, dass sich die Mempools unterscheiden.
Ein Miner könnte mit eigenen Transaktionen warten, bis er einen Block findet. Wenn der Mempool gerade leer ist, dann wäre das sinnvoll. Ansonsten müsste er anderen Minern die Transaktionsgebühr bezahlen. Wenn er die Transaktionen aber selbst in einem Block mit ausreichend Platz unterbringt, dann spart er sich die Transaktionskosten. Peanuts, aber prinzipiell korrekt und sinnvoll.
Falls Miner oder einige Nodes im allgemeinen bestimmte Transaktionen zensieren, dann schmeissen sie diese aus ihrem Mempool und leiten sie auch nicht weiter. Anderen Nodes wäre das womöglich egal und sie würden die Transaktionen weiterleiten. Weil die Weiterleitung von Transaktionen nicht Teil der Konsensus Regeln ist, bedeutet das auch nicht, dass das Netzwerk forkt. Schließlich würden die zensierten Transaktionen von einem indifferenten Miner in einen Block aufgenommen.
Die Mindestgebühr von 1\,sat/vB ist nicht verpflichtend. Ein Block mit Transaktionen unter dieser weichen Grenze wäre ebenso gültig. Nur ein sehr kleiner Teil der Nodes leitet diese Transaktionen weiter, aber es gibt sie. Auch hier wäre das Ergebnis, dass sich die Mempools unterscheiden.
Je nachdem wann eine Node alte Transaktionen als abgelaufen invalidiert und aus ihrem Mempool löscht, akzeptiert sie eine neue Transaktion von der gleichen utxo früher oder später. Das kommt vor, wenn sich der Mempool über einen langen Zeitraum nicht leert. Je nach Konfiguration werden diese alten Transaktionen dann aus dem Mempool gelöscht. Es bleiben aber weiterhin gültige Transaktionen. Ein Miner könnte ein Interesse daran haben, diese Transaktionen zu behalten. Es wäre unredlich, aber nicht verboten. Wenn eine eigene Transaktion nicht durchgeht, sollte man daher die gleiche utxo wiederverwenden, um auf der sicheren Seite zu sein. Jeder der diese signierte Transaktion gesehen hat, könnte sie zu einem beliebigen Zeitpunkt wieder ins Netzwerk einspeisen.
Ein thin client könnte weniger Transaktionen in seinem Mempool halten, um Speicherplatz zu sparen. Dann würden die billigsten Transaktionen früher aussortiert – unter der Annahme, dass sie von anderen Nodes wieder durch das Netzwerk propagiert würden, wenn sich der Mempool wieder leert. Der thin client hängt also in seiner Mempool Pflege etwas stärker von anderen Nodes ab.
Es gibt also in der Praxis durchaus Unterschiede. Das sind aber alles Randbereiche und stellen allesamt nicht die Konsensus Regeln in Frage.
Und deshalb ja auch der Name: Mem (Memory / Speicher) -pool.
Eine große Grabbelkiste, auf die alle zugreifen. Und kommen alle zum selben Ergebnis sind die Blöcke bestätigt.
Wenn ich mich nicht irre ist der Standardwert für den Mempool bei Raspiblitz 300MB.
Dann würde es doch auch unterschiedliche Stände des Mempool geben, wenn der Mempool eine Größe von 300MB übersteigt, oder? Also nicht nur ein Effekt bei „thinclients“.
Wobei es sicher auch nodes gibt, welche mehr als 300MB Mempool zulassen.
Nicht unbedingt. Wenn alle Nodes bei 300MB die gleichen Regeln verwenden, dann verwerfen auch alle die gleichen Transaktionen.
Das ist alles gar nicht so kompliziert. Die Datenstruktur dazu ist eine Priority queue - Wikipedia derart, dass die Priorität durch die sats/vB gegeben ist. In der Regel ist das sinnvoll und rational, aber es ist eben kein Zwang, sich an die Priorisierung von Transaktionen zu halten.
Ich habe bis vor kurzem MyNode benutzt. Der Mempool ist dort nur 250MB groß. Die Blöcke sind jedoch identisch zu Mempool.space. Nur wenn der Mempool voll war, war bei mir die Kette der wartenden Blöcke kürzer.
Bei Citadel hingegen habe ich zwar auch 300MB, aber die Blöcke unterscheiden sich sehr stark zu denen von Mempool.space.