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

По какой теме?

Но я же могу при поднятии полного узла не скачивать witness, ведь свидетели вне блокчейна хранятся? Если что я понимаю что при внедрении segwit старые ScriptSig удаляться не будут из блокчейна (наверное), поэтому точнее будет сказать что суть данного пункта исследования ответить на вопрос, каким бы был размер блокчейна, если бы с самого начала использовался segwit.

смысла нет, но я должен убедить комиссию на защите, что таким образом segwit сокращает размер блокчейна.

Не понял, имеешь ввиду скрипт для блокировки? вроде не обязательно, зачем ему такм хранить если вход содержит ссылку на выход со scryptPubKey

Сам понимаю бесполезность такого исследования из за данного факта, по хорошему еще размер скрипта из свидетелей доставать, но это сложно для меня

для дипломной работы собираюсь оценить как повлияет удаление данных о подписи транзакции на размер текущего блокчейна биткоина, для этого напишу скрипт на питоне (python-bitcoinlib) который
1) пройдется по всем транзакциям и запишет все scryptSig в сериализованном виде
2) посчитает эти подписи из расчета символ hex = 4 бита
3) вычтет из размера блокчейна (bitcoin-cli getblockchaininfo size_on_disk) подсчитанный объем всех подписей
Понимаю, что это будут грубые расчеты, но насколько они будут правдоподобны? есть ли у вас предложения как проще решить поставленную задачу или повысить точность расчетов
Еще интересует как получить актуальный размер блокчейна, так как bitcoin-cli getblockchaininfo size_on_disk видимо возвращает размер папки с блоками, а не размер сериализованных блоков

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

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

пожалуйста, приведите пример, когда может быть полезен сценарий с return.
Я так понял return в сценариях блокировки используется просто для хранения данных в блокчейне, когда это может пригодиться?

спасибо за ответ, это то что нужно!)

я понял вас. Но все равно интересует какие данные используются для вычисления корня меркала. Я так понимаю для вычисления нужны только транзакции блока для которого вычисляем меркала

это вы про хэш блока (hashPrevBlock), а меня интересует хэш дерева меркла (hashMerkleRoot), который так же содержится в  block header

Какие аргументы необходимы для вычисления hashMerkleRoot в хедере блока? Я правильно понимаю, что нам нужны хэши транзакций только одного блока?
То есть hashMerkleRoot блока n+1 никак не связан с hashMerkleRoot  блока n, верно?