Topic: Bitcoin als Zahlungsmethode akzeptieren - techn. Fragen (Read 2431 times)

+1

Sie haben Post

Dürfen wir auch erfahren um welche Seite es sich handelt?

Ich habe nun alle Hinweise berücksichtigt und denke dass nun alles zuverlässig und relativ sicher funktioniert.
Ich akzeptiere nun sofort die Zahlung bei Bekanntwerden Bitcoin-Netz und prüfe später nach ob Confirmations vorliegen. Falls die Zahlung auch nach einer Stunde noch nicht mindestens eine Confirmation bekommen hat, werde ich darüber informiert, zwecks manueller Kontrolle der Zahlung. Dies sollte bei kleineren Beträgen von <15 BTC ausreichend sein.
Vielen Dank nochmals für eure schnelle und kompetente Hilfe!

Zu 4: Ich würde den VWAP oder AVG Preis von Mtgox benutzen. Zusätzlich würde ich den letzten Preis immer in deiner DB speichern und auf diesen im Fall, dass Mtgox nicht erreichbar ist, zurückgreifen.

das ist eine sehr interessante frage. wahrscheinlich dürfte die zahlung dann gar nicht mehr existieren, weil der block in dem der angreifer sie eingebaut hat, als ungültig erkannt wurde und damit zum orphan block wird, also nicht mehr teil der blockchain ist. wenn du mit einem api call nach den transaktionen mit 2 confirmations an eine bestimmte adresse fragst, ist es aber egal ob es gar keine transaktion gibt oder noch eine mit 0 confirmations rumliegt. das ergebnis ist beide male leer.
eine confirmation reicht aber. die finney attack funktioniert so, daß jemand, wenn einen block findet, ihn nicht sofort veröffentlicht, sondern erst noch irgendwo (z.b. in deinem shop) sein geld ausgibt, und wartet bis du die zahlung im netzwerk siehst.  dann veröffentlicht er schnell den block, in dem die bitcoins, die dir überwiesen werden sollten, an eine andere, eigene adresse überwiesen werden. dadurch kann die ursprünglich transaktion an dich nicht mehr ausgeführt werden. dazu braucht man nicht unbedingt massivste rechnenpower. aber man muss halt erstmal einen block finden, alleine der versuch lohnt sich also nur wenn man eine reelle chance hat einen block zu finden. außerdem riskiert der angreifer, daß jemand in dem kurzen zeitraum, den der unbestätigte zahlungsvorgang an dich dauert, auch einen block findet und dann kann er den eigenen block samt den 50btc belohnung in den müll werfen.

Ich erstelle bei der gewünschten Zahlung mit getnewaddress [account] eine Adresse an die dann gezahlt wird.
Danach prüfe ich alle 5 Sekunden mit getreceivedbyaddress

• , ob eine Zahlung eingegangen ist, die aber noch keine Confirmation haben muss. Diese Zahlung nehme ich zunächst als gültig an, mit einem Vermerk dass diese Zahlung noch nicht Confirmed wurde.

Meine Idee zur späteren Verifikation der Zahlung ist, die min. Confirmations bei getreceivedbyaddress auf z.B. 3 zu setzen, und falls der Betrag dem in der Datenbank entspricht, die Zahlung fest zu verbuchen.
Meine Frage ist nun, was passiert falls es sich um eine Double-Spend Attacke handelt. Dann würde die Zahlungen ja ewig in "unconfirmed" stehen bleiben.
Wie sollte man die Zahlungen also später verifizieren? Kann ich bei erfolgter Zahlung mit 0 Confirmations die Anzahl der generierten Blöcke speichern, und falls 2 weitere Blöcke generiert wurden und die Zahlung noch 0 Confirmations hat, die Zahlung stornieren, da es sich um eine Double-Spending Attacke handeln muss.
Ist diese Annahme korrekt?

Naja, du wirst bei einem Bezahlsystem auf die API Calls gettransaction  oder listreceivedbyaddress  zurückgreifen, je nach herangehensweise. Dort werden die Confirmations bereits für jede Transaktion gespeichert.

Bei meinem System checke ich "einfach" ob auf der Adresse des Users eine neue Transaction angekommen ist und erstelle eine entsprechende Reihe in meiner DB. Danach prüfe ich die Confirms so lange bis sie größer als 6 sind und nehme die Transaktion an.

Ich danke euch für die Antworten! 

Da es sich bei aktuellem Kurs nur um Transaktionen im Bereich von ca. 10-20 BTC handelt, werde ich die Transaktionen wohl zusätzlich nach Eingang über Transaction Radar prüfen und zunächst als gültig ansehen. Und selbst bei einem unwahrscheinlichen Fall von Double-Spending kann ich den entsprechenden Benutzer auch noch sperren, da nur Laufzeit gekauft wird und keine Waren o.ä.
Als Endgültig werde ich Transaktionen allerdings nur behandeln, falls ich einige Confirmations bekommen habe.
Es stellt sich mir nun die Frage, wie man diese Confirmations nun am besten prüfen kann.
Sollte man zusätzlich bei erstem Empfang der Transaktion die Anzahl der generierten Blöcke in die Datenbank mit aufnehmen und sobald nach z.B. 2 weiteren Blöcken die Transaktion noch nicht mindestens eine Bestätigung bekommen hat, die Zahlung als ungültig markieren? Oder gibt es dafür eine einfachere/bessere Möglichkeit?
Wenn ich nur nach Confirmations prüfe, bleiben "Double-Spending" Zahlungen dauerhaft mit 0 Confirmations stehen oder?
Nach Zeit will ich allerdings auch nicht gehen, da ja nicht absehbar ist wann der nächste Block generiert wird ...

Ich hoffe ihr könnt mir hiermit nochmal helfen und ein paar Tipps geben.

Es gibt prinzipiell zwei verschiedene Arten von double-spending: broadcasten von widersprüchlichen Transaktionen und die sogenannte Finney-Attacke. Erstere ist einfach durchzuführen aber leicht zu erkennen und hat geringe Erfolgswahrscheinlichkeit. Ich empfehle dir dazu auf jeden Fall ca. 10 Sekunden nachdem du die Transaktion im Netzwerk registriert hast zu warten und dann auf einen Dienst wie zBsp http://transactionradar.com zurückzugreifen. Dort siehst du wie die Transaktion im Netz propagiert wurde. Diese Messmethode ist nicht absolut fehlerfrei aber wenn du dort einen Wert > 95% erhältst dann kannst du die Transaktion getrost als akzeptiert annehmen, auch ohne confirmations.

Die Finney-Attacke ist hingegen bei weitem schwerer zu entdecken und die einzig zuverlässige Methode sich dagegen zu schützen ist mindestens eine confirmation abzuwarten. Für diese Art des double-spendings benötigt der Angreifer jedoch eine recht hohe Hashleistung und ist daher auch nicht sehr wahrscheinlich.

Mein Rat: für Beträge unter, sagen wir 100 BTC, kannst du mit oben genannter Methode ohne Probleme die Zahlung auch unbestätigt akzeptieren. Für Beträge unter 1000 BTC würde ich 1 confirmation abwarten, für alles darüber 6.

Generell wird das Risiko eines double-spendings meines Erachtens eher überschätzt und eine unbestätigte BTC-Transaktion ist wohl immer noch weit sicherer als eine Paypal-Zahlung

nur ein Nachtrag:

zu den confirms, 6 werden benötigt, das eine Zahlung innerhalb des Netzes als valid markiert wird, bei dem Schwierigkeitsgrad reichen aber wohl 3 aus, damit man sichergeht. Das sollte auch verkraftbar sein dauert ja nur 20-60 minuten.

Bisher habe ich, in Bitcoins, noch keine Double Spendings erlebt, sind auch afaik recht unwahrscheinlich. Am ebsten schützt du dich dadurch, dass du mehrere Confirms abwartest, bist du die Coins gutschreibst.


Mit jedem Block, der auf die Transaktion folgt erhält diese eine Confirmation


Nein. Eher sogar im Gegenteil. Aber da derartige Probleme eigentlich erst bei einem 51% Angriff passieren ist die Gefahr so oder so recht gering.


Ja, ist imho die beste Referenz.


Kurzum: Um Bitcoin Zahlungen zu empfangen solltest du immer mehrere Confirms abwarten, denke 6 bis 10 sind ok (jedenfalls der standardwert bei den meisten Seiten). Darüber hinaus ist eigentlich nur wenig wirklich sinnvoll.

Hallo,

Ich will auf meiner Seite künftig auch Bitcoin akzeptieren. Da es sich um eine Online-Dienstleistung handelt sollte der Bezahlungsprozess möglichst schnell abgewickelt werden.
Ich habe es testweise so implementiert dass Zahlungen, die im Bitcoin-Netzwerk bekannt gegeben werden, auch sofort verbucht werden.
Es soll noch eine Überprüfung dazukommen ob diese Zahlung nun wirklich durchgeführt wurden, und falls nicht der entsprechende Account geblockt bzw. die Zahlung aus dem System entfernt wird.

Dazu habe ich auch noch einige Fragen:
1. Wie wahrscheinlich ist Double-Spending und gibt es eine möglichst schnelle zuverlässige Methode dies zu erkennen?
2. Wird eine Zahlung immer sofort mit dem nächsten (oder übernächsten) Block eine Confirmation bekommen, oder kann dies auch mehrere Blöcke dauern?
3. Macht es Sinn, den Bitcoin-Client der die Zahlungen prüft anzuweisen, sich nur mit bestimmten "Trusted"-Clients zu verbinden, keine Verbindungen von Außerhalb zu akzeptieren und auch nicht im IRC nach weiteren Peers zu suchen? Wird dadurch die Gefahr von Fake-Zahlungen/Double-Spending verringert?
4. Wie sollte der aktuelle Umrechnungskurs berechnet werden? Ich möchte nämlich ein System was sich selbständig anpasst, da meine Kalkulationen auf Euro basieren und leider der Bitcoin-Kurs immernoch ziemlich schwankt. Zur Umrechnung benutze ich zur Zeit folgende API von Mt.Gox: https://mtgox.com/api/1/BTCEUR/public/ticker . Ist diese Methode sinnvoll?

Schonmal vielen Dank für eure Antworten und Hilfe!