Bitcoin Forum
April 26, 2024, 07:13:30 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Angebot: BTC (2-aus-3) Multisig Escrow (Treuhandabwicklung)  (Read 7797 times)
mezzomix (OP)
Legendary
*
Offline Offline

Activity: 2618
Merit: 1252


View Profile
February 09, 2014, 11:31:08 AM
Last edit: June 01, 2017, 12:59:29 PM by mezzomix
Merited by mole0815 (1)
 #1

Da es inzwischen auch die ersten Probleme mit Escrow (Treuhandabwicklung) gibt, habe ich mich entschlossen, ein Multisig Escrow anzubieten. Dabei ist der Kerngedanke, dass der Escrower/Treuhänder nur noch in strittigen Fällen eingreifen kann, selbst aber nicht über den Bitcoin Betrag verfügen kann wie beim herkömmlichen Escrow.

Um die Durchführung einfach zu halten, schlage ich eine 2-aus-3 Abwicklung vor. Es wird eine Treuhandadresse (Multisig Address) eingerichtet, für die es 3 Verfügungsberechtigte gibt: Der Käufer, der Verkäufer und der Escrower/Treuhänder. Überweisungen, die von dieser Adresse ausgehen, können von 2 dieser 3 Parteien gemeinsam verfügt werden. Der Käufer überweist den Kaufbetrag auf das Treuhandkonto (eine Multisigadresse). Ist z.B. der Warenaustausch oder die Dienstleistung abgewickelt, unterschreiben der Käufer und der Verkäufer eine ausgehende Transaktion womit der Verkäufer sein Geld bekommt. Im Betrugsfall kann entweder der Treuhänder/Escrower zusammen mit dem Käufer oder aber mit dem Verkäufer das Geld freigeben. Keine der drei Parteien kann alleine über die Summe auf dem Treuhandkonto verfügen.

Für die Abwicklung stehen inzwischen ein paar einfache Werkzeuge zur Verfügung. Diese sind Open Source und nutzen nur soweit es notwendig ist den Online-Zugang. Ausserdem lassen sich die Werkzeuge auch durch andere Ersetzen.

Vorgeschlagene Werkzeuge:

Vorgehensweise:
  • Jede Partei wählt oder erzeugt einen privaten Schlüssel. Erzeugung mit a) New -> New Address oder b) Einzelnes Wallet -> Neues Wallet Erstellen. Vorhandene Schlüssel sollten im Wallet Import Format (WIF) vorliegen. Diese Schlüssel haben die Form 5... / L... / K... (z.B. 5HqoZTAUW2DBLm5FM4BcjpyB9xJ45fpx7RmXcV1E4daa9bnEvDT <- diesen hier nicht benutzen! - L.../K... sind komprimierte Schlüssel). Diese Schlüssel/Adressen müssen zum unterschreiben genutzt werden es. Sie werden üblicherweise nicht als Empfangsadresse für eine Überweisung genutzt.
  • Daraus kann nun der unkomprimierte öffentliche Anteil gewonnen werden. In a) wird dieser mitgeliefert. Ansonsten kann man diesen mit b) Walletdetails aus dem WIF Schlüssel errechnen lassen. Dieser öffentliche Anteil hat die Form 04... (z.B. 04A2556FC15DB1D5FA1E2FCBAFBB9E379660BA611F2F66649C77C37FDD7D1152E0247FCACEDB7C6 A96A9017613C2563B0EDCA8CE180176A45BBD8B39A86C7BD564) bzw. 02... oder 03... für komprimierte Schlüssel.
  • Eine Partei sammelt nun alle 3 öffentlichen Anteile ein und erzeugt mit a) New -> MultiSig Address die MultiSig Adresse. Unter 'Enter the amount of signatures required to release the coins' wird 2 angegeben. Die erzeugte MultiSig Address 3... und das Redeem Script wird nun an die anderen Parteien weitergegeben.
  • Mit a) Verify kann nun jede Partei das Redeem Script überprüfen. Wichtig ist, dass die Multisig Adresse stimmt, sich der eigene öffentliche Anteil unter den Schlüsseln befindet, genau 3 Adressen vorhanden sind und eine gültige Transaktion mit 2 Schlüsseln erstellt werden kann.
  • Der Käufer überweist nun den vereinbarten Betrag mit einer Fee an die erzeugte Multisig Address. Die Fee (Vorschlag 0.0001 BTC) dient dazu, dass die Auszahlung an den Käufer nicht zu lange benötigt.
  • Sobald der Betrag auf der Multisig Address eingegangen ist, kann der Verkäufer seinen Teil des Geschäfts erfüllen. Über den dort liegenden Betrag können nur noch zwei der drei Parteien gemeinam verfügen.
  • Wenn das Geschäft abgewickelt ist, wird mit a) New -> Transaction die Auszahlung vorbereitet. Dazu wird das Redeem Script und eine Auszahlungsadresse benötigt.
  • Die erzeugte Transaction wird nun an die notwendigen Parteien verteilt. Wenn alles sauber gelaufen ist, sind das der Käufer und der Verkäufer.
  • Der erste signiert die Transaction mit a) Sign und dem Schlüssel der im ersten Schritt erzeugt oder benutzt wurde.
  • Die Signed Transaction wird nun der zweiten Partei übermittelt. Diese unterschreibt sie ebenfalls mit a) Sign. Die zweite Signed Transaction enthält nun alle notwendigen Signaturen und wird mit a) Broadcast übermittelt. Sobald die Transaktion vom Bitcoin Netzwerk bestätigt wird, ist das Geschäft abgeschlossen.

Umd die Durchführung zu unterstützen biete ich meine folgende Adresse für die Escrow/Treuhandabwicklung an. Falls sich Käufer/Verkäufer nicht einigen können, kann ich (mit entsprechenden Nachweisen!) die jeweilige Partei dann mit meiner Signatur unterstützen. Ich selbst kann ohne den Käufer oder den Verkäufer nicht über den Betrag auf dem Treuhandkonto verfügen. Allgemein erwarte ich, dass sich Käufer und Verkäufer selbst einigen und ich hier erst gar nicht eingreifen muss! Kosten fallen für meinen Teil, der üblicherweise mit der Bereitstellung der Treuhandadresse erledigt ist, nicht an.

Mein öffentlicher Anteil (der komprimierte Schlüssel führt zu kleineren Redeem Scripts):
Code:
02a4b5d388eac33c8065474f101cd7b969b3e18818a741f8900d4cb97f43cc646a

Ähnlich wie Bitcoin selbst, sehe ich das erst mal als Experiment. Je nachdem wie es sich entwickelt, könnte ich mir in Zukunft auch eine weitere Automatisierung vorstellen, um das ganze noch benutzerfreundlicher zu gestalten.
1714158810
Hero Member
*
Offline Offline

Posts: 1714158810

View Profile Personal Message (Offline)

Ignore
1714158810
Reply with quote  #2

1714158810
Report to moderator
1714158810
Hero Member
*
Offline Offline

Posts: 1714158810

View Profile Personal Message (Offline)

Ignore
1714158810
Reply with quote  #2

1714158810
Report to moderator
Once a transaction has 6 confirmations, it is extremely unlikely that an attacker without at least 50% of the network's computation power would be able to reverse it.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Dunkelheit667
Legendary
*
Offline Offline

Activity: 1045
Merit: 1157


no degradation


View Profile
February 09, 2014, 12:30:13 PM
Last edit: February 09, 2014, 05:28:41 PM by Dunkelheit667
 #2

Vielen Dank für das Angebot und die verständliche Anleitung, gute Idee. Smiley

Edit: Fragen haben sich erledigt. Cheesy

"And the machine keeps pushing time through the cogs, like paste into strings into paste again, and only the machine keeps using time to make time to make time.
And when the machine stops, time is an illusion that we created free will.
" - an unnamed Hybrid
mezzomix (OP)
Legendary
*
Offline Offline

Activity: 2618
Merit: 1252


View Profile
February 09, 2014, 04:22:23 PM
 #3

@Dunkelheit667: Beides mal richtig, vielen Dank! Ich habe den Text entsprechend geändert.
chMiner
Full Member
***
Offline Offline

Activity: 155
Merit: 100



View Profile
February 09, 2014, 05:30:24 PM
 #4

Daumen hoch. Find ich eine gute Idee.

Ich könnte mir auch gut vorstellen, dass man zudem auch andere Anbieter ins Boot holen könnte, die Dienstleistungen und Waren anbieten, bei denen mit Bitcoins und/oder Altcoins bezahlt werden kann.

weglaufbürger
Sr. Member
****
Offline Offline

Activity: 394
Merit: 250


guckguck...hallöle


View Profile
February 09, 2014, 10:03:35 PM
 #5

+1

tolle Idee, Danke für die ausführliche Anleitung und Dein Angebot.

Sollten sich Minerkäufer mal genüßlich auf der Zunge zergehen lassen...

Zwei Monologe, die sich gegenseitig immer und immer wieder unterbrechen, nennt man Diskussion.
elitenoob
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



View Profile
February 09, 2014, 10:05:50 PM
 #6

Jetzt müsste nurnoch ein Video gemacht werden damit es auch jeder versteht Smiley
yxt
Legendary
*
Offline Offline

Activity: 3528
Merit: 1116



View Profile
March 03, 2014, 06:58:30 PM
 #7

sollte man mal oben anpinnen,
gute Arbeit mezzomix Smiley

BTCKano Pool██ ██
██ ██
██ ██
██ ██
██ ██
██ ██
██ ██
██ ██
██ ██
██
██
██
██
██ ██ ██
██ ██ ██
██ ██ ██
██ ██ ██
██ ██ ██
██ ██ ██
██ ██ ██
██ ██ ██
██ ██ ██
   ██
   ██
   ██
   ██
██ ██
██ ██
██ ██
██ ██
██ ██
██ ██
██ ██
██ ██
██ ██
   ██
   ██
   ██
   ██
IVIasterZox
Sr. Member
****
Offline Offline

Activity: 330
Merit: 250


View Profile
March 04, 2014, 10:23:49 PM
 #8

Sehr gute Idee!

Kann man anhand des Redeem Scriptes und der erzeugten Multisig Addresse herausfinden welche Addressen zur Generierung verwendet wurden?
Ansonsten bräuchte es wieder eine Vertrauenswürdige Person die alles zusammen bringt...
mezzomix (OP)
Legendary
*
Offline Offline

Activity: 2618
Merit: 1252


View Profile
March 05, 2014, 06:28:31 AM
Last edit: March 05, 2014, 06:46:54 AM by mezzomix
 #9

Selbstverständlich kann man das prüfen!

Im Redeem Script steckt die gesammte Information. Auf https://coinb.in/multisig/ kann man das Script unter Verify überprüfen. Dort sieht man dann die Multisig Adresse, die zugrundeliegenden öffentlichen Anteile der Schlüssel und wieviele Schlüssel für eine Überweisung benötigt werden.

Damit kann man sicherstellen, dass der eigene Schlüssel dazugehört und eine Transaktion die erwartete Anzahl an Signaturen benötigt. Ich habe den Punkt in die Liste im Eingangspost mit aufgenommen.

Ihr könnt das auf der Seite gerne mal mit Wegwerfadressen (einfach unter New -> Bitcoin Keys drei Stück generieren) bis zu diesem Punkt durchspielen, dann wird der Prozess schnell klar.
Truman
Legendary
*
Offline Offline

Activity: 826
Merit: 1000



View Profile
August 30, 2014, 09:12:15 AM
 #10

So, hab das gerade mal aus aktuellem Anlass ausprobiert. Hört sich komplizierter an als es ist!  Smiley

Danke mezzomix!



     ▄██    ▐███████▄▄▄       ▄▄█████▄▄      ▄██▄      ▐██▄    ▒▓▓▄      ▄▓▓▒
     ███    ▐██▌▀▀▀▀▀███▄    ███▀▀▀▀▀███▄    ████▄     ▐██▌  ▐▓▄ ▀▓▓▄  ▄▓▓▀ ▄▓▌
     ███    ▐██▌      ███   ███▌      ███▌   ██████    ▐██▌   ▀▓▓▄ ▀▓▓▓▓▀ ▄▓▓▀
     ███    ▐██▌    ▄████  ▐███▌      ▐██▌   ███ ███▄  ▐██▌     ▀▓▓▄ ▀▀ ▄▓▓▀
     ███    ▐█████████▀▀   ▐███▌      ▐██▌   ███  ▀███ ▐██▌      ▓▓▓    ▓▓▓
     ███    ▐██▌   ▀███     ███▌      ███▌   ███    ██████▌   ▄▓▓▀ ▄▓▓▓▓▄ ▓▓▓▄
     ███    ▐██▌     ███    ▀███▄▄▄▄▄████    ███     ▀████▌  ▐▓▀ ▄▓▓▀  ▀▓▓▄ ▀▓▌
     ███    ▐██▌      ███     ▀▀██████▀▀     ███       ███▌    ▄▓▓▀      ▀▓▓▄
                  ▄▄▄█████▄▄▄▄
             ▄▄█▓▓▓▓▓█▀▀▀▀█▓▓▓▓▓█▄
           ▄▓▓▓█▀▀            ▀▀█▓▓█▄
         ▓▓▓█▀                    ▀▓▓█▄
       ▄▓▓▓▀                        ▀▓▓█
      ▄▓▓█                            █▓▓
      ▓▓▓                    ▄██▄     ▐▓▓█
     ▓▓▓                   ▄█▓▓▀       ▐▓▓▌
     ▓▓▓                 ▄█▓▓▀          ▓▓▓
     ▓▓▓       ▓▓▓▄    ▓▓▓▓▀            ▓▓▓
     ▓▓▓        ▀▓▓▓▄█▓▓▓▀             ▐▓▓▌
     ▀▓▓▓         ▀█▓▓█▀               █▓▓
      ▓▓▓▄                            ▓▓▓▌
       ▓▓▓█                         ▄█▓▓▀
        ▀▓▓█▄                     ▄▓▓▓█▀
          ▀▓▓▓█▄               ▄▄█▓▓█▀
            ▀▀█▓▓▓█▄▄▄▄▄▄▄▄▄▄█▓▓▓█▀
                ▀▀██▓▓▓▓▓▓▓███▀▀
IVIasterZox
Sr. Member
****
Offline Offline

Activity: 330
Merit: 250


View Profile
August 30, 2014, 05:56:41 PM
Last edit: August 30, 2014, 06:08:10 PM by IVIasterZox
 #11

Gibt es eigentlich schon Multisig Escrows?
Coinb.in ist leider down? Wem gehört die Seite? Gibt wohl mit der SSL Version probleme, aber wer braucht schon SSL Cheesy
mezzomix (OP)
Legendary
*
Offline Offline

Activity: 2618
Merit: 1252


View Profile
August 31, 2014, 09:36:47 AM
 #12

Leider gibt es nicht nur mit HTTPS Probleme: In einem aktuellen Fall wird leider die (bereits vorhandene) Transaktion nicht erkannt und das Generieren der Auszahlungsadresse verweigert.

Da hier Bitcoin Standardfunktionen genutzt werden, kann man auf bitcoin-cli createrawtransaction ... ausweichen, aber schön und bequem geht anders.  Sad

Allerdings sind die Multisig Scripte öffentlich. Mit etwas Zeit könnte man das Frontend auf einen eigenen Server mit laufendem Client aufsetzen. Eine bitcoin-core Instanz ohne Wallet ist ausreichend. Man benötigt die Blockchain um die richtige TXout ("vout") zu selektieren, und um die signierte Auszahlung der Multisig Adresse ins Bitcoin Netzwerk zu übertragen.
mezzomix (OP)
Legendary
*
Offline Offline

Activity: 2618
Merit: 1252


View Profile
January 19, 2015, 07:58:25 AM
 #13

Anmerkung zu meinem letzten Post: Inzwischen hat OutCast3k das Tool überarbeitet und die Seite, wie auch seine API, funktionieren wieder. Ausserdem hat real1510 das Tool auf die blockchain.info API angepasst, sodass eine völlig unabhängige Alternative zur Verfügung steht. Beide Tools arbeiten bis auf die das Lesen der Unspent Transaktionen und des Broadcast von Transaktionen lokal im Browser. Der vollständige Sourcecode (HTML, CSS und Javascript) wird jeweils vom Webserver ausgeliefert und steht in beiden Fällen auch auf GitHub zur Verfügung.

Etwas weniger komfortabel kann der gesammte Ablauf auch mit dem Bitcoin-Core Client vollständig durchgeführt werden. Gavin Andresen hat den Ablauf in einem GitHub Gist dokumentiert: https://gist.github.com/gavinandresen/3966071.

Damit stehen nun 3 unabhängige Werkzeuge zur Verfügung. Diese sind alle untereinander kompatibel, d.h. jeder Schritt der Abwicklung kann mit einem beliebigen Werkzeug durchgeführt werden. Die gesammte Abwicklung nutzt ausschliesslich Standardmechanismen des Bitcoin-Systems. Damit kann jeder vollständige Bitcoin-Client diese Schritte ebenfalls durchführen können. SPV Clients wie die Schildbach-Wallet können allerdings nur Teilschritte - wie die Überweisung an die Multisig-Adresse - durchführen. Durch die Web basierten Tools sollte aber jeder Internet- und Bitcoin-Nutzer in der Lage sein, das Verfahren zu nutzen.
david123
Legendary
*
Offline Offline

Activity: 1022
Merit: 1004


View Profile
January 19, 2015, 01:09:28 PM
 #14

Das ist alles schon auf einem guten Weg.. Ich sehe allerdings noch Bedarf nach einer zentralen
Stelle wo die potentiellen Escrows verwaltet werden. Was man ja wirklich will, ist dass Käufer und
Verkäufer den Deal sofort durchziehen können, ohne auf die Übernahmebestätigung eines Escrows
zu warten. Und nur weil irgendwo ein 2-of-3 public key steht von jemand der irgendwann mal
angeboten hat, Escrow zu machen, heisst das leider noch nicht dass das alles aktuell ist (zumindest
würde ich mich nicht darauf verlassen).

Im einfachsten Fall wäre das ein Thread im Forum, der immer aktuell gehalten wird. Das löst aber
auch nicht alle Probleme, z.B. könnte ein Escrow den PrivKey verlieren und es erst bemerken wenn
er in eine 2-of-3 Transaktion eingebaut wurde. Am besten
würde mir eine Paypal-ähnliche Seite gefallen, d. h. es gibt einen öffentlichen Anteil der von
einer zentralen Stelle verwaltet wird, und Escrows können sich im Streitfall dort einloggen und
entsprechende Transaktionen signieren: nicht weil sie den privaten Anteil haben sondern über das
Portal. Da könnte man dann auch eine Escrow-Fee verankern, die nur im Streitfall anfällt und zu
x% an den schlichtenden Escrow und zu y% an das Portal gezahlt wird. Auch könnten sich Käufer
und Verkäufer einigen, ob sie einen bestimmten Escrow bevorzugen oder im Streitfall ein beliebiger
Escrow aus einem ganzen Pool von vertrauenwürdigen Leuten die Schlichtung übernimmt. Am Anfang
sollte man sicher die bekannten Escrows aus diesem Forum übernehmen, aber weiterlaufen könnte
es ja mit einer Bewertungsfunktionalität für Escrows etc.

Gibt es sowas schon oder hat jemand Interesse etwas in der Richtung zu entwickeln? Mich würde
es schon reizen..
mezzomix (OP)
Legendary
*
Offline Offline

Activity: 2618
Merit: 1252


View Profile
January 19, 2015, 01:40:44 PM
 #15

Das ist alles schon auf einem guten Weg.. Ich sehe allerdings noch Bedarf nach einer zentralen
Stelle wo die potentiellen Escrows verwaltet werden. Was man ja wirklich will, ist dass Käufer und
Verkäufer den Deal sofort durchziehen können, ohne auf die Übernahmebestätigung eines Escrows
zu warten. Und nur weil irgendwo ein 2-of-3 public key steht von jemand der irgendwann mal
angeboten hat, Escrow zu machen, heisst das leider noch nicht dass das alles aktuell ist (zumindest
würde ich mich nicht darauf verlassen).

Ich habe den Private-Key, der übrigens nur für dieses Escrow genutzt wird, ebenso wie meine
anderen Daten in redundanten und örtlich getrennten Backups gespeichert. Der sollte also
nicht verloren gehen.

Ein weiterer Vorteil ist, dass die Geschäftspartner diesen Key, bzw. den Escrower, in den
meisten Fällen gar nicht benötigen, da sie gemeinsam ebenfalls über die Escrow-Summe
entscheiden können.

Im einfachsten Fall wäre das ein Thread im Forum, der immer aktuell gehalten wird. Das löst aber
auch nicht alle Probleme, z.B. könnte ein Escrow den PrivKey verlieren und es erst bemerken wenn
er in eine 2-of-3 Transaktion eingebaut wurde. Am besten
würde mir eine Paypal-ähnliche Seite gefallen, d. h. es gibt einen öffentlichen Anteil der von
einer zentralen Stelle verwaltet wird, und Escrows können sich im Streitfall dort einloggen und
entsprechende Transaktionen signieren: nicht weil sie den privaten Anteil haben sondern über das
Portal. Da könnte man dann auch eine Escrow-Fee verankern, die nur im Streitfall anfällt und zu
x% an den schlichtenden Escrow und zu y% an das Portal gezahlt wird. Auch könnten sich Käufer
und Verkäufer einigen, ob sie einen bestimmten Escrow bevorzugen oder im Streitfall ein beliebiger
Escrow aus einem ganzen Pool von vertrauenwürdigen Leuten die Schlichtung übernimmt. Am Anfang
sollte man sicher die bekannten Escrows aus diesem Forum übernehmen, aber weiterlaufen könnte
es ja mit einer Bewertungsfunktionalität für Escrows etc.

Gibt es sowas schon oder hat jemand Interesse etwas in der Richtung zu entwickeln? Mich würde
es schon reizen..

Man könnte sich hier so etwas in der Richtung M-aus-N Key-Sharing vorstellen, sodass im
Ernstfall eine bestimmte Anzahl an Treuhändern gemeinsam den Part des Treuhänders
einnimmt. Die Gefahr die ich dabei sehe ist, dass der Server hier einen zentralen Angriffspunkt
darstellen könnte.

Daneben habe ich keine Ahnung, wie weit mein Angebot überhaupt genutzt wird. Die
Rückmeldungen sind minimal und als Treuhänder musste ich, neben der Bereitstellung
des Public-Key, bisher noch nie tätig werden (was idealerweise auch so sein soll).
Aswan
Legendary
*
Offline Offline

Activity: 1734
Merit: 1015



View Profile
January 19, 2015, 01:42:40 PM
 #16

Das ist alles schon auf einem guten Weg.. Ich sehe allerdings noch Bedarf nach einer zentralen
Stelle wo die potentiellen Escrows verwaltet werden. Was man ja wirklich will, ist dass Käufer und
Verkäufer den Deal sofort durchziehen können, ohne auf die Übernahmebestätigung eines Escrows
zu warten. Und nur weil irgendwo ein 2-of-3 public key steht von jemand der irgendwann mal
angeboten hat, Escrow zu machen, heisst das leider noch nicht dass das alles aktuell ist (zumindest
würde ich mich nicht darauf verlassen).

Im einfachsten Fall wäre das ein Thread im Forum, der immer aktuell gehalten wird. Das löst aber
auch nicht alle Probleme, z.B. könnte ein Escrow den PrivKey verlieren und es erst bemerken wenn
er in eine 2-of-3 Transaktion eingebaut wurde. Am besten
würde mir eine Paypal-ähnliche Seite gefallen, d. h. es gibt einen öffentlichen Anteil der von
einer zentralen Stelle verwaltet wird, und Escrows können sich im Streitfall dort einloggen und
entsprechende Transaktionen signieren: nicht weil sie den privaten Anteil haben sondern über das
Portal. Da könnte man dann auch eine Escrow-Fee verankern, die nur im Streitfall anfällt und zu
x% an den schlichtenden Escrow und zu y% an das Portal gezahlt wird. Auch könnten sich Käufer
und Verkäufer einigen, ob sie einen bestimmten Escrow bevorzugen oder im Streitfall ein beliebiger
Escrow aus einem ganzen Pool von vertrauenwürdigen Leuten die Schlichtung übernimmt. Am Anfang
sollte man sicher die bekannten Escrows aus diesem Forum übernehmen, aber weiterlaufen könnte
es ja mit einer Bewertungsfunktionalität für Escrows etc.

Gibt es sowas schon oder hat jemand Interesse etwas in der Richtung zu entwickeln? Mich würde
es schon reizen..

Käufer und verkäufer können beide einen BTC Betrag auf die Multisig adresse schicken, und zwar gleichzeitig und trustless, indem es in derselben Tx passiert.
Dann kann hinterher nicht einer dne anderen erpressen mit "gib mir einen teil der BTC oder du siehst garnichts davon" falls der escrow den key verloren hat.
mezzomix (OP)
Legendary
*
Offline Offline

Activity: 2618
Merit: 1252


View Profile
January 19, 2015, 02:07:53 PM
 #17

Käufer und verkäufer können beide einen BTC Betrag auf die Multisig adresse schicken, und zwar gleichzeitig und trustless, indem es in derselben Tx passiert.
Dann kann hinterher nicht einer dne anderen erpressen mit "gib mir einen teil der BTC oder du siehst garnichts davon" falls der escrow den key verloren hat.

Das wäre sozusagen die Hinterlegung einer Sicherheit. Wenn es nur als Absicherung gegen einen Private-Key Verlust des Escrower dienen soll, ist vermutlich eine Anfrage an den Escrower die einfachere Möglichkeit.

Ich habe diesen Ablauf noch nicht durchgespielt, aber die Tools müssten diese zusätzliche Hinterlegung durchaus hergeben, indem einer der beiden die Transaktion zur Hinterlegung der Sicherheitsleistung erstellt und beide die Transaktion signieren. Der Ersteller muss dafür allerdings die Informationen zur Unspent Transaction vom Geschäftspartner bekommen.

Das Verfahren wird aber, selbst bei weiterer Automatisierung, durch den notwendigen Austausch von Informationen immer einen erhöhten Aufwand erfordern. Da im Augenblick bei den meisten Geschäften - nicht nur in der Bitcoin-Welt sondern auch bei Fiat - immer eine Partei in Vorleistung geht, ist alleine schon der Escrow Prozess ein deutlicher Schritt nach vorne. Wie man in der Vergangenheit im Biete/Suche Bereich gesehen hat, meiden Betrüger den Escrow (egal ob Multisig oder nicht) wie der Teufel das Weihwasser.
david123
Legendary
*
Offline Offline

Activity: 1022
Merit: 1004


View Profile
January 19, 2015, 02:09:54 PM
 #18

Ich habe den Private-Key, der übrigens nur für dieses Escrow genutzt wird, ebenso wie meine
anderen Daten in redundanten und örtlich getrennten Backups gespeichert. Der sollte also
nicht verloren gehen.
Das meinte ich auch gar nicht so sehr auf dein Angebot bezogen. Ich glaube schon dass du
den Key sicher verwahrst. Trotzdem würde ich, wenn ich in ein paar Wochen den Service
nutzen will, dir (wie jedem anderen multisig-escrow) vorher eine PM schreiben ob alles noch aktuell ist.
Ich denke das würden die meisten machen wenn es um mehr als einen einstelligen Eurobetrag geht.

Ein weiterer Vorteil ist, dass die Geschäftspartner diesen Key, bzw. den Escrower, in den
meisten Fällen gar nicht benötigen, da sie gemeinsam ebenfalls über die Escrow-Summe
entscheiden können.
Das ist doch, wenn ich alles richtig verstanden habe, einer der wesentlichen multisig-Escrow-
Eigenschaften. Daran will ich ja gar nicht rütteln. In der Mehrzahl der Fälle muss der escrower
nichts tun, so ist es ja gedacht..

Man könnte sich hier so etwas in der Richtung M-aus-N Key-Sharing vorstellen, sodass im
Ernstfall eine bestimmte Anzahl an Treuhändern gemeinsam den Part des Treuhänders
einnimmt. Die Gefahr die ich dabei sehe ist, dass der Server hier einen zentralen Angriffspunkt
darstellen könnte.
Ja, der Server wäre ein Angriffspunkt. Allerdings kein wirklich ergiebiger, denn selbst wenn ein
Angreifer den 2-of-3 privkey bekommt, gibt es ja praktisch keine Gelegenheit dass er sich
bereichern kann. Es sei denn er bekommt einige Käufer/Verkäufer auf seine Seite, die mit
ihm zusammen Transaktionen signieren.
Jedenfalls kein Vergleich zu z.B. Exchanges, wo man eine Hot Wallet plündern kann. Sowas
gäbe es hier ja nicht. Natürlich muss es trotzdem vernünftig abgesichert werden.

Es geht mir vor allem darum, dass multisig-escrow kaum genutzt wird, da es de facto aufwändiger
als normales escrow ist. Ich denke es wäre lohnenswert, es einfacher zu machen, auch wenn das
eine zentrale Instanz erschafft. Mir schwebt da halt eine Paypal-ähnliche Instanz vor, die natürlich
auch Nachteile mitbringt (Zentralisierung), aber Bequemlichkeit scheint der Weg zur Akzeptanz
zu sein.

Es lässt sich ja auch so implementieren (mit 3-of-n) dass entweder ein Escrower über das Portal
oder zwei Escrower zusammen (bei komplettem Ausfall des Portals) eine vom (Ver)käufer
vorsignierte Transaktion fertigsignieren können. Dann wäre das Vertrauen in das Portal
minimiert. Ideal wäre wenn entweder Käufer und Verkäufer oder (Ver)Käufer und zwei
Escrows notwendig sind um eine Tx zu signieren. Lässt sich das technisch machen?
Also im Prinzip 3-of-n aber zwei der n Adressen sind derartig ausgezeichnet dass sie
zu zweit signieren können?

Daneben habe ich keine Ahnung, wie weit mein Angebot überhaupt genutzt wird. Die
Rückmeldungen sind minimal und als Treuhänder musste ich, neben der Bereitstellung
des Public-Key, bisher noch nie tätig werden (was idealerweise auch so sein soll).
Ich glaube (wie schon gesagt) dass dich fast jeder kontaktiert der dein Angebot nutzt (ausser vielleicht
für Tests). Dem letzten Teil stimme ich nicht zu, weisst du noch wie du mir helfen musstest mit
outcasts script? Cheesy

Käufer und verkäufer können beide einen BTC Betrag auf die Multisig adresse schicken, und zwar gleichzeitig und trustless, indem es in derselben Tx passiert.
Dann kann hinterher nicht einer dne anderen erpressen mit "gib mir einen teil der BTC oder du siehst garnichts davon" falls der escrow den key verloren hat.
Das verstehe ich nicht. Was passiert dann wenn der escrow den key verloren hat? Kannst
du das detaillierter erklären?
mezzomix (OP)
Legendary
*
Offline Offline

Activity: 2618
Merit: 1252


View Profile
January 19, 2015, 02:24:00 PM
 #19

Daneben habe ich keine Ahnung, wie weit mein Angebot überhaupt genutzt wird. Die
Rückmeldungen sind minimal und als Treuhänder musste ich, neben der Bereitstellung
des Public-Key, bisher noch nie tätig werden (was idealerweise auch so sein soll).
Ich glaube (wie schon gesagt) dass dich fast jeder kontaktiert der dein Angebot nutzt (ausser vielleicht
für Tests). Dem letzten Teil stimme ich nicht zu, weisst du noch wie du mir helfen musstest mit
outcasts script? Cheesy

Das war aber nur technischer Support und gehört für mich eher zu den Rückmeldungen. Als Treuhänder (Nutzung meines Private-Key wegen Ausfall des Käufer/Verkäufer) musste ich dabei nicht tätig werden.

Käufer und verkäufer können beide einen BTC Betrag auf die Multisig adresse schicken, und zwar gleichzeitig und trustless, indem es in derselben Tx passiert.
Dann kann hinterher nicht einer dne anderen erpressen mit "gib mir einen teil der BTC oder du siehst garnichts davon" falls der escrow den key verloren hat.
Das verstehe ich nicht. Was passiert dann wenn der escrow den key verloren hat? Kannst
du das detaillierter erklären?

Ich habe es so Verstanden, dass beide erst mal gleichzeitig(!) in Vorleistung gehen. Damit hat jeder eine Sicherheitsleistung in das Geschäft investiert und kann den anderen (bei Verlust des Escrow Key) nicht erpressen, ohne im Ernstfall auch selbst einen Verlust zu erleiden.
david123
Legendary
*
Offline Offline

Activity: 1022
Merit: 1004


View Profile
January 19, 2015, 02:27:54 PM
 #20

Ich habe es so Verstanden, dass beide erst mal gleichzeitig(!) in Vorleistung gehen. Damit hat jeder eine Sicherheitsleistung ins das geschäft investiert und kann den anderen (bei Verlust des Escrow Key) nicht erpressen, ohne im Ernstfall auch selbst einen Verlust zu erleiden.
Achso. Naja, dann aber mal viel Spass dabei einen Verkäufer zu finden, der neben dem Versand der Ware auch
noch mit einem BTC-Betrag in Vorleistung geht. Wink
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!