метаданных транзакций (нам нужен тип транзакции OP_DROP?)

Водрузили от комментариев по тянуть запрос 1809:

котировка

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

Я думаю, что, безусловно, использовать футляры для связывания некоторых неизменный мета-данные с транзакцией. Пример: Bitcoin-клиент, который дал уникальный адрес возврата для каждой исходящей сделки, и автоматически групп возврат сделку вместе с первоначальными платежными операциями.

Кто-то может создать службу, которая связывает данные с транзакционными идентификаторами, но они должны сделать больше работы, чтобы сделать данные неизменны ... и это мне не ясно, как вы делаете, что безопасно.

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

Если я делаю некоторый тип смарт-контракта с Bitcoin сделок, я хочу, данные договора, запеченные в и охватываемые подписи сделки. И человек, я деловой операции с хотел бы, чтобы убедиться, что я не могу изменить условия договора, как только сделка будет подписан.

Мне кажется, самым простым, самым простой и безопасный способ сделать это с типом OP_DROP сделки с ограниченными данными. Данные в blockchain есть (транзакция + HASH (метаданные)), и это то, что будет подписано. Фактические метаданные могут храниться вне blockchain и посмотрели вверх (и проверяются) с помощью хэша (рука-волны, рука волны, я понятия не имею, как это происходит, если есть больше чем одно место, которое хранит метаданные транзакции, и т.д.).

Любая схема, которая пытается переместить HASH (метаданные) за пределами транзакции подписи, записанной в blockchain будет, по крайней мере, быть более сложной. И, таким образом, очень вероятно, будет менее безопасным.

Я пропускаю некоторую другую простую, безопасную, децентрализованная, без blockchain схемы подключения метаданных транзакций?

Цитата: Гэвин Андресен 10 сентября 2012 года, 6:25:20 PM

Я пропускаю некоторую другую простую, безопасную, децентрализованная, без blockchain схемы подключения метаданных транзакций?

Может быть. С верхней части моей головы (извиняюсь заранее, если я что-то очевидное отсутствует):

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

В теории, это уже позволяет безопасное объединение произвольных метаданных с сделкой Bitcoin. Проблема заключается в том, что нам необходимо связаться с получателем * до * мы делаем сделку, которая не работает хорошо для многих случаев применения.

Так как об этом.

Получатель публикует свою общественную точку ECDSA P.

Отправитель генерирует JSON-метаданные объекта М и вычисляет его хэш-е = SHA256 (M). Затем отправитель вычисляет новую общественную точку P_M = Р * е. Затем отправитель создает транзакцию отправки денег на адрес RIPE160 (SHA256 (P_M)). Наконец, он передает M получателя через защищенный канал - это может быть отправлен непосредственно через HTTPS, зашифрованную электронную почту и т.д., или, возможно, оставили в виде сообщения в DHT, зашифрованный с ECDH и общественной точкой P получателя в качестве ключа.

Какие свойства обладает такой схемой есть?

Получатель стремится к одному набору метаданных M для этой сделки, если они не могут найти столкновение SHA256. До тех пор, пока объект метаданных приватный, никто не может определить связь между точкой P и общественной сделкой конкретной точкой P_M. Получатель не должен быть всегда-онлайн.

Продуктивное обсуждение в IRC сегодня:
http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/09/10#l4463724

Резюме: Хорошая идея, Стефан. Много деталей должны быть разработаны ...

Выполнение трюков с открытым ключом не решают дела на рынке облигаций, где вы хотите, чтобы явно рекламировать какую сделку "является" (За оплату Bitcoin).

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

Код:

Сообщение оплаты {
  необходимые байты TX = 1; // Не имеет выхода, подписанный с SIGHASH_NONE
  дополнительные байты refund_scripts = 2;
  Необязательная строка сообщения = 3;
}

будет делать трюк.

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

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

Цитата: Гэвин Андресен 10 сентября 2012 года, 6:25:20 PM

Я думаю, что, безусловно, использовать футляры для связывания некоторых неизменный мета-данные с транзакцией.

Я отправляю отчасти потому, что я чувствовал, что мои уши сжигая на # Bitcoin-DEV.

Есть ли все, что транслируется, должны быть включены в блок цепи? Я предложил давно, что подписи не может быть частью хэша, так что данные подписи могут быть сокращены из.

Есть две проблемы, связанные с включением данных OP_DROP. Одним из них является объем данных, сохраненных в блоке цепи для вечности, а другой объем данных, который должен распространяться по сети прямо сейчас. Эти вопросы не то же самое, и не страдают теми же ограничениями. Я считаю, что нынешняя система smooshes их вместе, чтобы сделать вещи «проще». Я не думаю, что это хорошая идея.

ByteCoin

Цитата: Майк Херн на 10 сентября 2012, 10:14:21 PM

Выполнение трюков с открытым ключом не решают дела на рынке облигаций, где вы хотите, чтобы явно рекламировать какую сделку "является" (За оплату Bitcoin).

Ну, по крайней мере, это будет оптимизация размера.

Возьмем, к примеру "BOND" сообщение:

котировка

"BOND" <хэш сообщения облигаций> DROP DROP <эмитент Публичных> CHECKSIG

Может быть уменьшено до:

котировка

"BOND" DROP <сообщение Публичных> CHECKSIG

где <сообщение Публичных> знак равно <эмитент Публичных> * <хэш сообщения облигаций>,

Только необходимые изменения в сетевой протокол связь является то, что объект должен эмитент (а не "май") Содержат эмитента Публичных.

Можно сказать, что сейчас мы не можем получить хэш сообщения облигаций от сделки, если мы не видели соответствующее сообщение Bond еще. Но если это так, хэш сообщения Bond не сказал бы нам что-нибудь в любом случае, так что мы ничего не теряем. Для HashMaps мы можем использовать сообщение Публичное в качестве ключа, который может быть получен как из сделки и сообщения Bond, поэтому индексации и поиска в в любом направлении по-прежнему возможно.

все "BOND" строка действительно делает это предупредить нас о том, что нам нужно, чтобы проверить эту сделку против индекса. Другими словами, существует только из соображений производительности, так стоит ли действительно беспокойство практического / реализации, взвешивая blockchain раздуваться от производительности узла связи. Учитывая, что это всего лишь шесть байтов, хотя это, кажется, безусловно, стоит.

Если мы хотим действительно уменьшить размер выходного сценария, мы можем даже использовать хэш Публичных сообщения вместо сообщения Публичных себя.

котировка

"BOND" DROP DUP HASH160 EQUALVERIFY CHECKSIG

Я не смотрел на нее в глубине, но, кажется, одни и те же оптимизации применяются к "ПОЛИТИКА" сделка, хотя я думаю, что новый эфир и новый HashMap должен быть добавлен к сети связи.

котировка

Есть ли все, что транслируется, должны быть включены в блок цепи? Я предложил давно, что подписи не может быть частью хэша, так что данные подписи могут быть сокращены из.

Подписи уже не является частью хэша, что сделало бы невозможным подписать сделку. Смотрите определение SignatureHash в коде. (Редактирование: извините ByteCoin, я думаю, что вы имели в виду транзакции хэш не подпись хэш, правильно я думаю, тот факт, что блок цепь полностью самодостаточен Validating очень важно, хотя?!).

Стефан - отличное предложение. Это отличный способ сделать вещи. Для входа на выход управления, то, что нынешний владелец облигаций должен рассчитывать владелец privkey * запись связь хэш тоже, чтобы сделать его соответствия Публичных, верно?

Цитата: Майк Хирн 11 сентября 2012 года, 3:59:42 PM

Стефан - отличное предложение. Это отличный способ сделать вещи. Для входа на выход управления, то, что нынешний владелец облигаций должен рассчитывать владелец privkey * запись связь хэш тоже, чтобы сделать его соответствия Публичных, верно?

Ага.

--

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

Скажем, у вас есть сообщение Публичных M. Подсчитано от эмитента открытого ключа P₁ и Bond сообщение хэш б₁ а М = Р₁ * б₁.

Теперь я злой хакер, и я хочу, чтобы создать еще одну пару P₂, б₂ что также приводит к М. Что я могу сделать, я выбираю сообщение произвольную Bond, вычислить его хэш-б₂ а затем рассчитать Р₂ = М * б₂^-1. Очевидно, что я не имею соответствующий закрытый ключ, но имеющий действительную пару P₂, б₂ может быть достаточно, чтобы вызвать проблемы, в зависимости от случая использования. Что мешает это нападение является тем фактом, что сообщение Bond содержит Публичное. Если я пытаюсь ввести P₂ в сообщении связи, его хэш изменения и P₂ уже не правильно. Для того, чтобы сделать сообщение действительным, я бы найти коллизию SHA256, то есть сообщение Bond, где я вставленный P₂, но это приводит к тому же хэш-б₂.

Спасибо за объяснение. Я должен был смотреть на некоторые обозначения / взять быстрый учебник ECC (опять же) :-), но теперь я думаю, я это понимаю.

Для тех, следующих вместе б^-1 означает модульный обратный Ь, то есть XB по модулю р = 1, где х представляет собой раствор и р определяется secp256k1 в качестве основных, в котором все модульных операции имеют место.

Цитата: Stefan Thomas на 11 сентября 2012 года, 8:32:03 PM

Скажем, у вас есть сообщение Публичных M. Подсчитано от эмитента открытого ключа P₁ и Bond сообщение хэш б₁ а М = Р₁ * б₁.

Теперь я злой хакер, и я хочу, чтобы создать еще одну пару P₂, б₂ что также приводит к М. Что я могу сделать, я выбираю сообщение произвольную Bond, вычислить его хэш-б₂ а затем рассчитать Р₂ = М * б₂^-1. Очевидно, что я не имею соответствующий закрытый ключ, но имеющий действительную пару P₂, б₂ может быть достаточно, чтобы вызвать проблемы

Тот, кто имеет частный ключ для P₁ можно легко вычислить закрытый ключ для P₂. Я не следовал вашей схеме, но я полагаю, что это эмитент. Если я ловлю на правильно, то эмитент может искажать информацию о связи, о том, что открытый ключ эмитента был на самом деле P₂.

Цитата: Майк Хирн 11 сентября 2012 года, 9:26:26 PM

Для тех, следующих вместе б^-1 означает модульный обратный Ь, то есть XB моды п = 1, где х представляет собой решение и п определяются secp256k1 в качестве основных, в котором все модульных операции имеют место.

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

Код:

р = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
п = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

Цитата: Майк Хирн 11 сентября 2012 года, 3:59:42 PM

Я думаю, что вы имели в виду транзакции хэш не подпись хэш, верно? Я думаю, тот факт, что блок цепь полностью самодостаточен Validating очень важно, хотя!

Да, это то, что я имел в виду. Блок цепь остается полностью самостоятельная проверка, если хэш сделки не включает подпись до тех пор, как вы потрудились, чтобы сохранить подпись. На данный момент, хотя вы должны хранить свои подписи. Может кто-нибудь предложить удаленно правдоподобный сценарий, в котором мы бы пожалеть не хеширования подписи?

ByteCoin

Цитата: ByteCoin 12 сентября 2012, 12:24:24 AM

Вам не нужно хранить подписи вы должны хранить подписи или TXID, ultraprune хранит TXID, но не подписи в своей базе данных монет (которая является единственной вещью, он использует для проверки, так что не только возможно, но реализовано) , Поскольку максимально эффективная обрезка всегда мгновенно отсекает подпись и делает обрезку за txout вместо за транзакцию вы будете иметь, чтобы сохранить TXID в любом случае.

Вот почему я громко бить в барабан вверх-нить о высказывании любой OP_DROP вещи, если она вообще существует, должны быть в scriptsig, а не scriptpubkey ... scriptsigs всегда мгновенно prunable.

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

Цитата: gmaxwell от 12 сентября 2012 года, 2:41:28 AM

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

Почему бы другой узел должен доверять вам полностью инициализировать себя под моей схеме?
Можете ли вы придумать отдаленно правдоподобной схему, в которой кто-то жалеет нас за исключением подписи от хэша, который генерирует идентификатор транзакции?

ByteCoin

Цитата: ByteCoin 12 сентября 2012, 12:24:24 AM

Совершенно верно, я не думал об этом, да Так что подчеркивает тот факт, что вам нужно иметь Публичных, содержащийся в хэш (и подтвердить это соответствует, конечно), чтобы предотвратить этот класс атаки.

Это, вероятно, было доведено до того, где-то, но предложение Гэвина, чтобы добавить новую стандартную операцию следующего типа:

Код:

..64-или-меньше байт .. OP_DROP ..n .. ..pubkeys .. ..m .. OP_CHECKMULTISIG

Так что мешает кому-то из сделок с использованием как следующий в качестве временной меры?

Код:

1 Публичных data1 (data2) 2/3 OP_CHECKMULTISIG

Это сохраняет 64 или 128 байт, закодированные в общественном ключе (ов), или даже просто 32 байт со сжатым открытым ключом, при этом имея один настоящий открытый ключ, который у вас есть закрытый ключ тоже, так что вы можете провести выходные сделки позже. (Любой один из 3-х подписей могут быть использованы, чтобы провести) Кодированные данные могут все еще быть в открытом виде, а также, например, один из двух открытых ключей может быть легко "BOND", А также обивка. (Я предполагаю, что случайное заполнение будет необходимо для обеспечения секретного ключа не может быть принуждено от чрезмерно простого открытого ключа)

Вы можете также использовать транзакцию P2SH стиле, перемещая данные в scriptSig:

scriptPubKey:

Код:

OP_HASH160 [20 байт-хэш-значение] OP_EQUAL

scriptSig:

Код:

 Подпись {1 Публичных data1 (data2) 2/3} OP_CHECKMULTISIG

Цитата: Retep 17 сентября 2012, 12:33:18 AM

Вы можете также использовать транзакцию P2SH стиле, перемещая данные в scriptSig:

Использование P2SH по крайней мере означает неизрасходованный txout мал, и не несет дополнительных данных.

Вы не можете поместить данные в scriptSig, по очевидным причинам - цель данных OP_DROPd должен объявить о том, что выход является особенным и требует специальной обработки, несмотря на то неизрасходованные.

Цитата: Майк Хирн 18 сентября 2012, 11:07:34 AM

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

О, я понимаю, что вы имеете в виду прямо сейчас. Это немного неудобно, но я предполагаю, что это может работать. Вы должны были бы объявить в scriptSig какой выход вы были на самом деле маркировки как специальные.

Цитата: Майк Хирн 18 сентября 2012 года, 3:49:02 PM

Вам даже не нужно делать это на самом деле: выходы пронумерованы так что ваш стандарт может быть, если есть более одного выхода, то первый один зарезервирован для изменения. В худшем случае вам нужно добавить некоторые дополнительные монеты, если то, что вы тратите водоразделы точно.

На самом деле, это заставило меня понять, что для многих приложений любого типа scriptPubKey сообщения открывает вам неприятную проблема: атаки повторного воспроизведения. Давайте предположим, что ваш "выпускать облигации" Протокол является то, что любые монеты из сделки с особо выраженной scriptPubKey считаются выдаваться. Теперь любой желающий может создать транзакцию с одинаковым шифром scriptPubKey, создавая выход, который выглядит, как будто это часть выпуска облигаций. Очевидно, что существует много способов, чтобы смягчить это, но ...

С другой стороны, scriptSig основе вопрос защищен от этого griefing, так как только вы можете выпустить больше облигаций с этого адреса, как только у вас есть закрытый ключ, чтобы создать действительный scriptSig.

Если вы должны были использовать мой P2SH взломать вы должны пойти на шаг дальше в протоколе, так как это действительно акт потратив от самого специального адреса, который передает информацию. Так что просто сказать, что только тогда, когда последний бит суммы выходного составляет 0, один Satoshi, является информация действительна. Теперь вы можете свободно любые сделки, отправленные на ваш волшебный адрес без общения ничего, в худшем случае, включив дополнительный вход, чтобы вы нечетное число satoshis.

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

котировка

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

Я не уверен, - точка смарт собственности является то, что сделки является недвижимость. ScriptPubKey не считывается в изоляции, это принципиально частью, содержащей сделки.

Если вы скопировали scriptPubKey подобное было бы создать другую связь, что произошло одни и те же параметры, что и первый. Он показал бы под кого-то ELSES идентичности, которая будет смущать да, но приложение, которое люди используют для торговли облигаций заметит проблему, когда он связался узел в объявлении облигаций и сказал "Я хочу, чтобы купить облигации, идентифицированной продукции <гашиш>:индекс" и узел сказал "э, я никогда не изданный", Обращение в узел происхождения является частью уже протокола (вот почему сообщение Protobuf имеет URL в нем).

Он может открыть интересные атаки DoS, хотя.

10 сентября 2012, 6:25:20 PM	# 1
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Водрузили от комментариев по тянуть запрос 1809: котировка Только данные, которые строго необходимы для мира, чтобы подтвердить сделку имеет место в блоке цепи. Вот вся суть. Все, что имеет значение только для отправителя и получателя (или минера) должно быть между отправителем и получателем (или шахтером) и не должно быть сохранено навсегда любым другим полным узлом в мире. Я думаю, что, безусловно, использовать футляры для связывания некоторых неизменный мета-данные с транзакцией. Пример: Bitcoin-клиент, который дал уникальный адрес возврата для каждой исходящей сделки, и автоматически групп возврат сделку вместе с первоначальными платежными операциями. Кто-то может создать службу, которая связывает данные с транзакционными идентификаторами, но они должны сделать больше работы, чтобы сделать данные неизменны ... и это мне не ясно, как вы делаете, что безопасно. Я действительно хочу, чтобы мой возврат адрес, который будет «запеченным в» к сделке, что я подписывать, так что, если сделка будет принята в блоке цепь я знаю, не был каким-то хакер-то, кому удалось переписать адрес возврата таким образом они получают мой монеты. Если я делаю некоторый тип смарт-контракта с Bitcoin сделок, я хочу, данные договора, запеченные в и охватываемые подписи сделки. И человек, я деловой операции с хотел бы, чтобы убедиться, что я не могу изменить условия договора, как только сделка будет подписан. Мне кажется, самым простым, самым простой и безопасный способ сделать это с типом OP_DROP сделки с ограниченными данными. Данные в blockchain есть (транзакция + HASH (метаданные)), и это то, что будет подписано. Фактические метаданные могут храниться вне blockchain и посмотрели вверх (и проверяются) с помощью хэша (рука-волны, рука волны, я понятия не имею, как это происходит, если есть больше чем одно место, которое хранит метаданные транзакции, и т.д.). Любая схема, которая пытается переместить HASH (метаданные) за пределами транзакции подписи, записанной в blockchain будет, по крайней мере, быть более сложной. И, таким образом, очень вероятно, будет менее безопасным. Я пропускаю некоторую другую простую, безопасную, децентрализованная, без blockchain схемы подключения метаданных транзакций?

10 сентября 2012, 6:56:35 PM	# 2
Stefan Thomas Сообщения: 235 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Получил 1806 Биткоинов Реальная история. Цитата: Гэвин Андресен 10 сентября 2012 года, 6:25:20 PM Я пропускаю некоторую другую простую, безопасную, децентрализованная, без blockchain схемы подключения метаданных транзакций? Может быть. С верхней части моей головы (извиняюсь заранее, если я что-то очевидное отсутствует): В настоящее время, как мы обрабатываем метаданные в Bitcoin, что метаданные передаются получателю, который затем отвечает с уникальным сгенерированным адресом. После того, как отправитель производит платеж, метаданные могут быть определены по адресу. В теории, это уже позволяет безопасное объединение произвольных метаданных с сделкой Bitcoin. Проблема заключается в том, что нам необходимо связаться с получателем * до * мы делаем сделку, которая не работает хорошо для многих случаев применения. Так как об этом. Получатель публикует свою общественную точку ECDSA P. Отправитель генерирует JSON-метаданные объекта М и вычисляет его хэш-е = SHA256 (M). Затем отправитель вычисляет новую общественную точку P_M = Р * е. Затем отправитель создает транзакцию отправки денег на адрес RIPE160 (SHA256 (P_M)). Наконец, он передает M получателя через защищенный канал - это может быть отправлен непосредственно через HTTPS, зашифрованную электронную почту и т.д., или, возможно, оставили в виде сообщения в DHT, зашифрованный с ECDH и общественной точкой P получателя в качестве ключа. Какие свойства обладает такой схемой есть? Получатель стремится к одному набору метаданных M для этой сделки, если они не могут найти столкновение SHA256. До тех пор, пока объект метаданных приватный, никто не может определить связь между точкой P и общественной сделкой конкретной точкой P_M. Получатель не должен быть всегда-онлайн.

10 сентября 2012, 8:34:53 PM	# 3
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Продуктивное обсуждение в IRC сегодня: http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/09/10#l4463724 Резюме: Хорошая идея, Стефан. Много деталей должны быть разработаны ...

10 сентября 2012, 10:14:21 PM	# 4
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Выполнение трюков с открытым ключом не решают дела на рынке облигаций, где вы хотите, чтобы явно рекламировать какую сделку "является" (За оплату Bitcoin). Я думаю, что опасения по поводу заворота преувеличены, за исключением случаев использования я говорил. Шансы на многие или большинство операций, имеющих дополнительные данные в них, кажется маловероятной. Для таких вещей, как обратные адреса, связанные с ними сообщения, и т.д. почти всегда есть лучшие способы сделать это - как платежный протокол, или от человека к человеку сделкам просто подключая хороший простой буфер протокола для электронной почты, который содержит: Код: Сообщение оплаты { необходимые байты TX = 1; // Не имеет выхода, подписанный с SIGHASH_NONE дополнительные байты refund_scripts = 2; Необязательная строка сообщения = 3; } будет делать трюк. Как я уже говорил, за исключением случаев использования как рынки облигаций и платить результаты политики, имеющие дополнительные данные в сделке имеют некоторые преимущества. Bitcoin уже компрометирует затраты на хранение по соображениям простоты и удобства использования, где это имеет смысл (адрес для удобства ввода, checkmultisig, а не тайный обмена для пороговых подписей). Я думаю, что Грегори, в первую очередь, утверждая, что, если мы добавим эту возможность, использование большинства случай не будет смарт собственности или другие протоколы, с довольно тонкими вопросами двойного связывания, но просто бессмысленно граффити. И это реальная проблема. Рынки облигаций и другие вещи довольно экзотические, я полностью поддерживаю просьбу действительно прибить протоколы оплаты заранее.

11 сентября 2012, 12:23:45 AM	# 5
ByteCoin Сообщения: 416 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Цитата: Гэвин Андресен 10 сентября 2012 года, 6:25:20 PM Я думаю, что, безусловно, использовать футляры для связывания некоторых неизменный мета-данные с транзакцией. Я отправляю отчасти потому, что я чувствовал, что мои уши сжигая на # Bitcoin-DEV. Есть ли все, что транслируется, должны быть включены в блок цепи? Я предложил давно, что подписи не может быть частью хэша, так что данные подписи могут быть сокращены из. Есть две проблемы, связанные с включением данных OP_DROP. Одним из них является объем данных, сохраненных в блоке цепи для вечности, а другой объем данных, который должен распространяться по сети прямо сейчас. Эти вопросы не то же самое, и не страдают теми же ограничениями. Я считаю, что нынешняя система smooshes их вместе, чтобы сделать вещи «проще». Я не думаю, что это хорошая идея. ByteCoin

11 сентября 2012, 3:48:14 AM	# 6
Stefan Thomas Сообщения: 235 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Цитата: Майк Херн на 10 сентября 2012, 10:14:21 PM Выполнение трюков с открытым ключом не решают дела на рынке облигаций, где вы хотите, чтобы явно рекламировать какую сделку "является" (За оплату Bitcoin). Ну, по крайней мере, это будет оптимизация размера. Возьмем, к примеру "BOND" сообщение: котировка "BOND" <хэш сообщения облигаций> DROP DROP <эмитент Публичных> CHECKSIG Может быть уменьшено до: котировка "BOND" DROP <сообщение Публичных> CHECKSIG где <сообщение Публичных> знак равно <эмитент Публичных> * <хэш сообщения облигаций>, Только необходимые изменения в сетевой протокол связь является то, что объект должен эмитент (а не "май") Содержат эмитента Публичных. Можно сказать, что сейчас мы не можем получить хэш сообщения облигаций от сделки, если мы не видели соответствующее сообщение Bond еще. Но если это так, хэш сообщения Bond не сказал бы нам что-нибудь в любом случае, так что мы ничего не теряем. Для HashMaps мы можем использовать сообщение Публичное в качестве ключа, который может быть получен как из сделки и сообщения Bond, поэтому индексации и поиска в в любом направлении по-прежнему возможно. все "BOND" строка действительно делает это предупредить нас о том, что нам нужно, чтобы проверить эту сделку против индекса. Другими словами, существует только из соображений производительности, так стоит ли действительно беспокойство практического / реализации, взвешивая blockchain раздуваться от производительности узла связи. Учитывая, что это всего лишь шесть байтов, хотя это, кажется, безусловно, стоит. Если мы хотим действительно уменьшить размер выходного сценария, мы можем даже использовать хэш Публичных сообщения вместо сообщения Публичных себя. котировка "BOND" DROP DUP HASH160 EQUALVERIFY CHECKSIG Я не смотрел на нее в глубине, но, кажется, одни и те же оптимизации применяются к "ПОЛИТИКА" сделка, хотя я думаю, что новый эфир и новый HashMap должен быть добавлен к сети связи.

11 сентября 2012, 3:59:42 PM	# 7
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) котировка Есть ли все, что транслируется, должны быть включены в блок цепи? Я предложил давно, что подписи не может быть частью хэша, так что данные подписи могут быть сокращены из. Подписи уже не является частью хэша, что сделало бы невозможным подписать сделку. Смотрите определение SignatureHash в коде. (Редактирование: извините ByteCoin, я думаю, что вы имели в виду транзакции хэш не подпись хэш, правильно я думаю, тот факт, что блок цепь полностью самодостаточен Validating очень важно, хотя?!). Стефан - отличное предложение. Это отличный способ сделать вещи. Для входа на выход управления, то, что нынешний владелец облигаций должен рассчитывать владелец privkey * запись связь хэш тоже, чтобы сделать его соответствия Публичных, верно?

11 сентября 2012, 8:32:03 PM	# 8
Stefan Thomas Сообщения: 235 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Цитата: Майк Хирн 11 сентября 2012 года, 3:59:42 PM Стефан - отличное предложение. Это отличный способ сделать вещи. Для входа на выход управления, то, что нынешний владелец облигаций должен рассчитывать владелец privkey * запись связь хэш тоже, чтобы сделать его соответствия Публичных, верно? Ага. -- Еще один момент, который будет очевидны для комфортно с эллиптической кривой математикой, но медведи записи: Очень важно, что база Публичный захватываются в хэше, в противном случае схема становится неоднозначным. Я буду использовать случай сообщения облигации в качестве примера. Скажем, у вас есть сообщение Публичных M. Подсчитано от эмитента открытого ключа P₁ и Bond сообщение хэш б₁ а М = Р₁ * б₁. Теперь я злой хакер, и я хочу, чтобы создать еще одну пару P₂, б₂ что также приводит к М. Что я могу сделать, я выбираю сообщение произвольную Bond, вычислить его хэш-б₂ а затем рассчитать Р₂ = М * б₂^-1. Очевидно, что я не имею соответствующий закрытый ключ, но имеющий действительную пару P₂, б₂ может быть достаточно, чтобы вызвать проблемы, в зависимости от случая использования. Что мешает это нападение является тем фактом, что сообщение Bond содержит Публичное. Если я пытаюсь ввести P₂ в сообщении связи, его хэш изменения и P₂ уже не правильно. Для того, чтобы сделать сообщение действительным, я бы найти коллизию SHA256, то есть сообщение Bond, где я вставленный P₂, но это приводит к тому же хэш-б₂.

11 сентября 2012, 9:26:26 PM	# 9
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Спасибо за объяснение. Я должен был смотреть на некоторые обозначения / взять быстрый учебник ECC (опять же) :-), но теперь я думаю, я это понимаю. Для тех, следующих вместе б^-1 означает модульный обратный Ь, то есть XB по модулю р = 1, где х представляет собой раствор и р определяется secp256k1 в качестве основных, в котором все модульных операции имеют место.

12 сентября 2012, 12:24:24 AM	# 10
ByteCoin Сообщения: 416 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Цитата: Stefan Thomas на 11 сентября 2012 года, 8:32:03 PM Скажем, у вас есть сообщение Публичных M. Подсчитано от эмитента открытого ключа P₁ и Bond сообщение хэш б₁ а М = Р₁ * б₁. Теперь я злой хакер, и я хочу, чтобы создать еще одну пару P₂, б₂ что также приводит к М. Что я могу сделать, я выбираю сообщение произвольную Bond, вычислить его хэш-б₂ а затем рассчитать Р₂ = М * б₂^-1. Очевидно, что я не имею соответствующий закрытый ключ, но имеющий действительную пару P₂, б₂ может быть достаточно, чтобы вызвать проблемы Тот, кто имеет частный ключ для P₁ можно легко вычислить закрытый ключ для P₂. Я не следовал вашей схеме, но я полагаю, что это эмитент. Если я ловлю на правильно, то эмитент может искажать информацию о связи, о том, что открытый ключ эмитента был на самом деле P₂. Цитата: Майк Хирн 11 сентября 2012 года, 9:26:26 PM Для тех, следующих вместе б^-1 означает модульный обратный Ь, то есть XB моды п = 1, где х представляет собой решение и п определяются secp256k1 в качестве основных, в котором все модульных операции имеют место. "модульные операции" использовать простое число р, но для приведенного выше расчета следует использовать группу порядка п, которая несколько меньше первична. Код: р = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F п = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 Цитата: Майк Хирн 11 сентября 2012 года, 3:59:42 PM Я думаю, что вы имели в виду транзакции хэш не подпись хэш, верно? Я думаю, тот факт, что блок цепь полностью самодостаточен Validating очень важно, хотя! Да, это то, что я имел в виду. Блок цепь остается полностью самостоятельная проверка, если хэш сделки не включает подпись до тех пор, как вы потрудились, чтобы сохранить подпись. На данный момент, хотя вы должны хранить свои подписи. Может кто-нибудь предложить удаленно правдоподобный сценарий, в котором мы бы пожалеть не хеширования подписи? ByteCoin

12 сентября 2012, 2:41:28 AM	# 11
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Цитата: ByteCoin 12 сентября 2012, 12:24:24 AM Да, это то, что я имел в виду. Блок цепь остается полностью самостоятельная проверка, если хэш сделки не включает подпись до тех пор, как вы потрудились, чтобы сохранить подпись. На данный момент, хотя вы должны хранить свои подписи. Может кто-нибудь предложить удаленно правдоподобный сценарий, в котором мы бы пожалеть не хеширования подписи? Вам не нужно хранить подписи вы должны хранить подписи или TXID, ultraprune хранит TXID, но не подписи в своей базе данных монет (которая является единственной вещью, он использует для проверки, так что не только возможно, но реализовано) , Поскольку максимально эффективная обрезка всегда мгновенно отсекает подпись и делает обрезку за txout вместо за транзакцию вы будете иметь, чтобы сохранить TXID в любом случае. Вот почему я громко бить в барабан вверх-нить о высказывании любой OP_DROP вещи, если она вообще существует, должны быть в scriptsig, а не scriptpubkey ... scriptsigs всегда мгновенно prunable. Если вы говорите о данных, вам не нужно инициализировать другой узел, который не доверяет вам полностью, в этом случае вы не можете отказаться от подписи независимо от того, что хешируется.

13 сентября 2012, 9:35:42 PM	# 12
ByteCoin Сообщения: 416 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Цитата: gmaxwell от 12 сентября 2012 года, 2:41:28 AM Если вы говорите о данных, вам не нужно инициализировать другой узел, который не доверяет вам полностью, в этом случае вы не можете отказаться от подписи независимо от того, что хешируется. Почему бы другой узел должен доверять вам полностью инициализировать себя под моей схеме? Можете ли вы придумать отдаленно правдоподобной схему, в которой кто-то жалеет нас за исключением подписи от хэша, который генерирует идентификатор транзакции? ByteCoin

13 сентября 2012, 9:38:14 PM	# 13
Stefan Thomas Сообщения: 235 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Цитата: ByteCoin 12 сентября 2012, 12:24:24 AM Тот, кто имеет частный ключ для P₁ можно легко вычислить закрытый ключ для P₂. Я не следовал вашей схеме, но я полагаю, что это эмитент. Если я ловлю на правильно, то эмитент может искажать информацию о связи, о том, что открытый ключ эмитента был на самом деле P₂. Совершенно верно, я не думал об этом, да Так что подчеркивает тот факт, что вам нужно иметь Публичных, содержащийся в хэш (и подтвердить это соответствует, конечно), чтобы предотвратить этот класс атаки.

17 сентября 2012, 12:33:18 AM	# 14
Питер Тодд Сообщения: 1106 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Это, вероятно, было доведено до того, где-то, но предложение Гэвина, чтобы добавить новую стандартную операцию следующего типа: Код: ..64-или-меньше байт .. OP_DROP ..n .. ..pubkeys .. ..m .. OP_CHECKMULTISIG Так что мешает кому-то из сделок с использованием как следующий в качестве временной меры? Код: 1 Публичных data1 (data2) 2/3 OP_CHECKMULTISIG Это сохраняет 64 или 128 байт, закодированные в общественном ключе (ов), или даже просто 32 байт со сжатым открытым ключом, при этом имея один настоящий открытый ключ, который у вас есть закрытый ключ тоже, так что вы можете провести выходные сделки позже. (Любой один из 3-х подписей могут быть использованы, чтобы провести) Кодированные данные могут все еще быть в открытом виде, а также, например, один из двух открытых ключей может быть легко "BOND", А также обивка. (Я предполагаю, что случайное заполнение будет необходимо для обеспечения секретного ключа не может быть принуждено от чрезмерно простого открытого ключа) Вы можете также использовать транзакцию P2SH стиле, перемещая данные в scriptSig: scriptPubKey: Код: OP_HASH160 [20 байт-хэш-значение] OP_EQUAL scriptSig: Код: Подпись {1 Публичных data1 (data2) 2/3} OP_CHECKMULTISIG

18 сентября 2012, 12:54:46 AM	# 15
jgarzik Сообщения: 1484 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Цитата: Retep 17 сентября 2012, 12:33:18 AM Вы можете также использовать транзакцию P2SH стиле, перемещая данные в scriptSig: Использование P2SH по крайней мере означает неизрасходованный txout мал, и не несет дополнительных данных.

18 сентября 2012, 11:07:34 AM	# 16
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Вы не можете поместить данные в scriptSig, по очевидным причинам - цель данных OP_DROPd должен объявить о том, что выход является особенным и требует специальной обработки, несмотря на то неизрасходованные.

18 сентября 2012, 2:07:08 PM	# 17
Питер Тодд Сообщения: 1106 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Цитата: Майк Хирн 18 сентября 2012, 11:07:34 AM Вы не можете поместить данные в scriptSig, по очевидным причинам - цель данных OP_DROPd должен объявить о том, что выход является особенным и требует специальной обработки, несмотря на то неизрасходованные. Что вы можете. Поставив его в scriptSig мы объявляем о том, что выход из сделки с помощью этого scriptSig является особенным и нуждается в специальной обработке, несмотря на то неизрасходованные.

18 сентября 2012, 3:49:02 PM	# 18
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) О, я понимаю, что вы имеете в виду прямо сейчас. Это немного неудобно, но я предполагаю, что это может работать. Вы должны были бы объявить в scriptSig какой выход вы были на самом деле маркировки как специальные.

18 сентября 2012, 7:09:11 PM	# 19
Питер Тодд Сообщения: 1106 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) Цитата: Майк Хирн 18 сентября 2012 года, 3:49:02 PM О, я понимаю, что вы имеете в виду прямо сейчас. Это немного неудобно, но я предполагаю, что это может работать. Вы должны были бы объявить в scriptSig какой выход вы были на самом деле маркировки как специальные. Вам даже не нужно делать это на самом деле: выходы пронумерованы так что ваш стандарт может быть, если есть более одного выхода, то первый один зарезервирован для изменения. В худшем случае вам нужно добавить некоторые дополнительные монеты, если то, что вы тратите водоразделы точно. На самом деле, это заставило меня понять, что для многих приложений любого типа scriptPubKey сообщения открывает вам неприятную проблема: атаки повторного воспроизведения. Давайте предположим, что ваш "выпускать облигации" Протокол является то, что любые монеты из сделки с особо выраженной scriptPubKey считаются выдаваться. Теперь любой желающий может создать транзакцию с одинаковым шифром scriptPubKey, создавая выход, который выглядит, как будто это часть выпуска облигаций. Очевидно, что существует много способов, чтобы смягчить это, но ... С другой стороны, scriptSig основе вопрос защищен от этого griefing, так как только вы можете выпустить больше облигаций с этого адреса, как только у вас есть закрытый ключ, чтобы создать действительный scriptSig. Если вы должны были использовать мой P2SH взломать вы должны пойти на шаг дальше в протоколе, так как это действительно акт потратив от самого специального адреса, который передает информацию. Так что просто сказать, что только тогда, когда последний бит суммы выходного составляет 0, один Satoshi, является информация действительна. Теперь вы можете свободно любые сделки, отправленные на ваш волшебный адрес без общения ничего, в худшем случае, включив дополнительный вход, чтобы вы нечетное число satoshis. Конечно, все это не имеет значения для чего-то вроде временных меток, где то, что вы на самом деле пытаетесь сделать, это получить некоторые данные в Merkle дерево блока.

19 сентября 2012, 11:04:10 AM	# 20
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: метаданные транзакций (нам нужен тип транзакции OP_DROP?) котировка Теперь любой желающий может создать транзакцию с одинаковым шифром scriptPubKey, создавая выход, который выглядит, как будто это часть выпуска облигаций. Я не уверен, - точка смарт собственности является то, что сделки является недвижимость. ScriptPubKey не считывается в изоляции, это принципиально частью, содержащей сделки. Если вы скопировали scriptPubKey подобное было бы создать другую связь, что произошло одни и те же параметры, что и первый. Он показал бы под кого-то ELSES идентичности, которая будет смущать да, но приложение, которое люди используют для торговли облигаций заметит проблему, когда он связался узел в объявлении облигаций и сказал "Я хочу, чтобы купить облигации, идентифицированной продукции <гашиш>:индекс" и узел сказал "э, я никогда не изданный", Обращение в узел происхождения является частью уже протокола (вот почему сообщение Protobuf имеет URL в нем). Он может открыть интересные атаки DoS, хотя.

Заголовок