Nostr, скорочення від «нотатки та інший вміст, що передається через ретрансляцію», — це новий протокол зв’язку, розроблений розробником Lightning Network fiatjaf у 2021 році. Спроби децентралізації ринків розвивалися. На відміну від інших комунікаційних рішень, більшість з яких працюють через тупі клієнти та розумні сервери, Nostr надає розумні клієнти та тупі сервери, тим самим підвищуючи стійкість користувачів до цензури.
**У Nostr усі дані зберігаються локально у користувача й поширюються лише через ретранслятори, а не на центральний сервер, як-от Twitter. ** У випадку соціальних медіа Nostr додає опір цензурі, оскільки користувачі повністю володіють їхнім вмістом і профілями. У світлі нещодавньої суперечки навколо політики цензури Twitter користувачі починають переходити на рішення федеративних комунікацій Mastodon. Однак у Mastodon право власності на вміст і профілі належить оператору сервера Mastodon, на якому реєструється користувач. Хоча об’єднана система, як-от Mastodon, пропонує більший опір цензурі, ніж центральний сервер, оскільки користувачі можуть просто зареєструватися на іншому сервері, якщо їх цензурують, була критика, що Mastodon може застосовувати цензуру через власника сервера.
У грудні 2022 року спільнота Nostr отримала фінансування у розмірі 14 BTC від засновника Twitter Джека Дорсі, що привернуло безпрецедентну увагу до протоколу. Оскільки додатки, побудовані на Nostr, продовжували зростати, мобільний клієнт Damus посів перше місце в категорії соціальних мереж китайського магазину додатків для iOS і в результаті був заборонений. Намагаючись приборкати рух #MarchOffTwitter, генеральний директор Twitter Ілон Маск швидко заборонив контент, пов’язаний з Nostr, і заборонив інші сторонні платформи, такі як Instagram, але безуспішно.
Хоча Nostr сам по собі не є протоколом конфіденційності — за замовчуванням клієнти передають IP-адреси користувачів ретрансляторам — протокол Nostr потенційно може покращити конфіденційність біткойнів.
Покращте конфіденційність і масштабованість BIP47
**BIP47 — це пропозиція щодо вдосконалення біткойнів для створення повторно використовуваних платіжних кодів для регулярних платежів, захищаючи конфіденційність користувачів. **Якщо BIP47 відсутній, щоб уникнути повторного використання адреси, користувачі повинні генерувати нові адреси вручну та трудомістко. Коли користувач повторно використовує адресу для транзакцій, будь-хто, хто спостерігає за ланцюгом блоків, може легко агрегувати всі транзакції, що належать цій адресі, формуючи графік історії платежів і власного капіталу користувача. Таким чином, у біткойнах запобігання повторному використанню адрес є найкращою практикою конфіденційності та вже реалізовано за замовчуванням у багатьох біткойн-гаманцях. Однак часте створення нових адрес може бути незручним, коли користувач намагається встановити регулярні платіжні відносини з іншою стороною, наприклад між продавцем і клієнтом.
**Через BIP47 клієнти можуть створити набір платіжних адрес для продавців. **Якщо клієнт купує продукти щомісяця, продавець повинен щомісяця надсилати адресу клієнту. За допомогою BIP47 клієнт створює спеціальний платіжний код для продавця, подібний до розширеного відкритого ключа. Це дозволяє клієнту автоматично генерувати нову адресу для продавця, не вимагаючи від продавця створення адреси для клієнта.
**BIP47 використовує адреси сповіщень, які відстежуються HD Wallet для виходу. **Під час транзакції сповіщення продавець надсилає клієнту закритий відкритий ключ і ланцюжковий код через поле OP_RETURN разом із спільним секретом, щоб спільна адреса залишалася приватною в загальнодоступному блокчейні. Через архітектуру мережі Bitcoin цей обмін створює кілька проблем. Перші дві проблеми є економічними: транзакція сповіщень складається з 80 байтів, що може стати дорогим для користувачів, коли комісія за транзакції в мережі Bitcoin висока. Крім того, транзакції сповіщень створюють вихідні дані, які неможливо надіслати, **роздуваючи набір UTXO з часом. **Це збільшує обчислювальне навантаження на біткойн-вузли, оскільки їм наразі потрібно зберігати весь набір UTXO, тобто кожен вихідний біткойн, який не використовується як новий вхід, щоб гарантувати дійсність транзакції.
**Повідомлення про транзакції створює те, що називається «отруєними змінами». **Коли користувач отримує зміну від транзакції сповіщення та сплачує її третій стороні, будь-хто, хто спостерігає за блокчейном, зможе співвіднести регулярний платіж користувача з одноразовим платежем, навіть якщо адреса не використовується повторно. Адреса для сповіщень існує лише один раз на гаманець. Якщо продавець бажає мати регулярні платіжні відносини з 10 клієнтами, будь-хто, хто спостерігає за блокчейном, зможе дізнатися про клієнтську базу продавця, оскільки всі 10 клієнтів повинні створювати транзакції сповіщень для продавця на ту саму адресу сповіщень.
**Замість використання транзакцій сповіщень для обміну платіжними кодами між продавцями та клієнтами, платіжні коди можна обмінювати через Nostr. ** На відміну від інших методів зв’язку, Nostr підходить для обміну платіжними кодами BIP47, оскільки немає центрального органу, який би міг цензурувати обмін повідомленнями. При цьому всі прямі повідомлення на Nostr зашифровані за замовчуванням, і немає необхідності обчислювати спільний секрет. Використовуючи BIP47 через Nostr, користувачі можуть уникнути навантаження, пов’язаного зі створенням наборів UTXO з невитраченими виходами, і від’єднати подвійні витрати від недублюючих витрат, уникаючи шкідливих змін і повторного використання адрес сповіщень, а також уникаючи розголошення клієнтської бази, щоб уникнути випуску клієнтська база.
Примітка. Завдяки впровадженню UTreeXO у майбутньому може бути усунуто необхідність у вузлах Bitcoin для зберігання всього поточного набору UTXO. UTreeXO перекладає тягар доведення того, чи транзакція використовує дійсний UTXO, на власника UTXO, зменшуючи вимоги до пам’яті з кількох ГБ до кількох КБ.
Nostr Pay-To-EndPoint
** У біткойнах служба аналізу блокчейну відображає транзакції на ідентифікатори за допомогою евристичного правила «загальної власності на вхідні дані». **Згідно з цим правилом, транзакції, що містять різні відкриті ключі як вхідні дані, класифікуються як належні одній особі. Протокол біткойн також сприйнятливий до аналізу підсумовування підмножин через його архітектуру на основі UTXO, за якою входи та виходи транзакцій корелюються. У аналізі підмножини суми зловмисник може обчислити ймовірність того, що вхід і вихід належать одній сутності, навіть якщо різні відкриті ключі використовуються як вхідні дані для транзакції. Наприклад, якщо транзакція має входи 1, 4, 7, 23 і 6 і виходи 5 і 36, можна зробити висновок, що входи 1 і 4 і входи 7, 23 і 6 належать одній сутності.
Джерело: Відкриття знань у торгівлі криптовалютами: опитування, 2021 р. Ся Фан Лу та Сінь-Цзян Чан
**Pay-to-EndPoint (P2EP) — це захищений конфіденційністю оновлений дизайн Pay-to-IP (P2IP) Сатоші Накамото, закодований в оригінальному клієнті Bitcoin. **Однією з форм транзакції P2EP є транзакція PayJoin, призначена для порушення евристичного правила спільного володіння введенням. У транзакції PayJoin і відправник, і одержувач надають вхідні дані, щоб порушити загальну евристику введення. Використовуючи PayJoins, користувачі можуть обмінюватися інформацією про UTXO, яка буде використовуватися як вхідні дані для створення частково підписаних транзакцій біткойн (PSBT) через будь-який канал зв’язку (наприклад, Tor Onion як кінцеву точку). Після того, як дві сторони узгодять умови та підпишуть транзакцію, транзакція PayJoin виглядає як будь-яка інша транзакція біткойн у блокчейні. Оскільки залучені сторони відіграють роль відправника та одержувача, транзакції PayJoin не лише порушують евристичне правило спільного володіння, але також порушують аналіз підмножини суми: сторони можуть надавати вхідні дані 3 та 5, а результат, створений транзакцією, для 6 і 2.
Джерело: Pay To EndPoint, Адам Фіскор, 2018 рік
Проблема: координація транзакцій PayJoin є досить складною, оскільки учасники мають бути онлайн одночасно, незалежно від того, використовують домени clearnet чи кінцеві точки Tor Onion. Якщо користувач ініціює транзакцію P2EP, наприклад, вимкнувши свій комп’ютер або втративши з’єднання з мережею, трансакція не може зв’язатися. У Nostr зв'язок є асинхронним: користувачі отримують інформацію від ретранслятора після відновлення з'єднання з мережею. Транзакції P2EP можна легше координувати, використовуючи ключі Nostr замість Tor Onion як кінцеву точку для транзакцій P2EP.
Іншою реалізацією P2EP є суперечливий LNURL. За допомогою LNURL замість виснажливого створення нових рахунків-фактур для кожної транзакції користувачі можуть отримати статичну кінцеву точку, яка вказує на веб-сервер для автоматичного створення нових рахунків-фактур. Однак, оскільки веб-сервери покладаються на глобальну службу доменних імен (DNS), користувачі, які використовують LNURL, неминуче розкривають свою особу хостинг-провайдерам і, якщо не вжито належних заходів, свої IP-адреси одержувачам платежу. Широке впровадження LNURL зашкодить анонімності Lightning Network**. Замість того, щоб використовувати веб-сервер як кінцеву точку для LNURL, користувачі можуть використовувати ключі Nostr як кінцеву точку для транзакцій LNURL, щоб приховати свою особу. **
Nostr для CoinJoin
У той час як PayJoin чудово порушує евристику спільного володіння, підмножини та аналіз, PayJoin не забезпечує захист конфіденційності відправника та одержувача від сторін, які співпрацюють. PayJoin — це, по суті, двосторонній CoinJoin, обмежений двома учасниками, що означає, що і відправник, і одержувач знають свої власні входи та виходи, що робить входи та виходи їхніх партнерів ідентифікованими. Якщо транзакція CoinJoined не використовується для сприяння PayJoin, користувачі ризикують розкрити баланс своїх гаманців, а також минулі й майбутні транзакції партнерам PayJoin.
В анонімній системі сертифікатів сум, як-от протокол координації CoinJoin Wasabi Wallet (WabiSabi), ключ Nostr може служити кінцевою точкою зв’язку для координації транзакцій CoinJoin. Це дозволяє відправнику та одержувачу транзакції CoinJoin обмінюватися обліковими даними, необхідними для участі в раунді CoinJoin, уможливлюючи окрему форму оплати в CoinJoin. Використовуючи ключ Nostr як кінцеву точку в CoinJoins, сторони, що співпрацюють, залишаються прихованими від натовпу, не знаючи про баланси та транзакції своїх контрагентів. У той же час використання ключів Nostr як кінцевої точки транзакцій CoinJoin допомагає користувачам PayJoin заощаджувати комісії, здійснюючи платежі безпосередньо в CoinJoin замість того, щоб полегшувати платежі через CoinJoin.
Ще одне використання Nostr у CoinJoins — виявлення координатора. Хоча більшість координаторів CoinJoin працюють за Tor, щоб приховати особи учасників CoinJoin, користувачі наразі не можуть легко знайти нових координаторів, за винятком JoinMarket (ринок CoinJoin для більш досвідчених користувачів CoinJoin). Хоча користувачі CoinJoin можуть додавати користувацькі координатори до гаманця Wasabi (так само просто, як обмінюватися URL-адресами у фоновому режимі), через відсутність платформи для публікації немає можливості автоматизувати процес оновлення координаторів. Тому, щоб знайти нових координаторів, користувачі повинні вручну шукати в соціальних мережах і на форумах (таких як Reddit або Twitter), щоб додати координаторів. Однак публікація послуги Координатора через соціальні медіа чи форуми може становити ризик для Постачальника координації, залежно від політики, застосованої до служби, оскільки деякі сторінки можуть бути легко закриті.
Якщо Tor є анонімним сервером ретрансляції, протоколом, який полегшує анонімне пересилання та отримання повідомлень між одноранговими користувачами, Nostr може діяти як анонімна дошка оголошень. Координатори CoinJoin можуть публікувати свої послуги за допомогою типу події Nostr, а гаманці CoinJoin можуть увімкнути автоматичне отримання інформації з цих серверів ретрансляції та відображення на своїх клієнтах. Трансляція серверів координаторів від Nostr, наприклад, через плагін Servers CoinJoin від BTCPay і підхід, запропонований у програмному забезпеченні Vortex CoinJoin на базі Lightning Network, може позбавити від необхідності ручного пошуку та додавання координаторів CoinJoin у клієнтах CoinJoin, ще більше децентралізуючи ландшафт координації CoinJoin.
Обійти вимоги IP через NOSTR
Як згадувалося раніше, початкова концепція протоколу **Nostr полягала в реалізації повністю децентралізованого ринку під назвою «Коса алея». **З розвитком протоколу Nostr Diagon Alley стає NostrMarkets, розширенням LNbits: торговельної площадки з підтримкою Nostr, що дозволяє продавцям і клієнтам працювати з онлайн-магазинами та взаємодіяти з ними через реле. У NostrMarkets клієнти можуть підписатися на відкритий ключ продавця та отримувати продукти з реле замість відвідування веб-сайту продавця через онлайн-магазин. Це посилює опір онлайн-магазину цензурі, оскільки замість того, щоб покладатися на веб-сайт, який підлягає цензурі, магазин продавця розміщено на всіх ретрансляторах, з якими він спілкується. Навіть якщо сервер продавця захоплено, магазин можна легко розмістити в різних місцях, оскільки всі продукти зберігаються на ретрансляторі в мережі Nostr. NostrMarkets обробляє замовлення та координує платежі через зашифровані прямі повідомлення Nostr, а платежі здійснюються через Lightning Network.
Окрім стійкості до цензури, розширення NostrMarkets від LNbits забезпечує повністю анонімний ринок. Торговці та клієнти не розголошують свої IP-адреси світу, а лише ретранслятору, до якого вони підключаються, і це можна легко вирішити, запустивши клієнт або магазин за Tor. Перевага роботи магазину повністю за Tor полягає в тому, що хоча магазин доступний лише через браузер Tor і веб-сторінки .onion, NostrMarkets може працювати в будь-якому веб-браузері чи смартфоні, покращуючи взаємодію користувача із збереженням конфіденційності між клієнтом і сервером. Оскільки платежі обговорюються за допомогою зашифрованих прямих повідомлень Nostr і здійснюються через мережу Lightning, платежі в NostrMarkets залишатимуться відносно приватними, поки вузол Lightning магазину працює за Tor, оскільки координацію платежів Прямі повідомлення не можна порівняти з іншими прямими повідомленнями в Nostr. .
Ще один спосіб обійти вимогу IP-адреси під час спілкування між сервером і клієнтом — NOSTREST. REST означає «Representational State Transfer», що є частиною архітектури програмного забезпечення всесвітньої мережі для зв’язку між серверами та клієнтами через запити GET, POST, PUT, DELETE та PATCH. Однак, коли клієнт надсилає запит REST на сервер, IP-адреса розкривається, потенційно відкриваючи особисту інформацію. На GitHub __escapeee__ запропонував міст REST API, побудований на Nostr під назвою NOSTREST. Використовуючи ключі Nostr без заголовка автентифікації, користувачам і операторам серверів не потрібно знати IP-адреси один одного. Таким чином, реалізація NOSTREST може покращити конфіденційність Bitcoin-додатків, які використовують REST, оскільки серверу не потрібна IP-адреса клієнта.
Прикладом цього може бути використання кастодіального монетного двору електронної готівки Chaumian, анонімної системи ваучерів для сум. У монетному дворі електронної готівки оператор монетного двору не знає баланси своїх користувачів або вартість обміну. Однак через поточну архітектуру REST, якщо за замовчуванням не працює за Tor (наприклад, у системі електронної готівки Cashu), він вивчає IP-адресу користувача. Однак впровадження та керування підтримкою Tor є громіздким. Через міст NOSTREST проект може легко захистити конфіденційність користувачів. Запустивши монетний двір електронної готівки за Tor і використовуючи NOSTREST для зв’язку між сервером і клієнтом, можна досягти асинхронного зв’язку, у той час як оператор сервера та користувач знають лише відкритий ключ один одного, усуваючи потребу в ідентифікації за ризиком IP.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Парадокс конфіденційності Ностра та вдосконалення конфіденційності біткойнів
Автор: L0la L33tz, Упорядник: DoraFactory
Nostr, скорочення від «нотатки та інший вміст, що передається через ретрансляцію», — це новий протокол зв’язку, розроблений розробником Lightning Network fiatjaf у 2021 році. Спроби децентралізації ринків розвивалися. На відміну від інших комунікаційних рішень, більшість з яких працюють через тупі клієнти та розумні сервери, Nostr надає розумні клієнти та тупі сервери, тим самим підвищуючи стійкість користувачів до цензури.
**У Nostr усі дані зберігаються локально у користувача й поширюються лише через ретранслятори, а не на центральний сервер, як-от Twitter. ** У випадку соціальних медіа Nostr додає опір цензурі, оскільки користувачі повністю володіють їхнім вмістом і профілями. У світлі нещодавньої суперечки навколо політики цензури Twitter користувачі починають переходити на рішення федеративних комунікацій Mastodon. Однак у Mastodon право власності на вміст і профілі належить оператору сервера Mastodon, на якому реєструється користувач. Хоча об’єднана система, як-от Mastodon, пропонує більший опір цензурі, ніж центральний сервер, оскільки користувачі можуть просто зареєструватися на іншому сервері, якщо їх цензурують, була критика, що Mastodon може застосовувати цензуру через власника сервера.
У грудні 2022 року спільнота Nostr отримала фінансування у розмірі 14 BTC від засновника Twitter Джека Дорсі, що привернуло безпрецедентну увагу до протоколу. Оскільки додатки, побудовані на Nostr, продовжували зростати, мобільний клієнт Damus посів перше місце в категорії соціальних мереж китайського магазину додатків для iOS і в результаті був заборонений. Намагаючись приборкати рух #MarchOffTwitter, генеральний директор Twitter Ілон Маск швидко заборонив контент, пов’язаний з Nostr, і заборонив інші сторонні платформи, такі як Instagram, але безуспішно.
Хоча Nostr сам по собі не є протоколом конфіденційності — за замовчуванням клієнти передають IP-адреси користувачів ретрансляторам — протокол Nostr потенційно може покращити конфіденційність біткойнів.
Покращте конфіденційність і масштабованість BIP47
**BIP47 — це пропозиція щодо вдосконалення біткойнів для створення повторно використовуваних платіжних кодів для регулярних платежів, захищаючи конфіденційність користувачів. **Якщо BIP47 відсутній, щоб уникнути повторного використання адреси, користувачі повинні генерувати нові адреси вручну та трудомістко. Коли користувач повторно використовує адресу для транзакцій, будь-хто, хто спостерігає за ланцюгом блоків, може легко агрегувати всі транзакції, що належать цій адресі, формуючи графік історії платежів і власного капіталу користувача. Таким чином, у біткойнах запобігання повторному використанню адрес є найкращою практикою конфіденційності та вже реалізовано за замовчуванням у багатьох біткойн-гаманцях. Однак часте створення нових адрес може бути незручним, коли користувач намагається встановити регулярні платіжні відносини з іншою стороною, наприклад між продавцем і клієнтом.
**Через BIP47 клієнти можуть створити набір платіжних адрес для продавців. **Якщо клієнт купує продукти щомісяця, продавець повинен щомісяця надсилати адресу клієнту. За допомогою BIP47 клієнт створює спеціальний платіжний код для продавця, подібний до розширеного відкритого ключа. Це дозволяє клієнту автоматично генерувати нову адресу для продавця, не вимагаючи від продавця створення адреси для клієнта.
**BIP47 використовує адреси сповіщень, які відстежуються HD Wallet для виходу. **Під час транзакції сповіщення продавець надсилає клієнту закритий відкритий ключ і ланцюжковий код через поле OP_RETURN разом із спільним секретом, щоб спільна адреса залишалася приватною в загальнодоступному блокчейні. Через архітектуру мережі Bitcoin цей обмін створює кілька проблем. Перші дві проблеми є економічними: транзакція сповіщень складається з 80 байтів, що може стати дорогим для користувачів, коли комісія за транзакції в мережі Bitcoin висока. Крім того, транзакції сповіщень створюють вихідні дані, які неможливо надіслати, **роздуваючи набір UTXO з часом. **Це збільшує обчислювальне навантаження на біткойн-вузли, оскільки їм наразі потрібно зберігати весь набір UTXO, тобто кожен вихідний біткойн, який не використовується як новий вхід, щоб гарантувати дійсність транзакції.
**Повідомлення про транзакції створює те, що називається «отруєними змінами». **Коли користувач отримує зміну від транзакції сповіщення та сплачує її третій стороні, будь-хто, хто спостерігає за блокчейном, зможе співвіднести регулярний платіж користувача з одноразовим платежем, навіть якщо адреса не використовується повторно. Адреса для сповіщень існує лише один раз на гаманець. Якщо продавець бажає мати регулярні платіжні відносини з 10 клієнтами, будь-хто, хто спостерігає за блокчейном, зможе дізнатися про клієнтську базу продавця, оскільки всі 10 клієнтів повинні створювати транзакції сповіщень для продавця на ту саму адресу сповіщень.
**Замість використання транзакцій сповіщень для обміну платіжними кодами між продавцями та клієнтами, платіжні коди можна обмінювати через Nostr. ** На відміну від інших методів зв’язку, Nostr підходить для обміну платіжними кодами BIP47, оскільки немає центрального органу, який би міг цензурувати обмін повідомленнями. При цьому всі прямі повідомлення на Nostr зашифровані за замовчуванням, і немає необхідності обчислювати спільний секрет. Використовуючи BIP47 через Nostr, користувачі можуть уникнути навантаження, пов’язаного зі створенням наборів UTXO з невитраченими виходами, і від’єднати подвійні витрати від недублюючих витрат, уникаючи шкідливих змін і повторного використання адрес сповіщень, а також уникаючи розголошення клієнтської бази, щоб уникнути випуску клієнтська база.
Примітка. Завдяки впровадженню UTreeXO у майбутньому може бути усунуто необхідність у вузлах Bitcoin для зберігання всього поточного набору UTXO. UTreeXO перекладає тягар доведення того, чи транзакція використовує дійсний UTXO, на власника UTXO, зменшуючи вимоги до пам’яті з кількох ГБ до кількох КБ.
Nostr Pay-To-EndPoint
** У біткойнах служба аналізу блокчейну відображає транзакції на ідентифікатори за допомогою евристичного правила «загальної власності на вхідні дані». **Згідно з цим правилом, транзакції, що містять різні відкриті ключі як вхідні дані, класифікуються як належні одній особі. Протокол біткойн також сприйнятливий до аналізу підсумовування підмножин через його архітектуру на основі UTXO, за якою входи та виходи транзакцій корелюються. У аналізі підмножини суми зловмисник може обчислити ймовірність того, що вхід і вихід належать одній сутності, навіть якщо різні відкриті ключі використовуються як вхідні дані для транзакції. Наприклад, якщо транзакція має входи 1, 4, 7, 23 і 6 і виходи 5 і 36, можна зробити висновок, що входи 1 і 4 і входи 7, 23 і 6 належать одній сутності.
Джерело: Відкриття знань у торгівлі криптовалютами: опитування, 2021 р. Ся Фан Лу та Сінь-Цзян Чан
**Pay-to-EndPoint (P2EP) — це захищений конфіденційністю оновлений дизайн Pay-to-IP (P2IP) Сатоші Накамото, закодований в оригінальному клієнті Bitcoin. **Однією з форм транзакції P2EP є транзакція PayJoin, призначена для порушення евристичного правила спільного володіння введенням. У транзакції PayJoin і відправник, і одержувач надають вхідні дані, щоб порушити загальну евристику введення. Використовуючи PayJoins, користувачі можуть обмінюватися інформацією про UTXO, яка буде використовуватися як вхідні дані для створення частково підписаних транзакцій біткойн (PSBT) через будь-який канал зв’язку (наприклад, Tor Onion як кінцеву точку). Після того, як дві сторони узгодять умови та підпишуть транзакцію, транзакція PayJoin виглядає як будь-яка інша транзакція біткойн у блокчейні. Оскільки залучені сторони відіграють роль відправника та одержувача, транзакції PayJoin не лише порушують евристичне правило спільного володіння, але також порушують аналіз підмножини суми: сторони можуть надавати вхідні дані 3 та 5, а результат, створений транзакцією, для 6 і 2.
Джерело: Pay To EndPoint, Адам Фіскор, 2018 рік
Проблема: координація транзакцій PayJoin є досить складною, оскільки учасники мають бути онлайн одночасно, незалежно від того, використовують домени clearnet чи кінцеві точки Tor Onion. Якщо користувач ініціює транзакцію P2EP, наприклад, вимкнувши свій комп’ютер або втративши з’єднання з мережею, трансакція не може зв’язатися. У Nostr зв'язок є асинхронним: користувачі отримують інформацію від ретранслятора після відновлення з'єднання з мережею. Транзакції P2EP можна легше координувати, використовуючи ключі Nostr замість Tor Onion як кінцеву точку для транзакцій P2EP.
Іншою реалізацією P2EP є суперечливий LNURL. За допомогою LNURL замість виснажливого створення нових рахунків-фактур для кожної транзакції користувачі можуть отримати статичну кінцеву точку, яка вказує на веб-сервер для автоматичного створення нових рахунків-фактур. Однак, оскільки веб-сервери покладаються на глобальну службу доменних імен (DNS), користувачі, які використовують LNURL, неминуче розкривають свою особу хостинг-провайдерам і, якщо не вжито належних заходів, свої IP-адреси одержувачам платежу. Широке впровадження LNURL зашкодить анонімності Lightning Network**. Замість того, щоб використовувати веб-сервер як кінцеву точку для LNURL, користувачі можуть використовувати ключі Nostr як кінцеву точку для транзакцій LNURL, щоб приховати свою особу. **
Nostr для CoinJoin
У той час як PayJoin чудово порушує евристику спільного володіння, підмножини та аналіз, PayJoin не забезпечує захист конфіденційності відправника та одержувача від сторін, які співпрацюють. PayJoin — це, по суті, двосторонній CoinJoin, обмежений двома учасниками, що означає, що і відправник, і одержувач знають свої власні входи та виходи, що робить входи та виходи їхніх партнерів ідентифікованими. Якщо транзакція CoinJoined не використовується для сприяння PayJoin, користувачі ризикують розкрити баланс своїх гаманців, а також минулі й майбутні транзакції партнерам PayJoin.
В анонімній системі сертифікатів сум, як-от протокол координації CoinJoin Wasabi Wallet (WabiSabi), ключ Nostr може служити кінцевою точкою зв’язку для координації транзакцій CoinJoin. Це дозволяє відправнику та одержувачу транзакції CoinJoin обмінюватися обліковими даними, необхідними для участі в раунді CoinJoin, уможливлюючи окрему форму оплати в CoinJoin. Використовуючи ключ Nostr як кінцеву точку в CoinJoins, сторони, що співпрацюють, залишаються прихованими від натовпу, не знаючи про баланси та транзакції своїх контрагентів. У той же час використання ключів Nostr як кінцевої точки транзакцій CoinJoin допомагає користувачам PayJoin заощаджувати комісії, здійснюючи платежі безпосередньо в CoinJoin замість того, щоб полегшувати платежі через CoinJoin.
Ще одне використання Nostr у CoinJoins — виявлення координатора. Хоча більшість координаторів CoinJoin працюють за Tor, щоб приховати особи учасників CoinJoin, користувачі наразі не можуть легко знайти нових координаторів, за винятком JoinMarket (ринок CoinJoin для більш досвідчених користувачів CoinJoin). Хоча користувачі CoinJoin можуть додавати користувацькі координатори до гаманця Wasabi (так само просто, як обмінюватися URL-адресами у фоновому режимі), через відсутність платформи для публікації немає можливості автоматизувати процес оновлення координаторів. Тому, щоб знайти нових координаторів, користувачі повинні вручну шукати в соціальних мережах і на форумах (таких як Reddit або Twitter), щоб додати координаторів. Однак публікація послуги Координатора через соціальні медіа чи форуми може становити ризик для Постачальника координації, залежно від політики, застосованої до служби, оскільки деякі сторінки можуть бути легко закриті.
Якщо Tor є анонімним сервером ретрансляції, протоколом, який полегшує анонімне пересилання та отримання повідомлень між одноранговими користувачами, Nostr може діяти як анонімна дошка оголошень. Координатори CoinJoin можуть публікувати свої послуги за допомогою типу події Nostr, а гаманці CoinJoin можуть увімкнути автоматичне отримання інформації з цих серверів ретрансляції та відображення на своїх клієнтах. Трансляція серверів координаторів від Nostr, наприклад, через плагін Servers CoinJoin від BTCPay і підхід, запропонований у програмному забезпеченні Vortex CoinJoin на базі Lightning Network, може позбавити від необхідності ручного пошуку та додавання координаторів CoinJoin у клієнтах CoinJoin, ще більше децентралізуючи ландшафт координації CoinJoin.
Обійти вимоги IP через NOSTR
Як згадувалося раніше, початкова концепція протоколу **Nostr полягала в реалізації повністю децентралізованого ринку під назвою «Коса алея». **З розвитком протоколу Nostr Diagon Alley стає NostrMarkets, розширенням LNbits: торговельної площадки з підтримкою Nostr, що дозволяє продавцям і клієнтам працювати з онлайн-магазинами та взаємодіяти з ними через реле. У NostrMarkets клієнти можуть підписатися на відкритий ключ продавця та отримувати продукти з реле замість відвідування веб-сайту продавця через онлайн-магазин. Це посилює опір онлайн-магазину цензурі, оскільки замість того, щоб покладатися на веб-сайт, який підлягає цензурі, магазин продавця розміщено на всіх ретрансляторах, з якими він спілкується. Навіть якщо сервер продавця захоплено, магазин можна легко розмістити в різних місцях, оскільки всі продукти зберігаються на ретрансляторі в мережі Nostr. NostrMarkets обробляє замовлення та координує платежі через зашифровані прямі повідомлення Nostr, а платежі здійснюються через Lightning Network.
Окрім стійкості до цензури, розширення NostrMarkets від LNbits забезпечує повністю анонімний ринок. Торговці та клієнти не розголошують свої IP-адреси світу, а лише ретранслятору, до якого вони підключаються, і це можна легко вирішити, запустивши клієнт або магазин за Tor. Перевага роботи магазину повністю за Tor полягає в тому, що хоча магазин доступний лише через браузер Tor і веб-сторінки .onion, NostrMarkets може працювати в будь-якому веб-браузері чи смартфоні, покращуючи взаємодію користувача із збереженням конфіденційності між клієнтом і сервером. Оскільки платежі обговорюються за допомогою зашифрованих прямих повідомлень Nostr і здійснюються через мережу Lightning, платежі в NostrMarkets залишатимуться відносно приватними, поки вузол Lightning магазину працює за Tor, оскільки координацію платежів Прямі повідомлення не можна порівняти з іншими прямими повідомленнями в Nostr. .
Ще один спосіб обійти вимогу IP-адреси під час спілкування між сервером і клієнтом — NOSTREST. REST означає «Representational State Transfer», що є частиною архітектури програмного забезпечення всесвітньої мережі для зв’язку між серверами та клієнтами через запити GET, POST, PUT, DELETE та PATCH. Однак, коли клієнт надсилає запит REST на сервер, IP-адреса розкривається, потенційно відкриваючи особисту інформацію. На GitHub __escapeee__ запропонував міст REST API, побудований на Nostr під назвою NOSTREST. Використовуючи ключі Nostr без заголовка автентифікації, користувачам і операторам серверів не потрібно знати IP-адреси один одного. Таким чином, реалізація NOSTREST може покращити конфіденційність Bitcoin-додатків, які використовують REST, оскільки серверу не потрібна IP-адреса клієнта.
Прикладом цього може бути використання кастодіального монетного двору електронної готівки Chaumian, анонімної системи ваучерів для сум. У монетному дворі електронної готівки оператор монетного двору не знає баланси своїх користувачів або вартість обміну. Однак через поточну архітектуру REST, якщо за замовчуванням не працює за Tor (наприклад, у системі електронної готівки Cashu), він вивчає IP-адресу користувача. Однак впровадження та керування підтримкою Tor є громіздким. Через міст NOSTREST проект може легко захистити конфіденційність користувачів. Запустивши монетний двір електронної готівки за Tor і використовуючи NOSTREST для зв’язку між сервером і клієнтом, можна досягти асинхронного зв’язку, у той час як оператор сервера та користувач знають лише відкритий ключ один одного, усуваючи потребу в ідентифікації за ризиком IP.