NovaCoin (scrypt PoW + PoS hybrid)

[penek]

Внимание: на домене novaco.in ведутся внеплановые работы по обновлению ОС...

Ожидаемое время работ: 4 часа...

[1714738621]

1714738621

[1714738621]

1714738621

[1714738621]

1714738621

[bee7]

Транзакции будут иметь разное время (совпадение времен хоть и вероятно, но мало). Блоки будут иметь разный хеш (время создания, набор транзакций и т.д).

Это не имеет никакого значения.

Этот комментарий относился к тому, что транзакции будут одинаковыми. То, что это не имеет значения, я знаю.

Предусмотренное явление, из двух блоков выживет тот, который первым получит потомка.

Я всё ж найду время посмотреть, почему тот форк, о котором я говорил, возник.

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

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

[Balthazar]

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

Создав один kernel, нельзя создать ещё один равноценный с использованием того же набора инпутов. Точнее можно, но только в течение времени, которое в среднем требуется для нахождения ими блока. С помощью одного kernel можно создать сколько угодно блоков, но все они будут конкурентами друг другу, т.к. нельзя увеличить высоту более чем на 1 с использованием одного kernel.

Но если этих "гонок" можно избежать и не позволять таким форкам вообще возникать, то почему бы этого не сделать?

Тут все просто. Во-первых, кроме nBits в заголовке PoS блоков нет ничего, чему можно доверять без дополнительных проверок. Во-вторых, клиент ведет историю использованных kernel'ов, и при совпадении не принимает блок-конкурент, если у него нет потомков. Если есть потомки - пожалуйста, если нет то воспринимается как флуд и отклоняется.

[bee7]

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

Создав один kernel, нельзя создать ещё один равноценный с использованием того же набора инпутов. Точнее можно, но только в течение времени, которое в среднем требуется для нахождения ими блока. С помощью одного kernel можно создать сколько угодно блоков, но все они будут конкурентами друг другу, т.к. нельзя увеличить высоту более чем на 1 с использованием одного kernel.

Именно о осоздании двух блоков высоты N с использованием одного и того же ядра речь и идет. Этого достаточно, что бы создать развилку. Далее идет соревнование двух форков. При желании (а желальцев с мощностями и неуёмным энтузиазмом тут хватает: BCX и прочие) можно таким образом заставить часть сети копать форк. Рано или поздно ситуация будет разрулена, конечно, но скорее всего людьми, которые выкинули на ветер некоторое количество электричества, оказавшись на форке. После чего они начинают распространять вонь на форумах: "аааа, монета говно, девелопер пид*р" и т.д., а биржы начинают морозить торги, что тоже не прибавляет к ситуации стабильности. Если можно такие случаи просто исключить на уровне протокола, то почему бы этого не сделать?

Но если этих "гонок" можно избежать и не позволять таким форкам вообще возникать, то почему бы этого не сделать?

Тут все просто. Во-первых, кроме nBits в заголовке PoS блоков нет ничего, чему можно доверять без дополнительных проверок.

Проверка нужна не всегда, а только при совпадении траста.

Во-вторых, клиент ведет историю использованных kernel'ов, и при совпадении не принимает блок-конкурент, если у него нет потомков. Если есть потомки - пожалуйста, если нет то воспринимается как флуд и отклоняется.

Вы видимо вот это имеете ввиду:

Code:

    // ppcoin: check proof-of-stake
    // Limited duplicity on stake: prevents block flood attack
    // Duplicate stake allowed only when there is orphan child block
    if (pblock->IsProofOfStake() && setStakeSeen.count(pblock->GetProofOfStake()) && !mapOrphanBlocksByPrev.count(hash) && !Checkpoints::WantedByPendingSyncCheckpoint(hash))
        return error("ProcessBlock() : duplicate proof-of-stake (%s, %d) for block %s", pblock->GetProofOfStake().first.ToString().c_str(), pblock->GetProofOfStake().second, hash.ToString().c_str());

Чудесно. Две ноды одновременно получают два разных блока высоты N, сделанных на одном и том же ядре. У каждой из них setStakeSeen.count() ноль, они принимают блоки, каждая свой, и делают их bestChain. Дальше они получают уведомления, о том, что существует еще блок высоты N, запрашивают его и просто выкидывают на проверке выше, и продолжают быть уверенными, что bestChain это тот, который их...

Трендеть не мешки ворочать, я вернусь к разговору, когда смоделирую ситуацию.

[mall]

тишина, ничего не происходит...

[Balthazar]

Чудесно. Две ноды одновременно получают два разных блока высоты N, сделанных на одном и том же ядре. У каждой из них setStakeSeen.count() ноль, они принимают блоки, каждая свой, и делают их bestChain. Дальше они получают уведомления, о том, что существует еще блок высоты N, запрашивают его и просто выкидывают на проверке выше, и продолжают быть уверенными, что bestChain это тот, который их...

Ну да, нода будет считать "свой" блок последним, до тех пор пока кто-то для этой или конкурентной цепи не сгенерирует потомок. В тех же лайтах подобное происходит десятки раз в день.

Если можно такие случаи просто исключить на уровне протокола, то почему бы этого не сделать?

Проверка нужна не всегда, а только при совпадении траста.

Как вы себе представляете подобную проверку? Без использования централизованных методов это выглядит, как поднимание самого себя в воздухе за волосы. Децентрализованные чекпоинты, правда, могли бы решить вопрос.

Далее идет соревнование двух форков. При желании (а желальцев с мощностями и неуёмным энтузиазмом тут хватает: BCX и прочие) можно таким образом заставить часть сети копать форк.

В NXT граждане некоторые уже занимались подобным, тут же такая деятельность дается намного труднее и затратнее. С учетом 500-блокого окна, псевдослучайного модификатора и неравноценности PoW/PoS блоков остается лишь пожелать удачи энтузиастам.

[bee7]

Если можно такие случаи просто исключить на уровне протокола, то почему бы этого не сделать?

Проверка нужна не всегда, а только при совпадении траста.

Как вы себе представляете подобную проверку? Без использования централизованных методов это выглядит, как поднимание самого себя в воздухе за волосы. Децентрализованные чекпоинты, правда, могли бы решить вопрос.

Зачем такие сложности? На момент вызова CBlock::SetBestChain, hashProofOfStake обрабатываемого блока уже посчитан. Следовательно можно так:

Code:

--- a/src/main.cpp
+++ b/src/main.cpp
@@ -2068,8 +2068,20 @@ bool CBlock::AddToBlockIndex(unsigned int nFile, unsigned int nBlockPos)
 
     // New best
     if (pindexNew->nChainTrust > nBestChainTrust)
+    {
         if (!SetBestChain(txdb, pindexNew))
             return false;
+    }
+    else
+    if (pindexNew->nChainTrust == nBestChainTrust)
+    {
+        // Proof-of-stake always beats proof-of-work block; the smaller proof wins otherwise
+        if (pindexNew->IsPoofOfStake() > pindexBest->IsPoofOfStake() || 
+                (pindexNew->IsPoofOfStake() ? pindexNew->hashProofOfStake < pindexBest->hashProofOfStake:
+                    hash < hashBestChain))
+            if (!SetBestChain(txdb, pindexNew))
+                return false;
+    }
 
     if (pindexNew == pindexBest)
     {

При этом не важно, одно и тоже ядро использовалось или разные, так как  любые два конкурентных PoS блока одной высоты в точке "развилки", будут иметь один и тот же траст: nBits - одинаковые и вся предистория - тоже. Это укоротит жизнь форка до одного блока, а не отложит решение вопроса до следующего. Но это дело скорее вкуса. По мне - чем раньше сеть придет к согласию - тем лучше.

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

[bee7]

В тех же лайтах подобное происходит десятки раз в день.

И тем не менее, лайты при совпадении эквивалента "траста", т.е. nChainWork, делают дополнитеьное сравнение хешей блоков, что бы более однозначно сказать, какой из блоков выигрывает:

Code:

struct CBlockIndexWorkComparator
{
    bool operator()(CBlockIndex *pa, CBlockIndex *pb) {
        if (pa->nChainWork > pb->nChainWork) return false;
        if (pa->nChainWork < pb->nChainWork) return true;

        if (pa->GetBlockHash() < pb->GetBlockHash()) return false;
        if (pa->GetBlockHash() > pb->GetBlockHash()) return true;

        return false; // identical blocks
    }
};

[WhiteShum]

Россия внезапно развенчала миф об анонимности криптовалют  

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

даже не знаю почему, но сразу вспомнил http://ria.ru/world/20140604/1010635874.html думаю намек понятен 

Echoes
Чем тебе вебмани не угодили, если в целом?

[bee7]

Россия внезапно развенчала миф об анонимности криптовалют  

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

даже не знаю почему, но сразу вспомнил http://ria.ru/world/20140604/1010635874.html думаю намек понятен 

Статя про ИИ, распознающий сарказм напомнила мне попытки перевести на английский "Да нет, наверное" при помощи гугл-транслейта

[WhiteShum]

WhiteShum кстати, изначально они ничего не требовали -- ввод/вывод прекрасно работал с анонимными аккаунтами. Потом сделали задержку в 24/48 часов для тех кто не хочет называть своё имя. Не помогло -- стали требовать паспортные данные, а иначе не дают делать ввод/вывод биткойнов.

Это называется соблюдение законов и ограничение компании от юридических рисков по рекомендации юр отдела. Тот же Гугл не стал создавать криптовалюту по настоятельной рекомендации юр отдела.

[Echoes]

WhiteShum кстати, изначально они ничего не требовали -- ввод/вывод прекрасно работал с анонимными аккаунтами. Потом сделали задержку в 24/48 часов для тех кто не хочет называть своё имя. Не помогло -- стали требовать паспортные данные, а иначе не дают делать ввод/вывод биткойнов.

Это называется соблюдение законов и ограничение компании от юридических рисков по рекомендации юр отдела. Тот же Гугл не стал создавать криптовалюту по настоятельной рекомендации юр отдела.

Однако другие системы позволяют выводить хоть что-то без верификации, оставаясь в правовом поле. Я не от кого не прячусь, просто далеко не всегда есть возможность ее пройти.
Ещё от их интерфейса у меня зубы ноют и кровавые слёзы наворачиваются, я банально ничего не могу найти на их сайте.

[penek]

"Характерный" ПоС на нормальной сложности при наличии "высокой" вероятности

[Balthazar]

В тех же лайтах подобное происходит десятки раз в день.

И тем не менее, лайты при совпадении эквивалента "траста", т.е. nChainWork, делают дополнитеьное сравнение хешей блоков, что бы более однозначно сказать, какой из блоков выигрывает:

Code:

struct CBlockIndexWorkComparator
{
    bool operator()(CBlockIndex *pa, CBlockIndex *pb) {
        if (pa->nChainWork > pb->nChainWork) return false;
        if (pa->nChainWork < pb->nChainWork) return true;

        if (pa->GetBlockHash() < pb->GetBlockHash()) return false;
        if (pa->GetBlockHash() > pb->GetBlockHash()) return true;

        return false; // identical blocks
    }
};

Эта проверка перекочевала из Bitcoin 0.8 сравнительно недавно.

Вообще же, хэш proof-of-stake блока не имеет какой-либо ценности, да и не должен. Добавление подобной проверки позволит юзеру создавать блоки-близнецы с разным приоритетом, а это уже будет на самом деле уязвимостью.

[Echoes]

"Характерный" ПоС на нормальной сложности при наличии "высокой" вероятности

Раз в год и палка стреляет. 
Хотя, на месте владельца адреса, с п2пула я все бы подклеивал понемногу, часть монет может "залежаться" на очень долгий срок. Ну это если его вообще интересует пос майнинг Некоторым на оптимизации вообще фиолетово.

[aclon]

господа использующие всякие кубиборды, как думаете нормально будет использовать его в качестве тонкого клиента? по  крайней мере в качестве ученических рабочих мест кабинета информатики а в перспективе и все остальные административно-бумажные компы им заменить.
а то что-то специализированные тонкие по цене от 12к рублей при бюджетном системнике  в 10к наводят на вопрос что где меня наё... обманывают

[Balthazar]

Вполне может быть и толстым, а не то что тонким. Во всяком случае, дистрибутивный libreoffice бегает вполне сносно.

[penek]

господа использующие всякие кубиборды, как думаете нормально будет использовать его в качестве тонкого клиента? по  крайней мере в качестве ученических рабочих мест кабинета информатики а в перспективе и все остальные административно-бумажные компы им заменить.
а то что-то специализированные тонкие по цене от 12к рублей при бюджетном системнике  в 10к наводят на вопрос что где меня наё... обманывают

в какчестве тонких -- сойдёт, только тестировать надо, зависит от того, какой софт у тебя будет поверх...

а "специализированые" тонкие клиенты дороже (если не рассматриват Неттопы по $150-250) из-за:
1) железа, содержащегося в нём ("мобильное" железо часто дороже десктопного)
2) зачастую вложенные лицензии для подключения к серверам, обслуживающими "тонкую" инфраструктуру

мне на неттопе пришлось в своё время поднять и потестировать "тонкий клиент" с загрузкой по сети какого-то кастрированного линя и выходом на RDP/VNC подключение...
думаю что с кубиками это тоже будет не сложно, тем более что там есть куда положить изначально систему или накостылись что-то с EEPROM...

[bee7]

В тех же лайтах подобное происходит десятки раз в день.

И тем не менее, лайты при совпадении эквивалента "траста", т.е. nChainWork, делают дополнитеьное сравнение хешей блоков, что бы более однозначно сказать, какой из блоков выигрывает:

Code:

struct CBlockIndexWorkComparator
{
    bool operator()(CBlockIndex *pa, CBlockIndex *pb) {
        if (pa->nChainWork > pb->nChainWork) return false;
        if (pa->nChainWork < pb->nChainWork) return true;

        if (pa->GetBlockHash() < pb->GetBlockHash()) return false;
        if (pa->GetBlockHash() > pb->GetBlockHash()) return true;

        return false; // identical blocks
    }
};

Эта проверка перекочевала из Bitcoin 0.8 сравнительно недавно.

Вообще же, хэш proof-of-stake блока не имеет какой-либо ценности, да и не должен. Добавление подобной проверки позволит юзеру создавать блоки-близнецы с разным приоритетом, а это уже будет на самом деле уязвимостью.

Думаю, что лайтам следовало бы тут сравнивать не хеш блока, а сам PoW, а то что у них получилось - результат просто кат-н-пэйст. Чем уязвим вариант со сравнением hashProofOfStake в нашем случае? Чем он более уязвим, чем генерация двух блоков на одном ядре, опубликование одной версии и удержание другой с последующим майном потомка для удержанного и публикацией этой "сторонней" цепочки по нахождению такового?

[Balthazar]

В тех же лайтах подобное происходит десятки раз в день.

И тем не менее, лайты при совпадении эквивалента "траста", т.е. nChainWork, делают дополнитеьное сравнение хешей блоков, что бы более однозначно сказать, какой из блоков выигрывает:

Code:

struct CBlockIndexWorkComparator
{
    bool operator()(CBlockIndex *pa, CBlockIndex *pb) {
        if (pa->nChainWork > pb->nChainWork) return false;
        if (pa->nChainWork < pb->nChainWork) return true;

        if (pa->GetBlockHash() < pb->GetBlockHash()) return false;
        if (pa->GetBlockHash() > pb->GetBlockHash()) return true;

        return false; // identical blocks
    }
};

Эта проверка перекочевала из Bitcoin 0.8 сравнительно недавно.

Вообще же, хэш proof-of-stake блока не имеет какой-либо ценности, да и не должен. Добавление подобной проверки позволит юзеру создавать блоки-близнецы с разным приоритетом, а это уже будет на самом деле уязвимостью.

Думаю, что лайтам следовало бы тут сравнивать не хеш блока, а сам PoW, а то что у них получилось - результат просто кат-н-пэйст. Чем уязвим вариант со сравнением hashProofOfStake в нашем случае? Чем он более уязвим, чем генерация двух блоков на одном ядре, опубликование одной версии и удержание другой с последующим майном потомка для удержанного и публикацией этой "сторонней" цепочки по нахождению такового?

Сравнение hashProofOfStake ничего не даст, потому что это хэш кернела и у разных блоков с одним кернелом он будет одинаковым.  Сравнение же хэшей блоков даст лишь одно - возможность перезаписывать собственные блоки, путем создания блока с "лучшим" хэшем. Вообще, лайтов это тоже касалось бы, если бы не тот факт что PoW и хэш считаются от заголовка.