что будет если посчитать блок с завышеным

[chabapok]

1. Допустим, владелец пула решит потроллить немножко, и поставит time в блоке в максимум. В 0xffffffff. Ну или в 7fffffff если там знаковые. И выйдет интересная штука - клиенты этот блок подхватят, как самый длинный в цепочке и - остановятся. Они будут пытаться скачать цепочку предыдущих блоков, а этих блоков физически не существует. Без ручного вмешательства весь биткоин остановится. Прийдется сатоши этот блок банить в коде клиента и всем придется обновлять клиентов. Но доверие к биткоину уже будет подорвано.

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

[rPman]

1. От time ничего не зависит! только от difficulty (а соответствие блока ему проверяется) так что обломсс
2. почитайте про double spend attack, направление ваших размышлений именно в этом направлении, для успешной атаки нужно обладать мощностями близкими к половине мощности всей сети

[yurm]

1. Файл main.cpp, метод bool CBlock::CheckBlock:

Code:

    // Check timestamp
    if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
        return state.Invalid(error("CheckBlock() : block timestamp too far in the future"));

Т.е. блоки с меткой времени больше чем на 2 часа в будущем будут отброшены.

2. Файл тот же, метод bool CBlock::AcceptBlock:

Code:

    if (hash != hashGenesisBlock) {
        map<uint256, CBlockIndex*>::iterator mi = mapBlockIndex.find(hashPrevBlock);
        if (mi == mapBlockIndex.end())
            return state.DoS(10, error("AcceptBlock() : prev block not found"));

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

[chabapok]

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

Хм. Ясно, спасибо. Значит я не правильно понял суть алгоритма поиска самого длинного пути в blockchain.
Надо изучать исходники, в интернете ни одной нормальной статьи нет.

[yurm]

Значит я не правильно понял суть алгоритма поиска самого длинного пути в blockchain.
Надо изучать исходники, в интернете ни одной нормальной статьи нет.

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

[sevendark]

Значит я не правильно понял суть алгоритма поиска самого длинного пути в blockchain.
Надо изучать исходники, в интернете ни одной нормальной статьи нет.

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

а жаль, новичку трудно понять

[chabapok]

Да нет, про наличие локальной копии базы - очевидно. Ее как-то трудно не заметить, учитывая ее размер и время ее скачки.

По моим прикидкам, эта база станет со временем довольно узким местом....

Я вот придумал еще 1 способ.

Итак, система устроена так, что выбирается самая длинна цепочка, при этом сложность подстраивается каждые сколько-то блоков.

Итак, если у нас есть приличная ферма, то мы можем сделать так:
1. подправляем код, так чтобы unixtime был не реальный, а тот, что мы нарисуем.
2. оттолкнувшись от момента, когда сложность была низкой, генерируем blockchain, при этом unixtime "мы рисуем" четко на каждый следующий блок так, чтобы сложность при пересчете не росла. Поскольку мы "рисуем" какое нам надо unixtime, то реально мы можем считать блок очень быстро - при минимальной-то сложности, да нынешними мощностями. Но unixtime ставить как будто каждый следующий блок сгенерировался через 10 минут. Так мы строим свой альтернативный blockchain до текущего времени. И дальше мы "догоняем" кол-во блоков до числа кратного 2016 минус 1 (чтобы длина нашего blockchain получилась больше официального). И отправляем свой blockchain в сеть, в надежде, что оно перекроет существующий как более длинная последовательность блоков.

То есть тут основная идея в том, что создать нынешними мощностями альтернативный blockchain легко, если мы при этом правильно "эмулируем" условия при которых сложность получается минимальной. При этом в среднем что у нас, что в официале будет 1 блок в 10 секунд, поэтому длина нашего blockchain и официального - сравнима.

ps.
Странно но в коде официального клиента числа 2016 нет, хотя пишут что сложность подстраивается каждые 2016 блоков. Есть такое:
if ((pindexNew->nHeight % 20160) == 0 || (!fIsInitialDownload && (pindexNew->nHeight % 144) == 0))

но там дальше по коду не похоже на пересчет сложности.

[yurm]

Не получится. Во-первых, "длина" цепочки считается с учётом сложности, т.е. каждый блок входит в эту длину с весовым коэффициентом, равным своей сложности (конкретно сейчас лень искать в коде, но если захотите - найду). В описанном варианте вес каждого блока будет равен 1, в реальной же цепочке можете прикинуть сами по историческим данным. Во-вторых, difficulty увеличивается из-за того, что очередные 2016 блоков посчитаны быстрее, чем за 14 суток. Чтобы поддерживать одинаковую сложность, пришлось бы выпускать 2016 блоков строго раз в 2 недели; реальная же цепочка считается немного быстрее (например, уполовинивание награды до 25 btc произошло в ноябре 2012, хотя полных 4 лет с момента запуска системы - январь 2009 - не прошло). Т.е., даже если бы весовых коэффициентов не было, вы не смогли бы догнать реальную цепочку, у вас всегда будет меньше блоков (это можно было провернуть, пока сложность равнялась 1 - это минимальное её значение, прописанное в алгоритме, реальная же сложность поначалу была даже ниже 1).

UPD. 2016 находится в неявном виде в main.cpp

Code:

static const int64 nTargetTimespan = 14 * 24 * 60 * 60; // two weeks
static const int64 nTargetSpacing = 10 * 60;
static const int64 nInterval = nTargetTimespan / nTargetSpacing;

nInterval - это оно.

[chabapok]

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

Больше пока безумных идей нет.

откуда вы так хорошо это знаете? Вы специально изучали код официального клиента?

[yurm]

Да нет, просто некоторые статьи в https://en.bitcoin.it/wiki/Category:Technical читал, иногда по нескольку раз. А код клиента начал изучать только сейчас, решил, так сказать, перейти от слов к делу (а то мы частенько поминаем опенсорс всуе - не читая при этом исходников)