Telegram Group & Telegram Channel

Теперь о Graftroot
⬇️⬇️⬇️
Taproot эффективен в случае «совместного закрытия», однако альтернативные варианты предполагают раскрытие ветвей Меркла, что также тянет за собой обработку больших массивов данных.

Технология Graftroot, предложенная Максвеллом, предполагает, что участники смарт-контракта создают «пороговый публичный ключ», но в дальнейшем они его не видоизменяют. Вместо этого они подписывают скрипты (альтернативные условия траты) с целью создания «пороговых подписей» для каждого из них.

Так, пользователь выбирает определенный скрипт, хранит его вместе с соответствующей подписью, которая может подтвердить, что альтернативное условие траты истинное и одобрено всеми участниками делегированное.

Вернемся к ситуации с А и Б, которые могут осуществить трату средств при определенных условиях. У них есть опция «совместного закрытия», то есть А может потратить монеты через неделю или же это может сделать Б, если он задействует секретное число. В этом случае они оба объединяют публичные ключи и создают «пороговый публичный ключ», который позволит им осуществить трату при наличии “пороговой подписи”. Последнюю создадут при непосредственной трате.

Затем оба участника создают и подписывают альтернативные скрипты. А сохраняет «пороговую подпись» для скрипта, который позволит ей осуществить трату через неделю, а Б делает то же для сценария с секретным числом. Отметим при этом, что “пороговых подписей” и соответствующих сценариев для траты недостаточно: они служат лишь подтверждением, что Б и А договорились об условиях. Для осуществления траты необходимо выполнить условия, заложенные в скрипте.

В случае провала «совместного закрытия», участники должны раскрыть альтернативный скрипт и «пороговую подпись». Сторонние пользователи смогут сопоставить «пороговый публичный ключ» с «пороговой подписью», чтобы подтвердить, что условия в скрипте были одобрены всеми сторонами. Таким образом они оба могут потратить средства, а другие пользователи никогда не узнают о наличии альтернативных сценариев.

Проблемой решения Graftroot является его интерактивность. Участники должны контактировать друг с другом для подтверждения альтернативных скриптов до траты. Кроме того, они должны хранить «пороговые подписи» для каждого из этих скриптов, и при их потере, они лишатся запасных вариантов для траты в случае провала «совместного закрытия».

Graftroot скрывает наличие альтернативных версий, однако в каждой транзакции должна указываться используемая версия протокола, которая может показать пользователям, какая именно технология использовалась.

Есть небольшая проблема, связанная с одновременным развертыванием всех этих функций. Каждый раз, когда развертывается новое «изменение консенсуса», оно требует нового формата адресации.

Новые адреса отличаются от старых, и этим выдают тех, кто уже использует новую функцию – тем более, что не каждый внедрит обновление сразу в день его запуска. Это займет время, точно так же, как и прошлые изменения. Это небольшой удар по конфиденциальности, однако одновременное развертывание всех этих обновлений превратилось бы в настоящий хаос.

#SmartContracts



tg-me.com/CryptoBotan/711
Create:
Last Update:


Теперь о Graftroot
⬇️⬇️⬇️
Taproot эффективен в случае «совместного закрытия», однако альтернативные варианты предполагают раскрытие ветвей Меркла, что также тянет за собой обработку больших массивов данных.

Технология Graftroot, предложенная Максвеллом, предполагает, что участники смарт-контракта создают «пороговый публичный ключ», но в дальнейшем они его не видоизменяют. Вместо этого они подписывают скрипты (альтернативные условия траты) с целью создания «пороговых подписей» для каждого из них.

Так, пользователь выбирает определенный скрипт, хранит его вместе с соответствующей подписью, которая может подтвердить, что альтернативное условие траты истинное и одобрено всеми участниками делегированное.

Вернемся к ситуации с А и Б, которые могут осуществить трату средств при определенных условиях. У них есть опция «совместного закрытия», то есть А может потратить монеты через неделю или же это может сделать Б, если он задействует секретное число. В этом случае они оба объединяют публичные ключи и создают «пороговый публичный ключ», который позволит им осуществить трату при наличии “пороговой подписи”. Последнюю создадут при непосредственной трате.

Затем оба участника создают и подписывают альтернативные скрипты. А сохраняет «пороговую подпись» для скрипта, который позволит ей осуществить трату через неделю, а Б делает то же для сценария с секретным числом. Отметим при этом, что “пороговых подписей” и соответствующих сценариев для траты недостаточно: они служат лишь подтверждением, что Б и А договорились об условиях. Для осуществления траты необходимо выполнить условия, заложенные в скрипте.

В случае провала «совместного закрытия», участники должны раскрыть альтернативный скрипт и «пороговую подпись». Сторонние пользователи смогут сопоставить «пороговый публичный ключ» с «пороговой подписью», чтобы подтвердить, что условия в скрипте были одобрены всеми сторонами. Таким образом они оба могут потратить средства, а другие пользователи никогда не узнают о наличии альтернативных сценариев.

Проблемой решения Graftroot является его интерактивность. Участники должны контактировать друг с другом для подтверждения альтернативных скриптов до траты. Кроме того, они должны хранить «пороговые подписи» для каждого из этих скриптов, и при их потере, они лишатся запасных вариантов для траты в случае провала «совместного закрытия».

Graftroot скрывает наличие альтернативных версий, однако в каждой транзакции должна указываться используемая версия протокола, которая может показать пользователям, какая именно технология использовалась.

Есть небольшая проблема, связанная с одновременным развертыванием всех этих функций. Каждый раз, когда развертывается новое «изменение консенсуса», оно требует нового формата адресации.

Новые адреса отличаются от старых, и этим выдают тех, кто уже использует новую функцию – тем более, что не каждый внедрит обновление сразу в день его запуска. Это займет время, точно так же, как и прошлые изменения. Это небольшой удар по конфиденциальности, однако одновременное развертывание всех этих обновлений превратилось бы в настоящий хаос.

#SmartContracts

BY CryptoBotan


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/CryptoBotan/711

View MORE
Open in Telegram


CryptoBotan Telegram | DID YOU KNOW?

Date: |

What is Telegram?

Telegram’s stand out feature is its encryption scheme that keeps messages and media secure in transit. The scheme is known as MTProto and is based on 256-bit AES encryption, RSA encryption, and Diffie-Hellman key exchange. The result of this complicated and technical-sounding jargon? A messaging service that claims to keep your data safe.Why do we say claims? When dealing with security, you always want to leave room for scrutiny, and a few cryptography experts have criticized the system. Overall, any level of encryption is better than none, but a level of discretion should always be observed with any online connected system, even Telegram.

Telegram hopes to raise $1bn with a convertible bond private placement

The super secure UAE-based Telegram messenger service, developed by Russian-born software icon Pavel Durov, is looking to raise $1bn through a bond placement to a limited number of investors from Russia, Europe, Asia and the Middle East, the Kommersant daily reported citing unnamed sources on February 18, 2021.The issue reportedly comprises exchange bonds that could be converted into equity in the messaging service that is currently 100% owned by Durov and his brother Nikolai.Kommersant reports that the price of the conversion would be at a 10% discount to a potential IPO should it happen within five years.The minimum bond placement is said to be set at $50mn, but could be lowered to $10mn. Five-year bonds could carry an annual coupon of 7-8%.

CryptoBotan from kr


Telegram CryptoBotan
FROM USA