Я пришел с идеей для того, как Bitcoin (или альт цепь) может быть использована для облегчения крошечных анонимных nanopayments, сохраняя при этом вожжи на блок цепи наворотов. Интересно, что другие думали об этом.

По nanopayment, я имею в виду что-то платить супер крошечное для тривиального сервиса - например - для оплаты 0.0001 BTC каждому из трех узлов Tor для передачи одного мегабайта трафика с приоритетом премиум. Или, как антиспам электронной почты марок.

Проблема на его лицо: Создание nanopayments расходится с вздутием живота блока цепи Bitcoin в. Это должно быть довольно легко видеть, что ряд платежей, как это будет "спам" в Bitcoin и неосуществимым из-за операционные издержки, а также нежелателен для всех, кто хочет провести весь блок цепи (это означает, что все).

Я упоминаю альт цепь в качестве подходящего для этого задания по двум причинам. Одна моя идея, что решает "nanopayment наворотов" вопрос потребует включений отключенных арифметических опкодов на Bitcoin, новых сообщений в протокол, и, вероятно, цепи вилки - что-то совершенно вряд ли будет принято на Bitcoin как заявлено разработчиками ядра. Но если моя идея заслуживает внимания, может быть, это даст легитимность существующей альт цепи делает это, и найти свою нишу. Может быть, Litecoin может быть официальной цепью вероятностных платежей или что-то.

Так что идея?

Идея, в общем, для Алисы, чтобы сделать 0,0001 BTC nanopayment Бобу, подписав сообщение, не стоит 0,0001 BTC, но, подписав сообщение, которое имеет (с точки зрения Алисы) 1 в 10000 вероятность того стоит 1 BTC Бобу и отправив его непосредственно к нему.  Это сообщение будет функционировать так же, как доля в майнинг. Из 10000 таких nanopayments, в среднем, 9999 ничего не будет стоить и 1 не будет.

Для того, чтобы работать честно, Алиса не должна иметь никакого способа узнать, доля которых на самом деле погашаемые получателю. Итак, вот что я предлагаю.

• Алиса начинает с txout она владеет, стоимостью 1 BTC. Может быть, Боб получит его, может быть, Боб не будет, но чем больше она потребляет услуги Боба, шансы пойти вверх, что Боб будет получить все это.
• Боб создает новый адрес Bitcoin и посылает его Алисе. Важно, чтобы Алиса еще не знает, публичный ключ к этому Bitcoin адреса, чтобы предотвратить ее от обмана Боба, поэтому Боб никогда не должен был потрачен с этого адреса раньше.
• Алиса генерирует и подписывает сделку для Боба, который проводит ее 1 BTC к нему. Тем не менее, эта сделка для Боба обременено Алисе тремя способами через скрипт txout.
  
  • Во-первых, он должен быть подписан Алисе, что, конечно, есть. (Это держит незнакомец вне.)
  • Два в том, что его погашение также требует знаний открытого ключа по адресу, который до поры до времени, только Боб.
  • Три в том, что какое-либо условие псевдослучайного - непредсказуемый Алисе, но статистически вероятно, произойдут с вероятностью 1/10000 - должно быть выполнено для оплаты. Алиса не должна быть в состоянии предсказать хорошие акции или же она может удерживать их. Непредсказуемость Элис зависит от Элис не зная открытый ключ Боба оплаты.
• Как Алиса продолжает запрашивать и потреблять услуги от Боба (например, мегабайты премиума пропускной способности Tor), она постоянно знаки и отправляет это nanopayment транзакцию Бобу. Каждый раз, когда она подписывает, она должна выбрать другое случайное значение K в подписи (или поочередно, подписывает его с увеличивающимся одноразовым номером, который OP_DROPped), который в основном бросает кости и делает новую акцию. Боб оценивает их spendability, и если он обнаруживает, что он получил долю, которая удовлетворяет всем трем требованиям, он передает его на blockchain раскрывая свой открытый ключ, и собирает свою полную Bitcoin.

Конечно, из-за дисперсии, Алиса иногда получить свои услуги бесплатно, а иногда она будет сильно переплачивать за них. Однако, если Алиса потребляет такие услуги на регулярной основе, то сумма, она платит будет стремиться к сумме она потребляет.

Теперь, вот как эти шаги будут работать на Bitcoin (игнорируя тот факт, что он использует для инвалидов опкодов и нестандартные сделки. - вот почему эта идея может получить прыгнула на с помощью альт цепи, ища различия)

• Предположим, у Алисы есть нормальный txout стоит ровно 1 BTC.
• Алиса знает <качается-адрес> получив его Боба.
• Когда Алиса посылает Бобу долю, она подписывает сделку, которая выглядит следующим образом: OP_DUP OP_HASH160 <качается-адрес> OP_EQUALVERIFY OP_2DUP OP_CHECKSIGVERIFY OP_HASH160 OP_SWAP OP_HASH160 OP_XOR <константа: 10000> OP_MOD OP_0 OP_EQUAL
• Боб будет оценивать долю для spendability, и опубликовать его в блок цепи, если он решил, что он мог бы провести его, другими словами, случайная составляющая помечено победу. (Он мог бы еще опубликовать его в блок цепи без случайного выигрыша, но он будет посылать свою монету в могилу в процессе)
• Боб будет тратить его на себя, выпуская не только Sig и Публичных, но N, Sig, и Публичных
• Алиса может продолжать посылать микроплатежей Бобу, используя ту же самую операцию, только подписав его повторно и повторно отправить его Бобу, для каждого блока / мегабайта / все, что она потребляет от Боба. (Помните, что подпись Алисы имеет случайную составляющую К Известно только Алисе, поэтому подпись будет отличаться каждый раз, когда она подписывает такое же сообщение. Эта разница в том, как Боб может рассматривать его как совершенно новую акцию.)

ТЕПЕРЬ, КАК НА ЗЕМЛЕ ДЕЛАЕТ, ЧТО SCRIPT SOUP РАБОТУ?

Сложная в последующую части сценария является той частью, которая устанавливает 10000: условие 1, что Алиса не может предсказать, но Боб может подтвердить свои шансы на. Сценарий выполняет следующие действия:

• Проверяет подпись Алисы. (Первые несколько операций, за исключение OP_2DUP, должны выглядеть знакомой)
• Дополнительный OP_2DUP принимает дополнительную копию как Sig и Публичных, прежде чем они потребляются OP_CHECKSIGVERIFY, потому что мы хотим, чтобы оба из них, чтобы проверить, если наша доля ничего хорошего
• OP_CHECKSIGVERIFY проверяет подпись, в противном случае сделки, если это плохо. Он потребляет одну копию Sig и Публичных, оставляя другую копию обоих из них на стеке.
• Теперь у нас есть OP_HASH160 OP_SWAP OP_HASH160 OP_XOR. Это занимает хэш как Sig и Публичного, и операцию XOR их в одно число, что важно, Алиса не мог предсказать. EDIT: см примечание внизу. Эта часть может не работать, и, возможно, потребуется заменить чем-то другим, как случайное число или увеличивающимся нонса включены Алисой, чтобы хэширования с открытым ключом Боба для того, чтобы выполнить ту же цель: производить ряд псевдослучайных Алиса не может предсказать, , на основе приверженности Боб не может измениться.
• 10000 OP_MOD делит комбинированный хеш и сохраняет остаток. (10000, в данном случае, является "шансы" фактор, который определяет вероятность доли будет хорошо.)
• Если модуль оказывается равным нулю, Боб является победителем и получает весь 1 BTC.

Довольно простой и прямой.

Теперь, чтобы убедиться, что Боб держит 1 BTC Баунти сейф, один вызов остается: он должен получить его в блок цепи, прежде чем Алиса выясняет, что он успешно выиграл. Это потому, что Алиса может дважды провести его из-под него. Алиса также может использовать тот же 1 BTC купить услуги от кого-то другого, кто не будет знать, что она является залог акций той же монетой в более чем одном месте, где кто-то был бы обмануты, если обе службы выиграли тот же Bitcoin на вокруг в то же время.

Таким образом, чтобы сделать эту работу, то должны были бы быть способом для Алисы положить, что 1 BTC на удержание в пользу Боба, хотя и временно. Таким образом, Алиса не может красть монету из-под Бобом, но с другой стороны, Боб не получает, чтобы сохранить контроль над монетой, если он не получает выигрышную долю после определенного количества времени.

Единственным возможным способом я мог думать, что делать, это вещательными новое сообщение памяти только равный-равному, что Залоги определенный txout к определенному пункту назначения Bitcoin адрес в течение определенного периода времени. Это сообщение не идет в блок цепи - это просто помещает узлы на уведомления только признавайте затрачивает предназначен для Боба, пока не истечет время блокировки. Что-то я думаю, что было бы крайне маловероятно, чтобы летать с разработчиками Bitcoin, но что-то, что альт цепь ищет нишу не может иметь такую ​​проблему, с.

Я запрашивающий комментарии, так жарь.

EDIT: Я думаю, что я понял одну проблему с моим предложением, по крайней мере, в отношении его осуществления. Я считаю, что я неправильно предположить, что сценарий будет хэширование сигового и Публичного посланной Алисой, но на самом деле, этот сценарий будет запущен, когда Боб тратит средства, и, таким образом, что будет хешированным Публичная и подпись Боба, который он мог просто повторно генерировать. Так что, если вы заметили это, то, возможно, прежде чем указывать на это, считают, что там может быть другой способ, чтобы придумать случайное условие (в конечном счете это в виде подписанного случайного числа, посланного Алисой, если не подпись сама .. . в сочетании с хэш-то известным только Бобу).