Topic: Асикостойкий алгоритм PoW - page 4. (Read 6109 times)
Причем у меня на уровне стереотипов отложилось, что майнер это тот кто не прикасается к деньгам в блоке.
Повторяюсь что в криптокоде я ноль.
Повторяюсь что в криптокоде я ноль.
Я не раз и не два уже говорил, что существует омонимическая проблема.
Майнерами называют и владельцев асиков, и администраторов пула.
Из-за этого происходят постоянные недопонимания сути процесса.
Это разные сущности с отличающимися интересами, правами и обязанностями.
И вот дальше мне абсолютно нихрена непонятно было как наличие двух вышеуказанных
полей обеспечивает знание майнером приватного ключа соответствующего коинбейз
транзакции и что это вообще такое.
Ну из твоих слов это понятно вроде.полей обеспечивает знание майнером приватного ключа соответствующего коинбейз
транзакции и что это вообще такое.
Если я майню эту валюту - я не могу поставить в coinbase-транзакции адрес Сатоши Накамото
1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa потому что я не знаю его приватный ключ, им надо
еще что-то подписать будет, а у меня нет этой возможности
Повторяюсь что в криптокоде я ноль.
Я просто додуматься не мог, что можно тупо на уровне консенсус правила установить гоп-стоп, типа: "пул - отдавай кошелек блин, бысто, иначе блоки не валидные, твагь бысто отдавай кошелек, кому сказал !!!". Мне казалось при первом прочтении что майнер этой сигнатурой, что то левое не связанное с транзакциями в блоке подписывает и все.
Мысль о том, что майнер с парадного входа и абсолютно законно, может открыто взять ключ от сейфа в голову не помещалась.
Мне, вот только, не понятно. Получил я от этого майнера блок. Как мне валидировать эту
подпись, хранящуюся в MinerSignature? Мне нужен публичный ключ этого майнера, а где мне его взять?
подпись, хранящуюся в MinerSignature? Мне нужен публичный ключ этого майнера, а где мне его взять?
Не знаю уж как там в вашем спермакойне это сделано, но для валидации подписи вообще-то
говоря публичный ключ не нужен. Это является потрясением для многих, но публичный ключ
можно восстановить имея то что мы подписывали и подпись. Потом из публичного ключа получить
адрес и сравнить его с адресом в coinbase-транзакции.
Можете погуглить "ecdsa recover public key from signature"
Впрочем, на месте авторов спермакойна я бы действительно установил бы консенсус-правило
в coinbase-транзакции использовать только p2pk
А значит информацию по каждому блоку в виде getblock они по любому должны получать и переваривать.
На хуя? Зачем это надо?Что они будут переваривать, если им нужны только транзакции с их адресами
и доказательство того, что эти транзакции зафиксированы в блокчейне?
Вообще то лайт-клиенты должны переваривать не только это, но и все текущие транзакции, что бы в этом потоку найти свои.
Ну должны так должны. Мне они не должны, а тебе почему-то стали должны.
Не буду спорить с тобой, меня не волнует чье мнение по этому вопросу правильное,
а чье - нет.
И вот дальше мне абсолютно нихрена непонятно было как наличие двух вышеуказанных
полей обеспечивает знание майнером приватного ключа соответствующего коинбейз
транзакции и что это вообще такое.
Ну из твоих слов это понятно вроде.полей обеспечивает знание майнером приватного ключа соответствующего коинбейз
транзакции и что это вообще такое.
Если я майню эту валюту - я не могу поставить в coinbase-транзакции адрес Сатоши Накамото
1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa потому что я не знаю его приватный ключ, им надо
еще что-то подписать будет, а у меня нет этой возможности
А значит информацию по каждому блоку в виде getblock они по любому должны получать и переваривать.
На хуя? Зачем это надо?Что они будут переваривать, если им нужны только транзакции с их адресами
и доказательство того, что эти транзакции зафиксированы в блокчейне?
Вообще то лайт-клиенты должны переваривать не только это, но и все текущие транзакции, что бы в этом потоке найти свои.
Сейчас попытался сопоставить WhitePaper спредкоина и описание протокола биткоина.
В каждой итерации майнинга майнер должен подписать все содержимое полей блока за исключением хеша всего блока.
Все верно, это есть защита это пулов о которой я писал выше. А еще это есть опровержение "синей гипотезы" амаклина.В каждой итерации майнинга майнер должен подписать все содержимое полей блока за исключением хеша всего блока.
Но если вы не читатели, а писатели и не читали, про минусы которые я вам писал, то ладно...
Quote
1. В сети может появиться нода, которая быстро майнит монеты. Минимум 100 быстрее других нод, за счет того что она не тратит время не расчет подписи (который в свою очередь заложен внутри каждой итерации хеша). Она подписывает случайным мусором. Сама не получает, но и другим не дает. В итоге блокчейн никому не интересен - умирает
2. Можно ввести проверку валидности подписи, но тогда проверка хешей в цепочки блоков будет занимать большое время (например чтобы сравнить одну цепочку орфанов с другой).
В свое время я пришел к выводу, что для высокой скорости хеш должен быть быстрым. Особенно это актуально для блокчейнов с генерацией блоков раз в секунду.
Ну а если скромная скорость генерации блоков - 5-10 минут. Реально ли устранить вышеуказанные противоречия путем валидации подписей или иным каким то путем?2. Можно ввести проверку валидности подписи, но тогда проверка хешей в цепочки блоков будет занимать большое время (например чтобы сравнить одну цепочку орфанов с другой).
В свое время я пришел к выводу, что для высокой скорости хеш должен быть быстрым. Особенно это актуально для блокчейнов с генерацией блоков раз в секунду.
И еще мне непонятно про подписывание случайным мусором в вышеуказанном алгоритме, можете разъяснить?
И в спредкоине механизм валидации подписи реализован или нет? Есть там бешеная нода?
Сейчас попытался сопоставить WhitePaper спредкоина и описание протокола биткоина.
В каждой итерации майнинга майнер должен подписать все содержимое полей блока за исключением хеша всего блока.
В каждой итерации майнинга майнер должен подписать все содержимое полей блока за исключением хеша всего блока.
Все верно, это есть защита это пулов о которой я писал выше. А еще это есть опровержение "синей гипотезы" амаклина.
Но если вы не читатели, а писатели и не читали, про минусы которые я вам писал, то ладно...
Сейчас попытался сопоставить WhitePaper спредкоина и описание протокола биткоина.
https://bravenewcoin.com/assets/Whitepapers/SpreadCoin-WhitePaper.pdf
Сразу скажу этот WP полная хрень в плане непонятности.
Описание биткоина (не из WP спредкоина)
Если вы посмотрите на структуру любого блока, то самой первой всегда идет так называемая coinbase транзакция — именно она отправляет вознаграждение на адрес майнера. В отличии от обычных транзакций, coinbase transaction не тратит в качестве входов выходы из UTXO pool. Вместо этого у нее указан только один вход, называемый coinbase, который "создает" монеты из ничего. Выход у такой транзакции тоже только один. Он отправляет на адрес майнера награду за блок плюс сумму комиссий со всех транзакций в блоке.
Описание Спредкоина (WP)
В спредкоине майнинг организован так что майнер обязан знать следующие вещи:
1.Приватный ключ соответствующий транзакции коинбэйз (непонятно что это такое если коинбэйз из ничего создает бабло, я так понял что это приватный ключ от кошелька на который коинбейз транзакция посылает бабло)
2.Майнер должен иметь полный блок а не заголовок.
Чтобы обеспечить знание майнером этих двух вещей, в заголовке блока добавляется два новых поля - minersignature и hashwholeblock.
minersignature это цифровая подпись всех полей заголовка блока, за исключением hashwholeblock. В каждой итерации майнинга майнер должен подписать все содержимое полей блока за исключением хеша всего блока.
И вот дальше мне абсолютно нихрена непонятно было как наличие двух вышеуказанных полей обеспечивает знание майнером приватного ключа соответствующего коинбейз транзакции и что это вообще такое.
В комментариях к этому спредкоину я нашел вот такое объяснение 2014 года:
Как хэш блока или заголовка может зависеть от приватного ключа коинбейз транзакции?
И как, КАК КАРЛ? на уровне протокола можно вынудить пул или кого бы то ни было, раскрыть какой то приватный ключ, иначе протокол работать не будет.
Единственное что у меня в больной башке возникает (в качестве объяснения вышеизложенной хреноты) - это заставить владельца адреса получателя награды подписывать каждую итерацию перебора в майнинге приватным ключем от этого кошелька.
То есть minersignature это тупо подпись хозяина кошелька на который платится награда за блок. У меня полчаса ушло для того, чтобы дойти до этой простой мысли, поскольку она была для меня равносильна разрыву шаблона.
То есть либо сам перебирай если хочешь бабла, либо ключ отдай от кошелька, а мы за тебя поперебираем.
Тупо подпись хозяина кошелька в заголовке блока.
И никаких выходов за пределы доказательства работы.
И никакого нарушения консенсуса.
Привожу Вам выдержку из WP на английском:
In SpreadCoin mining is organized in such way that miner must know the following things:
1. Private key corresponding to the coinbase transaction.
2. Whole block, not only its header.
This ensures that miner can broadcast mined block and spend coins generated in that block. It may seem that it is necessary to know only the private key to spend coinbase transaction. If two conflicting transactions will appear on the network then the one that was broadcasted first will have much higher probability to be included in a block because each peer remembers and retransmits only the first one of the conflicting transactions. If both miner and pool know private key but only pool knows the content of the block than pool can generate and broadcast spending transaction earlier than miner. If both miner and pool know content of the block than miner will be the first one who can broadcast block and spending transaction.
To prove knowledge of the private key and whole block there are two new fields in the block header: MinerSignature and hashWholeBlock.
MinerSignature is a digital signature of all fields of the block header except for the hashWholeBlock. Changing any information in the block requires regeneration of this signature which means that it is necessary to recalculate it during each iteration of the mining process. This implies that miner must be able to sign any arbitrary data.
It is important that block is hashed twice. If it was hashed only once then pool could hash the beginning of the block and send resulting hash state to the miners. Each miner would then modify some information in the end of the block and recalculate the hash based on the known state without actual knowledge about what is contained in the beginning of the block. Appending block data to itself make it necessary to know the whole block to recalculate hashWholeBlock.
Pool may detect and ban cheating miners. However, many miners may still prefer to cheat so that pool will be completely unusable for honest miners.
Miners that have low probability of finding a block will get more profit by stealing reward for accidentally found block even if pool will ban them thereafter.
Miners that have enough mining power to find blocks consistently can still connect to a pool and submit shares for some time but steal the first found block. This way they can get both reward for their shares and the actual mined block.
Given all this it is expected that no one will create a pool. But even if someone will than it can be countered by releasing stealing miner software which many miners will switch to.
Вот ребята умные объясните мне в чем наеб то?
В английской ветке 400 страниц, я рыл их поиском.
minersignature и hashwholeblock и privatekey и fraud
и не нашел там хоть одного разоблачения что это наеб.
https://bravenewcoin.com/assets/Whitepapers/SpreadCoin-WhitePaper.pdf
Сразу скажу этот WP полная хрень в плане непонятности.
Описание биткоина (не из WP спредкоина)
Если вы посмотрите на структуру любого блока, то самой первой всегда идет так называемая coinbase транзакция — именно она отправляет вознаграждение на адрес майнера. В отличии от обычных транзакций, coinbase transaction не тратит в качестве входов выходы из UTXO pool. Вместо этого у нее указан только один вход, называемый coinbase, который "создает" монеты из ничего. Выход у такой транзакции тоже только один. Он отправляет на адрес майнера награду за блок плюс сумму комиссий со всех транзакций в блоке.
Описание Спредкоина (WP)
В спредкоине майнинг организован так что майнер обязан знать следующие вещи:
1.Приватный ключ соответствующий транзакции коинбэйз (непонятно что это такое если коинбэйз из ничего создает бабло, я так понял что это приватный ключ от кошелька на который коинбейз транзакция посылает бабло)
2.Майнер должен иметь полный блок а не заголовок.
Чтобы обеспечить знание майнером этих двух вещей, в заголовке блока добавляется два новых поля - minersignature и hashwholeblock.
minersignature это цифровая подпись всех полей заголовка блока, за исключением hashwholeblock. В каждой итерации майнинга майнер должен подписать все содержимое полей блока за исключением хеша всего блока.
И вот дальше мне абсолютно нихрена непонятно было как наличие двух вышеуказанных полей обеспечивает знание майнером приватного ключа соответствующего коинбейз транзакции и что это вообще такое.
В комментариях к этому спредкоину я нашел вот такое объяснение 2014 года:
Quote
Смысл как раз в том, что хэш зависит от приватного ключа coinbase и чтобы правильно посчитать хэш майнеру необходимо его знать, причём полностью. А если майнер знает ключ, значит он может воспользоваться (забрать) награду за блок. Поскольку блок находит именно майнер на своём оборудовании, он сможет воспользоваться ключем раньше пула.
Как хэш блока или заголовка может зависеть от приватного ключа коинбейз транзакции?
И как, КАК КАРЛ? на уровне протокола можно вынудить пул или кого бы то ни было, раскрыть какой то приватный ключ, иначе протокол работать не будет.
Единственное что у меня в больной башке возникает (в качестве объяснения вышеизложенной хреноты) - это заставить владельца адреса получателя награды подписывать каждую итерацию перебора в майнинге приватным ключем от этого кошелька.
То есть minersignature это тупо подпись хозяина кошелька на который платится награда за блок. У меня полчаса ушло для того, чтобы дойти до этой простой мысли, поскольку она была для меня равносильна разрыву шаблона.
То есть либо сам перебирай если хочешь бабла, либо ключ отдай от кошелька, а мы за тебя поперебираем.
Тупо подпись хозяина кошелька в заголовке блока.
И никаких выходов за пределы доказательства работы.
И никакого нарушения консенсуса.
Привожу Вам выдержку из WP на английском:
In SpreadCoin mining is organized in such way that miner must know the following things:
1. Private key corresponding to the coinbase transaction.
2. Whole block, not only its header.
This ensures that miner can broadcast mined block and spend coins generated in that block. It may seem that it is necessary to know only the private key to spend coinbase transaction. If two conflicting transactions will appear on the network then the one that was broadcasted first will have much higher probability to be included in a block because each peer remembers and retransmits only the first one of the conflicting transactions. If both miner and pool know private key but only pool knows the content of the block than pool can generate and broadcast spending transaction earlier than miner. If both miner and pool know content of the block than miner will be the first one who can broadcast block and spending transaction.
To prove knowledge of the private key and whole block there are two new fields in the block header: MinerSignature and hashWholeBlock.
MinerSignature is a digital signature of all fields of the block header except for the hashWholeBlock. Changing any information in the block requires regeneration of this signature which means that it is necessary to recalculate it during each iteration of the mining process. This implies that miner must be able to sign any arbitrary data.
It is important that block is hashed twice. If it was hashed only once then pool could hash the beginning of the block and send resulting hash state to the miners. Each miner would then modify some information in the end of the block and recalculate the hash based on the known state without actual knowledge about what is contained in the beginning of the block. Appending block data to itself make it necessary to know the whole block to recalculate hashWholeBlock.
Pool may detect and ban cheating miners. However, many miners may still prefer to cheat so that pool will be completely unusable for honest miners.
Miners that have low probability of finding a block will get more profit by stealing reward for accidentally found block even if pool will ban them thereafter.
Miners that have enough mining power to find blocks consistently can still connect to a pool and submit shares for some time but steal the first found block. This way they can get both reward for their shares and the actual mined block.
Given all this it is expected that no one will create a pool. But even if someone will than it can be countered by releasing stealing miner software which many miners will switch to.
Вот ребята умные объясните мне в чем наеб то?
В английской ветке 400 страниц, я рыл их поиском.
minersignature и hashwholeblock и privatekey и fraud
и не нашел там хоть одного разоблачения что это наеб.
А значит информацию по каждому блоку в виде getblock они по любому должны получать и переваривать.
На хуя? Зачем это надо?Что они будут переваривать, если им нужны только транзакции с их адресами
и доказательство того, что эти транзакции зафиксированы в блокчейне?
Если я посчитаю хэш от правой половины, с чем мне его сравнивать? В заголовке ведь полный хэш от всех транзакций.
Вы клиент.
У вас есть рут-хэш и txid
Для простоты не будем рассматривать весь алгоритм до упора
Вам сервер передает хэш левой половины дерева (меркль-хэш от первых 1500 транзакций)
И передает все txid от транзакций начиная с 1501 до 3000
Вы строите правую половину дерева и на последнем этапе у вас получилось два 32-байтных числа
одно передано с сервера, другое - вычислено вами. Берем и делаем меркль-хэш этих двух значений
Если получился меркль-рут блока - это доказательство того, что вас не наебали.
Но трафик вы уже вдвое сократили от сервера. На самом деле он сокращается даже не в два
раза, а как-то там логарифмически-степенно, короче еще круче получается. И вычислений
меньше - сплошная лепота.
В биткоине отдельного merkleroot без списка всех txid транзакций дерева быть не может.
Вы написали набор слов не имеющий смысла.Изначальный вопрос был примерно из этой же оперы.
Разумеется, блок - это заголовок, где есть меркль-хэш и набор транзакций.
И можно посчитать и проверить - валидный этот блок или нет.
Мы заговорили про лайт-клиенты. У них нет полного списка транзакций в блоке.
И можно посчитать и проверить - валидный этот блок или нет.
Мы заговорили про лайт-клиенты. У них нет полного списка транзакций в блоке.
До лайт-клиентов я ещё не добралcя и не знаю как они работают, но по любому лайт-клиенты должны проверять достоверность тех данных, которые они получают. А значит информацию по каждому блоку в виде getblock они по любому должны получать и переваривать. А сами транзакции им без надобности, кроме своих конечно.
В биткоине отдельного merkleroot без списка всех txid транзакций дерева быть не может.
Вы написали набор слов не имеющий смысла.Разумеется, блок - это заголовок, где есть меркль-хэш и набор транзакций.
И можно посчитать и проверить - валидный этот блок или нет.
Мы заговорили про лайт-клиенты. У них нет полного списка транзакций в блоке.
Ну тогда значит я ничего не понял про какие-то соседние узлы и т.д. Ну да ладно, пост не мне адресовался, может адресат и поймет )
Смысл такой.
Есть 3000 транзакций. У каждой свой txid размером 32 байта.
Если тупо записать их друг за другом - то это 9 килобайт надо отправить чтобы было доказательство
Но хэш меркла строится по-другому - элементы разбиваются по парам, и хэшируются парами
Потом эти полученные - опять парами и так далее, пока не останется один элемент - он-то и называется
меркль-хэшем.
Теперь возвращаемся к исходной задаче. есть транзакция, она допустим 1852-ая в списке из 3000
Нам не надо передавать клиенту первые 1500 txid, потому что наша транзакция
в "правой половине" достаточно их меркль-хэша - смотрите, мы уже сэкономили из 9 килобайт - половину!
Ну и так далее.
Я кстати пока пост амаклина не прочитал, думал что хэш меркла это тупо хэш всех txid. А вот сейчас засомневался что-то...
Хэш меркла это действительно хэш всех txid
Но не тупо, а очень даже элегантно.
Ну тогда значит я ничего не понял про какие-то соседние узлы и т.д. Ну да ладно, пост не мне адресовался, может адресат и поймет )
Jump to: