Comments 13
Хм, если пчела живет неделю, а стоит 1.0, при этом максимум блоков, которые произведут пчелы за эту неделю, равен числу PoW-блоков за неделю, деленному на emaDesiredSpacing (т.е. плюс-минус константа), то мы имеем этакую лотерею с бесконечным выводом токенов из блокчейна, за награду, которая берется, как я понимаю, «из ниоткуда» (т.е. пчелы имеют свою, независимую базу для добычи токенов, размером с недобытый остаток на момент запуска первой пчелы, деленный на spacing), выдается одному «счастливчику» за ролл (а что если две разные пчелы сгенерируют хэши сложностью ниже beeHashTarget — какую награду получат пчеловоды, полную или разделенную?), а также может вообще никому не достаться. Любопытная схема, в ней, если пчел меньше какого-то конкретного порога, выгодно создать пчелу, потеряв сейчас, но потенциально получить больше, чем потерял.
Однако возникает интересный вопрос — а как определить, что адрес, куда запендюрили комиссию на создание пчелы, таки тупиковый? Кроме того, можно ли на тот же адрес послать ещё комиссию, «оживив» пчелу из предыдущей итерации (предположим, время жизни предыдущей итерации уже истекло)? Если да, то потенциально возможна лазейка, когда кто-то сгенерирует такой ключ, которому будет соответствовать валидный адрес для пчел, и будет эту комиссию возвращать себе на счет (что может быть слишком невероятным, да и особо много не даст, но если заморачиваться, нужно почитать и этот шанс). А также не вижу, как пчелы решают проблему про противодействие 51% майнеров — намайнивший следующий блок в альтветке точно так же просчитает всех активных пчел, кому-то забашляет, если его пчела добыла блок, и преспокойно дальше будет майнить альтветку, тратя бабки в основной, а потом её дропнет как слишком короткую.
Однако возникает интересный вопрос — а как определить, что адрес, куда запендюрили комиссию на создание пчелы, таки тупиковый? Кроме того, можно ли на тот же адрес послать ещё комиссию, «оживив» пчелу из предыдущей итерации (предположим, время жизни предыдущей итерации уже истекло)? Если да, то потенциально возможна лазейка, когда кто-то сгенерирует такой ключ, которому будет соответствовать валидный адрес для пчел, и будет эту комиссию возвращать себе на счет (что может быть слишком невероятным, да и особо много не даст, но если заморачиваться, нужно почитать и этот шанс). А также не вижу, как пчелы решают проблему про противодействие 51% майнеров — намайнивший следующий блок в альтветке точно так же просчитает всех активных пчел, кому-то забашляет, если его пчела добыла блок, и преспокойно дальше будет майнить альтветку, тратя бабки в основной, а потом её дропнет как слишком короткую.
не вижу, как пчелы решают проблему про противодействие 51% майнеров — намайнивший следующий блок в альтветке точно так же просчитает всех активных пчел, кому-то забашляетВознаграждение выплачивает не майнер, а пчела сама себе, когда получает возможность создать блок. Чтобы подписать такой блок, нужно знать приватный ключ второго адреса из транзакции создания пчелы, т.е. нужно быть её создателем.
Получается, что владелец 51% мощности должен свои сгенерированные блоки разбавлять «пчелиными». Для этого нужно нагенерить очень много своих пчёл, чтобы они получали вознаграждение вместе с PoW.
Что, во-первых, требует траты средств (которая не окупится, потому что только одна пчела получает вознаграждение, увеличивать число пчёл выгодно только до какого-то предела).
А во-вторых, из-за «периода созревания», потребует выкидывания пчелиных транзакций в публичный блокчейн за какое время заранее, что наведёт всех на мысль, что кто-то готовит атаку 51%. Не получится тихо майнить альт. цепочку, а потом выкинуть её в сеть.
То есть майнер, чьи пчелы, должен уметь оперативно отследить создание нового блока в сети, а дальше кто первым проверил своих пчел, тот и папка? Тогда случай, когда две пчелы пролезают под beeHashTarget, порождает сразу две ветки, так как каждая пчела имеет возможность создать новый блок над последним намайненным блоком. Теперь вопрос — как сеть будет решать, какую из двух голов майнить? Они обе фактически равноправны, обе валидны, только бенефициары у них разные. При этом атакующий по 51% в такой ситуации получает возможность сделать виртуальный double spend — создать две разных пчелы, по одной в каждый блок, заплатив за них одну цену (так как одна из двух пчел будет создана, а вторая нет). То есть атаку 51% все равно можно провести, но она растянется на две недели, при этом трафик создания пчел будет нормально замешан в нормальный трафик всех остальных. Реакцией сети в этом случае будет денежная гонка за пчелами, и порешает опять количество этих самых денег. То есть получается, что пчелы решают проблему внезапной атаки 51%, но через добавление PoS-компонента и отсрочки на его применение. Маловато будет!
Тут можно предложить 2 решения:
1) Цепочка разделяется и далее выигрывает самая длинная (как и при одновременном нахождении майнерами PoW-блоков). PoW-майнеры будут майнить какую-то одну цепочку, она и победить в итоге.
2) Выбирается более «точная» пчела, т.е. такая, у которой beeHash ближе к beeHashTarget. Тогда коллизий не будет.
1) Цепочка разделяется и далее выигрывает самая длинная (как и при одновременном нахождении майнерами PoW-блоков). PoW-майнеры будут майнить какую-то одну цепочку, она и победить в итоге.
2) Выбирается более «точная» пчела, т.е. такая, у которой beeHash ближе к beeHashTarget. Тогда коллизий не будет.
Реакцией сети в этом случае будет денежная гонка за пчелами, и порешает опять количество этих самых денегНет смысла слишком много вкладывать в пчёл, потому что профит он них будет ниже прибыли. Но как только все перестают вкладываться в пчёл, профит пчелы возрастает. Такая вот саморегуляция.
Нет смысла слишком много вкладывать в пчёл, потому что профит он них будет ниже прибыли. Но как только все перестают вкладываться в пчёл, профит пчелы возрастает. Такая вот саморегуляция.
Но тогда атака на пчел будет вполне себе незаметной, причем она может предшествовать атаке на 51% мощностей — просто генерируешь пчел чуть больше, чем отобьется при нормальном майнинге, остальные будут выходить из пчел и ты в какой-то период получаешь 51% пчел. Причем эта атака, как мне кажется, куда менее затратная, чем 51% мощности сети.
Равновесное состояние — это когда затраты на пчёл равны вознаграждению.
То есть, нужно вложить столько монет, сколько получают все майнеры суммарно за «период созревания».
Появляется необходимость тратить криптовалюту.
У кого-то может случайно оказаться 51% мощности (особенно если прийти на какой-то шиткойн с большой монеты), но не оказаться средств на пчёл.
То есть, нужно вложить столько монет, сколько получают все майнеры суммарно за «период созревания».
Появляется необходимость тратить криптовалюту.
У кого-то может случайно оказаться 51% мощности (особенно если прийти на какой-то шиткойн с большой монеты), но не оказаться средств на пчёл.
UFO just landed and posted this here
Так это же классический Proof-of-Burn. Понапридумывали каких-то пчёл, чтобы всех запутать?
Да, похоже что так.
Интересно, а если в цепочку добавлять такой блок, который уничтожает (пересылает на заведомо недоступный адрес) наибольшее количество монет, какие будут недостатки у такого способа?
Интересно, а если в цепочку добавлять такой блок, который уничтожает (пересылает на заведомо недоступный адрес) наибольшее количество монет, какие будут недостатки у такого способа?
Пересылает из чьего кошелька?
Никто не захочет тратить впустую свои монеты.
Никто не захочет тратить впустую свои монеты.
Из своего, а так же из комиссий транзакций, которые включаются в блок. Возможно такой вариант позволил бы избежать гонки PoW, и, следовательно, растрат которые из нее вытекают.
По аналогии с атакой 51% при таком подходе будет возможна атака «перебивания размера уничтоженных монет». Но ведь есть же способы защиты от этого, например, считать транзакцию завершенной только после некоторого количества подтверждений.
Sign up to leave a comment.
Хайв-майнинг: новейший вариант защиты PoW-блокчейна от «атаки 51%»