Nach dem Update von Bitcoin Core auf Version 27.0 besteht die Möglichkeit OP_RETURN Outputs raus zu filtern. Ich mag die Ordinals zwar nicht, bezweifle aber, dass meine Entscheidung irgendetwas bewirkt. Es interessiert die Miner und die Blockchain doch nicht, wie ich meinen Node einstelle, oder?
Daher meine Fragen an die Experten:
Hat diese Einstellung Konsequenzen für mich oder das Netzwerk?
Macht die Erlaubnis von incoming connections diesbezüglich einen Unterschied?
Soll ich den Filter einschalten oder nicht?
Lernfähig und folgsam wie ich bin, werde ich der Schwarmintelligenz des Forums Folge leisten.
Zunächst mal die Gegenfrage: Wie geht das in Bitcoin Core 27.0? Ich habe das Feature nicht gefunden. Meines Wissens kann das Bitcoin Knots, aber nach wie vor nicht Bitcoin Core.
Falls mir da was entgangen sein sollte und es tatsächlich geht, würde ich die Fragen wie folgt beantworten: Es würde die Inscriptions oder sonstigen Spam zwar kaum aufhalten, da jeder stets die Möglichkeit hat, sich direkt mit Minern/Pools zu verbinden, die den Spam nicht rausfiltern. Allerdings würdest du dich selbst nicht an der Weiterleitung beteiligen und du würdest deine Hardware ein wenig entlasten, da sie nicht mit der Weiterleitung dieser Transaktionen beschäftigt ist. Daher würde ich es einschalten. Was genau du mit den incoming connections meinst, verstehe ich nicht so ganz, das müsstest du nochmal genauer erklären.
Ich betreibe Bitcore Core mit Umbrel und kann dort unter Advanced Settings den Filter ein- oder ausschalten.
Mit incoming connections ist der Node listening, liefert also an andere Peers, ohne holt er sich nur die Daten von der Blockchain. Jedenfalls habe ich das so verstanden.
Das hat aber eigentlich nichts mit v27.0 zu tun, bzw. ging auch schon vorher. Mich würde auch interessieren, welche Funktion du genau meinst @Beli99? Es kann natürlich sein, dass die Einstellung, von der du sprichst, einfach eine Neuerung im Umbrel UI ist.
Ah okay, aber datacarrier=0 würde tatsächlich nur OP_RETURN-Transaktionen rausfiltern, oder? Ordinals-Inscriptions benutzen kein OP_RETURN, sondern OP_FALSE OP_IF.
Das hast du, glaube ich, ein bisschen missverstanden. listening heißt nur, dass der Node eingehende Verbindungen annimmt, also dass andere Nodes sich von sich aus mit deiner Node verbinden können. Wenn man listen=0 setzt, ist dein Node nur mit Nodes verbunden, zu denen dein Node aktiv die Verbindung aufgebaut hat. Diese Verbindungen sind aber trotzdem bidirektional, also es laufen Daten in beide Richtungen.
Full nodes normally make outgoing connections (8) but can have incoming connections as well if you allow the port 8333 open from outside. Incoming connections can be other nodes or SPV wallets, for example. In order to configure your node to do that you must have port open on your local firewall and appropriate bitcoin configuration on the software.
Please note that running a personal node does not require inbound connections. So you can leave closed the 8333 port in your firewall.
@all: Ich meinte den Filter für OP_RETURN. Ordinals habe ich nur erwähnt, weil für mich Inscriptions, Runes und Ordinals alle in der selben Kategorie Spam sind.
Diesen Filter gibt es meines Wissens erst seit dem Update auf 27.0
Wie da schon steht, es ist nicht notwendig, dass du eingehende Verbindungen zulässt, du hast trotzdem die volle Funktionalität. Die incoming connections helfen nur anderen, damit sie sich ohne dein Zutun mit dir verbinden können. Falls du incoming connections über das Clearnet zulassen willst (also nicht Tor) musst du wahrscheinlich die Firewall deines Routers entsprechend konfigurieren. Ist aber, wie gesagt, nur optional.
Sehe ich ganz genauso. Allerdings basieren sie auf verschiedenen Techniken, man braucht also auch verschiedene Techniken, um sie rauszufiltern. Mit datacarrier=0 wird, wie wir oben geklärt haben, nur OP_RETURN gefiltert, damit wären die Runes schonmal weg, Inscriptions wären aber noch drin.
Du meinst das mit dem datacarrier=0? Ich versuch’s nochmal ausführlicher zu erklären: Ein Bitcoin Node leitet drei Arten von Informationen über das P2P-Netzwerk weiter:
Neu erstellte Blöcke,
neu erstellte, noch unbestätigte Transaktionen (die also noch nicht in einem Block enthalten sind), auch als Mempool bekannt und
Informationen über andere Nodes im Netzwerk, mit denen man sich verbinden kann.
datacarrier=0 wird davon nur Punkt 2 betreffen, dein Node wird also keine unbestätigten Transaktionen weiterleiten, die ein OP_RETURN enthalten. Damit wird die Propagation solcher Transaktionen durch das P2P-Netzwerk also minimal verzögert. Falls du mit deinem Node zusätzlich Solo Mining oder einen Mining Pool betreibst, werden solche Transaktionen auch nicht in die Blöcke aufgenommen, die du findest. Das kann allerdings nicht verhindern, dass andere Miner diese Transaktionen in ihre Blöcke aufnehmen. Inscriptions werden ebenso nicht aufgehalten, da diese, wie gesagt, kein OP_RETURN enthalten.
Wenn du Runes etc. (genau wie ich) für Spam hältst, würde ich die Option auf jeden Fall aktivieren. Das wird den Spam zwar kaum aufhalten, aber zumindest beteiligst du dich dann nicht selbst an dessen Weiterleitung und entlastest deine Hardware ein bisschen.
Der Vollständigkeit halber gibt es noch ein weiteres Setting, mit denen man zumindest einen Teil der Stamps filtern kann:
permitbaremultisig=0
Auf der anderen Seite bringt es nicht wirklich viel, erstens aus den Gründen, die @sypher schon erläutert hat und auch im verlinkten Beitrag erklärt werden. Zweitens, weil die Stamp Nutzer bereits anfangen ihre Daten in anderen Output-Typen zu verstecken, die man nicht pauschal filtern kann (ohne finanzielle Transaktionen auch zu filtern).
