Вернуться   Биткоин Форум > Разработка и Техническое Обсуждение
27 декабря 2011, 10:08:22 PM   # 1
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

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


Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru
Несколько дней назад я начал обсуждение в клиентском потоке Электрум о новом протоколе и реализации серверной наложенной сети по p2p сети Bitcoin. Я думаю, что обсуждение не больше отношения к самой Электрум клиенту, поэтому я начал эту новую тему, посвященную мое предложение. Просьба прокомментировать мое предложение, попросите что-нибудь или предложить какое-либо улучшение, если вы хотите.

предложение Сетевой протокол (в процессе): https://docs.google.com/document/d/17zHy1SUlhgtCMbypO8cHgpWH73V5iUQKk_0rWvMqSNs/edit?hl=en_US

Реализация сервера (в процессе): https://gitorious.org/stratum/

Запуск узлов:
  • london.stratum.bitcoin.cz (TCP - 3333, HTTP - 8001), поставщик: Linode.com
  • chicago.stratum.bitcoin.cz (TCP - 3333, HTTP - 8000), поставщик: BitVps.com (спасибо!)

Короткая цитата из документа Google, описывающая основной целью такой наложенной сети. (Текущий Кодовое является "платформа Электрум", Но я ищу лучшее название банкомата: редактировать: "слой" выиграл конкурс на имя сети.

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

В основном Электрум является наложенной сетью на вершине протокола Bitcoin P2P, создавая упрощенный фасад для облегченных клиентов и скрывая излишнюю сложность децентрализованного протокола. Однако есть гораздо больший потенциал в этой наложенной сети, чем просто предоставление упрощенного API для доступа к blockchain хранится на серверах Электрума. Для использования такого потенциала, мы, безусловно, нуждаются в надежной протокол обеспечения достаточной гибкости для различных типов клиентов Электрум и их целей.

Некоторые передовые идеи для сети Электрум, которая будет нуждаться в гибкой сетевой протокол:
* Интеграция BTC / декретные обменов в клиент
* Кошелек для хранения бездисковых или крайне клиентов с низким уровнем ресурсов (AVR на основе аппаратных кошельков)
* Серверные escrows (отправка биткойны на электронную почту)
* Интеграция Bitcoin белья
* Обмен калькуляторы (для обеспечения «Fiat» эквивалентов BTC в клиентах)
* Firstbits поддержка
* Поддержка Mining для клиентов
* Различные транспортные протоколы (особенно HTTP Push, которая позволяет PHP сайты интеграции с Bitcoin легко)

Требования к протоколу:

котировка
* Протокол должен быть как можно более простым. Некоторые клиенты не способны обрабатывать системы сообщений на высоком уровне, как Google, протокол буферов или Apache бережливость.
* Протокол должен быть текст на основе. Некоторые языки не могут обрабатывать двоичные данные (JavaScript) или это довольно трудно правильно (PHP) реализовать.
* Протокол должен поддерживать стандартный механизм RPC (запрос-ответ). Запрос должны содержать идентификатор и параметры метода, ответ должен быть в состоянии передать состояния ошибки / исключение.
* Преобразование между запросом и ответом должно быть ясно. Не допускать неопределенную связь между запросом и ответом. Некоторые системы на основе сообщений используют только текстовые конвенции для отображения запросов и ответов вместе, как «firstbits_resolve firstbits_response»» ожидает <адрес>»Или«firstbits_error <причина>». Это создает неоднозначный поток данных, избежать его.
* Протокол должен поддерживать публикации-подписки механизм. Клиент может подписаться на сервер для получения какой-то информации. После этого запроса, сервер будет активно транслировать сообщения в подписавшиеся клиент до клиента разъединяет или отменить его подписка.
* Протокол должен быть двунаправленным. В противоположность стандартной модели клиент-сервер, мы иногда необходимо разрешить серверу инициировать связь. В качестве примера, сервер может попросить клиента подключиться к другому узлу (перед переключением в режим технического обслуживания) или отправить некоторое текстовое сообщение пользователю.
слякоть сейчас офлайн Пожаловаться на слякоть   Ответить с цитированием Мультицитирование сообщения от слякоти Быстрый ответ на сообщение слякоть


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


27 декабря 2011, 10:13:41 PM   # 2
 
 
Сообщения: 1708
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

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





Я думаю, что это был всего лишь вопрос времени, прежде чем была создана сеть parrallel / sidechannel.
Moonshadow сейчас офлайн Пожаловаться на Moonshadow   Ответить с цитированием Мультицитирование сообщения от Moonshadow Быстрый ответ на сообщение Moonshadow

27 декабря 2011, 10:22:21 PM   # 3
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

Да, я думал, что это было бы хорошей идеей, как хорошо.

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

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

27 декабря 2011, 10:28:25 PM   # 4
 
 
Сообщения: 742
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

Следующий.

Я очень заинтересован в Электрум / тонких клиентов и имеют пропускную способность / оборудование для запуска supernode так готов проверить.
Red Emerald сейчас офлайн Пожаловаться на Red Emerald   Ответить с цитированием Мультицитирование сообщения от Red Emerald Быстрый ответ на сообщение Red Emerald

27 декабря 2011, 10:31:36 PM   # 5
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

Я думаю, что это был всего лишь вопрос времени, прежде чем была создана сеть parrallel / sidechannel.

Что ж, цель обеспечить только Bitcoin услуги, связанные с любым возможным устройства или приложения, где сохранение blockchain локально является излишеством. Я определенно не хочу, чтобы разработать что-нибудь, который заменяющий Bitcoin. Я просто вижу концепцию различных транспортов (TCP сокеты, HTTP опрос, HTTP кнопочного, даже интерфейс электронной почты!) Очень гибкая.

Некоторые люди спрашивают меня, почему я не просто расширить протокол Bitcoin. Я думаю, что обе вещи решают другие проблемы. Bitcoin P2P сети распределенной базы данных, это хранение blockchain и обработку транзакций. Мое предложение больше об услугах на вершине этой базы данных, и я не думаю, что они могут быть предоставлены исключительно через p2p сети. Кроме того, я не думаю, что Bitcoin p2p сети должны заботиться о таких "Сервисы" как раздаточный USD / BTC цена или аналогичный.

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

27 декабря 2011, 10:34:59 PM   # 6
 
 
Сообщения: 742
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

Некоторые люди спрашивают меня, почему я не просто расширить протокол Bitcoin. Я думаю, что обе вещи решают другие проблемы. Bitcoin P2P сети распределенной базы данных, это хранение blockchain и обработку транзакций. Мое предложение больше об услугах на вершине этой базы данных, и я не думаю, что они могут быть предоставлены исключительно через p2p сети. Кроме того, я не думаю, что Bitcoin p2p сети должны заботиться о таких "Сервисы" как раздаточный USD / BTC цена или аналогичный.

Я полностью согласен с вами. Я думаю, строительные услуги на вершине Bitcoin гораздо умнее, чем изменения протокола Bitcoin.
Red Emerald сейчас офлайн Пожаловаться на Red Emerald   Ответить с цитированием Мультицитирование сообщения от Red Emerald Быстрый ответ на сообщение Red Emerald

27 декабря 2011, 10:36:57 PM   # 7
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

Да, я думал, что это было бы хорошей идеей, как хорошо.

Мое независимое воображение этой концепции было то, что "supernode"

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

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

27 декабря 2011, 11:25:15 PM   # 8
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

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

Я не думаю, что протокол ядра Bitcoin необходимо будет изменить. Он будет заменен полностью, для клиентов, предназначенных для использования другого протокола.

Причины нового протокола может включать в себя:
  • поддержка клиентов, которые действуют в качестве полноправных узлов, но которые никогда не видели полный blockchain (работающий с обрезанной версией) ... текущий протокол предполагает, что все узлы имеют полный блок цепь ... нет никакого языка за слова "У меня есть отсеченный блок"Или для согласования, что на блоке должны и не должны быть сокращены
  • огибают метаданные, которые не принадлежат в блок цепи, но тем не менее полезно против 51% атак (например, подписанных сообщений, подтверждающих, кто видел, что блоки)
  • поддержка запросов к узлам с полным блоком цепью, в пользу легких узлов
  • своего родом взаимной аутентификации, при необходимости (например, если я легкий узел, я бы предпочел, чтобы запросить узел, которому я доверяю, а не случайный, и предпочел бы, чтобы его ответ на мой запрос цифровой подписи .. . Кроме того, этот узел может взимать плату за эту услугу, и, возможно, хочет знать, кто я, а)
  • возможно, сервис, который может обрабатывать несколько cryptocurrencies или альт цепи (не то, что я был бы фанатом, но это законная функция, которая может побудить кого-то сделать новый протокол)
  • механизм для клиентов, чтобы спросить только о сообщениях, которые относятся к ним, чтобы сократить затраты ресурсов (например, клиент спрашивает, "только сказать мне о сделках, связанных с <список адресов>" и / или "только сказать мне о новых блоках",

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

28 декабря 2011, 12:00:01 AM   # 9
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

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

28 декабря 2011, 1:54:13 AM   # 10
 
 
Сообщения: 714
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

предложение для сетевого имени:

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

28 декабря 2011, 2:55:53 AM   # 11
 
 
Сообщения: 1988
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

Привет слякоть (и другие читатели)!

Я перечитал Ваше предложение (здесь и в Документах Google). На моем взгляде, вы предлагаете или (1) внутренне противоречивый протокол или (2) семейство несовместимых протоколов, поддерживаемых надеждой на обмен некоторых деталей реализации.

Второй вопрос заключается в том, что я не предлагаю RPC через HTTP (S).

Мне нужно добавить пользовательский способ, как поддерживать HTTP опрос или HTTP толчок, потому что я хочу * * для предоставления услуг для такого типа клиентов.

потому что JSon кодер / декодер или скручиванию / Аякс доступен везде в стандартных библиотеках

Полученный монстр Франкенштейна (или семейство монстров) будет пытаться задушить свой создатель.

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

1) Протокол может быть либо RPC или двунаправленным, но не оба. Парадигма RPC (запрос-ответ, ведущий-ведомый) взаимно противоречивы с парой коллег, обменивающихся асинхронных сообщений. Биткойн протокол сам по себе от своего происхождения асинхронных и не могут быть сжаты в ведущий-ведомый архитектуры. Он требует двунаправленного асинхронный протокола с конечными автоматами (FSMS) на обоих концах, сообщающихся с двумя потоками секвенсированных кадров. Удачная конструкция будет выглядеть очень похоже на TCP поверх IP кадров.

2) Ваш целевой рынок (младшие устройства потребительского уровня) требует, чтобы там checksuming и кадрирование на прикладном уровне. Именно потому, что дешевые шлюзы NAT и дешевые модемы DSL / Cable / WLAN известны калечить кадры транспортного уровня из-за ошибки (в реализации NAT) и чрезмерной буферизации (для улучшения односторонних передач файлов реперов).
Если вы думаете, что вы можете добавить CRC позже вы собираетесь потерять, не обнаруживать развращения рано.

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

3.1) ультра-постное протокола символов на основе похоже на FIX, разработанное первоначально для MNP5 и V.42bis модемов, в настоящее время используется через простой сокет TCP / IP
3.2) SOAP (RPC через XML) с Content-Length, Content-MD5 и проверка DTD включена
3.3) SOAP и обычный XML-RPC без указанных выше опций УКРЕПЛЕНИЯ
3.4) JSON-RPC
3,5) RPC по электронной почте с различным человеческим считываемым кодировком

Все вышесказанное в основном продаются для малого бизнеса и индивидуальных путешествующих продавцов, которые, как представляется, целевой рынок вы планируете обслуживать. У нас также есть услуги предприятия-ориентированное использование различных MQ и * -remoting технологии, но предлагаемые услуги непосредственно не сопоставимы. Я вещь, что JSON может быть приемлемым выбором, если вы с самого начала требовать усиления какой-либо формой Content-Length и Content-Checksum. JSON также печально для позволяя людям легко сделать байт-порядком байтов ошибок, очень похоже на текущий "getwork" который не является ни большой обратный порядок байт не прямой порядок байтов. Да, JSON экономит много пропускной способности по сравнению с XML. Но я не знаю ни одного доступной в настоящее время реализации, не производит загадочными и трудно устранить режимы отказа. Это классический пример "постный, но очень средний" дизайн.

4) Вы как-то прочитал, что мои предыдущие предложения о IPsec подразумевает высокого класса большого объема целевого рынка. Реальность совсем напротив: Windows поддержка IPsec с 2000 года, Linux в течение длительного времени, семья Netgear ProSafe имеет несколько моделей в $ 100- $ 200 диапазон, L2TP и PPTP доступны бесплатно на всех iPhone'ов для, ежевика, андроиды; многие Nokias и другие смартфоны. Реальным препятствием является HTTP (S) -uber-аллес мышления, а не фактическая сложность и стоимость реализации.

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

У меня есть личная лакмусовая бумажка для технологической реализации в области Bitcoin: он должен поддерживать (и быть испытан на) цепи реорганизацию. Предпочтительно он должен правильно повторить транзакции на REORG. Абсолютная минимальная реализация должна завершаться корректно с четким сообщением об ошибке и определенным образом, чтобы перезапустить операции. Любая реализация, которая будет вести себя как Том Уильямс Mybitcoin.org вина-это-на-цепного REORG провал. До сих пор ваши предложения, кажется, не охватывают эту важную особенность Bitcoin. Если Electrum (и связанные с ними протоколы) не будут правильно вести себя в присутствии реорганизации событий цепи, то я снимаю свое ранее мнение, что Электрум имеет больший потенциал, чем клиент Satoshi.

Еще раз спасибо за ваше время и внимание.
2112 сейчас офлайн Пожаловаться на 2112   Ответить с цитированием Мультицитирование Сообщения от 2112 Быстрый ответ на сообщение 2112

28 декабря 2011, 3:10:46 AM   # 12
 
 
Сообщения: 1232
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

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

28 декабря 2011, 4:25:23 AM   # 13
 
 
Сообщения: 1988
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

Дело в том, чтобы не слишком догнал написания длинных предложений и документов. Подумайте немного, коды вверх реализации, получить прокатки и уточнить требования, как они становятся очевидными. Это проще попросить прощения, чем просить разрешения.
У вас есть справедливое замечание. Но я очень скептически, как к общим программным архитектурным навыкам в сообществе широкой Bitcoin. Мой абсолютный фаворит инверсия вопроса управления в Satoshi клиента выставлены ThreadSafeAskFee (). Такой учебник случай анти-паттерна.



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

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

28 декабря 2011, 4:32:27 AM   # 14
 
 
Сообщения: 742
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

Дело в том, чтобы не слишком догнал написания длинных предложений и документов. Подумайте немного, коды вверх реализации, получить прокатки и уточнить требования, как они становятся очевидными. Это проще попросить прощения, чем просить разрешения.
Я не согласен. Я думаю, что заблаговременное планирование всегда ведет к улучшению программного обеспечения, даже если разработчик программного обеспечения может быть медленнее, чтобы начать. Лучше найти проблемы в вашем предложении и переписать, что, чем обнаружить проблему в коде и переделывать тонну работы там ИМО

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

28 декабря 2011, 6:58:27 AM   # 15
 
 
Сообщения: 1232
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

Дело в том, чтобы не слишком догнал написания длинных предложений и документов. Подумайте немного, коды вверх реализации, получить прокатки и уточнить требования, как они становятся очевидными. Это проще попросить прощения, чем просить разрешения.
У вас есть справедливое замечание. Но я очень скептически, как к общим программным архитектурным навыкам в сообществе широкой Bitcoin. Мой абсолютный фаворит инверсия вопроса управления в Satoshi клиента выставлены ThreadSafeAskFee (). Такой учебник случай анти-паттерна.



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



Bitcoin кодовая страшен архитектурно.

Вы можете быть заинтересованы, чтобы пересмотреть свои кодовый который является асинхронной библиотекой Bitcoin инструментария, используя proactors. Обработчики завершения использования зОго :: BIND и зЬй :: функций передаются операциям.



Также видео на принципах, лежащих в API:

http://www.youtube.com/watch?v=zyKcSpx5xDg
genjix сейчас офлайн Пожаловаться на genjix   Ответить с цитированием Мультицитирование сообщения от genjix Быстрый ответ на сообщение genjix

28 декабря 2011, 7:00:08 AM   # 16
 
 
Сообщения: 1232
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

Дело в том, чтобы не слишком догнал написания длинных предложений и документов. Подумайте немного, коды вверх реализации, получить прокатки и уточнить требования, как они становятся очевидными. Это проще попросить прощения, чем просить разрешения.
Я не согласен. Я думаю, что заблаговременное планирование всегда ведет к улучшению программного обеспечения, даже если разработчик программного обеспечения может быть медленнее, чтобы начать. Лучше найти проблемы в вашем предложении и переписать, что, чем обнаружить проблему в коде и переделывать тонну работы там ИМО

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

Вы выступает древний метод водопада, который в основном из моды, так как в последнее десятилетие.

котировка
genjix: ~ $ питон
Python 2.7.2+ (по умолчанию, 4 октября 2011, 20:03:08)
[GCC 4.6.1] на linux2
Тип "Помогите", "Авторские права", "кредиты" или "лицензия" Чтобы получить больше информации.
>>> импортировать этот
Дзен Python, Тим Питерс

Красивое лучше, чем уродливое.
Явное лучше, чем неявное.
Простой лучше, чем сложнее.
Комплекс лучше, чем сложнее.
Плоский лучше, чем вложенное.
Разреженное лучше, чем плотный.
Читаемость имеет значение.
Особые случаи не настолько особенные, чтобы нарушать правила.
Хотя практичности бьет чистоту.
Ошибки никогда не должны проходить молча.
Если явно не молчать.
В условиях неопределенности, отказаться от соблазна угадать.
Там должно быть одно-- и предпочтительно только один --obvious способ сделать это.
Несмотря на то, что способ не может быть очевидным на первый, если вы не голландцы.
Сейчас лучше, чем никогда.
Хотя никогда зачастую лучше, чем * прямо * сейчас.

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

28 декабря 2011, 7:48:29 AM   # 17
 
 
Сообщения: 742
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

Дело в том, чтобы не слишком догнал написания длинных предложений и документов. Подумайте немного, код до реализации, получить прокатки и уточнить требования, как они становятся очевидными. Это проще попросить прощения, чем просить разрешения.
Я не согласен. Я думаю, что заблаговременное планирование всегда ведет к улучшению программного обеспечения, даже если разработчик программного обеспечения может быть медленнее, чтобы начать. Лучше найти проблемы в вашем предложении и переписать, что, чем обнаружить проблему в коде и переделывать тонну работы там ИМО

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

Вы выступает древний метод водопада, который в основном из моды, так как в последнее десятилетие.

котировка
genjix: ~ $ питон
Python 2.7.2+ (по умолчанию, 4 октября 2011, 20:03:08)
[GCC 4.6.1] на linux2
Тип "Помогите", "Авторские права", "кредиты" или "лицензия" Чтобы получить больше информации.
>>> импортировать этот
Дзен Python, Тим Питерс

Красивое лучше, чем уродливое.
Явное лучше, чем неявное.
Простой лучше, чем сложнее.
Комплекс лучше, чем сложнее.
Плоский лучше, чем вложенное.
Разреженное лучше, чем плотный.
Читаемость имеет значение.
Особые случаи не настолько особенные, чтобы нарушать правила.
Хотя практичности бьет чистоту.
Ошибки никогда не должны проходить молча.
Если явно не молчать.
В условиях неопределенности, отказаться от соблазна угадать.
Там должно быть одно-- и предпочтительно только один --obvious способ сделать это.
Несмотря на то, что способ не может быть очевидным на первый, если вы не голландцы.
Сейчас лучше, чем никогда.
Хотя никогда зачастую лучше, чем * прямо * сейчас.

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

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

И я определенно стоят за моей второй точки.  

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

РЕДАКТИРОВАТЬ: Перечитайте свой пост. Я пропустил "код до реализации" и думал, что вы хотите закодировать, без дорожной карты.
Red Emerald сейчас офлайн Пожаловаться на Red Emerald   Ответить с цитированием Мультицитирование сообщения от Red Emerald Быстрый ответ на сообщение Red Emerald

28 декабря 2011, 9:20:36 AM   # 18
 
 
Сообщения: 1892
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

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

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

Вещи, которые я хотел бы видеть в протоколе:

* Использование JSON RPC
* Множество функций, которые в настоящее время используются клиентскими и серверными (адрес функции, основанные) Электрум: сервер не знает множество адресов в кошельке клиента, он просто посылает адресные истории и Трансляции транзакции. Это означает, что клиент должен иметь возможность использовать несколько серверов одновременно для повышения анонимности.
* Кошелек на основе функции (аналогичные BCCAPI) для ультра-тонких клиентов: Сервер знает открытый ключ, используемый для генерации последовательности адресов в 2 кошельке типа. Он посылает баланс и историю бумажника. Он также посылает число адресов, обнаруженных в кошельке (разрыв обнаружение на основе, обратите внимание, что это отличается от BCCAPI, потому что сервер BCCAPI должен хранить количество ключей в базе данных). Сервер также отправляет неподписанные транзакции клиента, а клиент подписывает их.
* Также, я хотел бы увидеть что-то похожее на сделки Radar: http://www.transactionradar.com/ : Когда транзакция не подтверждена, то клиент должен отображать свою скорость распространения. Серверы Электрум могут быть частью существующей транзакции радиолокационной службы.
ThomasV сейчас офлайн Пожаловаться на ThomasV   Ответить с цитированием Мультицитирование сообщения от ThomasV Быстрый ответ на сообщение ThomasV

28 декабря 2011, 1:57:12 PM   # 19
 
 
Сообщений: 39
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

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

Использование WebSocket в качестве транспорта. Это би-derectional и достаточно просто.
http://en.wikipedia.org/wiki/WebSocket
Grami сейчас офлайн Пожаловаться на Grami   Ответить с цитированием Мультицитирование сообщения от Grami Быстрый ответ на сообщение Grami

28 декабря 2011, 1:58:17 PM   # 20
 
 
Сообщений: 39
Цитировать по имени
цитировать ответ
по умолчанию Re: сетевой протокол [Stratum] Накладка над Bitcoin

3) По моему опыту JSON, вероятно, близка к наименее устойчивыми кодирования возможно.

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



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

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

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

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW