Я неправильно прочитал пост на Gavin думая, что он говорил о том, как это мульти-подпись ТХ-х могут быть использованы пользователями, и я создал несколько макетов потенциального пользовательского интерфейса. Я перепроведение в новом потоке, где это более уместно. Я работаю (очень медленно) На создание моего собственного света клиента, хотя у меня нет предвкушения получить это сделано в любое время в ближайшем будущем. Тем не менее, я уже сделал эти макеты, и думал, что они могли бы быть вдохновляющими для других разработчиков, которые могли бы работать на эталонный клиенте или своих клиентов.
Сложности нескольких сигнатурных операции потребуют очень полированный, чистый интерфейс для менее опытных пользователей, чтобы иметь возможность использовать эти операции должным образом. Моя цель состоит в том, чтобы прибить, какие функции (кнопки, параметры проверки ввода) необходимо в графическом интерфейсе, а также попытаться сойтись на согласованную терминологию для каждого из различных сложностей. Например, я использовал "распределение предложения" для обозначения того, как пользователь может предложить ТЕ провести и собирают подписи от других партий.
Полноразмерная изображение находится здесь: http://dl.dropbox.com/u/1139081/BitcoinImg/AdvTxDialogsFiveEx.png
Было бы неплохо, чтобы обсудить различные возможности, представленные здесь, выяснить, чего не хватает, и вид ветеринара идеи дизайна, прежде чем добраться до точки на самом деле программирования GUI.
|
|
||||||
26 августа 2011, 4:27:56 AM
|
# 1 |
Сообщения: 1428
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru |
|
|
|
Как заработать Биткоины?
Без вложений. Не майнинг.
|
1 сентября 2011, 2:01:13 PM
|
# 2 |
|
Сообщения: 1428
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Получил 1806 Биткоинов
Реальная история. Я обычно не врезаться темы, потому что я думаю, что это грубо, но я это делаю. С Gavin говорить о включении мульти-подписи сделки, сообщество будет иметь, чтобы начать решить, как довести их до 99,99% пользователей, которые не могут или не хотят строить их вручную. Это не очень полезно, если никто не может его использовать.
Я хотел бы выяснить КОНОПС (противСЕРТ-ofопчествоs) Для пользователей, которые будут использовать эти транзакции. Мой макет содержит много идей, но это не весь раствор. Например, что является наиболее эффективным способом для выполнения 2-из-3 сделки по депозитному случае покупателю-продавец? - Интернет покупатель хочет приобрести товар для X BTC - Покупатель обязуется 110% * X к операции 2-в-3 между покупателем, продавцом и третья стороной арбитром. - Если покупатель получает продукт и все доволен, покупатель и продавец и внести свой вклад подпись отправить X продавцу и 10% возврат к покупателю (поэтому покупатель имеет стимул для завершения ОГО). - Если покупатель и продавец не могут прийти к согласию, никто не получает деньги (так что обе стороны имеют стимул для разрешения ситуации приятно). - В случае возникновения спора, как покупатель и продавец могут обратиться к третьей стороне для арбитража. Третья сторона получает 10% в качестве платы. Это может даже не быть Лучший способ выполнения такого рода сделки, но это возможно, и будет включать в себя жонглирование много разных вещей. Предложив распределения обремененных денег, сбор подписей, сериализацию, конструируя окончательные ТЙ будет транслироваться, и все с "идиот-доказательство" интерфейс для пользователей, которые не понимают полностью, как эти вещи работают. |
|
|
|
|
1 сентября 2011, 5:13:32 PM
|
# 3 |
Сообщений: 93
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Я считаю, ваша работа очень вдохновляет! Просто хочу, чтобы вы знали, что вы не одиноки возбуждаться на возможности здесь.
|
|
|
|
|
1 сентября 2011, 5:16:10 PM
|
# 4 |
|
Сообщения: 1372
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Для меня самый идиота доказательства сценарий я могу думать, если кто-то запускает веб-сайт, как "сервис безопасности" которая содержит одну из клавиш и выполняет дополнительную вторичную проверку, прежде чем разрешить подпись для второго ключа, чтобы быть оказан, особенно на высоких сделках стоимости.
Для пользователя, вторичный "сервис безопасности" может выпустить свой собственные заплатки клиента Bitcoin UI (с источником), что, в дополнении к обычным функциям Bitcoin UI, предлагает автоматически взаимодействовать со службой с целью обременения и unencumbering биткойно. Это заплата клиент хотел бы спросить (через RPC и т.д. в) для веб-службы, чтобы подписать вещи с ключами он держит. Веб-служба будет осуществлять независимо от политики были соответствующими (например, получение "из группы" подтверждение законного владельца счета через SMS) до выдачи второй подписи. |
|
|
|
|
1 сентября 2011, 9:03:28 PM
|
# 5 |
|
Сообщения: 1428
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Ну, конечно, это было бы идиотом доказательство для ((А и В) или C) типа сделки. Тем не менее, я думаю, что пользователи получают гораздо больше, если эта возможность встроена в "стандарт" клиент, а затем безопасность компания только должно сосредоточиться на двухфакторной аутентификации. Это будет стоить буквально в 10-100 раз больше, чем в также должно сделать разработку программного обеспечения, внедрение, обслуживание и поддержку программного обеспечения. Не говоря уже, пользователи тогда придется жонглировать несколько программ, просто использовать Bitcoin и это не хорошо для общего признания.
Это было бы удивительно к успеху Bitcoin, если эти функции не были слишком сложными в использовании и не требует участия третьих сторон. Возможно, семья будет положить кучу денег на счет обремененного 2-в-3 сделок между вами, вашей женой и вашим малышом - ребенок может потратить / снять деньги, только если по крайней мере один родитель соглашается, и родители не может взять деньги у малыша, если они оба не согласны. Тем не менее, эти идеи могут создать шумиху, а затем неосуществим из-за реализации деталей / интерфейса, которые не могут быть выработаны. |
|
|
|
|
1 сентября 2011, 9:18:29 PM
|
# 6 |
|
Сообщения: 1372
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Ну, конечно, это было бы идиотом доказательство для ((А и В) или C) типа сделки. Тем не менее, я думаю, что пользователи получают гораздо больше, если эта возможность встроена в "стандарт" клиент, а затем безопасность компания только должно сосредоточиться на двухфакторной аутентификации. Это будет стоить буквально в 10-100 раз больше, чем в также должно сделать разработку программного обеспечения, внедрение, обслуживание и поддержку программного обеспечения. Не говоря уже, пользователи тогда придется жонглировать несколько программ, просто использовать Bitcoin и это не хорошо для общего признания. Это было бы удивительно к успеху Bitcoin, если эти функции не были слишком сложными в использовании и не требует участия третьих сторон. Возможно, семья будет положить кучу денег на счет обремененного 2-в-3 сделок между вами, вашей женой и вашим малышом - ребенок может потратить / снять деньги, только если по крайней мере один родитель соглашается, и родители не может взять деньги у малыша, если они оба не согласны. Тем не менее, эти идеи могут создать шумиху, а затем неосуществим из-за реализации деталей / интерфейса, которые не могут быть выработаны. Если Bitcoind может быть отделены таким образом, чтобы все это было было говорить P2P, не было никакого пользовательского интерфейса, и служил в качестве ядра для кого-то другого, чтобы написать передний менеджер конца бумажник, кто-то может создать пользовательский интерфейс, который способствует все различные сценарии (службы бумажника , жена / Я / ребенок, эскроу агент и т.д.), а также удовлетворить все ОС по выбору пользователя. Я думаю, что bitcoind должен быть изменен таким образом, чтобы она позволяет такие сделки (и признает их "стандарт"), Но если бар требуется, чтобы написать новый Bitcoin интерфейс может быть снижен в процессе, кто-то может заполнить каждый из этих ниш, не беспокоясь, когда Гэвины смогут прочесать и тестировать свой код. Конечно, bitcoind уже выделены и недостатки пользовательского интерфейса, но и не хватает пару ключевых вызовов, которые позволили бы новый передний конец UI и бумажник менеджер функционировать. В основном, там должно быть RPC вызова попросить bitcoind для списка всех расходуемых операций в блоке цепи, принадлежащего к каждому Bitcoin адресу в данном списке (например, блок исследователь дает сегодня). Вторично, там должны были бы быть способ, чтобы получить в реальном времени уведомления и нажать подписанные транзакции в сети, хотя это может быть достигнуто путем соединения по протоколу p2p и действует как ограниченный сверстников, и это может работаться вокруг. |
|
|
|
|
26 октября 2011, 11:24:17 PM
|
# 7 |
|
Сообщения: 1428
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Вот раздражающий интерфейс подробно я понял, при попытке осуществить это:
(1) я создаю "распределение предложения" для фондов - это беззнаковая сделка (2) Я хэш этот объект, чтобы придать ему уникальный идентификатор, чтобы ссылаться при разговоре с другими сторонами ("Эй, вы когда-нибудь подписать сделку 9bf3218a?") (3) Каждый подписывает ТЙ, и транслируется, но официальные ТЕ ID (его хэш) изменяется из-за подписи (4) Никто на самом деле не знает, что идентификатор будет до тех пор, пока пакет не будет подписан и широковещательный (5) Заинтересованные стороны должны искать свою собственную Txs ищет тот, который хэш 9bf3218a при удалении Sigs Конечно, шаг 5 может быть автоматизированы до некоторой степени, но это раздражает. Люди будут в конечном счете, должны отслеживать два разных идентификаторов для одной и той же ТХ. Это сумасшествие запутанным для людей, которые имеют сомнительное понимание того, как работает Bitcoin. Кроме того, требуется второй шаг: возможно, вы пытаетесь следить за ваших транзакций в БД. Вы должны обновить БД один раз, когда вы получаете DP, а затем ждать, пока она не появится в blockchain снова обновить БД с новым хэш. Как мы можем интуитивно представить эти идеи для пользователей, которые хотят использовать их? Можно ли для сообщества использовать согласованную терминологию, так что она не меняется между программами? Это может показаться тривиальным для некоторых, но это детали, которые действительно запутать ад из конечных пользователей, которые не понимают его, как разработчики делают. пользователей необходимость способ ссылаться на эти операции, как до, так и после. возможно "без знака ID ТХ" а также "ID вещания." Кроме того, вероятно, было бы хорошо использовать другую кодировку для них. Регулярные TxIDs (широковещательные) обычно отображается в шестнадцатеричном формате. возможно "без знака Тх ID"s может быть представлена в Base58 с парой статичных ведущих персонажей, чтобы добавить некоторую последовательность во всех из них. Я думаю, мы также выиграли бы от придумывая "стандарт" Процесс сериализации для распределения и сбора подписей. Хотя, вероятно, сделать BIP для этого ... |
|
|
|
|
27 октября 2011, 3:00:52 AM
|
# 8 |
|
Сообщения: 1652
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Я много думал об идентификаторах транзакций и как собирать подписи для транзакций многопартийных тоже.
По большей части, я думаю, что все детали должны нормально быть скрыты от users-- Я думаю, "Выберите тип транзакции" слишком вызывающим. Мысли вслух, и, начиная с того, что я думаю, будет очень общий случай использования: покупатель и продавец, и кто-то, чтобы разрешать споры, которые возникают (2-в-3 эскроу). Вы себе все три использует Bitcoin-клиент? В моей голове, можно было бы использовать Bitcoin-QT, другой веб-бумажник службы, и разрешение споров будет сделано компанией с веб-сайта. Я не думаю, "мы все работаем Bitcoin на наших компьютерах" будет общий случай. Так вот, как я вижу это работает (мой опыт ClearCoin может быть смещение меня): Покупатель и продавец подписывают с услугой условного депонирования. Во время регистрации, каждый из них дают Escrow службы открытого ключа. Как? -- Неуклюжий способ: они тыкают "Advanced .... New Public Key" кнопку, а затем скопировать&вставить длинную строку шестнадцатеричном -- Лучший способ: они совать ссылку на странице состояния депозитного, что делает некоторые магии (Может быть, есть Bitcoin: sendnewpublickey назначения = https: //www.clearcoin.com/newkey/user1234 тип URI, который может быть сделан, чтобы делать правильные вещи) Покупатель или Продавец затем создает эскроу на веб-сайте обслуживания Escrow. -- Escrow обслуживания создает или назначает для ключей их части из 2-из-3 -- Депонированию служба создает новомодный адрес Bitcoin с помощью 3 открытых ключей. Покупатель отправляет биткойны на новомодной адрес Bitcoin (нажав на него в page-- Сделки службы в это может быть Bitcoin: ... ссылка) Бумажник обслуживания Escrow видит компенсацию к новомодным Bitcoin адреса, обновляет страницу состояния. Покупатель сообщает продавцу они заплатили. Продавец проверяет страницу состояния депозитного, нажимает на "отправить мне деньги" ссылка и отправляет продукт покупателю. Что это "отправить мне деньги" ссылка делать? Необходимо, чтобы получить подпись от продавца по сделке, которая тратит от сделки 2-в-3 и посылает в кошелек продавца. Другой Bitcoin: URI, который делает магические вещи? (Bitcoin: signtransaction ТХ = ... шестигранной ...&назначения = https: //www.clearcoin.com / ...) Или некоторая другая неуклюжее копирование-и-склейка длинных шестигранных строк? Через несколько дней: Покупатель получает продукт и счастлив. Они посещают страницу состояния депозитного и нажмите на "послать им деньги" ссылка, которая делает более волшебный материал. Или более неуклюжие копирования-и-вставка из шестигранных строк. В любом случае служба эскроу получает вторую подпись и отправляет транзакцию в сети Bitcoin, а также монеты показывают в кошельке продавца. Пара примечаний: Я не вижу новомодный-Bitcoin-адрес является частью Нужно думать о том, что происходит, если служба эскроу вдруг исчезает ... они не могут украсть любые монеты, но если ни покупатель, ни продавец знает открытый ключ службы условного депонирования, используя то они не могут завершить сделку самостоятельно. Возможно, Bitcoin: URI, что покупатель использует для финансирования сделки должна включать все открытые ключи и должна быть добавлена к кошельку покупателя ... Все это было бы гораздо лучше, если бы был более удобным, безопасность людей представление Bitcoin адресов / открытых ключей. |
|
|
|
|
27 октября 2011, 3:30:40 AM
|
# 9 |
Сообщения: 714
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
2-из-3 сигнатур полезны.
Как Alipay.com в Китае (принадлежит Алибабе, принадлежит Yahoo), когда покупатель и продавец споры, ALIPAY будет решать, куда идут деньги (назад к покупателю или направить продавцу, в зависимости от доказательств). Большая часть электронной коммерции Китая использует этот вид услуг. |
|
|
|
|
27 октября 2011, 3:40:55 AM
|
# 10 |
|
Сообщения: 1428
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Я думаю, что это ошибка предположить, что пользователи не будут использовать Bitcoin со своих компьютеров. Одно ядро привлечение Bitcoin является децентрализация, и если предположить, что конечные пользователи будут стекаться в централизованную "точки доступа," мы создаем накликать пророчество. Мы не будем пытаться сделать его пригодным для использования конечным пользователем напрямую, и тогда придется быть третьи стороны немой это вниз для пользователей.
Мое отношение не уступать третьи стороны, пока мы не знаем, что мы должны. Польский ад из интерфейсов, сделать его интуитивно понятным, насколько это возможно, и дать пользователям возможность управлять своими деньгами. Если пользователь может добиться успеха без уплаты пошлины на третью сторону, почему бы он? Очевидно, что 2-из-3 эскроу сделки имеют сторонний, по определению, но это другая тема, чем будут ли пользователи будут управлять монетами на своем компьютере или через службу. Я думаю, что свет-клиенты, которые не загружают blockchain (или принять 4-48 часов, чтобы загрузить), с зашифрованными кошельками, будут иметь огромное значение в удобстве для "регулярный" пользователи. (Большинство обычных людей используют интернет-банк ... почему бы не BTC?) Кроме того, я думаю, что одна из самых важных вещей, является возможность управления в небольших компаниях обрабатывать BTC без необходимости нанимать / отвлекают сотрудников для борьбы с ним. Любые преимущества BTC видели небольшие компании будут наводнены стоимости, чтобы сохранить его. И без компаний, использующих его, BTC не получите очень много внимания. Несмотря на это, я полностью согласен прятать все эти вещи позади "продвинутый" Закладка / меню. я думаю "регулярный" пользователи должны быть защищены от путая себя со сложными операциями Bitcoin, пока они явно не решают, что они хотят. Так вдоль этих линий, я работаю на BIP прямо сейчас для многих сиг обменов, которые могут быть обработаны так же, как PGP / GPG сбщ и Sigs (бронированный ASCII, легко копировать / печать / электронная почта). Я думаю, что это дает нам возможность стандартизировать этот процесс, так что все программы BTC могут взаимодействовать без проблем. Может быть, я слишком оптимистичен ... Я выложу ссылку на BIP, когда я получаю его, но сейчас вики недоступна EDIT: Кстати, я не обращая внимания на остальную часть вашего поста, я просто хотел бросить его там, что мои первоначальные предположения различны, и я думаю, что есть основания для оптимизма. Я буду работать еще некоторые детали в моей голове, прежде чем ответить. |
|
|
|
|
28 октября 2011, 6:33:09 PM
|
# 11 |
|
Сообщения: 1428
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Кстати, я только что отправил BIP 0010 к сути: https://gist.github.com/1321518
К сожалению, я не мог понять, почему слово-обертывание неудачу, так что вы, возможно, придется нажать "сырье" ссылка, чтобы увидеть его, вынесенным в обычном тексте с обертыванием. Имейте в виду, что вся вторая половина этого BIP фактически псевдо-код. Так может показаться долго, на первый взгляд, но это только половина того, что это кажется. На этой ноте, я сохранил суть, как .py, так что если вы исследуете код из исходной линии, это будет немного легче читать с кодом на первый план. |
|
|
|
|
28 октября 2011, 7:05:47 PM
|
# 12 |
|
Сообщения: 1652
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
RE: BIP 0010: Круто!
Предложение: если мы будем брать формат файла PGP, то мы должны быть совместимы, насколько это возможно, и ссылки на их стандарты документ: http://tools.ietf.org/html/rfc2440 В частности, они используют Radix64 кодирования, а не гекс ... |
|
|
|
|
28 октября 2011, 7:30:08 PM
|
# 13 |
|
Сообщения: 1428
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
RE: BIP 0010: Круто! Предложение: если мы будем брать формат файла PGP, то мы должны быть совместимы, насколько это возможно, и ссылки на их стандарты документа: http://tools.ietf.org/html/rfc2440 В частности, они используют Radix64 кодирования, а не гекс ... Там на самом деле не имеет перекрытия между тем, что мы кодирующими и что PGP является кодированием, так что я не уверен, насколько необходимо. Тем не менее, я согласен, что кодирование Base64 приведет меньше символов на экране, и там могут быть и другие вещи, чтобы узнать с помощью PGP. Хотя, если что-нибудь, я бы ожидать, Base58 будет лучше, так как любая BTC программного обеспечения будет уже есть метод для преобразования. В любом случае, все это открыто для обсуждения. Другим отличием является то, что PGP в основном кодирует все в один непрозрачный блок Base64, в то время как я заинтересован в сохранении немного информации для восприятия человеком вне кодирования. Для тех, кто не знает / безразлично, что находится между началом / концом тегами, это не делает разницы. Но это делает огромный разница для тех из нас, кто склонен визуально проверить эти блоки кода. Я предвижу, получать электронную почту, где кто-то скопировал TxDP в электронной почте и сказал "добавьте вторую подпись и трансляцию." Я не придется возиться с любыми программами, чтобы знать, что они забыли подписать его. |
|
|
|
|
20 ноября 2011, 4:52:45 AM
|
# 14 |
Сообщений: 30
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Несколько вопросов, которые я думаю, что были затронуты немного:
Во-первых, будет рекомендуемый подход будет добавить вызовы к API? Например, вызов, который позволяет низкого уровень крафта сделки или, по крайней мере, сценарий может быть использован несколько UI так, что представление отделено от внутренней работы. Во-вторых, в случае покупатель-продавец-посредник может быть обработано с помощью операции подписи 2-в-3. Мой вопрос: имеет ли посредник платит в отдельной транзакции? Что делать, если посредник ожидает небольшую плату, если сделка идет правильно, и большей, если он должен вмешиваться? |
|
|
|
|
20 ноября 2011, 5:35:44 AM
|
# 15 |
|
Сообщения: 1428
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Во-первых, будет рекомендуемый подход будет добавить вызовы к API? Например, вызов, который позволяет низкого уровень крафта сделки или, по крайней мере, сценарий может быть использован несколько UI так, что представление отделено от внутренней работы. То, что вы сказали, по сути, что я предполагал. Любой вид мульти-сиг сделки можно сериализовать таким образом, и тогда любой, кто следует за этим подражатель-стандарт может взаимодействовать с другими, которые делают то же самое. Если кто-то хочет создать службу для обмена этих блоков, они могут, или кто-то может просто сделать клиент, который рекомендует отправку их инлайн в сообщениях электронной почты. Я просто хотел, чтобы определить последовательный способ распространять информацию, которая работает в ASCII полях и пригодный даже самыми легкими клиентами (не blockchain необходимо, чтобы использовать его подписать). Во-вторых, в случае покупатель-продавец-посредник может быть обработано с помощью операции подписи 2-в-3. Мой вопрос: имеет ли посредник платит в отдельной транзакции? Что делать, если посредник ожидает небольшую плату, если сделка идет правильно, и большей, если он должен вмешиваться? Я не знаю, если я нахожусь на переднем крае этой области, но я предполагаю, что там будет служба третьей стороной, которая свободно выдает адреса. Покупатель будет выставлен на 110% -120% от стоимости товара в многоступенчатом сиге ТХ, а затем покупатель получит, что 10% назад, когда сделка будет завершена (таким образом, давая ему стимул завершить сделку, даже после того, как он получает товар / услугу). Если что-то пойдет не так, покупатель и / или продавец может связаться с третьей стороной в качестве посредника, а третья сторона получит 10%. Это только тогда, когда что-то идет не так, что посредник вовлекается или получает какие-либо деньги. Можно утверждать, что это не идеальный потому что это означает, что покупатель всегда платит за медиатор. Вы могли бы покупатель и продавец как поставить 5% -10%, но это потребует еще несколько знач ОГО, чтобы засеять сделку, в дополнении к тому, чтобы разблокировать средства впоследствии. |
|
|
|
|
20 ноября 2011, 9:27:55 PM
|
# 16 |
|
Сообщения: 1372
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Кроме предпочитая Base64 над шестнадцатеричным, это то, как я себе это:
Код: ----- НАЧАТЬ Bitcoin TRANSACTION ----- Источник финансирования 1: 47cf51a4fb5f6dd6ed3169a78601e1ad10bcae27e00c7c0e126f67bb6cf06fb3: 1 Средства: 0,79 BTC Ключ: 044752605d1c731161ee631c8a224cf4d90303bd8596cafc53d67b2bcc765ed302c3 ff865acb1eabfedf202b6017b680802db19f4e1573497a76a1c2e7e2bf6625 Подпись: 3046022100b23d6df3c9c1dee438523043475ee717e2986af55c83c65730446d8bf4 d889fd022100e34a3b4e07b06fff299ffe0c5a00f60375324d55502b2fef4f774394 7eca107801 Источник финансирования 2: bcd1b6acc8d5980970ad993ab57f86da7259d5c4a4816a75065544d87b5eac50: 1 Средства: 0,4 BTC Ключ: Unsigned Подпись: Unsigned # Общий объем средств: 1,19 BTC Расходование 1: (А и В) или С A: 13y3HpqB99TSBotmrr7zstJHLvvvFQDYRE B: 1J5TrKD3XR1bw7HxcPp2cfTW7dev1T2ZNM C: 19jRCAkkA1vwrLqLESdbpLkBiFjbqm12kq Средства: 1 BTC Расходование 2: 1LrcnDZkLKm8bZC3Hxc8aGV7na7wcPvD3C Средства: 0,18 BTC Плата Авторизованных обработок: 0,01 BTC # Всего выплат: 1,19 BTC #Комментарии: # Эта сделка является неполной, поскольку источники один или более финансирующими ожидают подпись. # Изменение источников или выплаты аннулирует существующие подписи. ----- END TRANSACTION Bitcoin ----- |
|
|
|
|
21 ноября 2011, 10:39:07 AM
|
# 17 |
|
Сообщения: 1526
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Так, только повторить то, что я сказал в списке рассылки, я думаю, что любой пользовательский интерфейс, который включает в себя увидеть что-то (base64, наговор, base58), закодированного не будет работать.
Цель должна быть очень проста - пользователь должен никогда не видят каких-либо кодов на всех. Это UX профессиональное программное обеспечение компания будет стремиться к и Bitcoin не должно быть различными. Gavin находится на правильном пути - файлы или магические URL-адреса, которые могут быть обработаны с помощью программного обеспечения пользователь работает в путь сюда. Для установки депозитного, пользователь должен быть представлен список поставщиков эскроу, что купец находит приемлемым и некоторые полезные данные о каждом из них (логотип, название, ссылку на свой веб-сайт, рекламный текст и т.д.). Тогда вы просто выбрать один, а остальное автоматически. |
|
|
|
|
21 ноября 2011, 1:51:55 PM
|
# 18 |
|
Сообщения: 1428
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Цель должна быть очень проста - пользователь должен никогда не видят каких-либо кодов на всех. Это UX профессиональное программное обеспечение компания будет стремиться к и Bitcoin не должно быть различными. Это деталь реализации более высокого уровня. Для кого-то писать клиент или начать службу для оказания помощи людям, чтобы сделать несколько Sig сделки, они должен реализовать ее таким образом, что пользователь никогда не видит блок TxDP. Но это вовсе не означает, что мы должны игнорировать случай, когда использование продвинутых пользователей действительно могут оказаться полезными для работы с сырыми блоками. Цель BIP 0010 является создание компактного способа представления данных, которые должны хорошо работать для всех сценариев использования. Это до клиент / приложение реализатора, сколько они хотят, чтобы выставить их пользователям.. Если кто-то пытается сделать супер-простой клиент для обычных пользователей, и это требует от них, чтобы скопировать эти кодовые блоки вокруг, это не будет очень успешным. Но нет никаких оснований, что BIP 0010 не может также поддержка продвинутых пользователей, которые могли бы на самом деле предпочитают, чтобы скопировать код блоки вокруг, в то же время при определении интероперабельного способа для всех пользователей, чтобы приспособить его. Так, например, "просто" Пользователь может отправить мне .txdp через вложения электронной почты, не видя никакого кода, потому что их клиент может создать окно электронной почты Outlook / Thunderbird с приложением уже там. Я мог бы установить программное обеспечение для автоматического обнаружения и обработки этой привязанности, не подвергая какой-либо из кода мне ... или, может быть, я открою вложение себя и вручную проверить и подписать его с моими CLI инструментов. Это не стоит нам ничего, чтобы поддержать все эти случаи использования, и это действительно поддерживают все случаи использования и гарантирует совместимость, есть хороший шанс, что другие разработчики будут использовать его. Gavin находится на правильном пути - файлы или магические URL-адреса, которые могут быть обработаны с помощью программного обеспечения пользователь работает в путь сюда. Для установки депозитного, пользователь должен быть представлен список поставщиков эскроу, что купец находит приемлемым и некоторые полезные данные о каждом из них (логотип, название, ссылку на свой веб-сайт, рекламный текст и т.д.). Тогда вы просто выбрать один, а остальное автоматически. Опять же, сторонние обработки этих вещей является деталью реализации более высокого уровня. я действительно хотите "стандарт" который можно использовать без третьей стороны (даже если только для опытных пользователей), а затем сторонние сервисы могут вмешаться для размещения менее продвинутых пользователей. Я считаю, что с какой-то кодировке ASCII, как это определено в BIP 0010 (или предложение Cascasius'), то можно написать клиентское программное обеспечение, которое требует всего лишь несколько шагов, чтобы выполнить транзакцию с несколькими значи без третьей стороны. Это было бы здорово если нам удалось на это - и это вполне в духе Bitcoin, чтобы иметь систему, которая Можно бесполезен без третьих сторон, даже если большинство пользователей будет в конечном итоге с помощью одного. |
|
|
|
|
21 ноября 2011, 2:03:52 PM
|
# 19 |
|
Сообщения: 1428
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Кроме предпочитая Base64 над шестнадцатеричным, это то, как я себе это: Код: ----- НАЧАТЬ Bitcoin TRANSACTION ----- Источник финансирования 1: 47cf51a4fb5f6dd6ed3169a78601e1ad10bcae27e00c7c0e126f67bb6cf06fb3: 1 Средства: 0,79 BTC ... Источник финансирования 2: bcd1b6acc8d5980970ad993ab57f86da7259d5c4a4816a75065544d87b5eac50: 1 Средства: 0,4 BTC ... # Общий объем средств: 1,19 BTC Расходование 1: (А и В) или С ... Средства: 1 BTC #Комментарии: ... ----- END TRANSACTION Bitcoin ----- Casascius, я считаю, что приоритетом номер один для TxDPs (или то, что мы хотим, чтобы назвать их) должна быть машина читаемость. Это не значит, что ваше предложение очень трудно разобрать с помощью кода, но это, безусловно, гораздо больше внимания на человека-читаемость - который я думаю, должен быть один из низших приоритетов. Я думаю, что стандартное использование дело будет получать пользователь эту TxDP в качестве вложения электронной почты, а затем их клиент будет автоматически обнаружит его и отобразить его в читабельной форме в любом случае. Таким образом, я считаю, что мы должны определенно иметь формат, который имеет минимальный пробелы, лишние слова и знаки препинания. И мы обязательно должны ограничить до 80 столбцов, чтобы убедиться, что идентификация и копирование его вручную супер легко (я ненавижу получать электронные письма, где текст, работающие с правой стороны экрана ... это должно быть компактное представление). После этих двух приоритетов satistified, тогда мы должны начать добавлять вещи для человека-читаемость для тех из нас, которые могут быть наклонены вручную проверить его. Но я думаю, даже для продвинутых пользователей, кодовые блоки, как правило, будут загружены / скопированы в программу, которая будет представлять данные в приятной, удобной для восприятия человека формы, и, таким образом, мы должны сосредоточиться на простоте реализации клиента, а не человек -readability. Я считаю, в том числе суммы TxIn и поле комментариев является хорошей идеей. |
|
|
|
|
21 ноября 2011, 2:10:40 PM
|
# 20 |
|
Сообщения: 1372
цитировать ответ |
Re: Multi-подпись предложения интерфейса транзакции
Почему это не машина для чтения? Я нахожу это очень легко разобрать, и будет рассматривать написание кода для анализа его очень элементарно.
Все линии имеют следующую конструкцию: Название: Значение Синтаксический блок так просто разделив его на CR / ЛФ, отбрасывая комментарии, ищет двоеточие на каждой линии, принимая все до двоеточия как имя, беря остальное в качестве значения. И если строка начинается с пробела, рассматривать его как продолжение предыдущего значения. Вырезание и вставка текста так намного безопаснее, чем иметь людей открывать вложения файлов. |
|
|
|
Как заработать Биткоины?
Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包
bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru
3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW
Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包
bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru
3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW
Регистрация для новых участников, на данный момент не доступна. Просим извинения за временные неудобства.