BIP70: Вопрос о каноническом представлении подписанных данных

BIP70 подписывает "буфер протокола" сериализованные данных.
Одна большая проблема реализации у меня было, что то же самое сообщение может кодироваться по-разному, потому что по умолчанию поля большую часть времени не сериализации реализациями Protobuf.

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

Я ничего не вижу, указанный в БИП, я что-то отсутствует?

Я не думаю, что должно быть "необязательный" поля в схеме прото. Бы решить эту проблему.

Я смущен, так как осуществление, Гэвина в https://bitcoincore.org/~gavin/createpaymentrequest.php
Сформировать PaymentRequest, которые иногда включают в себя значения по умолчанию (paymentdetailsversion), а иногда нет (details.expires).

Почему вы reserializing вещи? В PaymentDetails хранится в двоичном виде в Protobuf точно так что вам не придется заботиться о деталях, как именно это было сериализации, подпись охватывает точное бинарное представление, которое хранится в PaymentRequest. Я не думаю, что кто-то еще не было никаких проблем реализации с этим.

Майк, это как я в настоящее время сделать, но я подозреваю, что исполнители не Interop между ними еще.
Кроме того, BitcoinJ не поддерживает подписания платежного сообщения. Насколько я знаю, у меня есть один из единственных рабочей реализации с тем, что сделали Гэвины. (И я подозреваю, что его код не может подтвердить платеж правильно я генерировать)
Вы должны десериализации нуля подписи, а затем вам нужно reserialize, так что вы можете получить байты, которые были хэшированными + подписанными с сертификатом, так что вы можете проверить подпись.

Моя поддержка в реализации, что большая, но я создание тестовых векторов для BIP70, и я почти уверен, что даже если они соответствуют BIP, некоторые из вектора тестов не будут проходить для некоторых реализаций.

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

Во всяком случае разговор дешев

Я положил несколько пробных вектор здесь https://github.com/NicolasDorier/bips/blob/master/bip-0070.mediawiki
Просто попробуйте третью против вашей реализации, если она работает, вы, вероятно, можете игнорировать этот пост. Если нет, и я не прав, мы, вероятно, необходимо пересмотреть BIP70, чтобы быть более четко о том, как сериализовать PaymentRequest перед тем хэширования и подписание.

Вы также можете быть правы, что есть Interop проблемы, но я до сих пор не понимаю, этот вопрос вы имеете.

Вам не нужно reserialize ничего, чтобы проверить подпись. PaymentDetails хранится в Protobuf как "необходимые байты", А не встроенный submessage. Для проверки подписи, вы просто что необработанный массив байт, взять необработанную подпись, и применять их с помощью открытого ключа. Нет Protobuf reserialization не происходит ни в одной точке.

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

Я думаю, что я понимаю, почему вы не понимаете, почему мне нужно reserialize.

Вы думаете, что подпись применяется на "serialized_payment_details", Который, как вы сказали, только один байт [] клякса.
Но подпись не делается на "serialized_payment_details" но в целом "платежный запрос",

Цитата: Майк Херн на 29 мая 2014, 10:57:42 AM

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

Так что, если я вас правильно понимаю, ваше предложение является неправильным. Вы не подпишете двоичные файлы по PaymentDetails. Вы должны подписать сообщение всего PaymentRequest без подписи.
Это означает, что после того, как вы храните информацию о платеже в PaymentRequest, вам необходимо сериализовать PaymentRequest, получить подпись, десериализацию, вставлять подписи, reserialize.
С другой стороны, приемник должен: десериализации, удалить подпись, сериализация, проверить подпись против целого двоичного файла.

Этот процесс / сериализации Deserialize есть где много ошибок лжи. Поскольку некоторые реализации Protobuf будет удалить (или добавить) значение по умолчанию.
Это означает, что конкретная реализация будет казаться хорошо работать, но не в состоянии сделать это с другими реализациями, что создает проблемы реализации, трудно обнаружить.
Это является не средним невозможно сделать хорошую реализацию, но не так легко, как это выглядит.

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

Простейшим примером является payment_details_version, Гэвин сделать вид, в сериализованном PaymentRequest. Моя Protobuf версия, по умолчанию, раздеть его.
Я поддерживаю оба, но оба правильно? Из спецификации, кажется, и все в порядке.

О верно. Я misremembering спецификации. Я не уверен, почему это было сделано именно так: мы были осведомлены о проблемах canonicalisation, поэтому поле детали двоичного кода в первую очередь.

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

Цитата: Майк Hearn 29 мая 2014 года, 7:16:43 PM

Я вижу, так что я думаю, что вы ответили на мой вопрос.
Мне было интересно, почему Гэвин не сериализации значения по умолчанию детали (как details.expires), но сериализации значение paymentrequest по умолчанию. (Как pki_type или payment_details_version)

Представьте себе, что я получаю от провода к PaymentRequest без payment_details_version ни pki_type, например. (По умолчанию является 1 и "никто")
Если я понимаю, правильно проверить подпись, я должен:
-десериализации PaymentRequest,
-обнулить подпись,
-reserialize PaymentRequest, но на этот раз спрашивая мою рамку для добавления полей по умолчанию
-проверить подпись полученных байтов

Что я сделал:
-десериализации PaymentRequest,
-обнулить подпись,
-reserialize PaymentRequest, как это было раньше ~~но на этот раз спрашивая мою рамку для добавления полей по умолчанию~~
-проверить подпись полученных байтов

Я проверял подписи против именно то, что я получил от провода. Но было явно не так, не так ли?

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

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

Честно говоря, если вы хотите, чтобы зависеть от бинарного формата, и подписи этого двоичного формата, моя оценка, что вы должны быть в то число STDIO, не protobufs.

Цитата: Cryddit от 29 мая 2014 года, 7:43:23 PM

Это не столько вопрос о том, есть ли другая реализация.
Речь идет о: Если я получаю requestpayment с отсутствующими (необязательно) полями. Если подписанные данные включают эти отсутствующие поля или нет. (См мой предыдущий ответ)
В зависимости от реализации Protobuf мы используем, по умолчанию, это так ... или нет. Но вопрос остается тем же самым.

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

Мы используем то, что не прямая команда выписать конкретный двоичный формат, а затем мы вводим зависимость от его конкретной двоичной формы. Bzzzt, неправильный ответ.

Цитата: Николас Dorier на 29 мая 2014 года, 7:33:50 PM

Представьте себе, что я получаю от провода к PaymentRequest без payment_details_version ни pki_type, например. (По умолчанию является 1 и "никто")
Если я понимаю, правильно проверить подпись, я должен:
-десериализации PaymentRequest,
-обнулить подпись,
-reserialize PaymentRequest, но на этот раз спрашивая мою рамку для добавления полей по умолчанию
-проверить подпись полученных байтов

Я понимаю, что в этом случае они не будут в данных повторно сериализовать, потому что они не были в оригинале. И библиотека Protobuf действительно следовать этому (IIRC).

Но это звучит, как вы говорите, вы проверили это, и в самом деле по умолчанию реализация Google поместить значения по умолчанию на проволоку, даже если они не были в оригинальной Protobuf? Почему они так работают? Это не поведение я знаю о.

Цитата: Cryddit от 29 мая 2014 года, 8:41:53 PM

Мы используем то, что не прямая команда выписать конкретный двоичный формат, а затем мы вводим зависимость от его конкретной двоичной формы. Bzzzt, неправильный ответ.

Нет, используя protobufs правильный подход. Нам нужно расширяемый формат, который имеет хорошую поддержку кросс языка. Если мы свернули что-то с нуля, мы в конечном итоге создать что-то, что выглядит в основном так же, как protobufs, но, возможно, лучше определяется в терминах деталей как при реализации должны писать полей по умолчанию. Однако, учитывая, что мы можем, а просто ввести некоторые дополнительные правила, которые Protobuf реализации, используемую в BIP70 должны следовать и сохранить каждый много времени, учитывая, что это легче исправить библиотеку, чем писать с нуля.

Спецификация BIP70 действительно настаивает на том, что поля сериализовать в числовом порядке. После того, как мы выяснить, что здесь происходит именно (я подозреваю реализацию Protobuf .NET, который не соответствует Google), мы можем просто обновить BIP70 настаивать на конкретной обработки дополнительных полей с по умолчанию. Это все еще много, гораздо проще, чем определение какой-то новый формат только для Bitcoin.

Николас, который Protobuf библиотеки вы используете? Давайте просто проверить код.

Цитата: Майк Хирн 30 мая 2014, 10:47:37 AM

Цитата: Cryddit от 29 мая 2014 года, 8:41:53 PM

Это не столько проблема библиотеки, я использую Protobuf-сеть, и могу попросить его сделать то, что я хочу, это солидная библиотека.
Мое недопонимание только что: BIP70 спецификация действительно настаивает на том, что поля сериализовать в числовом порядке, Ваше предложение верно только для данных, чтобы подписать.
Источником головной боли является то, что схема прото, определить "необязательный" поля, которые не являются "необязательный" для подписи.

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

Во всяком случае, я сделал запрос тянуть с испытаниями, которые проверяют на такую западню: https://github.com/bitcoin/bips/pull/69

Версия не является обязательным! Если отсутствует это считается 1, но это не означает, что он должен появиться, когда reserializing. Изменение необязательным требуется не будут совместимы.

Нам нужно выяснить, какую библиотеку делают неправильные вещи и исправить ее. Возможно, этот вопрос является реализация PHP вместо этого? Это не было бы действительно удивило меня.

Майк Хирн я думаю, что я не объяснил проблему достаточно хорошо.

Я цитирую :

котировка

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

Обратите внимание "со всеми полями сериализовать в числовом порядке", Это означает, что даже если платеж от провода не включает в себя версию (потому что по желанию), он должен еще быть сериализовать, чтобы вычислить подпись.
Это сложная часть, легко ошибиться.

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

В запросе тянуть, вы увидите, что: payreq1_without_detailversion.paymentrequest и payreq1.paymentrequest, оба имеют (и должны) ту же сигнатуру.
Я думаю, что каждая реализация получить один из них неправильно. (За исключением, если я неправильно понял часть подписи в BIP)

Мое чтение того, что говорит BIP, что поля Сериализованные, упорядочиваются в порядке. Не то, что все поля, включая необязательные поля должны быть избыточно записаны на проволоку.

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

28 мая 2014, 6:18:04 PM	# 1
Николя Dorier Сообщения: 700 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru BIP70 подписывает "буфер протокола" сериализованные данных. Одна большая проблема реализации у меня было, что то же самое сообщение может кодироваться по-разному, потому что по умолчанию поля большую часть времени не сериализации реализациями Protobuf. Так что я делаю, что я проверка подписи против сообщения, как я получаю его, и просто поставить подпись пустой. Это прекрасно работает, но я подозреваю, что каноническое представление сообщения протокола будет проще реализовать. Я ничего не вижу, указанный в БИП, я что-то отсутствует?

28 мая 2014, 6:25:06 PM	# 2
Николя Dorier Сообщения: 700 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Получил 1806 Биткоинов Реальная история. Я не думаю, что должно быть "необязательный" поля в схеме прото. Бы решить эту проблему.

28 мая 2014, 6:55:33 PM	# 3
Николя Dorier Сообщения: 700 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Я смущен, так как осуществление, Гэвина в https://bitcoincore.org/~gavin/createpaymentrequest.php Сформировать PaymentRequest, которые иногда включают в себя значения по умолчанию (paymentdetailsversion), а иногда нет (details.expires).

28 мая 2014, 6:58:17 PM	# 4
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Почему вы reserializing вещи? В PaymentDetails хранится в двоичном виде в Protobuf точно так что вам не придется заботиться о деталях, как именно это было сериализации, подпись охватывает точное бинарное представление, которое хранится в PaymentRequest. Я не думаю, что кто-то еще не было никаких проблем реализации с этим.

28 мая 2014, 9:25:22 PM	# 5
Николя Dorier Сообщения: 700 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Майк, это как я в настоящее время сделать, но я подозреваю, что исполнители не Interop между ними еще. Кроме того, BitcoinJ не поддерживает подписания платежного сообщения. Насколько я знаю, у меня есть один из единственных рабочей реализации с тем, что сделали Гэвины. (И я подозреваю, что его код не может подтвердить платеж правильно я генерировать) Вы должны десериализации нуля подписи, а затем вам нужно reserialize, так что вы можете получить байты, которые были хэшированными + подписанными с сертификатом, так что вы можете проверить подпись. Моя поддержка в реализации, что большая, но я создание тестовых векторов для BIP70, и я почти уверен, что даже если они соответствуют BIP, некоторые из вектора тестов не будут проходить для некоторых реализаций. Если вы считаете, что нормально, то и будет. Я просто не считаю, что правильно, чтобы не иметь канонический путь подписания PaymentRequest, это приведет к реализации багги. С плохой совместимостью между различными реализациями. Такая ошибка являются своего рода трудно найти.

28 мая 2014, 10:27:42 PM	# 6
Николя Dorier Сообщения: 700 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Во всяком случае разговор дешев Я положил несколько пробных вектор здесь https://github.com/NicolasDorier/bips/blob/master/bip-0070.mediawiki Просто попробуйте третью против вашей реализации, если она работает, вы, вероятно, можете игнорировать этот пост. Если нет, и я не прав, мы, вероятно, необходимо пересмотреть BIP70, чтобы быть более четко о том, как сериализовать PaymentRequest перед тем хэширования и подписание.

29 мая 2014, 10:57:42 AM	# 7
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Вы также можете быть правы, что есть Interop проблемы, но я до сих пор не понимаю, этот вопрос вы имеете. Вам не нужно reserialize ничего, чтобы проверить подпись. PaymentDetails хранится в Protobuf как "необходимые байты", А не встроенный submessage. Для проверки подписи, вы просто что необработанный массив байт, взять необработанную подпись, и применять их с помощью открытого ключа. Нет Protobuf reserialization не происходит ни в одной точке. Для того, чтобы подписать запрос платежа, то же самое: вы сериализации PaymentDetails в двоичную, войдите в двоичном вы сериализованную и хранить двоичный вы сериализованную в сообщении PaymentRequest.

29 мая 2014, 11:51:23 AM	# 8
Николя Dorier Сообщения: 700 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Я думаю, что я понимаю, почему вы не понимаете, почему мне нужно reserialize. Вы думаете, что подпись применяется на "serialized_payment_details", Который, как вы сказали, только один байт [] клякса. Но подпись не делается на "serialized_payment_details" но в целом "платежный запрос", Цитата: Майк Херн на 29 мая 2014, 10:57:42 AM Для того, чтобы подписать запрос платежа, то же самое: вы сериализации PaymentDetails в двоичную, войдите в двоичном вы сериализованную и хранить двоичный вы сериализованную в сообщении PaymentRequest. Так что, если я вас правильно понимаю, ваше предложение является неправильным. Вы не подпишете двоичные файлы по PaymentDetails. Вы должны подписать сообщение всего PaymentRequest без подписи. Это означает, что после того, как вы храните информацию о платеже в PaymentRequest, вам необходимо сериализовать PaymentRequest, получить подпись, десериализацию, вставлять подписи, reserialize. С другой стороны, приемник должен: десериализации, удалить подпись, сериализация, проверить подпись против целого двоичного файла. Этот процесс / сериализации Deserialize есть где много ошибок лжи. Поскольку некоторые реализации Protobuf будет удалить (или добавить) значение по умолчанию. Это означает, что конкретная реализация будет казаться хорошо работать, но не в состоянии сделать это с другими реализациями, что создает проблемы реализации, трудно обнаружить. Это является не средним невозможно сделать хорошую реализацию, но не так легко, как это выглядит. Я добавил несколько тестовых векторов, которые должны проверить против этого типа задач, но имеющий канонический способом выражения сериализованную paymentrequest будет лучше. Простейшим примером является payment_details_version, Гэвин сделать вид, в сериализованном PaymentRequest. Моя Protobuf версия, по умолчанию, раздеть его. Я поддерживаю оба, но оба правильно? Из спецификации, кажется, и все в порядке.

29 мая 2014, 7:16:43 PM	# 9
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных О верно. Я misremembering спецификации. Я не уверен, почему это было сделано именно так: мы были осведомлены о проблемах canonicalisation, поэтому поле детали двоичного кода в первую очередь. Я думаю, что большинство Protobuf реализации поместит поля в последовательную форму данных, если они были установлены на всех, даже если они совпадают значения по умолчанию. Вот почему сообщения Гевины в конечном итоге с набором версии поля. Если ваша реализация Protobuf снижается поля, которые установлены значения по умолчанию во время загрузки, это, наверное, ошибка (хотя с точки зрения большинства пользователей, не является важным один).

29 мая 2014, 7:33:50 PM	# 10
Николя Dorier Сообщения: 700 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Цитата: Майк Hearn 29 мая 2014 года, 7:16:43 PM О верно. Я misremembering спецификации. Я не уверен, почему это было сделано именно так: мы были осведомлены о проблемах canonicalisation, поэтому поле детали двоичного кода в первую очередь. Я думаю, что большинство Protobuf реализации поместит поля в последовательную форму данных, если они были установлены на всех, даже если они совпадают значения по умолчанию. Вот почему сообщения Гевины в конечном итоге с набором версии поля. Если ваша реализация Protobuf снижается поля, которые установлены значения по умолчанию во время загрузки, это, наверное, ошибка (хотя с точки зрения большинства пользователей, не является важным один). Я вижу, так что я думаю, что вы ответили на мой вопрос. Мне было интересно, почему Гэвин не сериализации значения по умолчанию детали (как details.expires), но сериализации значение paymentrequest по умолчанию. (Как pki_type или payment_details_version) Представьте себе, что я получаю от провода к PaymentRequest без payment_details_version ни pki_type, например. (По умолчанию является 1 и "никто") Если я понимаю, правильно проверить подпись, я должен: -десериализации PaymentRequest, -обнулить подпись, -reserialize PaymentRequest, но на этот раз спрашивая мою рамку для добавления полей по умолчанию -проверить подпись полученных байтов Что я сделал: -десериализации PaymentRequest, -обнулить подпись, -reserialize PaymentRequest, как это было раньше ~~но на этот раз спрашивая мою рамку для добавления полей по умолчанию~~ -проверить подпись полученных байтов Я проверял подписи против именно то, что я получил от провода. Но было явно не так, не так ли?

29 мая 2014, 7:43:23 PM	# 11
Cryddit Сообщения: 840 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Я думаю, что это вообще ошибка использовать что-либо из которых существует различные возможные реализации (например, protobufs) в программном обеспечении, где вы принимаете подписи за выход. Вы хотите, чтобы избежать звонков в любой библиотеке, где кто-то может изменить "деталь реализации" как или нет значения по умолчанию кодируются, потому что люди, делающие эти решения не делают их с идеей, что абсолютно надежно тождественны двоичное представление является то, что кто-то хочет. На самом деле, это посторонний вопрос к ним; они реализация protobufs специально, чтобы люди "не придется беспокоиться о" такие детали, как ничтожные двоичное представление, и мы активно подрывать свое намерение путем введения зависимости от конкретных бинарных деталей. Честно говоря, если вы хотите, чтобы зависеть от бинарного формата, и подписи этого двоичного формата, моя оценка, что вы должны быть в то число STDIO, не protobufs.

29 мая 2014, 8:04:56 PM	# 12
Николя Dorier Сообщения: 700 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Цитата: Cryddit от 29 мая 2014 года, 7:43:23 PM Я думаю, что это вообще ошибка использовать что-либо из которых существует различные возможные реализации (например, protobufs) в программном обеспечении, где вы принимаете подписи за выход. Вы хотите, чтобы избежать звонков в любой библиотеке, где кто-то может изменить "деталь реализации" как или нет значения по умолчанию кодируются, потому что люди, делающие эти решения не делают их с идеей, что абсолютно надежно тождественны двоичное представление является то, что кто-то хочет. На самом деле, это посторонний вопрос к ним; они реализация protobufs специально, чтобы люди "не придется беспокоиться о" такие детали, как ничтожные двоичное представление, и мы активно подрывать свое намерение путем введения зависимости от конкретных бинарных деталей. Честно говоря, если вы хотите, чтобы зависеть от бинарного формата, и подписи этого двоичного формата, моя оценка, что вы должны быть в то число STDIO, не protobufs. Это не столько вопрос о том, есть ли другая реализация. Речь идет о: Если я получаю requestpayment с отсутствующими (необязательно) полями. Если подписанные данные включают эти отсутствующие поля или нет. (См мой предыдущий ответ) В зависимости от реализации Protobuf мы используем, по умолчанию, это так ... или нет. Но вопрос остается тем же самым.

29 мая 2014, 8:41:53 PM	# 13
Cryddit Сообщения: 840 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Мы допустили ошибку в выборе осуществления, где этот вопрос (как кодируется или нет значения по умолчанию), даже имеет смысл. Мы используем то, что не прямая команда выписать конкретный двоичный формат, а затем мы вводим зависимость от его конкретной двоичной формы. Bzzzt, неправильный ответ.

30 мая 2014, 10:37:10 AM	# 14
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Цитата: Николас Dorier на 29 мая 2014 года, 7:33:50 PM Представьте себе, что я получаю от провода к PaymentRequest без payment_details_version ни pki_type, например. (По умолчанию является 1 и "никто") Если я понимаю, правильно проверить подпись, я должен: -десериализации PaymentRequest, -обнулить подпись, -reserialize PaymentRequest, но на этот раз спрашивая мою рамку для добавления полей по умолчанию -проверить подпись полученных байтов Я понимаю, что в этом случае они не будут в данных повторно сериализовать, потому что они не были в оригинале. И библиотека Protobuf действительно следовать этому (IIRC). Но это звучит, как вы говорите, вы проверили это, и в самом деле по умолчанию реализация Google поместить значения по умолчанию на проволоку, даже если они не были в оригинальной Protobuf? Почему они так работают? Это не поведение я знаю о.

30 мая 2014, 10:47:37 AM	# 15
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Цитата: Cryddit от 29 мая 2014 года, 8:41:53 PM Мы используем то, что не прямая команда выписать конкретный двоичный формат, а затем мы вводим зависимость от его конкретной двоичной формы. Bzzzt, неправильный ответ. Нет, используя protobufs правильный подход. Нам нужно расширяемый формат, который имеет хорошую поддержку кросс языка. Если мы свернули что-то с нуля, мы в конечном итоге создать что-то, что выглядит в основном так же, как protobufs, но, возможно, лучше определяется в терминах деталей как при реализации должны писать полей по умолчанию. Однако, учитывая, что мы можем, а просто ввести некоторые дополнительные правила, которые Protobuf реализации, используемую в BIP70 должны следовать и сохранить каждый много времени, учитывая, что это легче исправить библиотеку, чем писать с нуля. Спецификация BIP70 действительно настаивает на том, что поля сериализовать в числовом порядке. После того, как мы выяснить, что здесь происходит именно (я подозреваю реализацию Protobuf .NET, который не соответствует Google), мы можем просто обновить BIP70 настаивать на конкретной обработки дополнительных полей с по умолчанию. Это все еще много, гораздо проще, чем определение какой-то новый формат только для Bitcoin. Николас, который Protobuf библиотеки вы используете? Давайте просто проверить код.

30 мая 2014, 11:06:21 AM	# 16
Николя Dorier Сообщения: 700 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Цитата: Майк Хирн 30 мая 2014, 10:47:37 AM Цитата: Cryddit от 29 мая 2014 года, 8:41:53 PM Мы используем то, что не прямая команда выписать конкретный двоичный формат, а затем мы вводим зависимость от его конкретной двоичной формы. Bzzzt, неправильный ответ. Нет, используя protobufs правильный подход. Нам нужно расширяемый формат, который имеет хорошую поддержку кросс языка. Если мы свернули что-то с нуля, мы в конечном итоге создать что-то, что выглядит в основном так же, как protobufs, но, возможно, лучше определяется в терминах деталей как при реализации должны писать полей по умолчанию. Однако, учитывая, что мы можем, а просто ввести некоторые дополнительные правила, которые Protobuf реализации, используемую в BIP70 должны следовать и сохранить каждый много времени, учитывая, что это легче исправить библиотеку, чем писать с нуля. Спецификация BIP70 действительно настаивает на том, что поля сериализовать в числовом порядке. После того, как мы выяснить, что здесь происходит именно (я подозреваю реализацию Protobuf .NET, который не соответствует Google), мы можем просто обновить BIP70 настаивать на конкретной обработки дополнительных полей с по умолчанию. Это все еще много, гораздо проще, чем определение какой-то новый формат только для Bitcoin. Николас, который Protobuf библиотеки вы используете? Давайте просто проверить код. Это не столько проблема библиотеки, я использую Protobuf-сеть, и могу попросить его сделать то, что я хочу, это солидная библиотека. Мое недопонимание только что: BIP70 спецификация действительно настаивает на том, что поля сериализовать в числовом порядке, Ваше предложение верно только для данных, чтобы подписать. Источником головной боли является то, что схема прото, определить "необязательный" поля, которые не являются "необязательный" для подписи. Предложение у меня есть, чтобы удалить "необязательный" от payment_details_version из PaymentRequest из схемы. Таким образом, данные, которые подписали одно и то же, чем данные, которые вы получаете от провода и нет головной боли не бывает.

31 мая 2014, 4:39:55 PM	# 17
Николя Dorier Сообщения: 700 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Во всяком случае, я сделал запрос тянуть с испытаниями, которые проверяют на такую западню: https://github.com/bitcoin/bips/pull/69

2 июня 2014, 5:46:30 AM	# 18
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Версия не является обязательным! Если отсутствует это считается 1, но это не означает, что он должен появиться, когда reserializing. Изменение необязательным требуется не будут совместимы. Нам нужно выяснить, какую библиотеку делают неправильные вещи и исправить ее. Возможно, этот вопрос является реализация PHP вместо этого? Это не было бы действительно удивило меня.

2 июня 2014, 9:19:29 AM	# 19
Николя Dorier Сообщения: 700 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Майк Хирн я думаю, что я не объяснил проблему достаточно хорошо. Я цитирую : котировка Подпись: цифровая подпись хэш буфер протокола сериализации изменения сообщения PaymentRequest, со всеми полями сериализовать в числовом порядке (Все текущие реализации буфера протокола сериализация поля в числовом порядке) и подписаны с использованием открытого ключа в pki_data. Перед сериализации, поле подписи должно быть установлено пустое значение, так что поле входит в подписанном PaymentRequest хэш, но не содержит никаких данных. Обратите внимание "со всеми полями сериализовать в числовом порядке", Это означает, что даже если платеж от провода не включает в себя версию (потому что по желанию), он должен еще быть сериализовать, чтобы вычислить подпись. Это сложная часть, легко ошибиться. Там нет ошибки библиотеки, просто поведения по умолчанию, которые не являются одинаковыми. Это поведение по умолчанию (если вы не будете осторожны) заставит вас появится ваша реализация работает, когда он не будет взаимодействовать с другими. Поведение по умолчанию в вопросе, будет ли библиотека сериализовать в проводе с detailversion со значением 1 или нет. В запросе тянуть, вы увидите, что: payreq1_without_detailversion.paymentrequest и payreq1.paymentrequest, оба имеют (и должны) ту же сигнатуру. Я думаю, что каждая реализация получить один из них неправильно. (За исключением, если я неправильно понял часть подписи в BIP)

2 июня 2014, 12:50:51 PM	# 20
Майк Хирн Сообщения: 1526 Цитировать по имени цитировать ответ	Re: BIP70: Вопрос о каноническом представлении подписанных данных Мое чтение того, что говорит BIP, что поля Сериализованные, упорядочиваются в порядке. Не то, что все поля, включая необязательные поля должны быть избыточно записаны на проволоку. Как я уже говорил, кто-то (то есть один из нас) будет иметь, чтобы сесть и посмотреть, что библиотека получает это неправильно, потому что это не должно быть что-то, что разработчики должны заботиться о.

Заголовок