Сделал заказ через знакомых с Ebay двух устройств 50 GH/S BITCOIN MINER и 25 GH/S BITCOIN MINER которые уже едут ко мне на Украину. Вот только не как не пойму смогу ли я на пулах фармить или нет ? Какое программное обеспечение нужно для этих устройств ? Ну и вообще кто не будь может объяснить мне по подробней как будет происходить фарм на них и что мне ещё будет нужно ? Можно отписывать в личку если не хотите тут ! За ранее благодарен .
дайте ссылку на ebay что вы там такое купили, есть большие шансы что вас надули, либо вы купили место в очереди на доставку bfl устройств, и если это 50GH/25GH то вас еще больше нае$%ли, bfl продает предзаказы на такие железки с апреля этого года, а поставки начались только только прошлогодние... сами догадаетесь сколько будете ждать? |
|
|
|
XRP - это не деньги, не криптовалюта.. грубо говоря - это акции компании opencoin / проекта ripple. Со всеми вытекающими - владельцы их могут нарисовать сколько угодно (кто сказал что нельзя). PoW не столь однозначно, посмотрите какой трэш в биткоине творится, я сомневаюсь, что Сатоши предполагал такое. Десятки (сотни?) тысяч вычислительных устройств, сжигающие мегаватты электроэнергии, фактически делают то, что способны делать пару компьютеров с Pentium4 на борту.  Ошибочка, пара компьютеров ни коим образом не смогут обеспечить надежность и независимость системы bitcoin! Самое главное достоинство bitcoin - это ее децентрализация (как монеты естественно). А если кто то опять будет повторять про зависимый курс от манипулятора, торговлю по паспортам, то еще раз скажу - поймите, это не bitcoin зависимый, это биржи и фиат централизованы и зависимы,.. и это тоже решаемо. |
|
|
|
|
Нет, но и не надо!
Тут мне понятно что ТС просто очень многого не понимает.. я умею слушать людей, которые не понимают или понимают ограниченно но в пределах своих знаний/возможностей, иногда это даже полезно, чистый незамутненный готовыми решениями взгляд.
p.s. или очередной троллинг, очень грустно
|
|
|
|
поэтому крыс зафильтруем, и по-возможности постараемся, на ноль умножить дополнительно. как это сделать - будем думать вместе с метабанком - возможно выдавать железо порциями небольшими, а не всем и сразу, и смотреть на поведение - как вариант не плохой. Думаем. Почему речь пошла о заказавших железо, если виноват оказался тестер? O_o |
|
|
|
|
О хранении и шла речь в самом начале... глупости в названии топика и в сообщени я просто опустил за ненадобностью
Я не изучал leveldb но многие key-value базы данных спокойно горизонтально масштабируются, ничто не мешает вместо оной базы вести две/много... одна для данных, к которым очень частый доступ (можно статистически выявить такой интервалл времени, в пределах которого чаще всего происходит доступ к монетам) и другая для старых данных, к которым доступ сравнительно редок. ВСЕ... работы не много польза - на порядок.
p.s. я не хочу больше вести беседу в этом треде, вы тут на друг друга откровенно наезжаете, это уже смахивает на очередной троллинг
|
|
|
|
bitfury: когда в россии запустите продажи, везде уже продают, а у нас нет (
где продают? Везде предзаказы! Или голые чипы. Единственное что странно, что сроки поставок те же что и у metabank в России (хорошо пока ограничены европой) |
|
|
|
Какие это дает преимущества? Он более устойчив к взлому? Более устойчив к атаке 51%?
Или просто он использует другой алогритм который сложнее майнится?
scryp форк БЫЛ устойчив к атаке 51% на заре своего становления, пока не было создано GPU-майнера, но так как он к этому моменту получил свое развитие - это стало не актуально. Но например благодаря scrypt litecoin защищен от атак мощностями из сети большого брата оборудованием ASIC в отличии к примеру terracoin или ppcoin. |
|
|
|
1) блоки устроены так, что их константы имеют один алгоритм хеширования: SHA 256
главная ошибка в рассуждениях, litecoin использует scrypt и пока это его главное и основное преимущество (второе - скорость появления блоков увеличена до 1 минуты) |
|
|
|
без прогрузки блоков это как - не лезет без спроса в интернет, или не скачивает всю цепочку? 2 способа, запрашивает информацию о транзакциях у сервера, и p2p-сеть (подробности этого не известны, не изучал) основная идея.. сервера рулят только работой по публичной информации (грубо говоря это тупой аналог blockchain.info или blockexplorer.com) и приемом raw-транзакций, а формирование этих транзакций (собственно доступ к монетам) полностью лежит на стороне клиента, т.е. доступа к монетам ни у кого нет, сервера максимум могут сопоставить ваш IP со списком ваших адресов (некоторая деанонимизация) |
|
|
|
в биткоин-цепочке ну может быть единственное, о чем можно было бы просто ... указать на ошибку. Я за долгое время общения с людьми кажется начинаю читать мысли в даже не между строк, а в ошибках, допускаемых при объяснении своих идей. Я уловил главную идею того что хотел сказать ТС а то в чем он ошибся... дело десятое. Вопрос оптимизации доступа в БД - это вопрос хранения данных. Когда проблема даст о себе знать - будьте уверены, разработчики введут ряд ассоциативных таблиц с "продуманной индексацией" - и этого будет более чем достаточно. Но ТС пишет не об этом. Да, возможно он хотел это сказать, но кашу, которую он вывалил в 1м сообщении, надо разбирать тщательно.
Не путаем, индексы это копия данных в особой форме/структуре, а идея ТС относится к частному случаю реализации хранения... в терминах классических баз данных - это кластер. Сюрприз, бывают что индексы создаются только на одной таблице кластера - горячей, а на других, к примеру, на архивных, индексы не создаются. |
|
|
|
Между прочим отличная идея, к моменту, когда для работы кошелька скорости обычного устройства чтения будет не хватать, даже тупое разделение старые транзакции на HDD - новые транзакции на SSD позволит ускорить обработку блоков (особенно это актуально майнерам и пулам, так как вероятность словить орфан напрямую зависит от скорости обработки блока, секунда - незаметна, шесть секунд - +1% к orphan, минута - уже +10% к вероятности словить orphan).. p.s. но пока этого точно не требуется  и к этой идее нужно будет вернуться, когда в одном блоке будет типичным размещать сотни тысяч транзакций. |
|
|
|
|
electrum - кошелек bitcoin, python, т.е. работает почти везде (есть инструкции запуска под android, пока к сожалению не 1-click-install), без прогрузки блоков и без делегирования доступа к монетам кому-либо как в online кошельках...
|
|
|
|
|
Кошелек ведет проверку параллельно скачиванию блоков, и делает по этой причине эту проверку не оптимальным методом. Очевидно что 'скачать базу до текущего момента' у соседа и проверить внешним приложением (где то тут была невероятно быстрая opensource утилита для разного анализа blockchain) гораздо эффективнее для 'старта'.
RAID с чередованием (stripe) сам по себе очень плохо решает задачу оптимизации чтения (да и записи если честно), наиболее заметный прирост замечают на блочных/линейных операциях больших объемов, и очень мало какие контроллеры будут делать грамотное кеширование и распределение запросов по устройствам (с отдельными очередями IO на диск, например), я не слышал чтобы софтовые решения LVM или MDADM этим могли похвастаться.
Для базы данных blockchain необходимы высокие IOPS на рандомных запросах, прирост которых для raid0 'дай бог' логарифмический (от количества). И не забываем, raid часто читают весь блок (дефолтные настройки) данных секторов, на которые порезан логический раздел (для оптимизации read ahead) - для базы blockchain это размер должен быть сравним с размером блока (десятки килобайт) или даже транзакции (считанные байты) а значения по умолчанию для типичных рейдов - 2-4 мегабайта. Т.е. raid может даже ухудшить скорость работы.
p.s. у вас 16 GB оперативной памяти, этого спокойно хватит для однократной загрузки блоков, после этого данные перемещаются на обычный диск.
Если у вас linux и оперативной памяти меньше или сравнимо с размером базы blockchain (можно и 8GB обойтись) то можно разместить blockchain на отдельном разделе с ext4, и временно включить на нем journal_write_back (и в опциях монтирования), в этом случае скорость работы с базой будет сравнима со скоростью tmpfs (пока не закончится оперативная память, доступная для файлового кеша и буферов).
|
|
|
|
|
Дважды перечитал, не вижу собственно состава преступления.
Нет ли тут путаницы, 500милионов доход - это от 2% или полные обороты (маловато для 400-человек на 5 лет)?
|
|
|
|
|
Этот форум. Иногда пользователи консультируют бесплатно или за свободное вознаграждение.
|
|
|
|
Сейчас абсурдная ситуация, несколько месяцев назад она была ещё абсурдней. Была ситуация, когда весь биткоин "стоил" более 2 миллиардов долларов, но в то же время любой человек с десятком миллионов долларов, и с плохими намерениями, мог обрушить это всё, просто наделав асиков и завалив сеть. Это мог сделать Китаец, это мог сделать Кот, и, будем чесны, нам просто повезло что эти люди положительно настроены к биткоину. Но такая ситуация продолжаться не может: не может то, что потенциально уничтожается за 10 миллионов доларов, стоить несколько миллиардов. И вот здесь я только за рост мощности, чем больше мощность сети, тем лучше, суммарная мощность это фундамент для роста курса.
это все еще может сделать bitfury и co  |
|
|
|
отказались от oracle berkely db и сменили ее на LevelDB
Странные люди. Ведь в этой новой базе данных нет индексов. "This is not a SQL database. It does not have a relational data model, it does not support SQL queries, and it has no support for indexes" зачем тогда вообще нужен движок БД? Не проще ли просто запрограммировать кастомную структуру данных? почитайте про document oriented и key-value database, они представляют из себя один больший индекс по primary key (если брать аналогию из реляционных sql db) они предоставляют больше возможностей для ускорения чем более сложные - реляционные. Ну и это не отвечает на вопрос - как запустить систему на допустим трёх машинах параллельно для ускорения (типа distcc) потому что никому не надо было, я предложил вам способы решения... первый же результат в google: http://serverfault.com/questions/152985/emulate-a-smp-server-with-a-linux-cluster |
|
|
|
для каждого блока приходится делать сотни и тысячи запросов к текущей базе на каждую транзакцию Это же отлично! Это означает, что можно параллелить работу на сотни и тысячи ядер, не так ли? Если есть N машин с многоядерными процессорами, это поможет? Но всё равно непонятно, как получается много часов. на сколько я понимаю 0.8+ версии так и делают, используют сразу несколько процессоров для проверки загружаемой цепочки, и даже для ускорения работы отказались от oracle berkely db и сменили ее на LevelDB p.s. что то мне говорит, что необходимости в кластерной реализации кошелька возникнет еще не скоро, но на сколько я знаю для linux есть библиотеки, позволяющие эмулировать многоядерную машину в кластере для тех приложений, которые это еще не поддерживают, конечно же итоговая производительность упрется в скорость сети, но вы можете попробовать... |
|
|
|
@Balthazar
А win-клиента с новыми параметрами оформишь?
Пока сборок никаких новых нет. Я думаю, новый релиз будет опубликован после 20 июля, чтобы не создавать путаницу версий. т.е. майнить с текущей git версией нельзя? |
|
|
|
тупо уприрается в мощность проца.
Правильно ли я понимаю, что там можно большую часть работы по проверке цепочки (а не по майнингу) провести через видеокарту? сомнительно. Основная нагрузка скорее идет не на вычисление sha256 (мой процессор максимум считает на скорости ~20MH/s т.е. миллионы в секунду, а весь blockchain содержит всего несколько сотен тысяч блоков) а определение связности между транзакциями (проверка, что все монеты потрачены правильно), т.е. для каждого блока приходится делать сотни и тысячи запросов к текущей базе на каждую транзакцию. |
|
|
|
|
Show Posts
