|
чей-то донат, там куча адресов в Output
|
|
|
|
|
торги работают всегда, но вывод (и почти наверняка ввод через банковский перевод) только в рабочие дни.
|
|
|
|
Думаю, пришел момент (если это так), как в свое время майнинг на процах ушел в прошлое, так и на видяхах тоже самое.. И это на самом деле ХОРОШО, я рад до усрачки, это уже становится серьезно! На самом деле есть серьезная проблема в переходе GPU/FPGA->ASIC, если сравнивать переход CPU->GPU/FPGA. Оборудование становится узкоспециализированным и для его получения потребуется чуть больше чем просто желание. Если сейчас и раньше для того чтобы поучаствовать в процессе генерации монет bitcoin достаточно просто воспользоваться уже имеющимся оборудованием - обычным компьютером (что кстати увеличивает защищенность всего проекта в целом, так как размазывает мощности по большему количеству пользователей), то при появлении единственного производителя оборудования, подходящего для майнинга приведет к сильному уменьшению обычный, не серьезных, майнеров (составляющих как минимум половину... кстати отдельный разговор сколько именно майнеров, не готовых покупать дополнительное оборудование). На текущий момент, люди, которые майнят в соло почти наверняка будут готовы и дальше вкладываться в оборудование, потому как для этого уже сейчас им приходится его покупать (1-3 видеокарты обычных пользователей не позволяют комфортно майнить в соло, таких терпеливых незначительное количество - это мощности выше 3-5Gh/s, т.е. блоки в течении месяца, будем считать 3Gh тем порогом, разделяющим серьезных майнеров от обычных). Соло майнеры - это почти наверняка Unknown на bitcoinwatch.com - это последние месяцы 40%!!! (раньше было 5%-20%) от мощности сети (кстати, почти наверняка, две трети мощности из них сконцентрировано на 7-8 узлах - как минимум это показывают статы, тоесть ~25% от мощности сети). Статы пулов eligius, p2pool (подробный список активных пользователей с их мощностями) показывают, что максимум 10% пользователей пулов так же серьезно вкладываются в оборудование. Итого порядка 50% майнеров, максимум, (не количественно а по уровню мощности) могут остаться майнить, остальные уйдут, так как стоимость электроэнергии им просто не позволит заниматься этим на видеокартах, а к покупке оборудования они скорее всего не готовы. Могу предположить, что в течении следующего года (ASIC чипы для майнинга публично доступны станут в лучшем случае в новом году) и повысят мощность сети примерно в 10-20 раз (текущая мощность * [35%..50% серьезных майнеров в сети] * [40кратное ускорение при фиксированной цене] = [15..20 раз выше сложность]) И вся эта мощность будет сконцентрирована у гораздо меньшего количества майнеров, почти наверняка это будут не пулы майнинга (майнеры ведь серьезные), и рулить всеми ими будет один единственный производитель с проприетарным софтом  |
|
|
|
|
Неужели не понятно, что для пула с таким высоким уровнем реджектов удачу нужно считать с их учетом (кстати на всех пулах, просто реджекты нужно брать в т.ч. из статистики orphaned блоков пула).
Видно же что неудача фактически равна среднему уровню stale rate пула 8%-12%.
Держите эффективность на уровне 100%+ и не парьтесь (отдельный хостинг, вручную подключайте пул к ближайшим узлам и т.п.).
|
|
|
|
Разработчики bitcoin-qt такие душки, одну кнопочку поленились сделать, кода в которой строчек на пять. Если в сообщении нет всяких символов типа " или перевода на новую строку (может еще какие подводные камни будут, с кодировкой например) то можно воспользоваться командной строкой: Пуск -> выполнить -> cmd -> [enter]
в открывшемся окне:
C:\>"C:\Program Files (x86)\Bitcoin\daemon\bitcoind.exe" "C:\Program Files (x86)\Bitcoin\daemon\bitcoind.exe" verifymessage адрес_в_кошельке_bitcoin строка-подпись "подписанное_сообщение_в_ковычках"
выведет 'true' - если подпись верная, 'false' - нет Иначе нужно будет формировать соответствующий RPC запрос (это если сообщение в несколько строк или с проблемными для командной строки DOS символами. |
|
|
|
|
Что за повреждение у вас такое? Вы разломили диск пополам? Просверлили в нем отверстие? Взорвали?
Диски вынимаются и вставляются в другую рабочую модель, а электроника точно так же заменяется еще проще... хотя, могу предположить что дьявол в мелочах и частностях.
p.s. Томск, общался со специалистами нескольких фирм, когда сдавал диски на восстановление, цены были на порядок ниже (4-6т.р. при этом сюда входила стоимость донора)
|
|
|
|
Восстановление данных будет стоить 32000 рублей. Тебя пытаются нереально на$&@ть. Себестоимость восстановления данных даже с проблемами в железе стоит максимум сумма точно такой же железки плюс несколько часов работы специалиста (не больше 500 р./ч). |
|
|
|
Бедные, как мне жалко windows пользователей, вечные проблемы - красивые тяжелые софтины на один чих, с ограниченным функционалом... Под linux с драйверами идет штатная утилита atitools она все может 'и жнец и на дуде игрец'. p.s. под windows 7 для ATI видеокарт у меня давно стоит утилита http://bitcoinX.com/clocktweak/ простая, консольная, мульти-GPU, настройка частот, кулеров и т.п. |
|
|
|
Еще раз спрошу, кто знает, подскажите, сколько тактов требуется для используемых в биткойн операций, и сколько для этого транзисторов понадобится? Тут ведь есть инженеры знакомые с VHDL, или на чем, там, сейчас модно чипы проектировать? На запрос vhdl sha256 гугл выдал первое попавшееся. А второе: https://bitcointalk.org/index.php?action=printpage;topic=22415.0Area for 1 core, including test rig: 2,113 cells (plus a little memory)
Maximum frequency: 385 - 421 MHz (depending on temperature)
Clock cycles per SHA-256 (1 chunk): 64 (on average, if pipeline is kept full)
Clock cycles per double-SHA-256: 128 (ditto)
Bitcoin Mhash/s per core: 3.0 - 3.3 (temp-dependent)
Cores per FPGA: At least 50
Bitcoin Mhash/s per FPGA: 150 - 165 Mhash/s (temp-dependent)
~2тысячи ячеек на вычислительное ядро (я хз что есть ячейка для FPGA является ли это тупо транзистор или что то по мудрее, но это что то где то рядом) ядро считает хеш bitcoin за 128 такта при ~400MHz В одну микросхему таких ядер можно напихать не 50 как в FPGA (все таки это эмулятор) а десятки тысяч (22 млн у древнего amd athlon), это как минимум в 200 раз быстрее при не худшем энергопотреблении... так что ребята либо реализуют на каком то очень фиговом техпроцессе, либо не заморачивались с эффективностью... либо скорость искусственно замедлена! p.s. Я приблизительно считал сколько должен быть одно ядро вычислений.. но со своей колокольни и необразованности по этой тематике у меня получалось в сотню раз больше транзисторов.. и даже при этом результаты даже не с самым современным техпроцессом были ошеломляющие. |
|
|
|
|
Для ЭТОГО случая я уже сказал.. Electrum готовое решение, работает на python, запускается и на Android (а это железо от 100$ с экраном), хотя да его нужно причесать, инсталятор под Android, и по мелочи...
|
|
|
|
Смысл в этих списках адресов и прочем отсутствует. Вот почему: {
"account" : "",
"address" : "MxsBycySBb4gNfHLNERruMxm5YmMiAfCFG",
"category" : "send",
"amount" : -0.10000000,
"fee" : 350.02900002,
"confirmations" : 4185,
"txid" : "793a046bcaebffd2e6cc515e558112d30a9bf37597278f8cc941c1627a034af2",
"time" : 1337468357
}Кто в теме, тот поймет что такая транзакция делает.  Мне не ясно, как это скроет, на какой адрес зачислены эти 350монет.. ведь видно же кому начисляется на генерированный блок (туда же складываются комиссии), я правда смутно понимаю механизм, и как именно он позволяет это скрыть. |
|
|
|
А сам интерпретатор питона сколько весит? Это настолько фигня мелкая, что недостойна даже упоминания. Питон сейчас можно запустить почти на всем что питается электричеством... если не понятно, даже на 8-битных avr-ках запускают (понятно что именно это извращение но как пример). Не нравится python, возьмите реализацию из клиента на C++, будет быстро и компактно. В крайнем случае формирование транзакции можно взять из любых других альтернативных клиентов, может быть отдельно кто уже писал в виде утилиты. да хотя бы выцепить из C++ кода bitcoin.
... и написать на JavaScript... Бедный браузер на слабеньком мобильном процессоре, он же повесится! С фига ли повесится? Всего то подписать транзакцию своим ключом, к тому же на это можно и время потратить, секунды - не проблема (конечно если у вас проект, который в секунду десятки исходящих транзакций требует - вы можете подумать о чем то более производительном) Львиная доля кодинга в таком клиенте - это алгоритм выяснения, нужно ли действительно генерировать транзакцию (вы ведь должны какой то механизм предусмотреть, иначе если напрямую слать команды от веб-сервера на ваш секретный сервер, то ничем это не будет отличаться от 'обычный кошелек на сервере', просто взломщику придется чуть подольше покопаться с вашим кодом), - это всякие проверки на взломы, контроль итогового баланса, аномальные транзакции и т.п.
Обычный кошелёк на сервере. Под логином и паролем, которые передаются по защищённому каналу (HTTPS). Чем плохо? Значит не понял! С какой целью есть необходимость разделить сервис на две части? В обычной ситуации, если клиент bitcoin с кошельком сервиса размещен там же где и основной сервер, то доступ нему открыт всем участникам это проекта (разработчикам, администраторам, хостеру, ... хакерам, взламывающим сервис). После очень ярких примеров только очень глупый будет складывать такие яйца в одну корзину. Лучше разделить весь сервис на две составляющие: 1. Обычная серверная - обрабатывает всю логику, интерфейс пользователя (веб) и т.п. - тяжелый, требует ресурсы и много кода, тут запущен и обычный bitcoind исключительно для анализа входящих транзакций. 2. Небольшая, секретная, управляющая исходящими транзакциями. Между этими частями нужна связь, ведь 'секретный' модуль как то должен узнавать, какие транзакции нужно создать. Если сделать тупую отсылку, пусть даже и по защищенному протоколу, команд, то получивший доступ к серверу легко сможет их подделать (проанализировав код и вызвав нужные функции со своими данными). Идеальной защиты не существует, но можно очень усложнить вору задачу, если вместе с отсылкой сырых команд на создание транзакций, отсылать еще и часть базы главного сервера (а лучше всю, ее вообще неплохо бы реплицировать куда-нибудь), а эта 'секретная' программа должна проанализировать базу и транзакцию с таким условием, чтобы обнаружить аномальные отклонения от обычного и при обнаружении опасности придержать транзакацию 'до выяснения'. Главный се6рвер может даже не иметь возможности переслать любые деньги на адрес, пусть он оперирует терминами своего сервиса - 'вывести с депозита пользователя XXX сумму YYY' и уже злоумышленник не сможет украсть все средства сервиса одной транзакцией. Внезапные увеличения перемещений денежной массы, несовпадения 'дебита с кредитом', все это нужно анализировать, контролировать и дважды проверять.. ведь это не банковские транзакции, которые можно 'откатить в течении месяца', если отослал монеты - то это на всегда. |
|
|
|
Тогда этот клиент получается не очень-то и "тонким"...
O_o electrum\lib\wallet.py ~ 40кб (и там мне кажется много лишнего) И не нужно хранить и проверять базу blockchain В крайнем случае формирование транзакции можно взять из любых других альтернативных клиентов, может быть отдельно кто уже писал в виде утилиты. да хотя бы выцепить из C++ кода bitcoin. Львиная доля кодинга в таком клиенте - это алгоритм выяснения, нужно ли действительно генерировать транзакцию (вы ведь должны какой то механизм предусмотреть, иначе если напрямую слать команды от веб-сервера на ваш секретный сервер, то ничем это не будет отличаться от 'обычный кошелек на сервере', просто взломщику придется чуть подольше покопаться с вашим кодом), - это всякие проверки на взломы, контроль итогового баланса, аномальные транзакции и т.п. |
|
|
|
Чтобы сервер подписал транзакцию, ему один чёрт нужны ключи, и их тогда придётся передавать по сети...
В идеалогии https://en.bitcoin.it/wiki/Thin_Client_Security это не так. Клиент Electrum сообщает серверу только об адресах кошелька (только публичные ключи) а приватные остаются на клиенте. Сервер, благодаря адресам знает когда клиенту нужно будет ответить что приехала транзакция (там обычные push запросы от клиента). Зато Когда нужно создать транзакцию, клиент ее создает и подписывает своим приватным ключом, и уже эта подписанная транзакция отсылается серверу (для этого на стороне сервера стоит пропатченный bitcoin клиент с добавленной командой importtransaction). p.s. мне правда непонятно зачем там реализован механизм генерации адресов на основе seed, защищенности это не добавляет, удобство сомнительно, но его можно отключить а адреса импортировать из офф клиента. Благодаря этому патчу bitcoin от electrum при большом количестве можно спокойно держать на сервере клиент bitcoin с пустым кошельком (благо уже можно довольствоваться одним клиентом чтобы быстро анализировать любые адреса на приход транзакций, правда пока только после их помещения в блоки и самостоятельно эти транзакции анализировать), а на гораздо более защищенной машине (пусть даже на своем сотовом или специально выделенном для этого планшетнике/роутере/rasberry pi/ сервер в ethernet коннекторе) держать простенький модуль подписывания исходящих транзакций. |
|
|
|
Электрум всё равно опирается на сервер. И у него свой вариант RPC зачем-то. И опять питон...
Скажем так: я всё это замутил с некоторым прицелом на будущее. На какое - пока не скажу.
Интересно мне было одно: такие решения кому-нибудь интересны или можно спокойно отправлять его в долгий ящик?
Ну и ваше решение я так понимаю тоже опирается на серверную часть, логично если оно будет основано на оригинальном клиенте (Electrum патчит bitcoin чтобы он принимал 'не свои' транзакции и использует ABE... но последний только потому что нужного функционала по анализу не своих транзакций попросту не было). Пишите, не останавливайтесь, не бойтесь публиковать свои наработки. Любое развитие проекту bitcoin в целом - польза. Не нужно бояться эксперементировать, самое полезное останется, будет поглощено, использовано и улучшено. |
|
|
|
p.s. Ничего не имею против утверждения о плохой работе текущего клиента... Смотреть клиенты bitcoin тут https://en.bitcoin.it/wiki/SoftwareРадоваться этому https://en.bitcoin.it/wiki/Bitcoin-js-remote - A user interface for Bitcoin written in JavaScript. Вместе с ним идет мини RPC-веб-сервер на питоне с поддержкой SSL Так же предлагается документация по настройке RPC-прокси штатными средствами вебсервера Apache |
|
|
|
А вот и те самые mining specific asic, интегральные чипы, спроектированные исключительно для майнинга. p.s. смена 50->25 пройдет незаметно  p.p.s. догадаются они наконец выпустить вариант с солнечными батареями и выходом в gprs/3g |
|
|
|
|
Народ, это же ваши деньги, неужели сложно посерьезнее к ним и к софту относиться.
Софт надо обновлять, все начало года крики и вопли по поводу обновления bitcoin, которое убьет совместимость со старыми версиями... но нет, надо дотерпеть до конца, 'ведь именно со мной ничего же не случится..'
Хорошим способом может являться поэтапная установка и запуск клиента bitcoin разных версий,.. 0.3xx, 0.4xx, 0.5xx, 0.6xx. Я думаю из 0.6xx клиента убрали (перестали тестировать) код, обновляющий очень старые кошельки. -rescan тут не нужен, он имеет смысл когда в кошельке пропущена транзакция (например когда две копии кошелька использовались на разных компьютерах и с обоих отсылались деньги).
|
|
|
|
Буду использовать bitcoin если это будет выгодно |
|
|
|
|
Show Posts
