Umselbe VP, demselben Bitcoin-Key—bereits bei Aave v4 verifiziert. Warum kann man mit einer anderen Anwendung nicht automatisch eine Serviceberechtigung erhalten? Auf diese Frage gibt es genau eine Antwort: Schlüssel nachweisen und Berechtigung nachweisen sind zwei verschiedene Dinge.
Zuerst: Was beweist BIP-322 eigentlich? Es beweist, dass der Einreicher die zugehörige Bitcoin-Key kontrolliert. Beim Vault-Provider-Registrieren werden eine Ethereum-Adresse und ein Bitcoin-x-only-Public-Key verknüpft. BIP-322 verifiziert, wem diese Schlüssel gehören; der Beleg ist eine verifizierbare Signatur, keine Visitenkarte. Welche Türen dieser Schlüssel öffnen kann—ein einziger Nachweis deckt das nicht ab.
Dann: Was beweist es nicht? Es beweist kein KYC, keine rechtliche Identität, keinen Ruf und keine Servicequalität. Wenn der Key verifiziert ist, heißt das nicht, dass dieser Serviceanbieter in jedem Szenario zuverlässig ist.
Warum glauben also manche, dass der Wechsel der Anwendung automatisch wirksam sein müsste? Weil die Registrierungsbeziehung an eine konkrete Anwendung gebunden ist. In der aktuellen Auslegung ist Aave v4 die einzige registrierte Anwendung. Wenn derselbe VP in Zukunft mehrere Anwendungen bedient, müssen jeweils neue Registrierungsbeziehungen aufgebaut werden; „mehrere Anwendungen“ ist derzeit noch ein zukünftiges Szenario. Die Berechtigungsreichweite folgt der Registrierung, nicht der Marke. Die Marke ist nur Markteindruck, die Registrierung ist ein Protokoll-Eintrag—das Protokoll akzeptiert nur Letzteres.
Wenn derselbe VP in Zukunft wirklich mehrere Anwendungen bedient: Dann muss man die Registrierungsbeziehung selbst erneut hinterlegen, nicht eine einmalige Verifizierung als dauerhaften Pass partout überall verwenden. Der Schlüssel kann wiederverwendet werden, die Marke kann beibehalten werden, aber der Rechtebereich darf nicht automatisch mit der Marke „aufblasen“.
Zurück zur ursprünglichen Frage: Man kann nicht automatisch eine Berechtigung erhalten, weil in den @BabylonLabs_io Trustless Bitcoin Vaults (TBV) der Nachweis, dass man den Key besitzt, beim Key bleibt. Der Umfang des Services richtet sich nach der konkreten App-Registrierung; die Servicequalität braucht man über andere Belege, etwa tatsächliche Betriebsaufzeichnungen und verifizierbare Ergebnisse—nicht über einen einzelnen BIP-322-Nachweis. $BABY In der „Ökosystem“-Aussage sollte dieser Satz an die Stirn geklebt werden: Man kann nicht beweisen, dass man den Schlüssel hat, und daraus schließen, dass man jede Tür öffnen kann; und selbst wenn man eine Tür öffnen kann, heißt das nicht, dass hinter jeder Tür alles dir gehört. #baby
Zuerst: Was beweist BIP-322 eigentlich? Es beweist, dass der Einreicher die zugehörige Bitcoin-Key kontrolliert. Beim Vault-Provider-Registrieren werden eine Ethereum-Adresse und ein Bitcoin-x-only-Public-Key verknüpft. BIP-322 verifiziert, wem diese Schlüssel gehören; der Beleg ist eine verifizierbare Signatur, keine Visitenkarte. Welche Türen dieser Schlüssel öffnen kann—ein einziger Nachweis deckt das nicht ab.
Dann: Was beweist es nicht? Es beweist kein KYC, keine rechtliche Identität, keinen Ruf und keine Servicequalität. Wenn der Key verifiziert ist, heißt das nicht, dass dieser Serviceanbieter in jedem Szenario zuverlässig ist.
Warum glauben also manche, dass der Wechsel der Anwendung automatisch wirksam sein müsste? Weil die Registrierungsbeziehung an eine konkrete Anwendung gebunden ist. In der aktuellen Auslegung ist Aave v4 die einzige registrierte Anwendung. Wenn derselbe VP in Zukunft mehrere Anwendungen bedient, müssen jeweils neue Registrierungsbeziehungen aufgebaut werden; „mehrere Anwendungen“ ist derzeit noch ein zukünftiges Szenario. Die Berechtigungsreichweite folgt der Registrierung, nicht der Marke. Die Marke ist nur Markteindruck, die Registrierung ist ein Protokoll-Eintrag—das Protokoll akzeptiert nur Letzteres.
Wenn derselbe VP in Zukunft wirklich mehrere Anwendungen bedient: Dann muss man die Registrierungsbeziehung selbst erneut hinterlegen, nicht eine einmalige Verifizierung als dauerhaften Pass partout überall verwenden. Der Schlüssel kann wiederverwendet werden, die Marke kann beibehalten werden, aber der Rechtebereich darf nicht automatisch mit der Marke „aufblasen“.
Zurück zur ursprünglichen Frage: Man kann nicht automatisch eine Berechtigung erhalten, weil in den @BabylonLabs_io Trustless Bitcoin Vaults (TBV) der Nachweis, dass man den Key besitzt, beim Key bleibt. Der Umfang des Services richtet sich nach der konkreten App-Registrierung; die Servicequalität braucht man über andere Belege, etwa tatsächliche Betriebsaufzeichnungen und verifizierbare Ergebnisse—nicht über einen einzelnen BIP-322-Nachweis. $BABY In der „Ökosystem“-Aussage sollte dieser Satz an die Stirn geklebt werden: Man kann nicht beweisen, dass man den Schlüssel hat, und daraus schließen, dass man jede Tür öffnen kann; und selbst wenn man eine Tür öffnen kann, heißt das nicht, dass hinter jeder Tür alles dir gehört. #baby