28 ноября 2012, 4:00:19 AM   # 1
 
 
Сообщения: 1428
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome"
Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE
Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e
подробнее...


Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru
Я нахожусь в процессе ведения полного переписывания Оружейных кошельков; не только улучшить дизайн, но для того, чтобы множество новых функций. Тем не менее, я думаю, что на этот раз я хочу, чтобы собрать информацию от других, прежде чем я иду вперед и просто сделать это мой собственный путь. Я хотел бы некоторую обратную связь, прежде чем я слишком привержен это мой путь.  

Есть две основные особенности, которые я хочу реализовать в бумажнике, которые "дальновидный."  Там очень много других вещей происходит внутри, но эти два, что оправдывало реальное обсуждение. Некоторые быстро фона: новые бумажники будут основаны на BIP 0032 так что они будут совместимы с будущими Сатосите кошельками, и получить все полезные свойства иерархических детерминированных кошельков. Там будет иметь возможность хранить несколько кошельков / цепь / счетов для каждого файла. Там будет также способ объединить бумажники. И я хочу, бумажник для обработки сценариев P2SH элегантно.  

Однако, P2SH порождает некоторые сложности в конструкции бумажника. P2SH был разработан, чтобы скрыть скрипты, таким образом, вы не можете просто искать blockchain для мульти-сиг ТХ с участием вас - вы должны реально сэкономить пару (TXID, p2shScript) где-то, так что вы можете узнать и найти его позже. Это действительно раздражает из бумажника резервного копирования точки зрения: все сценарии P2SH должны быть подкреплены немедленно, чтобы избежать потенциала потери монет, но вы также не хотите, чтобы ваш первичный кошелек должен быть скопирован повсюду. Например, я думаю, что Dropbox идеально подходит для резервного копирования P2SH сценариев и TX / адрес комментарии, но если пользователь никогда не должно резервное копирование весь его бумажник Dropbox. И я не доверяю пользователям вручную&ответственно создать надежные резервные копии. С этим в мыслях:

  • (1) Поддержка Соединенного-кошелек (два фактора аутентификация):  Каждый бумажник / цепь / счет будет иметь поле, чтобы указать другой бумажник / цепь / счет. Если это поле присутствует, то это означает, что это "в паре" кошелек - Оружейная будет рассчитывать на наблюдающего только копию второго кошелька в том же файле. Он никогда не будет генерировать одну Sig адреса - это будет только генерировать P2SH сценарии, требующие подписи от обоих кошельков (дизайн также разместятся 2-из-3 и 3-в-3 бумажника комбо). Все сценарии мульти-сиг будут иметь открытые ключи добавлены к ним в порядке идентификаторов кошелек - бумажник с нижним двоичная отпечатка пальца / ID всегда будет иметь свой адрес первой и т.д. Делая это, устройства с бесплатными сочетаниях кошельков (A «в и АВ») будет генерировать один и тот же, полностью детерминированную цепь 2-в-2 платежных адресов. Это означает, что в любом кошельке, я могу сказать, "заставить меня обратиться индекс 37", И он будет получать PubKeyA [37] и PubKeyB [37], и поместить их в P2SH 2-из-2 сценария и вернуть соответствующий платежный адрес. Это делает P2SH для схем двухфакторной аутентификации полностью детерминированных, и будет выглядеть практически идентичны обычным бумажник. (Для двухфакторной AUTH, вам не нужно ((А и В) или С) сделок, вы просто используете (A и B) и резервное копирование обоих кошельков, где вы бы в противном случае резервное копирование бумажник C)
  • (2) "Слегка зашифрованы" P2SH и Комментарии файлы: Есть еще ситуации, когда вам необходимо сделать резервную копию ваших скриптов: эскроу сделки с незнакомыми людьми в Интернете, или различных других контрактов и т.д. Кроме того, было бы хороший сделать резервную копию ваших комментариев / метки тоже, но не стоит рисковать весь свой кошелек, чтобы сделать это. Таким образом, пользователь сможет включить внешний "бумажник" Файл, содержащий только эти скрипты & Комментарии ("бумажник" в кавычках, потому что не хранит ни одного ключа). Всякий раз, когда вы сохраняете комментарий или P2SH сценарий, он сохранит его в обоих файлах. Самое главное, что эти сценарии и комментарии будут шифруется с AES256 использованием HMAC (walletRootPubKey, walletRootChainCode) в качестве ключа шифрования.  Таким образом, этот внешний файл можно создать резервную копию практически в любом месте, даже Dropbox, потому что потребности держателя [по крайней мере] наблюдающий только бумажник, чтобы расшифровать его. Тот, кто компрометирует только ваш Dropbox счет не будет иметь этот бумажник, и, таким образом, ваша конфиденциальность сохраняется. Если ваш HDD аварий, вы можете восстановить детерминированных бумажники / цепи / счета из резервной копии, и слить Dropbox'd файл в него, и вы туда, где вы были до аварии на жестком диске. Это не только экономит ваши P2SH скриптов от неудачи, но дает вам возможность сохранить все ваши адреса комментарии / метки, тоже (т.е. - это полезно даже для не P2SH кошельков). Поведение по умолчанию будет не иметь внешний файл, но, чтобы позволить пользователю указать местоположение для его создания, которые будут подкреплены на регулярной основе.

Edit: Кто-то может предположить, что вы всегда можете получить сценарий P2SH с другой стороны, если вы потеряете свой бумажник. Мой ответ: то, что если вы сохранили свою контактную информацию в качестве комментария в файле бумажник? Эта система позволит сохранить как комментарии и сценарии P2SH по незащищенному каналу без ущерба для конфиденциальности.

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


etotheipi сейчас офлайн Пожаловаться на etotheipi   Ответить с цитированием Мультицитирование сообщения от etotheipi Быстрый ответ на сообщение etotheipi


Как заработать Биткоины?
Без вложений. Не майнинг.


28 ноября 2012, 4:11:17 AM   # 2
 
 
Сообщения: 1400
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Получил 1806 Биткоинов
Реальная история.





Например, я думаю, что Dropbox идеально подходит для резервного копирования P2SH сценариев и TX / адрес комментарии, но если пользователь никогда не должно резервное копирование весь его бумажник Dropbox. И я не доверяю пользователям вручную&ответственно создать надежные резервные копии.
Это не будет работать для всех, но для тех людей, у которых он установлен Freenet является идеальным решением для хранения данных, как это. В этом отношении вы могли безопасно резервное копирование всего кошелек в Freenet.
justusranvier сейчас офлайн Пожаловаться на justusranvier   Ответить с цитированием Мультицитирование сообщения от justusranvier Быстрый ответ на сообщение justusranvier

28 ноября 2012, 4:46:35 AM   # 3
 
 
Сообщения: 1428
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Например, я думаю, что Dropbox идеально подходит для резервного копирования P2SH сценариев и TX / адрес комментарии, но если пользователь никогда не должно резервное копирование весь его бумажник Dropbox. И я не доверяю пользователям вручную&ответственно создать надежные резервные копии.
Это не будет работать для всех, но для тех людей, у которых он установлен Freenet является идеальным решением для хранения данных, как это. В этом отношении вы могли безопасно резервное копирование всего кошелек в Freenet.

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

28 ноября 2012, 5:27:43 AM   # 4
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Когда я смотрю через BIP 0032 и увидеть предложения для сериализации расширенных открытых и закрытых ключей в Base58, я вроде выключил тем, что получившиеся строки не имеют никакого полезного видимый префикса. В любом случае, мы можем изменить это перед тем, как серьезно относится к реализации с участием BIP 0032?

BIP требует 74 или 75 байтов, начиная с "версия" байт 0x06. Это приводит строки в следующих диапазонах: CHp9i78Gq2z9cmoCwmasob3nLUfDMfhQPmRGAF12dARaUfsEi33j6UbWSe3SdRnfBbtqQmGZEFP5qvrD9amMVcbUuxZA znDwP1hKDNTKYb через EAx1Vd9V8hz1PQGEwEMBwMPaZPbv5n9UHtpe27fhZXL1PcgGzYPWn4CG1utBZqFbt33UUiypGTSmKRA5WM4QuiXZZnUs L5Rm7M9N2fPpqe на 74 байт, и rqD7SS36s1mF2tiwijnXEdHH6y5fYDoLFV45uno8AcbUm8YjW832oAoJxAVn7nQXXo1nftPfFUUUNxgCct2mTJ7CCkD1 82c72A4vu1oa9UR через 218uoBLYTB1tchsgGWMv7Gtzf7xm7J6GPTZjGPvRp2YrtipUMayYNRs6hH2QuduySxG1vHNHmdDiicHd4tXY4XgHtjhk1 9CYHh1uvD9aCV8b 75 байт. Это означает, что эти строки могли бы начинаться с любым символом в "CDErstuvwxyz12", Хлоп! Как можно узнать, посмотрев, что такая тарабарщина служит какой-либо конкретной цели?

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

Если вместо 0x06 и 0x0c, мы использовали 0x0488B21E и 0x0488ADE4 плюс 74 байт полезной нагрузки, в результате префиксов будут "xpub" а также "xprv" соответственно. 0x043587CF и 0x04358394 выход tpub и tprv (для testnet). Если вместо указания "использовать 32 байт для закрытого ключа, и 33 байт для открытого ключа"Мы определили "использовать 0x00 + 32 байт закрытого ключа" (Зная, открытые ключи всегда начинаются с 0x02 или 0x03), то полезной нагрузкой за префикс всегда будет 74 байт, и мы не имели бы base58 префиксов, которые изменяются резко, так как длина сообщения изменяется. Можно было бы знать, смотря только то, что они смотрят.

Что касается первоначального вопроса (как безопасно сохраняются P2SH скрипты), у меня есть вход на том, что, как хорошо, но я до сих пор рассматривают ли это разумно.
casascius сейчас офлайн Пожаловаться на casascius   Ответить с цитированием Мультицитирование сообщения от casascius Быстрый ответ на сообщение casascius

28 ноября 2012, 5:44:45 AM   # 5
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Вот что я думаю о P2SH настойчивости: Я думаю, что в паре бумажник идея отличный способ пойти.

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

Первая партия предлагает отношения как текстовую запись и решает, сколько вакансий в нем, и эта запись передается другим партиям / устройствам, которые, в свою очередь, генерируют текстовые записи, предлагая заполнить эти вакансии, очень похоже на создание запроса на подпись сертификата на приобрести сертификат SSL. Когда все стороны / устройства имеют все записи, все они должны производить один "отношения хэш" признавая взаимное понимание условий, в какой точке, пользователь (ей) систем P2SH может согласовать и подтвердить среди друг друга, что они копировали частные лакомства для каждой роли в отношениях с хэш-H, и, наконец, поколение адреса может происходить партии / устройства, которые уполномочены делать это.

P2SH адреса должны быть сгенерированы детерминированным от объекта отношений, которые должны быть подкреплены каждой из сторон в отношениях, когда создается связь, но нет резервной копии когда-либо необходимо для ключей, которые она производит.

Пример обмена в формировании отношения

1. Сторона / Устройство A создает запись, которая говорит: "Предлагаю (А и В)" отношения. Я хочу быть А, вот мой код общественной цепи. Я ищу для B, чтобы предложить код цепи."

Запись может продолжаться сказать "В этой связи, новые адреса должны быть выданы сторонами в этом списке: [A, B]", Одна сторона может нести ответственность за все выдачи (например, если сторона А компьютер и партия B это просто смартфон приложение для подтверждения транзакций). Или, если несколько сторон уполномочены выдавать адреса, а затем (к примеру) выдают адреса, имеющей последовательность по модулю 2 == 0, и вопросы, партии Б последовательности по модулю 2 == 1. (замените 2 с числом сторон, способным выдавать адреса ).

2. Сторона / Устройство B подается, что запись и соглашается. Это создает запись о том, "Я согласен быть B к предложению которого Хэш X. Вот мой код общественной цепи."

3. Эта запись передается обратно в партии / устройства А. Каждый из них согласны, что отношения H была сформирована, где H 32 бит хэша всех открытых ключей и т.д. вдаваясь в записи отношений. Когда все стороны / устройства признают, являющиеся участниками отношений Н, и пользователь (ей) благополучно все резервные копии, то они могут начать выдавать адреса.

Defined Таким образом, "отношения" становится супертип бумажника ... обычный бумажник может быть определен как просто "отношения" с одной стороны (само), который имеет только персональный код цепи и который сам выдает все адреса.
casascius сейчас офлайн Пожаловаться на casascius   Ответить с цитированием Мультицитирование сообщения от casascius Быстрый ответ на сообщение casascius

28 ноября 2012, 8:01:53 AM   # 6
 
 
Сообщения: 1050
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Когда я смотрю через BIP 0032 и увидеть предложения для сериализации расширенных открытых и закрытых ключей в Base58, я вроде выключил тем, что получившиеся строки не имеют никакого полезного видимый префикса. В любом случае, мы можем изменить это перед тем, как серьезно относится к реализации с участием BIP 0032?

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

Я вообще махнули на человеческом узнаваемости аспекте Base58 - если мы хотим, что base64 или base32 бы гораздо лучший выбор, так как они позволяют префиксов / суффикса с бит / байт массивов, не затрагивая каждый закодированный символ.

котировка
BIP требует 74 или 75 байтов, начиная с "версия" байт 0x06. Это приводит строки в следующих диапазонах: CHp9i78Gq2z9cmoCwmasob3nLUfDMfhQPmRGAF12dARaUfsEi33j6UbWSe3SdRnfBbtqQmGZEFP5qvrD9amMVcbUuxZA znDwP1hKDNTKYb через EAx1Vd9V8hz1PQGEwEMBwMPaZPbv5n9UHtpe27fhZXL1PcgGzYPWn4CG1utBZqFbt33UUiypGTSmKRA5WM4QuiXZZnUs L5Rm7M9N2fPpqe на 74 байт, и rqD7SS36s1mF2tiwijnXEdHH6y5fYDoLFV45uno8AcbUm8YjW832oAoJxAVn7nQXXo1nftPfFUUUNxgCct2mTJ7CCkD1 82c72A4vu1oa9UR через 218uoBLYTB1tchsgGWMv7Gtzf7xm7J6GPTZjGPvRp2YrtipUMayYNRs6hH2QuduySxG1vHNHmdDiicHd4tXY4XgHtjhk1 9CYHh1uvD9aCV8b 75 байт. Это означает, что эти строки могли бы начинаться с любым символом в "CDErstuvwxyz12", Хлоп! Как можно узнать, посмотрев, что такая тарабарщина служит какой-либо конкретной цели?

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

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

Если вместо 0x06 и 0x0c, мы использовали 0x0488B21E и 0x0488ADE4 плюс 74 байт полезной нагрузки, в результате префиксов будут "xpub" а также "xprv" соответственно. 0x043587CF и 0x04358394 выход tpub и tprv (для testnet). Если вместо указания "использовать 32 байт для закрытого ключа, и 33 байт для открытого ключа"Мы определили "использовать 0x00 + 32 байт закрытого ключа" (Зная, открытые ключи всегда начинаются с 0x02 или 0x03), то полезной нагрузкой за префикс всегда будет 74 байт, и мы не имели бы base58 префиксов, которые изменяются резко, так как длина сообщения изменяется. Можно было бы знать, смотря только то, что они смотрят.

Хорошо, я признаю, что в этом роде. Спрошу вокруг объектов ли кто-нибудь. Вместо 0х00 + privkey, я буду использовать privkey + 0x01, так, чтобы он соответствовал сериализированному секретному ключу формата точно (который имеет 0х01 в то, потому что соответствующий открытом ключ сжимается).
Pieter Wuille сейчас офлайн Пожаловаться на Pieter Wuille   Ответить с цитированием Мультицитирование сообщения от Pieter Wuille Быстрый ответ на сообщение Pieter Wuille

28 ноября 2012, 2:11:14 PM   # 7
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Я буду использовать privkey + 0x01, так, чтобы он соответствовал сериализированному секретному ключу формата точно (который имеет 0х01 в то, потому что соответствующий открытом ключ сжимается).

Я не считаю, что это будет работать, потому что вы не сможете неоднозначности, когда у вас есть 33 байт, которые начинаются с 0x02 / 0x03 и заканчивается с 0x01, как вы знаете, что ли государственный или частный ключ? Вы не будете.

Кроме того, у меня есть хитрый план, чтобы начать агитацию, написание BIP предложить консенсус поиск по base58 визуальным префиксам, и просим нас принизить "сериализованная частный формат ключ" Вы упоминаете, и пусть мир избавиться от Bitcoin частных ключей, которые начинаются с "L", Которые заставляют пользователей спросить "WTF разница между «5» и секретным ключом «L»? как о «K» и «L»?" и заставляя TMUI (слишком много бесполезной-информации) вниз горло просто понять Bitcoin. Это, скорее всего, будет использовать 0x82 вместо 0x80 в качестве префикса байта (так ключи все еще визуально отличаются во 2-й символ для тех, кто заинтересован в сжатом состоянии на первый взгляд), а затем продолжать принимать существующий формат K / L на основой которой является универсально приемлемым в качестве входных данных (для совместимости), но предполагают, что новые ключи в старом формате никогда не будет излучаемого.
casascius сейчас офлайн Пожаловаться на casascius   Ответить с цитированием Мультицитирование сообщения от casascius Быстрый ответ на сообщение casascius

28 ноября 2012, 2:23:51 PM   # 8
 
 
Сообщения: 1050
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Я не считаю, что это будет работать, потому что вы не сможете неоднозначности, когда у вас есть 33 байт, которые начинаются с 0x02 / 0x03 и заканчивается с 0x01, как вы знаете, что ли государственный или частный ключ? Вы не будете.

Потому что вы сами предложили положить "xpub" или "xprv" в начале. Там никогда не вопрос, один из которых вы работаете.
Pieter Wuille сейчас офлайн Пожаловаться на Pieter Wuille   Ответить с цитированием Мультицитирование сообщения от Pieter Wuille Быстрый ответ на сообщение Pieter Wuille

28 ноября 2012, 2:27:06 PM   # 9
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Я не считаю, что это будет работать, потому что вы не сможете неоднозначности, когда у вас есть 33 байт, которые начинаются с 0x02 / 0x03 и заканчивается с 0x01, как вы знаете, что ли государственный или частный ключ? Вы не будете.

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

Да, вы правы, это имеет смысл. Считайте меня за одного отсутствующего очевидное!
casascius сейчас офлайн Пожаловаться на casascius   Ответить с цитированием Мультицитирование сообщения от casascius Быстрый ответ на сообщение casascius

28 ноября 2012, 10:48:10 PM   # 10
 
 
Сообщения: 1428
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Re: "Отношения объектов"

Мне нравится идея определения "отношения" и, что где-нибудь определенно. Однако, если бы это хранить? Я действительно думаю, что, однако это будет сделано, он должен быть закодирован в кошелек: пользователь не должен находиться в положении, что они восстановить этот кошелек и думают, что это один-сиг бумажник. Я хочу бумажники быть посвящен мульти-сиг или нет. Если пользователь не хочет, чтобы мульти-сиговых, создайте обычный бумажник. (Легко для меня, чтобы сказать, Оружейная мульти-бумажник приложение а)

Для меня идеально было бы, если Auth бумажники два-фактора были всегда порождена компьютер, работающий в автономном режиме. Это создало бы как бумажники и генерировать 3 вещи для печати: резервное копирование бумаги для AB, A'B и AB «(где А полный кошелек и A» смотрит только кошелек). AB переходит в сейфе, A'B вводится в одно устройство (рабочий стол), AB»вошел в другое устройство (смартфон). Это может быть сохранено, тоже в разных местах, с меньшей безопасности, чем каждая резервное копирование AB. Физический взломщик бы найти как скомпрометировать средства. Я не хочу видеть резервные копии отдельно от B. Я действительно хочу, чтобы пользователь будет резервным копированием бумажника после связь была определена в бумажнике, так что очевидно из резервной копии, что это мульти-сиг бумажник и к которому другой бумажник он связан.  

Проблема заключается в том, что не все пользователи хотят, чтобы сделать это с помощью системы в автономном режиме. Рабочий стол может сделать так, а затем просто удалить B (после того, как это резервная копия). Но некоторые пользователи хотят ключи никогда не быть на том же устройстве, когда-либо. Там, вероятно, должен быть интерфейс, чтобы преобразовать регулярный бумажник к сопряженному бумажнике, и позволяют пользователям объединять их в более позднее время. Может быть, это так же просто, как выскакивать предупреждение, предполагая, что они делают новую резервную копию, когда создается ссылка.

Для депозитных сделок и контрактов, и т.д., я думаю, вы должны позволить регулярно, одного сига кошелек для создания закрытого ключа, предназначенный для использования для этой цели. Это будет обозначено хранимым сценарием P2SH в файле бумажник, который будет содержать оба открытые ключи (и самостоятельно будет легко идентифицировать). Когда бумажник загружен, он будет искать все сохраненные сценарии P2SH и определить, как они относятся к вашему кошельку. Но это должно быть подкреплено момент, когда вы генерировать его. Я просто не вижу другого пути, чтобы быть полностью безопасным об этом, не используя что-то, как постоянные, как Dropbox (то, что другие варианты резервного копирования, там для этого, помимо сохранения этого дополнительный файл на сетевом диске, на другой системе, или внешнее устройство?)


etotheipi сейчас офлайн Пожаловаться на etotheipi   Ответить с цитированием Мультицитирование сообщения от etotheipi Быстрый ответ на сообщение etotheipi

29 ноября 2012, 1:06:08 AM   # 11
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Re: "Отношения объектов"

Мне нравится идея определения "отношения" и, что где-нибудь определенно. Однако, если бы это хранить? Я действительно думаю, что, однако это будет сделано, он должен быть закодирован в кошелек: пользователь не должен находиться в положении, что они восстановить этот кошелек и думают, что это один-сиг бумажник. Я хочу бумажники быть посвящен мульти-сиг или нет. Если пользователь не хочет, чтобы мульти-сиговых, создайте обычный бумажник. (Легко для меня, чтобы сказать, Оружейная мульти-бумажник приложение а)

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


Для меня идеально было бы, если Auth бумажники два-фактора были всегда порождена компьютер, работающий в автономном режиме. Это создало бы как бумажники и генерировать 3 вещи для печати: резервное копирование бумаги для AB, A'B и AB «(где А полный кошелек и A» смотрит только кошелек). AB переходит в сейфе, A'B вводится в одно устройство (рабочий стол), AB»вошел в другое устройство (смартфон).

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

Учитывая, что оффлайн компьютеры являются то, что так легко для вас и меня, и популярность смартфонов среди всех остальных, я себе самый популярный сценарий варианта использования будучи где сторона А является компьютер, B является смартфоном того же человека. В этом случае, "запись отношения" идет от А к В в виде камеры сканирования на экране QR-код, и где возвращаемая запись путешествует из смартфона обратно в компьютер через электронную почту, или съемный флэш-носители, или пользователь просто принимая его и руку -typing записи ответа выключения дисплея своего телефона на свой компьютер с помощью клавиатуры. Закрытый ключ материал для подкреплен печати, и закрытый ключ материал для B подкреплен пользователем записывая словник закодированного рекорда они видят на экране своего телефона.

После того, как такая связь установлена, пользователи будут инициировать транзакции на своем компьютере (A), и их на компьютере клиент будет показывать QR-код (или ряд из них, если транзакция была большой), содержащей предлагаемую сделку и партию сигнатуры , Смартфон будет отображать сведения о транзакции на экране, получить согласие пользователя, предоставить участник B подпись и отправить все это непосредственно к самой Bitcoin сети.
casascius сейчас офлайн Пожаловаться на casascius   Ответить с цитированием Мультицитирование сообщения от casascius Быстрый ответ на сообщение casascius

29 ноября 2012, 1:18:28 AM   # 12
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Для депозитных сделок и контрактов, и т.д., я думаю, вы должны позволить регулярно, одного сига кошелек для создания закрытого ключа, предназначенный для использования для этой цели. Это будет обозначено хранимым сценарием P2SH в файле бумажник, который будет содержать оба открытые ключи (и самостоятельно будет легко идентифицировать). Когда бумажник загружен, он будет искать все сохраненные сценарии P2SH и определить, как они относятся к вашему кошельку. Но это должно быть подкреплено момент, когда вы генерировать его. Я просто не вижу другого пути, чтобы быть полностью безопасным об этом, не используя что-то, как постоянные, как Dropbox (то, что другие варианты резервного копирования, там для этого, помимо сохранения этого дополнительный файл на сетевом диске, на другой системе, или внешнее устройство?)

Для депозитных операций и разовых, где создания и резервное копирование отношений будет обуза, я вижу P2SH как неправильный инструмент для работы. Это может быть больше подходит для простой регулярной multisig сделки, где сценарий выкупа идет в блок цепи и на основе обычных ключей в обычном бумажнике. Цель P2SH, как я понимаю, чтобы подтолкнуть multisig нагрузки от отправителя и на приемник и убедиться, что пользователи и веб-сайты, не заинтересованные в использовании multisig всегда может отправить монеты для людей, которые, с нормальным смотреть и нормально -sized адрес назначения. Это бремя манетки не имеет особого смысла, если три согласившиеся люди хотят сознательно участвовать в сложной операции.

Такая сделка может быть выполнена так же, как отношения (в том смысле, что есть "предложение" а также "принятие"), Но было бы гораздо проще. Если Алиса хочет послать монеты Бобу и использовать эскроу агент Эдди, то Алиса и Боб могут отправлять друг другу свежий адрес Bitcoin своих собственных Эдди, а затем Эдди мог сформулировать большой и громоздкой "адрес" который содержал весь multisig скрипт сериализован внутри, а затем Алиса бы просто послать монеты к нему. И Алиса, и клиенты Боба автоматически распознает входящий, но "обремененный" сделка, и Алиса и Боб будут иметь возможность создать предложение сделки, которые должны быть посланы к Эдди, подписали, и выпущенные им за счет средств, чтобы пойти куда-нибудь.
casascius сейчас офлайн Пожаловаться на casascius   Ответить с цитированием Мультицитирование сообщения от casascius Быстрый ответ на сообщение casascius

29 ноября 2012, 1:46:41 AM   # 13
 
 
Сообщения: 1428
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Для депозитных сделок и контрактов, и т.д., я думаю, вы должны позволить регулярно, одного сига кошелек для создания закрытого ключа, предназначенный для использования для этой цели. Это будет обозначено хранимым сценарием P2SH в файле бумажник, который будет содержать оба открытые ключи (и самостоятельно будет легко идентифицировать). Когда бумажник загружен, он будет искать все сохраненные сценарии P2SH и определить, как они относятся к вашему кошельку. Но это должно быть подкреплено момент, когда вы генерировать его. Я просто не вижу другого пути, чтобы быть полностью безопасным об этом, не используя что-то, как постоянные, как Dropbox (то, что другие варианты резервного копирования, там для этого, помимо сохранения этого дополнительный файл на сетевом диске, на другой системе, или внешнее устройство?)

Для депозитных операций и разовых, где создания и резервное копирование отношений будет обуза, я вижу P2SH как неправильный инструмент для работы. Это может быть больше подходит для простой регулярной multisig сделки, где сценарий выкупа идет в блок цепи и на основе обычных ключей в обычном бумажнике. Цель P2SH, как я понимаю, чтобы подтолкнуть multisig нагрузки от отправителя и на приемник и убедиться, что пользователи и веб-сайты не заинтересованные в использовании multisig всегда могут отправить монеты для людей, которые. Это бремя манетки не имеет особого смысла, если три согласившиеся люди хотят сознательно участвовать в сложной операции.

Я был под впечатлением, что P2SH был предназначен для всех операций мульти-сига, хотя вы правы, нет причины, обычного текст мульти-сиг не может быть использован (там? Они, вероятно, не добавлял к isStandard ...) , Одной из причин желать P2SH, в целом, является то, что очень длинными скрипты становятся частью TxIns вместо этого TxOuts. Это означает, что они никогда не будут раздуваться в отсеченную версию blockchain. Если каждый использовал только P2SH, то ни TxOut сценарий никогда не будет больше, чем 22 байта.
etotheipi сейчас офлайн Пожаловаться на etotheipi   Ответить с цитированием Мультицитирование сообщения от etotheipi Быстрый ответ на сообщение etotheipi

29 ноября 2012, 1:54:11 AM   # 14
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Я был под впечатлением, что P2SH был предназначен для всех операций мульти-сига, хотя вы правы, нет причины, обычного текст мульти-сиг не может быть использован (там? Они еще считаются isStandard?). Одной из причин желать P2SH, в целом, является то, что очень длинными скрипты становятся частью TxIns вместо этого TxOuts. Это означает, что они никогда не будут раздуваться в отсеченную версию blockchain. Если каждый использовал только P2SH, то ни TxOut сценарий никогда не будет больше, чем 22 байта.

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

IsStandard может быть решена просто, предлагая вариант, который говорит "убедитесь, что моя сделка отправляется на это / эти шахтеры (s)" и получить кто-то где-то согласиться помоему их в блок. Это, конечно, игнорирует подавляющую вероятность того, что вся Bitcoin сообщество немедленно реализовать значение и будет принимать определения такой сделки, как стоит ретрансляции.
casascius сейчас офлайн Пожаловаться на casascius   Ответить с цитированием Мультицитирование сообщения от casascius Быстрый ответ на сообщение casascius

29 ноября 2012, 2:03:06 AM   # 15
 
 
Сообщения: 1428
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Я был под впечатлением, что P2SH был предназначен для всех операций мульти-сига, хотя вы правы, нет причины, обычного текст мульти-сиг не может быть использован (там? Они еще считаются isStandard?). Одной из причин желать P2SH, в целом, является то, что очень длинными скрипты становятся частью TxIns вместо этого TxOuts. Это означает, что они никогда не будут раздуваться в отсеченную версию blockchain. Если каждый использовал только P2SH, то ни TxOut сценарий никогда не будет больше, чем 22 байта.

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

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

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

etotheipi сейчас офлайн Пожаловаться на etotheipi   Ответить с цитированием Мультицитирование сообщения от etotheipi Быстрый ответ на сообщение etotheipi

29 ноября 2012, 2:23:52 AM   # 16
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

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

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

Другое дело, что мне пришло в голову, является ли Эдди в профессиональной депозитного бизнеса, P2SH все еще может быть использован с Эдди, имеющий основную ответственность за резервное копирование скрипт (учитывая, что он уже согласился принять основную ответственность за отпуская сделку в первое место). Эдди все еще может предложить мульти сделки сига, но вместо того, чтобы Алиса отправки монет в огромную строку, вместо этого, Алиса получит запись позволяет ей подтвердить, что P2SH назначение X действительно то, что она думает, что это (что может быть сделано на публике сайт вместо того, чтобы быть встроено в любой момент клиент), а затем она просто заплатить адрес P2SH. Мы могли бы оставить резервную ответственность Эдди, и снять Алису и Боба от бремени.

Давайте предположим на минуту, что Эдди только подкрепил его детерминированный бумажник цепи код, а не индивидуальный P2SH сценарий, принадлежащий к Алисе и Бобу, и страдает потерей данных. Хотя не тривиален, все равно было бы возможно для Эдди, чтобы восстановить этот P2SH скрипт из хэша просто принимая Алиса и Боб представила Bitcoin адреса, и комбинируя их со всеми клавишами, поступающих из кода цепи Эдди, пока результат не совпадает. Даже то, что потенциальная нагрузка может быть полностью устранена просто по электронной почте на P2SH "проверка назначения" Данные Алисы и Боба, как и в случае поломки жесткого диска Эдди, Алиса и Боб мог восстановить сценарий из своей электронной почты.

Кажется мне, идеальная сделка условного депонирования (А и Е) или (В и Е) или (А и В). Таким образом, в случае исчезновения эскроу агента, Алиса и / или Боб может выпустить монеты друг к другу, подав сделку оплачиваемую другой, требуя подписи этого другого человека.
casascius сейчас офлайн Пожаловаться на casascius   Ответить с цитированием Мультицитирование сообщения от casascius Быстрый ответ на сообщение casascius

29 ноября 2012, 1:12:02 PM   # 17
 
 
Сообщения: 1526
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Алан, вы смотрите на обсуждении протокола оплаты происходит на Bitcoin-разработке? Некоторые из них могут иметь отношение к этой работе.

Re: P2SH / нормальный, я согласен с Майком, что P2SH не всегда правильный инструмент для работы. Он был разработан на предположении, что люди будут хотеть использовать короткие адреса и что вполне может оказаться правдой, но если мы успешно двигаться большинство платежей использовать протокол оплаты (как мы собираемся попробовать), то адрес начнет угасать как пользователь видимой части Bitcoin и обоснование уходит. Он оставляет P2SH быть чисто UTXO набором оптимизацией размера, который, как и любой оптимизация должен оцениваться с дополнительной сложностью он вводит. Если он собирается сделать пользовательский опыт хуже, то лучше всего использовать обычные скрипты.

Майк, эскроу действительно предназначен для работы, как вы описали, но с использованием 2-из-3 multisig, которая сводится к (А и Е) или (В и Е) или (А и В):

  https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation

Мозговым много этих вещей стало легче рассуждать о том, когда вы предполагаете протокол оплаты.
Майк Хирн сейчас офлайн Пожаловаться на Mike Хирн   Ответить с цитированием Мультицитирование сообщения от Mike Хирн Быстрый ответ на сообщение Mike Хирн

29 ноября 2012, 1:35:41 PM   # 18
 
 
Сообщения: 1652
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов


Я был под впечатлением, что P2SH был предназначен для всех операций мульти-сига, хотя вы правы, нет причины, обычного текст мульти-сиг не может быть использован (там? Они, вероятно, не добавлял к isStandard ...) , Одной из причин желать P2SH, в целом, является то, что очень длинными скрипты становятся частью TxIns вместо этого TxOuts. Это означает, что они никогда не будут раздуваться в отсеченную версию blockchain. Если каждый использовал только P2SH, то ни TxOut сценарий никогда не будет больше, чем 22 байта.
Вы можете использовать обычный multisig, если вы хотите, они были добавлены в IsStandard.
Гэвин Андресен сейчас офлайн Пожаловаться на Гэвин Андресен   Ответить с цитированием Мультицитирование сообщения от Gavin Andresen Быстрый ответ на сообщение Гэвин Андресен

29 ноября 2012, 5:08:50 PM   # 19
 
 
Сообщения: 1428
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов


Я был под впечатлением, что P2SH был предназначен для всех операций мульти-сига, хотя вы правы, нет причины, обычного текст мульти-сиг не может быть использован (там? Они, вероятно, не добавлял к isStandard ...) , Одной из причин желать P2SH, в целом, является то, что очень длинными скрипты становятся частью TxIns вместо этого TxOuts. Это означает, что они никогда не будут раздуваться в отсеченную версию blockchain. Если каждый использовал только P2SH, то ни TxOut сценарий никогда не будет больше, чем 22 байта.
Вы можете использовать обычный multisig, если вы хотите, они были добавлены в IsStandard.

Ааа, так что имеет смысл использовать P2SH для парного / связанных бумажников, и регулярные мульти-сига для депозитных ТХ и т.д. По некоторым причинам, я был под впечатлением, что P2SH предназначались для все.  Я предпочитаю простой мульти-сиговый для тех депозитных ОГО.

@Майк,

Я не уверен, что протокол оплаты изменяет это много. Это означает, что решение о том, какой форме использовать будет иметь никакого значения для тех, кто использует протокол оплаты, но все равно будет пользователей, которые будут делать его "старый" путь, который по-прежнему должны быть размещены. Хотя это звучит, как у нас уже есть консенсус ... это имеет смысл использовать P2SH для связанных кошельков, и регулярных мульти-сига для изолированных escrows и контрактов.





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

Скажем, я сделать бумажник A / J, и мой супруг создает бумажник B / J.  Мы обмениваемся корень внешних / внутренних цепей.  Значение, мы обмениваемся данные, необходимые не только генерировать одну цепочку адресов, но и цепь и изменение цепи первичной.  

Итак, я даю ей А «/ J, и она дает мне B» / J. Все адреса, генерируемые бумажнике будет иметь вид 2of2 ([А '/ J / 0 / X, B' / J / 0 / х]), и все изменения будут идти в 2of2 ([А '/ J / 1 / г , в «/ J / 1 / г]) - внешняя цепь равно 0, внутренняя цепь 1. заказ будет включен для ее кошелька: она будет создавать адреса формы 2of2 ([в» / J / 0 / х , а '/ J / 0 / х]) и изменение пойдет на 2of2 ([B' / J / 1 / г, а '/ J / 1 / г]). Таким образом, каждый кошелек будет только генерировать адреса из своих собственных двух цепей, но наблюдение для адресов на всех четырех цепей.  

Я уверен, что это очень похоже на то, что вы предложили.  


РЕДАКТИРОВАТЬ: Чтобы избежать проблем, заказав для 3+ кошельков, адреса должны быть упорядочены по порядку кошелька отпечатков пальцев, и каждый кошелек всегда генерирует адреса, начиная с их собственными в этом списке, обернув вокруг. Таким образом, если кошелек отпечатки пальцев в конечном итоге заказе бумажники B, A, C, тогда все адреса 2-на-3, сгенерированные бумажник B будет {B, A, C}, бумажник А будет {А, С, В} и бумажник С будет {С, В, А}. Это гарантирует, что существует только N возможные адреса упорядоченность (по одному на каждую партию), вместо N-факториал
etotheipi сейчас офлайн Пожаловаться на etotheipi   Ответить с цитированием Мультицитирование сообщения от etotheipi Быстрый ответ на сообщение etotheipi

29 ноября 2012, 5:45:59 PM   # 20
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: Новые идеи бумажника файлов

Что касается упорядочения кошельков я никогда не предполагал, что это будет проблемой. В основном потому, что в моем уме, кто-то будет предлагать отношения с определенным количеством вакансий, которые могут или не могут быть эквивалентны по назначению. Если А должны были предложить (A и B) или C, кто-то вошел, что отношения нужно явно будет выбирать слот B или слот C, то не было бы никакой двусмысленности относительно того, что партия находится в каком слоте, и они не могут просто взять первый доступный слот. Кроме того, я полагаю, что, когда отношения были определены, каждая из ролей будет либо разрешено или не разрешено генерировать адреса. (Если B это просто смартфон проверки транзакций в, тогда это было бы пустой тратой ресурсов для назначения цепи для B он никогда не будет использовать, но где А придется идти вверх и вниз, что цепи в поисках сделок на большие затраты CPU просто в случае, если это как-то делал).

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

У меня есть больше читать, чтобы сделать по контрактам и цепи и как они работают, так что вполне вероятно, что мои предположения отражают дефицитное понимание тех.
casascius сейчас офлайн Пожаловаться на casascius   Ответить с цитированием Мультицитирование сообщения от casascius Быстрый ответ на сообщение casascius



Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW