Те, кто платит компании, все это знают: самое трудное для защиты — это не обязательно поддельные счета-фактуры. Название поставщика настоящее, договор тоже настоящий, проблема лишь в том, что расчетный счет подменили на чужой. Если смотреть на каждый пункт отдельно — все вроде бы безупречно, но стоит сложить их вместе, и деньги уходят не туда.
Такую же опасность таит и кроссчейн-сценарий. Данные могут быть не полностью фальшивыми, а опасность в том, что публичный ключ Bitcoin и адрес Ethereum искусственно связывают в одну цепочку с теми, кто к этому не имеет права.
В запросах на размещение (сбор средств) Trustless Bitcoin Vaults (TBV) с @BabylonLabs_io одновременно прикладываются Ethereum-адрес, Bitcoin-публичный ключ, выбор Vault Provider, WOTS-согласование и ключевое доказательство по BIP-322. Меня здесь волнует не то, сколько терминов в связке, а то, кто имеет право нажать кнопку подтверждения.
Как только запрос будет принят, дальнейший процесс будет воспринимать действия на двух цепочках как одну и ту же связь авторизации. Если инициатор не может контролировать соответствующий Bitcoin-публичный ключ, это не мелкий изъян — это значит, что кому-то за другого открыли счет и еще назначили следующие контактные данные.
BIP-322 здесь больше похоже на проверку полномочий перед тем, как открыть дверь. Сначала докажи реальный контроль над Bitcoin-публичным ключом, а уже потом говори о том, как подключать учетные записи и приложения со стороны Ethereum. Это не делает мир проще — это просто не дает незнакомцу связать набор публичной информации так, чтобы вместе оказались две стороны, которые ему не принадлежат.
Во многих бедах в интернете виноваты не подделанные файлы, а присвоенные связи. Номер телефона настоящий, банковская карта настоящая, имя тоже настоящее — в итоге неверным оказывается тот, кто имеет право собрать все это в одну операцию. Если система проверяет только детали, но не того, кто устанавливает саму связь, то чем быстрее становится автоматизация, тем быстрее начинают происходить ошибки.
В обсуждениях вокруг $BABY такой порог не звучит так громко, как в «нативном» BTC, но он ближе к самой сути ежедневной безопасности. Сначала протокол отказывает тем, кто в принципе не имеет права инициировать запрос, и только потом дальнейший процесс вообще имеет смысл.
BIP-322 — не KYC и не будет выносить юридических суждений о том, кому принадлежит BTC в реальном мире. Он охраняет вход в протокол, а не всю общественную собственность. Граница очень узкая, но место выбрано идеально.
Многие аварии случаются не потому, что детали поддельные, а потому что реальные детали оказываются связаны с тем, кому они не должны принадлежать. #baby
Такую же опасность таит и кроссчейн-сценарий. Данные могут быть не полностью фальшивыми, а опасность в том, что публичный ключ Bitcoin и адрес Ethereum искусственно связывают в одну цепочку с теми, кто к этому не имеет права.
В запросах на размещение (сбор средств) Trustless Bitcoin Vaults (TBV) с @BabylonLabs_io одновременно прикладываются Ethereum-адрес, Bitcoin-публичный ключ, выбор Vault Provider, WOTS-согласование и ключевое доказательство по BIP-322. Меня здесь волнует не то, сколько терминов в связке, а то, кто имеет право нажать кнопку подтверждения.
Как только запрос будет принят, дальнейший процесс будет воспринимать действия на двух цепочках как одну и ту же связь авторизации. Если инициатор не может контролировать соответствующий Bitcoin-публичный ключ, это не мелкий изъян — это значит, что кому-то за другого открыли счет и еще назначили следующие контактные данные.
BIP-322 здесь больше похоже на проверку полномочий перед тем, как открыть дверь. Сначала докажи реальный контроль над Bitcoin-публичным ключом, а уже потом говори о том, как подключать учетные записи и приложения со стороны Ethereum. Это не делает мир проще — это просто не дает незнакомцу связать набор публичной информации так, чтобы вместе оказались две стороны, которые ему не принадлежат.
Во многих бедах в интернете виноваты не подделанные файлы, а присвоенные связи. Номер телефона настоящий, банковская карта настоящая, имя тоже настоящее — в итоге неверным оказывается тот, кто имеет право собрать все это в одну операцию. Если система проверяет только детали, но не того, кто устанавливает саму связь, то чем быстрее становится автоматизация, тем быстрее начинают происходить ошибки.
В обсуждениях вокруг $BABY такой порог не звучит так громко, как в «нативном» BTC, но он ближе к самой сути ежедневной безопасности. Сначала протокол отказывает тем, кто в принципе не имеет права инициировать запрос, и только потом дальнейший процесс вообще имеет смысл.
BIP-322 — не KYC и не будет выносить юридических суждений о том, кому принадлежит BTC в реальном мире. Он охраняет вход в протокол, а не всю общественную собственность. Граница очень узкая, но место выбрано идеально.
Многие аварии случаются не потому, что детали поддельные, а потому что реальные детали оказываются связаны с тем, кому они не должны принадлежать. #baby