Ich kann nur für mich sprechen:

Mich langweilt es und ich fühle mich getrollt.

Gehe ich recht in der Annahme, dass die Überweisung an 3JtCtgADg45d6jT4PDzebbW3HZykH9zoY1 ging, die paar Brocken an 1DRbGn4hKjeb2KVSdCxAGDobL4ucMBzkhu das Wechselgeld ist und du Core nutzt?

In den Core-Einstellungen findest du den Punkt: "unbestätigte Eingänge dürfen ausgegeben werden". Der Punkt muss markiert sein.

Dann überweist du mit Coin-Control (muss ebenfalls aktiviert sein) die 0.00006488 und einen anderen Betrag aus deinem Wallet mit hoher Gebühr* an dich selbst.

Das nennt sich CPFP und zieht die alte TX mit durch.

*über die genaue Höhe reden wir gleich nochmal.

Magst du uns die ID sagen oder sagen wieviel Fee pro Byte du zahlst? Dann können wir mehr sagen.

Im Moment ist es nicht mehr nötig, mehr als 30 Satoshi pro byte zu zahlen. Es hängen von Mitte Dezember nur noch Transaktionen, die damals VIEL zu wenig Gebühren gezahlt haben oder aktuell nicht (mehr) im Mempool sind.

"Vergessen" musst du deine Bitcoins übrigens nie. Bis sie in einen Block aufgenommen wird, gehören sie dir. Danach dem Empfänger. "Weg" sind sie nie.

Nochmal: Es hat nichts mit einer zeitlichen Dauer zu tun. Es hängt ausschließlich an den Gerbühren und den anderen Transaktionen im Mempool.

Durch schlaues Setzen der von dir frei gewählten Transaktionsgebühr hättest du die TX in den nächsten gefundenen Block bringen können.

Betrachte es als Freiheit selbst entscheiden zu können, ob du eine schnelle oder eine sparsame Transaktion durchführen willst.

Und genau um diese Freiheit geht es beim Bitcoin.

Bitcoin funktioniert auch mit vollem Mempool prima.

App? Nutzt du Sipgate auf dem Handy? Wenn ja, da gibt es eine eigene App von Sipgate, die sollte am einfachsten zu nutzen sein.

Die SIP-Zugangsdaten kannst du aber beispielsweise auch in deinem Router daheim (wenn er eine Telefoniefunktion hat) eingeben.

Einige Android-Handys bieten auch mit Bordmitteln ohne eigene App SIP-Funktionalität.

Um Bitcoins zu versenden benötigst du zum Erstellen der Transaktion den privaten Schlüssel. Die Aufgabe, die TX mit deinem Schlüssel zu erstellen und zu signieren, übernimmt im Normalfall die Wallet für dich, deshalb bist du bisher noch nicht darüber gestolpert.

Einige Hardware-Wallets gehen auch recht gut mit Forks um.

Wenn es dir nur um das Lagern der Coins geht und dem Abschöpfen der Fork-Coins, würde ICH einfach ein Paperwallet nutzen. Dort steht übrigens der Privkey im Klartext drauf.

Aber eben Indizien. Schließlich ist es eher unwahrscheinlich, dass du mit einem völlig Fremden gemeinsam eine Transaktion signierst. Bei "normaler" Nutzung eines Wallets sollte sich recht schnell dein Bündel genutzter Adressen offenbaren. Will man das vermeiden, muss man schon entsprechend handeln.

Anfang Januar sind doch gerade einmal knapp zwei Wochen... Ich kenne da ganz andere Transaktionen. :-)

Alles, was du tun kannst, steht aber hier in diesem Thread beschrieben. Dafür ist er nämlich da.

Hast du die TX schon mal erfolgreich in einem accelerator (z.B. ViaBTC) unterbringen können (da muss man manchmal hartnäckig sein)?

Ansonsten: CPFP, RBF, Miner bezahlen ... sowas eben. Oder Warten. Dann aber nicht nach 2 Wochen ungeduldig werden. ;-)

Edit: habe mir gerade nochmals deine beiden TXe angesehen. Eine Sofortlösung wäre CPFP. Du müsstest den Bitcoin, den du an 17nsghyBjKCpw3qxFdPUgVdhf4Gv6sr6v7 überwiesen hast (wenn dir diese Adresse gehört) mit extrem hoher Fee (kann man ausrechnen) weiter versenden. Dann wird diese TX deine beiden hängenden mit durchziehen. Ob es sich lohnt, musst du entscheiden. Fee wäre grob geschätzt umgerechnet im hohen zweistelligen Euro-Bereich. Wenn du magst, rechne ich das mal durch.
Wenn dir diese Adresse nicht gehört, ist vermutlich der knappe halbe Bitcoin das Wechselgeld. Dann eben dieses mit extrem hoher Fee weiterversenden - macht keinen Unterschied.

Edit: Ging ja jetzt schneller als gedacht, dass die 40Sat-TXe durchgehen. Der Mempool baut sich gut ab gerade.

Ich gehe nur auf diesen Punkt ein. Du gehst je auf meine Fragen und Hinweise auch nie ein.

Du sollst keinen Block erstellen um reich zu werden, du sollst auch keinen zur Diff passenden gültigen Block händisch erzeugen (das wäre nun wirklich etwas viel verlangt). Mir ging es darum, dass du überhaupt versuchst, händisch SHA zu berechnen oder einen Block zu bauen. Nur um es zu verstehen. Du bist nämlich offenbar noch weit davon entfernt SHA oder Bitcoin zu verstehen und aus diesem Grund solltest du dir um das Ausnutzen von dir ersonnener Sicherheitslücken wirklich noch keine Gedanken machen.

Ich möchte nur für BTC antworten:

Du kannst in einer Wallet ganz viele unterschiedliche Adressen haben. Diese haben aber individuelle Privat-Keys. Das hat du vielleicht etwas schlecht dargestellt.
Im jungfräulichen Zustand kann man keinerlei Zusammenhang dieser Adressen ausmachen. Es lässt sich keine Verbindung darstellen.

ABER:

Wenn du mit dieser Wallet arbeitest und versehentlich Inputs verschiedener Adressen in einer Transaktion zusammenfasst, kann es sehr leicht passieren, dass man Rückschlüsse auf dein "Adresssbündel" anstellen kann.

Als Beispiel:

Du hast ein Wallet mit drei Adressen auf die du Geld überwiesen bekommst:

Adresse A hat 1BTC empfangen,
Adresse B hat 2BTC empfangen,
Adresse C hat 3BTC empfangen.

Zu diesem Zeitpunkt ist keinerlei Zusammenhang zwischen den Adressen A, B und C für Außenstehende sichtbar. Dein Wallet enthält 6 BTC.

Überweist du jetzt 6 BTC an Adresse D, werden die Inputs der drei Adressen genutzt und an D versandt. Die ganze Welt weiß jetzt, dass es wahrscheinlich ist, dass A, B und C den selben Eigentümer haben.
Durch gezielte Analyse kann man so erstaunlich genau auf dein Wallet schließen.

Mit Coin-Control kann man dem etwas entgegenwirken. Z.B. kann man gezielt Coins auswählen, die nur auf einer Adresse liegen und nur diese gebündelt ausgeben.

Nochmal: Dein Job. Du hast mit dem Quatsch angefangen.

Danke, ich fühle mich recht sicher mit meinen privkeys.

Was jetzt?

Sag mal... ganz im Ernst... Hast du überhaupt schon mal händisch einen SHA256 ausgerechnet? Bonus: ...der dann gestimmt hat.
(Ich kanns nicht, aber wenn ich SHA256 wirklich komplett verstehen wollte, würde ich damit beginnen.)

Oder einen Bitcoin-Block gebaut? Nur so zum Spaß... Das haben schon Leute gemacht. Das sollte dir gute Erkenntnisse bringen.

Ne, ge?

Fang doch damit mal an und lass uns an deinen Notizen teilhaben.

Wieso kämpfst du jetzt plötzlich eigentlich wieder an dieser Front und nicht mehr am Rückwärtsrechnen? Was ist aus der vor wenigen Tagen erwähnten Tabellenkalkulation geworden? Fragen über Fragen.

Steht doch da. Sie garantieren. :-)

Ja, das ist normal. Der Grund dafür steht schon im Topic.

Man müsste jetzt mal schauen, WARUM die TX noch nicht gebroadcastet wurde.

Meine Güte. Es wird ja immer besser.

Der Hinweis auf die Komprimierung sollte dich nicht motivieren, jetzt auch noch die perfekte Komprimierung zu erschaffen ("Egal was du hast, ich komprimiere es auf 256Bit!") sonder sollte verdeutlichen, wo dein Denkfehler ist.

Angenommen, du hast Daten von 100 Bit und einen Hashwert von 256Bit. Dann kann man schon auf die Idee kommen, diese 100 Bit innerhalb der256 Bit zu suchen - da gebe ich dir recht.
Ja, man kann auch auf die Idee kommen mit Blöcken zu komprimieren und einen 300Bit großen Input in 256Bit großen Hashes zu suchen - okay, denkbar.

Jetzt sind wir aber wieder ganz am Anfang. Ein SHA256-Hash ist IMMER 256 Bit lang. Das ist er wenn der Input 10Bit groß ist und auch wenn der Input 10TB groß ist. Du kannst dem Hash nicht ansehen, wie groß der Input ist. Und jetzt kommts: Da es viel mehr Möglichkeiten des Inputs geben kann als es Hashes geben kann, MUSS es gleiche Hashes geben für verschiedene Inputs.

Allein diese Tatsache schließt die Möglichkeit des Rückwärtsrechnens oder des Komprimierens aus weil du gar nicht wissen kannst WELCHEN der möglichen Inputs du aus diesem Hash berechnen willst.

Denkansatz: Beispielsweise wird beim Bitcoin-Minign nicht ein bestimmter Hash gesucht sondern ein Hash, der nach der aktuellen Difficulty mit soundsovielen Nullen beginnt. Welche Energie dafür weltweit aufgewendet wird, alle 10 Minuten so einen Hash zu finden, weisst du.  Mit jeder weiteren Null (im binären Hash) verdoppelt sich die nötige Hashleistung (...und es sind noch VIELE Nullen nötig für die kompletten 256Bit).
Wenn du jetzt aber mit bruteforfe ALLE 256Bit richtig raten willst, wäre das nicht nur die allerhöchste denkbare Bitcoin-Difficulty sondern auch eine nicht vorstellbare Vervielfachung der Hashleistung.
Kurz: Bruteforce auf einen Hash ist technisch zwar möglich, die Aussicht auf Erfolg wäre aber auch mit aller verfügbaren Technik in mehreren Jahrhunderten nicht wahrscheinlich.  

Ja, warum wohl? Was erwartest du denn? Es war DEINE Idee und wir versuchen die ganze Zeit nur auf deine Denkfehler hinzuweisen.

Ich weiß nicht, ob schon Kollisionen bekannt sind bei SHA256. Ausgeschlossen ist es nicht - schon allein, weil der Hash nur eine relativ geringe Größe hat.
Das Problem und die Herausforderung ist aber eben eine Kollision gezielt herbeizuführen. Und genau das ist eben noch keinem gelungen. Dann wäre SHA nämlich wirklich kaputt.


Wie meinen?


Bitte korrigiere mich: Du willst SHA rückwärts mit Excel (o.ä.) berechnen?

Was genau glaubst du im Februar zu "schaffen" und woraus schöpfst du den Optimismus?

Ja, natürlich hängt es wieder an der Fee. bei gut 40 Sat/Byte wirst du auch noch etwas warten müssen. Aber im Moment ist es ruhig, und der Stau im Mempool wird langsam abgebaut. Erst mal abwarten.

Die erste TX baut übrigens auf der zweiten auf. somit muss erst 1645... bestätigt werden bevor 200cc.. bestätigt werden kann. Das kann aber im selben Block passieren.

Versteckte Dateien lässt du dir anzeigen?

Ich kann das nicht genau beantworten, aber vermutlich hast du Recht.
RBF scheint in der Core-GUI nur sehr einfach eingebunden zu sein. Du hast scheinbar nur die Möglichkeit, die Fee zu erhöhen (vermutlich nur auf einen vorgegebenen und akutell sinnvollen Wert) und mehr nicht. Ja, scheinbar wird der zusätzliche Betrag dann einfach vom Wechselgeld abgezogen. Man hat scheinbar nicht die Möglichkeit, die TX gezielt zu verändern oder die Fee nur leicht anzuheben. Jedenfalls nicht in der GUI. (Ich weiß allerdings auch nicht ob größere Manipulationen im Standard überhaupt vorgesehen sind.)

Ou man, dieser Satz trifft es (leider).

Ich bin ja gewiss ebenfalls weder Mathe- noch SHA-Experte aber ich wäre nie im Leben auf die Frage gekommen, wie man mit Bytes rechnen soll, die per ASCII nicht darstellbar sind.
Uff.. was soll man jetzt dazu noch sagen? Was hast du denn die ganze Zeit gemacht? Du hast doch schon an irgendwelchen Kurven rumgerechnet sagtest du. Dann fällt dir das jetzt auf Seite 10 auf?
Und was hat (das frage ich jetzt glaube ich zum 10. mal) das eigentlich mit Bitcoin zu tun (siehe Frage 4)?