Чем запутал то? Наоборот, подробно указал линки на официальные доки, снабдил комментариями где что, почему абракадабра? По крайней мере нет демагогии с понтами, как, не будем показывать пальцем, у кого

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

Ещё раз вам выложу линки на документацию, там все ответы на ваши вопросы есть, причём они все на одной странице вики почти:

Это структура транзакций в блоке - в таком виде её отправляют майнеры в составе блока:
https://en.bitcoin.it/wiki/Protocol_documentation#BlockTransactions

Вот это сама таинственная структура "tx", указано как она упакована в двоичном виде при ответе на запрос getdata (то есть при отправке вашей транзакции после создания в мемпул):
https://en.bitcoin.it/wiki/Protocol_documentation#tx
Там же чуть ниже описано всё и про входы, и про выходы, а еще чуть ниже даже пример tx в виде hex-дампа - см. заголовок Example tx message

Здесь всё про getdata:
https://en.bitcoin.it/wiki/Protocol_documentation#getdata

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

Ознакомиться можно в спецификации:
https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages
https://en.bitcoin.it/wiki/Transaction
https://en.bitcoin.it/wiki/Protocol_documentation#Transaction_Verification
и так далее, всё есть в документации.


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


Под узлом тут имеется ввиду узел сети IRC, обычно это один из серверов, с которым связаны клиенты. Синхронизируются, да, но система хоть и распределённая, но работает в итоге по правилам, которые определили для себя участники сети. По поводу неподтверждённых транзакций было много бурных обсуждений, и тут важно по какой причине она не была подтверждена, например, из-за недостаточной комиссии - в системе биткойн были введены правила, по которым транзакция может быть не включена майнерами в блок. И каждый узел сети имеет администратора, который рано или поздно удалит эту транзакцию. Всё делается конечно автоматически, но определяется правилами и настройками мемпула участниками сети. Вечно такие транзакции никто "хранить" не будет.


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

1) Нет, tx в блоке - это не хэш транзакции, а собственно сама транзакция. Вот пример транзакции в формате JSON, это фрагмент блока, хэш в ней прописан отдельно:


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

3) Пул транзакций - условное понятие, собственно это некая "память" в сети узла IRC. Узел может удалить эту транзакцию, но она, к примеру, может опять туда прийти. В зависимости от настроек, конфигурации, время может различаться. Очень старые неподтверждённые транзакции в конце концов полностью "исчезают".

4) Хэш предыдущего блока - это ссылка на предыдущий блок. Собственно, с помощью хэшей на предыдущие блоки и создаётся цепочка блоков - блокчейн. По сути блокчейн - это односвязный список объектов данных (в биткойне такие объекты и называются блоками).

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

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

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

А в чём смысл майнить эту энтропию, какая польза от этого для альткойна, для майнера, для других участников? Просто научный или познавательный эксперимент? Тогда нужно искать инвестора, который это всё оплатит.

Да, структурирование данных в дерево Меркля затрачивает много ресурсов, но поскольку в биткойне был заложен алгоритм PoW - то там это было как бы к месту. Есть и другие, боле быстрые способы контроля целостности данных. Но в дереве Меркля важно то, что контролируется не только сами данные, но и  структура самого дерева, которая может быть полезной при восстановлении данных. Например, берется контрольная сумма от объёмного каталога файлов. Нам нужно проверить его целостность. Если мы видим, что контрольная сумма не совпадает - то можно спуститься по дереву на один уровень ниже и проверить два хэша - в случае повреждения одного файла в нашем каталоге один из хэшей нижележащего уровня будет совпадать, а другой нет. Далее мы опять спускаемся на один уровень, но только там, где хэш не совпадает. Таким образом мы очень быстро доберёмся до повреждённого файла.  Поскольку там получается степенная функция, то проход по дереву Меркля для поиска повреждённых данных занимает всегда очень мало времени. Буквально за несколько проверок хешей мы можем найти повреждённый файл, даже если этих файлов триллионы. Таким образом, алгоритм Меркля "долго" хеширует, но быстро находит повреждённые данные. И конечно, таким образом можно искать не только повреждённые, но и просто изменённые файлы.

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

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

Вы не совсем в тот раздел пишите, здесь о коде больше. Про возможности софта лучше уточните в теме Bitcoin Forum > Bitcoin > Development & Technical Discussion > Alternative clients  - это англоязычная тема.

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

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

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

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

Там не просто API используется, а целый протокол, между клиентом пула (майнером) и сервером пула. Самый распространённый протокол для пулов - стратум называется. Читайте, о нём много написано. Имейте в виду, что пулы бывает частично изменяют этот протокол для своих нужд. Так что читайте хелпы про протокол пула, а не про API. И задавайте им вопросы. Пулы бывает, и не говорят об этом подробно. Если код клиента майнинга открытый - вы и сами можете во всём разобраться, а вот если нет открытого кода вообще у пула - тогда всегда есть вопросы к ним, и не факт, что они горят желанием вам всё объяснять. Почитайте про протокол стратум для начала. Приличный майнинг-софт обычно поддерживает этот протокол.

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

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


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

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

Насколько я понял, вы хотите держать в базе данных только итоговый баланс по каждому адресу? А сами транзакции не хранить. Такие программы уже сделаны и для биткойна тоже, но они не в общественном доступе. Всё это вполне реально. Но имейте в виду, что у вас хранится только сумма на счету, а вот распечатку - историю всех транзакций счёта вы по своей базе уже не сделаете. Поэтому и памяти меньше требуется.  В целом, стандартный клиент биткойна, например, избыточных данных особо не содержит, но он хранит всю информацию о системе, поэтому столько съедает памяти.

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

Но важно, в какой базе вы храните данные. Во всех серьезных базах можно измерить скорость выборки для 1 млрд. записей. Затем, зная объём всех данных и производительность вашей машины для конкретной выбранной хэш-функции, вы легко сосчитаете время выполнения вашей задачи - т.е. время выборки плюс время для вычисление хэша.

Если немного изменить алгоритм, можно использовать параллельные вычисления, это даст возможность увеличить производительность во много раз, при наличии вычислительных мощностей (много процессоров или ASIC).

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

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

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

Так я об этом и говорю, только не до конца уточнил. При записи двоичных данных одинаковой длины на шесть HEX символов придётся чуть более четырех base58 символов - это уже в ASCII кодировке. Т.е. на каждый символ base58 в ASCII будет округлённо на два бита больше в HEХ-формате в ASCII тех же данных.