jetzt ist ein guter zeitpunkt um ein utxo-management zu machen!
denn momentan ist der mempool eer und die Gebühren liegen bei 0,10 sat/vb

 

Hier steht im Vordergrund die Coins günstig an sich selbst zu schicken und nicht an eine Exchange
Manchen Menschen fällt sowas erst ein wenn die Gebühren (wieder) bei 30€ pro Byte liegen und jammern dann rum.

Daher jetzt Adressen mit mehreren Inputs gesund schrumpfen und bei der nächsten Gebührenschlacht nicht ganz so stark bluten wie viele andere.

In diesem englischen Thread ab dem verlinkten Post findet ihr einige Infos wie Transaktionen unter 1 sat/vbyte bestätigt werden können. Kurzfassung: am besten direkt zu den Minern senden, ihr findet im Faden einige Links dazu, z.B: https://mempool.space/tx/push.

Ein Problem ist auch, dass zumindest über das grafische Standard-Interface einige Wallets wie Electrum eine solche Transaktion erst gar nicht erlauben, zu erstellen. Hier steht, dass es mit dem "Pay to many" Feature bei Electrum funktioniert. Ich werde es demnächst mal selbst ausprobieren, wenn ich wieder UTXOs zum konsolidieren habe.

Danke für die Info. Aber vielleicht bedarf dieser Teil einer Erklärung. Was genau kann "teuer werden"? Ist gemeint, dass die Transaktion am Ende doch festsitzt und man dann doch gezwungen ist, per RBF die Gebühr zu erhöhen? Eigentlich sind ja die "etwas höheren" Gebühren die wir zeitweise sehen (2-3 sat/vByte) immer noch traumhaft, wenn wir sie mit 2023/24 vergleichen.

Mal eine Frage zu dem Punkt: Die Bitcoin Adresse ist doch eine Ableitung bzw. quasi Verkürzung des öffentlichen Schlüssels. Ist es nicht möglich davon auf dem eigentlichen öffentlichen Schlüssel zu schließen? Davon bin ich eigentlich immer ausgegangen, dass die BTC-Adresse nur eine Vereinfachung dessen ist. Falls dem so sei, dann wäre es doch egal, ob man eine Transaktionen ausführt, die dann den ganzen öffentlichen Schlüssel freilegt, da über die BTC-Adresse die Bitcoin enthält und in der Chain ist, auch darauf geschlossen werden kann  

Die Mathematik dahinter ist ECDLP = Elliptic Curve Discrete Logarithm Problem.

Vereinfacht erklärt ist das so:
Der Private Key ist eine Zufallszahl, bspw. 256 Bit.
Der Public Key entsteht nun dadurch, dass man als Grundlage eine elliptische Kurve nimmt. Diese hat einen festen Startpunkt G. Du nimmst nun deinen Private Key k und berechnest k * G, was außerordentlich einfach ist und gleichzeitig auch einen Punkt auf dieser Kurve ergibt ... das ist der Public Key P.

Das Rückwärtsrechnen, also von P auf k, ist mit derzeitigen technischen Mitteln nicht möglich. Es gibt zwar Angriffsmuster wie Pollards Rho, diese sind aber exponentiell in der Bit-Länge. Bei unserem 256 Bit Schlüssel ist das quasi unmöglich zu berechnen - derzeit.

Das stimmt zwar für den Public/Private-Key, aber nicht für die Adressen, die mit mehreren Schritten SHA-256 und RIPEMD-160 berechnet werden und dann am Ende noch in das Adressformat, also entweder Base58 (legacy) oder bech32 konvertiert werden.

Da mich das gerade mal interessiert hat habe ichs mir mal angeschaut wie diese Algorithmus arbeitet. Der Wikipedia-Artikel dazu ist auch eher was für Mathematiker.  

SHA-256 (eine Variante von SHA-2 mit 256 bits) ist ein fünfstufiger Prozess bei dem das Ziel ist, dass der Hash (also das Resultat der Rechenoperation) genau 256 Bit hat.

1) Zuerst wird an die Originalzahl in binärer Form (also in diesem Fall den Public Key in Nullen und Einsen) eine 1 angehängt, und dann so viele Nullen, dass das Ergebnis in Blöcke von genau 512 bits Länge teilbar ist (sog. Padding). Ganz am Ende werden 64 bit reserviert um die Länge der originalen Zahl zu kodieren.

2) Nachricht wird in Blöcke von 512 bit Länge geteilt.

3) In 64 Runden werden mehrere Rechenoperationen auf den ersten Block angewendet. Dieser wird dabei in 16 Blöcke mit je 32 bit aufgeteilt. Als Startwerte werden Konstanten genommen die von Primzahlen abgeleitet werden, diese und die 32-bit-Blöcke sind die Grundwerte der Rechenoperationen. Das Wichtige dabei: Einige dieser Operationen sind Modulo-Operationen. Das Ergebnis ist auf 32 bit begrenzt, die Operationen können aber zu Zahlen führen, die "zu groß" ausfallen - dann werden nur die letzten 32 bit berücksichtigt. Das heißt, dieser Prozess ist destruktiv, man kann die Rechenoperationen nicht umkehren. Am Ende erhält man nur noch 8 (nicht meht 16) 32-bit-Blöcke.

4) Ist mehr als ein 512-bit-Block vorhanden, dann sind die 8 Endwerte der Operationen auf den ersten Block die Startwerte für die Operationen des zweiten Blocks, und so weiter, bis der letzte Block verarbeitet wurde. Das stellt sicher dass der Hash unterschiedlich wird, selbst wenn nur irgendwo ein Bit der Originalnachricht verändert wurde. Sind z.B. 5 Blöcke vorhanden und im 2. Block wird ein Bit verändert, dann für das schon dazu, dass der Endwert der 64 Runden des 2. Blocks sich stark ändert und der 3. Block schon einen ganz anderen Startwert erhält.

5) Nach der Verarbeitung des letzten Blocks werden die acht 32-bit-Blöcke des Ergebnisses aneinandergereiht und ergeben den 256-bit-Hash. Der wird meistens als hexadezimale Zahl mit 64 Stellen angezeigt.

RIPEMD-160 arbeitet grundsätzlich ähnlich, aber die Runden sind anders organisiert.

Man kann also selbst als Laie erahnen, warum der Hash eine "EInbahnstraße" ist und nicht zurückgerechnet werden kann, und warum es so schwierig ist, genau einen gleichen Hash mit einer anderen Zahl zu ezeugen, weil winzige Änderung der Originalzahl irgendwo in einer "Runde" ein komplett anderes Ergebnis ergeben, das dann für alle anderen Schritte als Startwert gilt und damit den ganzen Hash "durcheinanderbringt".

Interessant ist, dass SHA2 aus den USA stammt (2001 von der NSA entwickelt) während RIPEMD europäisch ist (1993/96 von RIPE entwickelt), genauer gesagt stammt der Algorithmus aus Belgien.