Jeder, der schon einmal an jemanden gezahlt hat, der das Unternehmen vertreten soll, weiß: Am schwersten zu verhindern ist nicht unbedingt die gefälschte Rechnung. Der Name des Lieferanten ist echt, der Vertrag ist echt – nur das Zahlungskonto wurde gegen das eines anderen ausgetauscht. Wenn man jedes Feld einzeln betrachtet, gibt es keine Beanstandung, aber in Kombination schicken sie das Geld an die falsche Stelle.
Auch beim Cross-Chain gibt es so eine Gefahr. Nicht alles ist zwangsläufig komplett gefälscht, sondern es werden Bitcoin-Öffentliche Schlüssel und Ethereum-Adressen, die eigentlich nicht zusammengehören, von Unberechtigten gewaltsam in eine Beziehung gesetzt.
@BabylonLabs_io s Trustless Bitcoin Vaults (TBV) werden in den Vault-Aufbauanfragen gleichzeitig mit Ethereum-Adresse, Bitcoin-Öffentlichem Schlüssel, der Auswahl des Vault Providers, einer WOTS-Zusage und einem BIP-322-Beweis für den Besitz des Schlüssels geliefert. Dieses Zusammenspiel macht mir nicht so viele Begriffe Sorgen, sondern vor allem: Wer ist berechtigt, die Bestätigungstaste zu drücken.
Sobald die Anfrage zustande kommt, behandelt der nachfolgende Ablauf die Aktionen auf beiden Ketten als dieselbe Autorisierungsbeziehung. Wenn der Initiator nicht einmal den entsprechenden Bitcoin-Öffentlichen Schlüssel kontrollieren kann, ist das kein kleines Versehen, sondern jemand hat für jemand anderen ein Konto eröffnet und außerdem den späteren Ansprechpartner festgelegt.
Wenn man BIP-322 hier einordnet, wirkt es eher wie eine Berechtigungsprüfung vor der Tür. Erst die tatsächliche Kontrolle über den Bitcoin-Öffentlichen Schlüssel nachweisen – dann darüber sprechen, wie man Konten und Anwendungen auf der Ethereum-Seite anschließt. Es macht die Welt nicht einfach; es verhindert nur, dass Unbekannte eine Reihe öffentlich zugänglicher Informationen kopieren und die beiden Enden miteinander verkoppeln, die nicht ihnen gehören.
Viele Probleme im Internet entstehen nicht, weil Dateien gefälscht werden, sondern weil Beziehungen missbraucht werden. Die Handynummer ist echt, die Bankkarte ist echt, der Name ist echt – am Ende ist es die Frage, wem die Berechtigung dazu zusteht, sie zu einer einzigen Aktion zusammenzusetzen. Wenn ein System nur die Einzelteile prüft und nicht die Person, die die Beziehung herstellt, gilt: Je schneller die Automatisierung, desto schneller laufen auch Fehler.
In den Diskussionen rund um $BABY ist diese Hürde nicht so laut wie bei nativen BTC, aber sie kommt viel näher an das eigentliche Wesen von alltäglicher Sicherheit. Das Protokoll lehnt zunächst Menschen ab, die grundsätzlich nicht berechtigt sind, eine Anfrage zu initiieren – erst danach hat der restliche Ablauf Bedeutung.
BIP-322 ist kein KYC und es fällt auch keine reale Rechtsentscheidung darüber, wem BTC gehört. Es schützt den Protokoll-Eingang, nicht das gesamte gesellschaftliche Eigentum. Der Spielraum ist eng, aber die Position ist genau richtig.
Viele Unfälle passieren nicht, weil die Einzelteile gefälscht sind, sondern weil die echten Einzelteile mit den falschen Personen verknüpft werden. #baby
Auch beim Cross-Chain gibt es so eine Gefahr. Nicht alles ist zwangsläufig komplett gefälscht, sondern es werden Bitcoin-Öffentliche Schlüssel und Ethereum-Adressen, die eigentlich nicht zusammengehören, von Unberechtigten gewaltsam in eine Beziehung gesetzt.
@BabylonLabs_io s Trustless Bitcoin Vaults (TBV) werden in den Vault-Aufbauanfragen gleichzeitig mit Ethereum-Adresse, Bitcoin-Öffentlichem Schlüssel, der Auswahl des Vault Providers, einer WOTS-Zusage und einem BIP-322-Beweis für den Besitz des Schlüssels geliefert. Dieses Zusammenspiel macht mir nicht so viele Begriffe Sorgen, sondern vor allem: Wer ist berechtigt, die Bestätigungstaste zu drücken.
Sobald die Anfrage zustande kommt, behandelt der nachfolgende Ablauf die Aktionen auf beiden Ketten als dieselbe Autorisierungsbeziehung. Wenn der Initiator nicht einmal den entsprechenden Bitcoin-Öffentlichen Schlüssel kontrollieren kann, ist das kein kleines Versehen, sondern jemand hat für jemand anderen ein Konto eröffnet und außerdem den späteren Ansprechpartner festgelegt.
Wenn man BIP-322 hier einordnet, wirkt es eher wie eine Berechtigungsprüfung vor der Tür. Erst die tatsächliche Kontrolle über den Bitcoin-Öffentlichen Schlüssel nachweisen – dann darüber sprechen, wie man Konten und Anwendungen auf der Ethereum-Seite anschließt. Es macht die Welt nicht einfach; es verhindert nur, dass Unbekannte eine Reihe öffentlich zugänglicher Informationen kopieren und die beiden Enden miteinander verkoppeln, die nicht ihnen gehören.
Viele Probleme im Internet entstehen nicht, weil Dateien gefälscht werden, sondern weil Beziehungen missbraucht werden. Die Handynummer ist echt, die Bankkarte ist echt, der Name ist echt – am Ende ist es die Frage, wem die Berechtigung dazu zusteht, sie zu einer einzigen Aktion zusammenzusetzen. Wenn ein System nur die Einzelteile prüft und nicht die Person, die die Beziehung herstellt, gilt: Je schneller die Automatisierung, desto schneller laufen auch Fehler.
In den Diskussionen rund um $BABY ist diese Hürde nicht so laut wie bei nativen BTC, aber sie kommt viel näher an das eigentliche Wesen von alltäglicher Sicherheit. Das Protokoll lehnt zunächst Menschen ab, die grundsätzlich nicht berechtigt sind, eine Anfrage zu initiieren – erst danach hat der restliche Ablauf Bedeutung.
BIP-322 ist kein KYC und es fällt auch keine reale Rechtsentscheidung darüber, wem BTC gehört. Es schützt den Protokoll-Eingang, nicht das gesamte gesellschaftliche Eigentum. Der Spielraum ist eng, aber die Position ist genau richtig.
Viele Unfälle passieren nicht, weil die Einzelteile gefälscht sind, sondern weil die echten Einzelteile mit den falschen Personen verknüpft werden. #baby