Topic: Multisig Escrow (Read 5475 times)

Ich habe die Seite überarbeitet, Änderungen aus der Originalversion eingebaut und nutze ein neues DNSSEC/TLSA gesichertes Zertifikat mit den folgenden Fingerprints.

SHA1: SHA256:
Die interessanteste Änderung dürfte sein, daß man nun den Public Key eines Mediator (Escrower/Treuhänder) beim Erstellen einer Multisig Adresse direkt einfügen kann. Ich habe die Schlüssel von mezzomix, OutCast3K und meinen eigenen eingebaut. Bei Interesse kann ich weitere Schlüssel von vertrauenswürdigen Nutzern ebenfalls aufnehmen.

Daneben lässt sich nun einstellen, von welchem Service die Unspent Transaktionen geladen werden und über welchen Service Transaktionen ins Bitcoin Netzwerk gestellt werden. Unterstützt werden nun neben blockchain.info auch blockr.io und coinb.in.

Den Source-Code findet ihr auf github unter https://github.com/real1510/multisig.

Ich habe den Fork nochmal neu aufgesetzt und mit der Version von OutCast3k synchronisiert. Der aktuelle Stand ist nun unter https://github.com/real1510/multisig zu finden. Die Onlineversion unter https://multisig.btcnet.eu/ ist ebenfalls auf dem aktuelle github Stand.

Beim Signieren werden nun keine Random k Werte mehr genutzt sondern deterministische Werte nach RFC 6979. Außerdem wird der s Wert entsprechend den BIP62 Regeln behandelt.

Es wird weiterhin blockchain.info benutzt um die unspent transactions zu bekommen und um die endgültige transaction zu versenden.

Bump. Ist dies noch aktuell?

Die Seite ist nun per DNSSEC/TLSA gesichert. Damit ist das Zertifikat besser abgesichert als wenn es von einer CA signiert wäre.

Das sieht gut aus. Da es mit der coinb.in Seite in der Vergangenheit zeitweise Ausfälle beim Multisig-Escrow gab, ist ein zusätzlicher Service immer willkommen. Ich habe meinen MultiSig-Escrow Beitrag angepasst und den Service ebenfalls mit aufgenommen. Eine dezentrale Anbindung an einen Bitcoin Knoten könnte die Verfügbarkeit nochmal deutlich verbessern.

Mit blockchain.info habe ich persönlich keine Probleme, mir gefällt es sogar
besser als mit einem eigenen core-client. Am besten wäre natürlich wenn
das script alternativ mit einem core reden kann (für den Notfall, sozusagen),
aber in der jetzigen Form finde ich die anbindung an die blockchain.info-API stimmig.

Das mit blockchain.info ist nur mal der erste Schritt. Auf Dauer möchte ich die Seite an bitcoin-core anbinden. Im Augenblick würde das leider nur mit dem broadcast klappen. Für die unspent outputs muss bitcoin-core gepatcht werden.

Falls einer den broadcast testet könnte er mir die blockchain.info Antwort geben. Die Schnittstelle ist bei blockchain.info nicht ausreichend dokumentiert. Ich habe bisher nur mit fehlerhaften Transaktionen getestet. Eine Positivmeldung wird deshalb noch mit Warnung statt mit einem OK quitiert.

Nice, das hört sich gut an, ein funktionierendes Multisig-Tool halte ich für sehr
wichtig. Vielen Dank dafür. Ich weiss allerdings nicht ob ich in den nächsten Tagen
zum testen komme.

Im Übrigen finde ich es wichtig, dass das Tool an prominenter Stelle gehostet
wird (nachdem es ausgiebig getestet wurde). Am liebsten wäre mir ja wenn sich
z.B. blockchain.info oder meinetwegen erstmal bitcoin.de dem annimmt. Ich meine nur
das zuverlässige Hosten des Scripts und dass sie mit Ihrem Namen dafür einstehen, dass
man keiner gefakten Version aufsitzt etc. Dann würde sich das mal endlich
durchsetzen können.

Das Tool von OutCast3k ist gut. Allerdings gab es in den letzten Monaten immer wieder längere Ausfälle. Ich habe deshalb die aktuelle Version angepasst:

• Statt coinb.in wird nun blockchain.info für die UTXO zum bauen von TX und zum broadcast genutzt
• Google Analytics und Google QR-Code wurde entfernt. QR-Code wird offline erzeugt
• Die Wallet habe ich erst mal entfernt
• Außer der UTXO Liste und dem broadcast funktioniert alles offline

Den aktuellen Stand des Fork findet ihr auf github unter https://github.com/real1510/coinbin

Testen könnt ihr unter https://multisig.btcnet.eu/
Die Seite nutzt ein self-signed SSL Zertifikat. Es muss im browser manuell aktzeptiert werden. SHA1 Fingerprint ist 77:A0:9C:47:C4:54:DC:45:5E:A2:E2:9C:08:D2:5B:99:FE:95:F9:73

Über Tests, Rückmeldungen, patches ... würde ich mich freuen.

Also es gibt IMO einige Szenarien, wo das zum Problem werden könnte. Die Ware könnte wochenalng unterwegs sein oder der Scammer könnte mich mit Ausreden hinhalten (z.B. Rechner mit dem Private Key defekt, muss erst repariert werden) oder ein unerfahrener Escrower könnte zu leichtfertig freigeben.

Das könnte man relativ einfach lösen, indem man die genauen Konditionen und die beiden Parteien im Vorfeld irgendwo speichert, so dass der Escrower darauf Zugriff hat. Wenn man es ganz hundertprozentig machen will, müsste man die Werte noch hashen und den Hash per OP_RETURN ins Redeem-Script schreiben, damit man sie verifizieren kann.

Ich gehe mal davon aus, dass Du Dich relativ schnell melden wirst, wenn die Ware beim Käufer angekommen ist, Du aber das Treuhandguthaben nicht bekommst. Dagegen habe ich gegenüber Handelspartnern, die sich komisch benehmen und z.B. die Signatur verweigern keinen Druck, möglichst sofort die Transaktion zu signieren.

Wichtig ist natürlich, dass sich ein Beteiligter auch an den Treuhänder wendet, wenn etwas schief geht (z.B. Zahlung bleibt aus). Dafür hat man den Treuhänder dazwischen!

Ich weiß, aber das meinte ich nicht. Ich meinte das ungefähr so:

Ich (Freyr) verkaufe eine Ware hier über das Forum an einen mir unbekannten Nutzer (nennen wir ihn Scammer1). Wir einigen uns auf einen Preis und verwenden deinen (mezzomix) Public Key als Escrow. Weil wir davon ausgehen, dass alles glatt läuft, geben wir dir auch vorher nicht bescheid, damit du keine Arbeit damit hast. Scammer1 schickt die vereinbarten BTC aufs Treuhand-Konto und ich verschicke die Ware.

Nun passiert folgendes: Scammer1 erstellt ein zweites Konto hier im Forum (nennen wir es Scammer2). Nun schreibt er dich (mezzomix) an und erzählt dir, er habe eine Ware von Scammer2 gekriegt (nicht von Freyr) und sie nicht erhalten. Er zeigt dir die Multisig-Adresse mit dem Geld und weist sich dir gegenüber mit einer signed Message aus. Um die Version der Gegenseite zu hören, schreibst du Scammer2 an und verlangst von ihm eine Stellungnahme. Scammer2 (der in Wirklichkeit Scammer1 ist) erzählt dir jetzt irgendeine Lügengeschichte, so dass du zum Ergebnis kommst, dass er ein Arschloch ist. Er zeigt sich zudem unkooperativ und weist sich auf deine Anforderung nicht mit dem Private Key aus (den er auch gar nicht hat). Dir bleibt also nichts anderes übrig, als Scammer1 recht zu geben und ihm das Geld vom Treuhandkonto zurück zu überweisen.

Irgendwann kriege ich (Freyr) diese Kontobewegung mit und wundere mich, weil ich die Transaktion ja nicht freigegeben habe. Aber dann ist es schon zu spät. Der Scammer hat die Ware und das Geld.

Alle Beteiligten sind durch ihre Schlüssel eindeutig identifizierbar. Wichtig ist, kein Geld an eine Multisig Adresse zu senden, ohne zu prüfen, dass der eigene Schlüssel (und der Schlüssel des Treuhänder) zur Generierung genutzt wurde. Damit sind im Ernstfall alle Parteien eindeutig identifizierbar und können signierte Erklärungen abgeben. Ein Scammer müsste das Public Key Verfahren brechen, um diese Signatur zu fälschen.

Genau. Der Service soll natürlich nicht auf die Wallet zugreifen können, aber er kann die bitcoin-URL und QR-Code mit dem entsprechenden Betrag anzeigen. Überweisen muss der Benutzer dann selber.


Ich glaube eher das Gegenteil; dadurch könnten Streitigkeiten vermieden werden. Natürlich müssen beide Parteien sich schon zu Beginn dazu committen, wie sie mit Kursschwankungen umgehen.


Genau, die Konsequenz wäre, dass man eine rudimentäre Datenbank mit den Transaktionen aufbauen müsste. Ich finde nämlich auch das Austauschen der Redeem-Scripts nicht besonders Benutzerfreundlich. Eine URL mit einer Transaktions-ID ist da viel einfacher. Ich würde außerdem noch so wie bei bitrated ein Freitextfeld einbauen, wo nochmal genau die Konditionen für die Transaktion festgehalten werden. Dann kann der Escrower im Steitfall genau sehen, was die beiden Parteien ursprünglich vereinbart hatten.

Nachtrag:

Ich würde auch noch die Kontaktmöglichkeiten für beide Parteien mitspeichern (E-Mail-Adresse, Forennick, Skype, etc.), damit der Escrower im Konfliktfall weiß, wen er ansprechen muss. Ich finde, das ist momentan bei coinb.in noch eine Sicherheitslücke, weil ein Scammer dem Escrower einfach einen falschen Geschäftspartner mitteilen kann und ihm vorspielen kann, dass der Geschäftspartner sich betrügerisch verhält. Damit kann der Escrower dazu bewegt werden, die Treuhandeinlage an den Scammer freizugeben, ohne dass der wahre Gechäftspartner überhaupt etwas davon mitkriegt und sich dazu äußern kann.

Das wäre in einem zweiten Schritt sicherlich eine interessante Funktion. Erst mal sollte aber das System rund laufen.


Man könnte einen Kursrechner anbieten. Da der Einzahler aber sowieso die Summe überweisen muss und der Service nicht auf dessen Wallet zugreifen soll, kann man dafür auch einen eigenen/eingebundenen Kursticker/-rechner nutzen.


Das würde ich eher nicht machen. Damit steigt die Wahrscheinlichkeit, dass es zu Streitigkeiten kommt und man den Escrower am Ende doch benötigt. Falls die Komplexität der Abwicklung nicht steigt und die Nachfrage da ist, könnte man es ähnlicher der Brain Wallet in einem zweiten Schritt einbauen.


Das wäre eine nette Funktion um die Abwicklung noch benutzerfreundlicher zu machen. Daneben könnte man diverse Links für die einzelnen Abwicklungsschritte zur Verfügung stellen. Man sollte allerdings nicht vergessen, dass der Server dann Informationen speichern muss, die mit der heutigen Lösung (z.B. coinb.in) nur den Geschäftspartnern bekannt sind (Redeem Script, Output Transaktion, Public Keys).

Treibt noch jemand das Projekt voran? Ich kann zwar aus Zeitgründen nicht viel zur Umsetzung beitragen, könnte so ein Portal aber gebrauchen.

Eine benutzerfreundliche Lösung sollte m.E. folgende Features haben:

• Brainwallet-Support: Der Nutzer sollte statt einem zufällig generierten Private-Key auch ein selbstgewähltes Passwort benutzen dürfen. Ich weiß, das ist nicht so sicher wie eine Zufallszahl, aber für Kleinbeträge ist es OK. Der Nutzer sollte eine Warnung kriegen, wenn er ein unsicheres Passwort verwenden will. Die Implementierung sollte mit brainwallet.org kompatibel sein, damit man das als Backup benutzen kann, falls die Escrow-Seite offline geht. (Alternativ: BIP32.org-Support, damit man aus dem gleichen Passwort verschiedene Private-Keys generieren kann)
  
  
• Umrechung in Fiat-Währungen: Man sollte als Betrag auch USD, EUR oder sonstige Fiat-Währungen eingeben können, die in BTC nach einem bestimmten Index umgerechnet werden.
  
  
• 2-von-2 Escrow: In bestimmten Fällen ist es besser, keinen Escrower zu haben, statt einem, dem man nicht vertraut. (Bei coinb.in geht das schon, bei bitrated.com und bitescrow.org aber z.B. nicht.)
  
  
• Aufteilung des Kursrisikos: Das hier ist etwas komplizierter, aber ziemlich nützlich. Da der BTC-Kurs leider ziemlich volatil ist, wäre es bei langfristigen Transaktionen (z.B. mehrmonatigen Freelancing-Projekten) ganz gut, wenn man die Möglichkeit hätte, das Risiko der Kursschwankungen zwischen beiden Parteien aufzuteilen. Der Käufer muss zu Beginn der Transaktion etwas mehr als den vereinbarten Betrag auf das Treuhand-Konto überweisen und kriegt es am Ende der Transaktion wieder.
  
  Beispiel: Der Käufer will sich von einem Freelancer eine Webseite designen lassen. Das dauert etwa 1 Monat und soll 1000 EUR kosten. Der BTC-Kurs liegt am Anfang des Projekts bei 1BTC = 1000 EUR. Der Käufer soll jetzt erstmal 20% mehr überweisen, also 1.2  BTC. Somit hat der Freelancer die Gewissheit, dass genug Geld auf dem Konto liegt, auch wenn der Kurs innerhalb des Projektlaufzeit um 20%-40% einbrechen sollte. Am Ende des Projekts wird nochmal der aktuelle Kurs geprüft und der Kursgewinn oder -verlust auf beide Parteien aufgeteilt und die übrigen BTC an den Käufer zurück überwiesen.
  
  (Das kann man zwar schon auch mit coinb.in und bitrated machen, aber da muss man alle Beträge selber ausrechnen. Eine benutzerfreundliche Lösung sollte das automatisieren)
  
  
• API-Support: Das ganze sollte einfach in beliebige Seiten integrierbar sein (Kleinanzeigenportale, Freelancing-Portale, Foren). Über eine API sollte man den Zustand einer Transaktion sehen können (bezahlt, noch nicht bezahlt, abgeschlossen), die Escrow-Adresse sehen können und man sollte einen "Bezahlen"-Knopf auf seine eigene Seite integrieren können, womit der Benutzer auf die Escrow-Seite weitergeleitet wird (ähnlich wie bei Paypal), wo er eine Transaktion einleiten kann, bzw. signieren kann (alles Browserseitig über JavaScript)
  
  

An den Servern mangelt es nicht. Ich habe ein paar Mietserver, auf denen sowieso schon Full Nodes - ohne Wallet - laufen.

Was die Sache mit bictoin-core etwas aufwändiger macht ist, dass zwar eine UTXO DB vorhanden ist, diese aber nur über einen Transaktionsindex verfügt. Mann müsste nun entweder ein UTXO Address / P2SH Hash Index hinzufügen, oder man erweitert die Wallet um Watch-Only Adressen (ohne Private Key). Für beides gibt es Patches, die aber evtl. nicht mehr aktuell sind. Die Core Entwickler haben gegen beide Lösungen eine Abneigung. Mir gefällt ein optionaler UTXO Address/Hash Index am besten.

Das hört sich ja machbar an.. Jetzt wo du dich schon so in den code eingelesen hast, willst du
das nicht vielleicht sauber aufziehen, als fork von outcasts Projekt sozusagen, mit eigener
minimal-API? Es gibt bestimmt jemand der hier eh schon einen Webserver hat und es darauf
hosten würde, und ich denke es würde gerne angenommen wenn man es ein bisschen
promotet hier im Forum

Ich korrigiere mich nochmal, man muss den Quellcode von coinb.in nicht umstellen. Es genügt, wenn man den/die Input(s) von Hand eingibt.

Hier übrigens mal das Protokoll um an die Daten zu kommen:

Der Client macht folgende Anfrage:

Der Server spielt im aktuellen Fall nicht mit und antwortet:

Im Prinzip muss man nur den Server ändern und die UTXO im geeigneten XML Format liefern. Ähnliches dann beim Versenden der Transaktion.

Wenn man den Quellcode auf HTTP umstellt und die Inputs für die Transaktion manuell eingibt, funktioniert es! Ich habe Dir per PN eine Transaktion geschickt (bitte verifizieren und nicht ungeprüft benutzen!). Das Signieren geht dann auch mit dem ungepatchten Code, da dieser kein Internet benötigt.


Das meiste wird im Javascript Code erledigt. Die Ajax API ist recht schmal und sollte sich einfach umsetzen lassen. Im Prinzip benötigt der Code nur eine UTXO Liste beim Generieren der Transaktion (reine Bequemlichkeit) und einen Zugang um am Ende die vollständig signierte Transaktion ins Bitcoin Netzwerk zu senden. Der Rest ist da und funktioniert auch ohne coinb.in.