Я думаю никто не будет на этом заморачиваться 
Попробуй выключить защиту от dust spam и увидишь, насколько неправ. 
Topic: Мега фейл 10 марта с разделением версий 0.7 0.8 (Read 3251 times)
А какой практический смысл ддосить пул?
чтобы не выпендривался и не позволял клиентам экономить на комиссиях. Комиссии уже дают +1% к награде майнерам (а значит пулам, некоторые забирают ее себе, например PPS пулы в расчетах комиссии не учитывают по определению).p.s. ожидаю в будущем появления дополнительной услуги пулов майнинга - вы даете им id транзакции а они ее проводят без комиссии, за отдельную плату (абонентка та же) а те кто генерируют такие транзакции своим клиентам плюшки.
Придут асики попробую чисто в академических целях на своем пуле сделаю.
p.s. ожидаю в будущем появления дополнительной услуги пулов майнинга - вы даете им id транзакции а они ее проводят без комиссии, за отдельную плату
Похоже, что эти всякие микроплатящие типа www.bitvisitor.com так давно работают А какой практический смысл ддосить пул?
чтобы не выпендривался и не позволял клиентам экономить на комиссиях. Комиссии уже дают +1% к награде майнерам (а значит пулам, некоторые забирают ее себе, например PPS пулы в расчетах комиссии не учитывают по определению).p.s. ожидаю в будущем появления дополнительной услуги пулов майнинга - вы даете им id транзакции а они ее проводят без комиссии, за отдельную плату (абонентка та же) а те кто генерируют такие транзакции своим клиентам плюшки.
А какой практический смысл ддосить пул?
Никак не поможет, пул заддосят транзакциями по 0.00000001 бтц.
Насколько я знаю, пока ничего с этим делать не планируется. Более того, 0.8.2 ужесточает правила выбора транзакций, установленные по умолчанию.
Насколько глупа моя мысль. Сделать пул который обрабатывает только транзакции с минимальным либо указанными без комиссии. Поможет ли это в быстрой обработки таких транзакций? Чисто теоретически. Чисто гипотетически.
Насколько я знаю, пока ничего с этим делать не планируется. Более того, 0.8.2 ужесточает правила выбора транзакций, установленные по умолчанию.
Balthazar, вы вроде общаетесь в "высших кругах" http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/05
что с этим:
http://blockchain.info/ru/unconfirmed-transactions
будут делать?
если 2-3 мес назад висящий мегабайт пугал, то щас вообще жесть!
что с этим:
http://blockchain.info/ru/unconfirmed-transactions
будут делать?
если 2-3 мес назад висящий мегабайт пугал, то щас вообще жесть!
Оно задется опцией командной строки.
Эта опция нужна для размера генерируемого именно этим кошельком блока. Вполне логично, что майнеры сами могут решать какие блоки им генерировать. Но если они уже сгенерировали блок, и он соответствует всем правилам, то остальные кошельки обязаны его принять, независимо от их настроек. А кошелек версии 0.7 отбросил правильный блок, просто потому что не смог записать его в базу.
На самом деле, все немножко сложнее. Баг проявляется не всегда, а в момент reorganize. И связан он не с самим по себе bdb, а с его настройками при инициализации. Как известно, клиент вытаскивает транзакции из отклоненных блоков в memorypool. Так вот, происходил упор в лимит количества блокировок (lk_max_locks ) в случае, если в отклоняемой цепочке блоков содержалось достаточно транзакций для этого. Code:
"\n" + _("Block creation options:") + "\n" +
" -blockminsize= " + _("Set minimum block size in bytes (default: 0)") + "\n" +
" -blockmaxsize= " + _("Set maximum block size in bytes (default: 250000)") + "\n" +
" -blockprioritysize= " + _("Set maximum size of high-priority/low-fee transactions in bytes (default: 27000)") + "\n" +
Фикс довольно прост в реализации:
https://github.com/CryptoManiac/novacoin/commit/16e1262471dba899f3e9251b485abec219aec844
И на данный момент доступен для всех актуальных веток клиента.
arruah, что Вы, как вообще можно назвать Bitcoin говнокодом, даже и в мыслях не было, естесственно нет. Концепция Bitcoin - гениальна. Я говорил лишь о фрагментах "говнокода", которые есть в исходниках. Не верите - убедитесь сами.
Называть говнокодом биткоин мягко говоря опрометчиво.
somenick я не хотел Вас оскорбить, согласившись с rPman в том, что действительно была ошибка и все ошибаются тем более что насколько я понял, кодируют "на перед и за бесплатно". 
Да, действительно фейл, самое противное что создатели заложили туда алерты, в моем понимании, у Гэвина (и у кого еще там глав-ключи) на стене должна в спальне красный фонарь закрутиться и заморгать 
когда половина клиентов отклонила блок и автоматом сработал алерт (они похоже его в ручную только разослать могут).
Да, действительно фейл, самое противное что создатели заложили туда алерты, в моем понимании, у Гэвина (и у кого еще там глав-ключи) на стене должна в спальне красный фонарь закрутиться и заморгать когда половина клиентов отклонила блок и автоматом сработал алерт (они похоже его в ручную только разослать могут).
Оно задется опцией командной строки.
Эта опция нужна для размера генерируемого именно этим кошельком блока. Вполне логично, что майнеры сами могут решать какие блоки им генерировать. Но если они уже сгенерировали блок, и он соответствует всем правилам, то остальные кошельки обязаны его принять, независимо от их настроек. А кошелек версии 0.7 отбросил правильный блок, просто потому что не смог записать его в базу.
Code:
"\n" + _("Block creation options:") + "\n" +
" -blockminsize= " + _("Set minimum block size in bytes (default: 0)") + "\n" +
" -blockmaxsize= " + _("Set maximum block size in bytes (default: 250000)") + "\n" +
" -blockprioritysize= " + _("Set maximum size of high-priority/low-fee transactions in bytes (default: 27000)") + "\n" +
Ситуация довольно проста.
Есть описанный протокол. В нем нет ограничений на количество и размер транзакций. Все клиенты должны придерживаться этого протокола.
Есть описанный протокол. В нем нет ограничений на количество и размер транзакций. Все клиенты должны придерживаться этого протокола.
А как тогда понимать фразу, которая сейчас висит в новостях:
Mining on 0.8 is OK, but you should not increase the target block size from the default. ?
Получается, что в клиенте версии 0.8 ограничение на размер блока есть, но владельцы пулов его увеличили ?
Именно. Считаю, что в протоколе ограничения, не обусловненные какими-то фундаментальными причинами (например, разрядностью соответствующего поля), не нужны. Считаю, что ситуация, когда блок с 1700 (например) транзакциями верен, а с 1701 транзакией - нет, является бредовой. Клиент должен обрабатывать любое количество. Как он будет это делать - это уже работа программистов. И то, что они не справились - действительно фейл. Но фейл именно в клиенте, а не в протоколе. В конце концов, сатоши-клиент - не последняя инстанция, и в сети теоретически может быть куча разных клиентов, которые будут хранить свои данные, как им вздумается. Поэтому ставить какое-то ограничение на протокол только потому что 0.7 версия сатоши-клиента не может чего-то там обработать, т.к. кому-то было лень прочитать документацию на BDB во время проектирования - считаю глупостью. Надо фиксить баг и заставлять всех переходить на новый клиент, а старый выкинуть, как несоответствующий протоколу. А тесты - понятно, что нужны, в том числе и на соответствие протоколу. И понятно, что 0.7 не просто должна была отбросить этот блок, а кричать "ай-ай-ай не могу сохранить в базу, ахтунг!!! голактеко опасносте!!!!11!11".
giv
вы считаете не нужны магичесие константы ?
может тогда их нужно сделать большими ? и опять же проверить работоспособность.
ограничение BDB
ЭТО МЕГА ФЕЙЛ
у них при любой ошибке, программа возвращала что блок не принят, а должен возвращать внутренюю ошибку в записью в лог об ошибке и отсылке разработчику письма об ошибке с пометкой срочно.
ps остальным не отвечаю ибо некомпетентны
вы считаете не нужны магичесие константы ?
может тогда их нужно сделать большими ? и опять же проверить работоспособность.
ограничение BDB
ЭТО МЕГА ФЕЙЛ
у них при любой ошибке, программа возвращала что блок не принят, а должен возвращать внутренюю ошибку в записью в лог об ошибке и отсылке разработчику письма об ошибке с пометкой срочно.
ps остальным не отвечаю ибо некомпетентны
а вы так не считаете ?
Ситуация довольно проста.Есть описанный протокол. В нем нет ограничений на количество и размер транзакций. Все клиенты должны придерживаться этого протокола. Но выясняется, что в версии 0.7 было скрытое ограничение на количество транзакций в блоке, о котором даже не знали сами разработчики. Оно было связано с каким-то внутренним ограничением BDB. Налицо несоответствие протокола и клиента. Если бы это был сторонний клиент, все бы сказали: "сами виноваты, что пользовались клиентом, не соответствующим протоколу", но ведь это "официальный" клиент. Выхода ровно два: подогнать протокол под кривой клиент или пофиксить клиент. Вы предлагаете подогнать протокол. Думаю, найдутся люди, которые с вами не согласятся. Лично я против внесения в протокол каких-то магических констант и непонятных ограничений. Я считаю, что правильный путь - это пофиксить клиент, т.е. заставить всех обновится до 0.8. Кстати, Гэвин предлагал именно этот путь. http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12
Jump to: