Wartezeit beim Bezahlen mit bitcoin?!

[FeeTisch]

Hallo,

ich hätte mal eine Frage zur Praxis beim Einkaufen mit bitcoin.

Wann immer ich irgendwo irgendetwas mit bitcoin bezahle, muss ich (mindestens) 10 Minuten warten, bis die Transaktion bestätigt ist. Ich hab irgendwo gelesen, daß man bei 6 Bestätigungen sogar erst relativ sicher sein kann, daß die Transaktion auch ok ist.

Für ein "schnell mal was Einkaufen" ist das doch eher hinderlich, oder?

[groocer]

Für schnell mal ne Kleinigkeit Einkaufen gibt es Lightning. On Chain BTC Abwicklung ist zu teuer und zu langsam um damit "schnell mal was einzukaufen".

 

https://lightning.network/

Bearbeitet 9. August 2022 von groocer

[FeeTisch]

vor 23 Minuten schrieb groocer:

Für schnell mal ... gibt es Lightning...

Dieses Stichwort fehlte mir. Vielen Dank. 👍

[MenionLeah]

Am 9.8.2022 um 16:27 schrieb FeeTisch:

Hallo,

ich hätte mal eine Frage zur Praxis beim Einkaufen mit bitcoin.

Wann immer ich irgendwo irgendetwas mit bitcoin bezahle, muss ich (mindestens) 10 Minuten warten, bis die Transaktion bestätigt ist. Ich hab irgendwo gelesen, daß man bei 6 Bestätigungen sogar erst relativ sicher sein kann, daß die Transaktion auch ok ist.

Für ein "schnell mal was Einkaufen" ist das doch eher hinderlich, oder?

Das ist auf jeden Fall hinderlich. Theoretisch kann die Bestätigung auch viel länger dauern als 10 Minuten, denn ob der Miner, der den nächsten Block erstellt auch DEINE Transaktion mit in den Block aufgenommen hat, ist ja nicht sichergestellt.

Ein interessantes Gedankenspiel ist aber Folgendes: DASS deine Transaktion im Netzwerk ist und im Pool der Miner auf die Aufnahme in einen Block wartet, lässt sich sehr schnell bestimmen (Sekunden). Geht es um kleine Beträge, könnte das für den "Empfänger" schon ausreichend sein, denn die Wahrscheinlichkeit, dass diese Transaktion es nie in einen Block schafft, ist sehr gering. Sowas nennt sich "zero confirmation", wenn ich nicht irre. Das kann man sich in etwa so vorstellen. Du willst mit dem Bus irgendwo hinfahren. Dass du dort angekommen bist, lässt sich nur dann bestätigen, wenn du wirklich am Ziel aussteigst. Dass du zur Haltestelle gehst und dort wartest, kann man aber sofort sehen, auch wenn vielleicht die nächsten zwei Busse dich wegen Überfüllung nicht mitnehmen können (nur das Prinzip des: Von der Haltestelle wieder weggehen gibt es bei Bitcoin nicht. Wenn die Transaktion einmal abgeschickt ist und im Netzwerk, gibt es kein Zurück).

[Cricktor]

vor 40 Minuten schrieb MenionLeah:

(nur das Prinzip des: Von der Haltestelle wieder weggehen gibt es bei Bitcoin nicht. Wenn die Transaktion einmal abgeschickt ist und im Netzwerk, gibt es kein Zurück).

Das würde ich so nicht unterschreiben, da du als Sender durchaus noch Möglichkeiten hast, Einfluß auf deine Transaktion im Mempool zu nehmen. Ob und inwiefern man die dann noch als Sender "umleiten" kann, solange keine Bestätigung vorliegt, die Transaktion also noch im Mempool darauf wartet, muss ich auch erst nochmal nachschlagen. Die Details dazu habe ich aber nicht so sicher im Kopf, als daß ich mich dazu konkret jetzt äußern möchte. Will ja deinen Quatsch verbreiten. (Stichworte sind: RBF und CPFP)

Zero confirmation policy birgt für den Handelspartner einige Risiken, besonders wenn RBF (Replace-By-(higher)-Fee) bei der Transaktion aktiv ist. Ich muss mir auch nochmal ansehen, ob und was mit Child-Pays-For-Parent-Transaktionen (Stichwort: CPFP) in diesem Zusammenhang möglich ist, wenn z.B. optionales RBF für die Transaktion nicht aktiviert wurde. (Details vergessen...)

Im Prinzip kann man mittlerweile nach zwei Bestätigungen ziemlich sicher sein, daß es zu keinem Chain-Split mehr kommen wird. Wenn ich meine RaspiBlitz-Node befrage, dann waren eigentlich alle letzten normalen "orphaned" Chain-splits nur mit einer Zweiglänge von 1 zu sehen:

admin@raspiblitz:~ $ bitcoin-cli getchaintips
[
  {
    "height": 750575,
    "hash": "00000000000000000005a94c416e7e9af91432937c9ec8a4e4763adfc7f9df66",
    "branchlen": 0,
    "status": "active"
  },
  {
    "height": 733430,
    "hash": "00000000000000000006ead1cff09f279f7beb31a7290c2a603b0776d98dc334",
    "branchlen": 1,
    "status": "valid-headers"
  },
  {
    "height": 730848,
    "hash": "000000000000000000029ec31578132d01696910f299f8d104f29b8f8bbdc24f",
    "branchlen": 1,
    "status": "valid-headers"
  },
  {
    "height": 723102,
    "hash": "00000000000000000006a970fdd8e537521747aff917d909bf3a78b4b68143e1",
    "branchlen": 1,
    "status": "valid-headers"
  },
  {
    "height": 714637,
    "hash": "00000000000000000009f819d004fea5bcb77bda25f4906d0a39e79c9ba19590",
    "branchlen": 1,
    "status": "valid-fork"
  },
  {
    "height": 705970,
    "hash": "00000000000000000002328fe71f98eff128c9566bbf344d76234570b4a96e69",
    "branchlen": 1,
    "status": "valid-headers"
  },
  {
    "height": 697008,
    "hash": "000000000000000000077247c3ca9bae18511418667c4562fc6f92477b5d339e",
    "branchlen": 1,
    "status": "valid-headers"
  },
  {
    "height": 696145,
    "hash": "00000000000000000007c8948e5a89cd01804b7e5c6f454597c49d5b3b368b66",
    "branchlen": 1,
    "status": "valid-headers"
  },
  {
    "height": 694157,
    "hash": "00000000000000000006e24bdc5c1875fa40909ace270fb2b8756ac652ede82d",
    "branchlen": 1,
    "status": "valid-headers"
  },
  {
    "height": 693118,
    "hash": "00000000000000000011563e0ffef300d61465d69c92875e510050fc332bbe99",
    "branchlen": 1,
    "status": "valid-headers"
  }
]

 

Bearbeitet 22. August 2022 von Cricktor

[MenionLeah]

RBF und CPFP kenne ich noch gar nicht, aber ich glaube, wir haben den Bereich "Einsteiger" schon lange verlassen :-)
Eine Sache noch, die ich immer lustig finde. Die sogenannten "orphans" sind in Wirklichkeit ja gar keine "Waisen" (haben keine Eltern) sondern das Gegenteil... sie haben keine Kinder ;-) (Oder zumindest nicht viele)

[Cricktor]

Stimmt, es sind im Sinne der Wortbedeutung keine Waisen, sondern aufgegebene Kettenabzweige.

Nach einem Chain-Split wird nach Konsensregeln die Hauptkette mit dem größeren Anteil Proof-of-Work fortgesetzt, der unterlegene Kettenabzweig wird aufgegeben und dessen in Blöcken gesammelte Transaktionen wandern zurück in den Mempool, sofern sie nicht schon in der weitergeführten Hauptkette bestätigt wurden (etwas arg vereinfacht).

[fox42]

CPFP scheint für mich kein Problem zu sein. Im Gegenteil. Der Empfänger kann der Transaktion helfen, dass die überhaupt in einen Block genommen wird und nicht nach Wochen irgendwann aus dem Mempool verschwindet oder so.

RBF ist interessanter, wenn man dort in der TX den Empfänger ändert.. Einfache Lösung wäre, zero confirmations nur bei deaktiviertem RBF zu akzeptieren.

Man muss natürlich auch sehen, vor was man sich schützen will und was man schützen will. Wenn der Kaffee für 2,60€ bezahlt wird, darf man sich die Frage stellen, wie viel Aufwand das wäre, diese TX rückgängig zu machen. RBF könnte ein versierter Nutzer schnell via Script automatisieren - also muss man das ausschließen. Wenn die TX aber schon in einem Block gelandet ist, ist es mit extremen Aufwand verbunden, diesen Block mutwillig durch eine 51% Attacke zu invalidieren. Bei einem zufälligen Fork ist die Wahrscheinlichkeit aber doch immer noch sehr hoch, dass die Transaktion direkt auch in die längere Kette wandert. Oder anders gesagt: Als Angreifer komme ich doch nicht so recht dazu, die TX in der Zwischenzeit irgendwie zu kompromittieren - und schon gar nicht für <2,60€ Aufwand. 

[Cricktor]

Das ist auch das, was ich so im Kopf habe. Bei aktiviertem RBF wäre Zero Confirmation Policy und höheren Beträgen zu riskant, bei niedrigeren Beträgen wird der Empfänger ggf. das Risiko akzeptieren, lohnt ja für den Sender nicht wirklich zu betuppen. Wobei ja der Kaffee geradezu nach Lightning schreit und so'n Kleinschiss nur dann On-chain gehen sollte, wenn gerade große Mempool-Langeweile herrscht.

CPFP sieht man immer wieder bei den Klau-Bots für die öffentlich bekannten Private Keys, wo immer wieder irgendwelche Dölmer durchaus größere Beträge auf die zugehörigen Adressen werfen. Das dauert meist nur wenige Sekunden bis die CPFP-Transaktion in den Mempool nachgeschoben wird. Bei den 0,9 BTC unten hat es anscheinend ungewöhnlich länger für die CPFP-Transaktion gedauert (fast 10 Minuten), aber leider gibt es nur wenige Blockexplorer (wie z.B. blockchain.com/explorer), die den Zeitpunkt des Aufschlagens in deren Mempool aufzeichnen. Die Blockzeit nützt hier wenig als Datum.

Gerade heute erst wieder um 21:20 70000sat auf die 1BoatSLRHtKNngkdXEeobR76b53LETtpyT (Vanitygen-Beispiel auf bitcointalk.org)
Beladen: Tx 64d0dc9bf41542e11f525c08562f482260796999c546dbaf5cf4f548d3de54ab
Geklaut: Tx ce4cf50b5d6d5f67b88e37f665225967a3bb34d012ddeccd36073b1f7364d113

14.8.2022, 17:02: 0,02120713 BTC auf 1LagHJk2FyCV2VzrNHVqg3gYG4TSYwDV4m (Raw Private Key ist Hex 00...0002)
Beladen: Tx a149d13dd2dcc44366b447de2fc8c15ed7289e93ab3c72a94e94bf80be9b3584
Geklaut: Tx 7b3fd1cf0d8c2f781fe0a25ad98538491ee4b9e827e83b5ac1e243ef2b670d91

27.7.2022, 20:20: 0,9 BTC (!) auf 1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN (Private Key ist SHA256(""), also Brainwallet von leerer "Geheimphrase")
Beladen: Tx 37e166a1e52e96bcfe535738082e328ef8db56aafd6945d9cad6f2afdb34b4a4
Geklaut: Tx 57a9a8192a86e168a4c77f933894897f16077c44ae5b959debfe3d9aaa654f13

 

Bearbeitet 23. August 2022 von Cricktor