Я почитал про scriptSig и scriptPubKey, понял, как оно работает, но вопрос в том, почему нельзя один и тот же vout какой-то транзакции потратить дважды, например в 10 блоке и 15?
Я получил n монет в 9 блоке, средства заблокировались с помощью моего публичного ключа; я создал транзакцию с этим конкретным vout той транзакции, предоставил приватный ключ, транзакция совершилась, так как скрипт сработал, ведь я владею нужным приватным ключом от публичного, и я отправил эти n монет своему другу. Почему мне не позволят создать точно такую же транзакцию с тем же самым vout, чтобы снова отправить n монет своему другу? Ну и в обозревателе блокчейна биткоина на blockchain.com потраченные vouts помечаются красным
Техническая часть интересует. Если при проверке каждой транзакции постоянно проходят по всему блокчейну на поиск траты этого vout, то я пойму, почему не позволят заюзать снова этот vout, но навряд ли это работает так, так как это майнеру нужно найти среди 70к блоков этот самый vout, который я пытаюсь заново заюзать + тогда это делается для каждого блока для каждой в нем транзакции, которых около 2к вроде
Это база, которую имеют все узлы, которые майнят?
Или какие узлы кроме майнерских имеют данную базу, и какие узлы проверяют транзакцию на совершение двойной траты?
В этой статье рассказывается более поверхностная часть. Это понятно, что блокчейн - цепочка блоков с записями и тд
Мне интересно, как именно неправильные транзакции отклоняются сетью, что делают узлы сети, чтобы понять, что конкретная транзакция невалидна
Дмитрий X, ну так вот а как найти этот последний хэш?)
Отправитель создаёт транзакцию, записывая туда свои выходы и подписывая закрытым ключом. Эти транзакции ещё в блок не записаны - Майнер должен собрать транзакций, чтобы наполнить блок и добавить в общую цепочку.
Как он проверит, что выход рабочий, а не потраченный? Что и с чем он сравнивает и как?
Вообще в соседних ответах на этот вопрос как раз и ответили, что есть специальная база, где это всё как раз и проиндексировано
Василий Банников, да, я нашёл ещё в инете, что абсолютно все непотраченные выходы лежат в LevelDB, и при проверке транзакции видимо сначала проходит поиск по этой бд на наличие этого самого utxo
Василий Банников, Этим и занимаются майнеры, вычисляют хэш. Соответсвенно, если вычислить хэш транзакции, и сравнить его с последним хэшем. И если эти хэши своподают, то либо ошибка, либо кто то думает что он хитрожопый. И для этого не нужно знать все содержание его предыдущих транзакция.
Василий Банников, Само собой, хэши в базе сидят. Найти что то в одноранговой базе очень быстро. А вот что то вычислять, это будет медленно, для этого и существуют хэши. Это суть блокчейна.
Дмитрий X, а почему именно с последним? А если трата уже была 10 блоков назад? 100? Миллиард?
Кто гарантирует, что при одной повторной трате хэш будет идентичен последнему блоку - в сети куча незафиксированных транзакций и майнер будет фиксировать наиболее выгодные для него, среди тех, о которых он знает. Так что набор транзакций будет у разных майнеров разный, даже без учёта nonce.
Если не заводить отдельно индекс непотраченных выходов, то для каждой транзакции придётся идти по всему блокчейну от начала до конца, что даже на самых быстрых дисках будет занимать несколько минут, и то в лучшем случае, и только для чтения, без вычислений - и это для каждого нового блока.
Василий Банников, А как их он потратил 10 блоков назад? Его и после первого блока не пропустит, тем более после второго. Вы посмотрите blokchain explorer, и сразу станет всё понятно. Хоть 100 миллионов блоков назад. В хэш последующего блока, включен хэш предыдущего, и т. д. А майнер, да включает в блок наиболее выгодные для него транзакции. НО НЕ ДУБЛИ! Иначе блок будет запорчен, и цепочка будет потеряна. Да, какой то отдельный майнер, может продолжать цепочку "фальшивых" блоков, но все вместе майнеры в Мире!
Дмитрий X, так в последнем блоке же не все транзакции за всю историю сохраняются, а только те, которые зафиксированы в нём.
Ну и ваш ответ не показывает, как именно технически понять, что выход потрачен.
Хэш - просто большое число, которое вычисляется от содержимого блока. В нём информации никакой нет.
Василий Банников, хэши одинаковых транзакций тоже будут одинаковы. Хэши разных транзакций будут разными. Нет надобности знать, сколько и чего было потрачено.
Дмитрий X, ну так как найти, были ли такие же транзакции раньше?
Одни и те же выходы можно запихнуть в разные транзакции - тогда хэш/id транзакции будут точно разные
Василий Банников, В том то и дело, что одни и те же выходы, нельзя запихнухнуть в разные транзакции. В одной транзакции можно сделать несколько выходов. А не наобарот.
Василий Банников, Это как если бы я отдал одному человеку 100 рублей, а потом попытался у него их отабрать, и передать другому. Он не отдаст без сопротивления.
Короче говоря. Вы попробуйте. Возьмите создайте себе изолированную ноду, и подключитесь туда, двумя клиентами, один как майнер, другой как отправитель, создайте 2 транзакции, и вы убетитесь, что так не получится.
"транзакция содержит дату создания, при её изменении меняется хеш. Как вы создадите одинаковые транзакции не прибегая к самописным скриптам?" консоль отладки
Василий Банников, Отвечаю последний раз. ПО ХЭШУ. Слово сканить, не нужное. Ты думаеш, что при каждой транзакции идёт проверка всего блокчейна на все возможные входы и выходы. Это бессмысленно и глупо. Ищится конкретные входы (а они уже доказаны, раз есть в блокчейне), которые указаны в транзакции, и если их нет, либо они уже потрачены, такая транзакция отклоняется.
Sergey, разве транзакция содержит дату создания? Я смотрел JSON формат транзакции биткоина и там ни одного поля, отвечающего за транзакцию, не было
Плюс смотрел разбор blk_*.dat файла, что в нем содержится, там тоже не было в полях транзакций инфы про время создания
Василий Банников, как ищется тебе придется очень много объяснять. И про связанные списки, и про дерево хэшей. Просто прими на веру, оно ищется и быстро находится. В json запросе содержится не вся информация, которая содержится в транзакции. Пытаюсь объяснить последний последний раз. Вот у тебя в кармане есть две купюры, по 100 рублей. Ты на рынке что то захотел купить, и суеш продавцу эти купюры. А продавец хитрожопый, он на номера купюр смотрит. Если они одинаковые, он тебя пошлет. Ему не надо знать всю историю, как к тебе эти деньги к тебе попали, и в каком количестве.
Дмитрий X, так вопрос как раз в том, какой именно механизм используется для быстрого поиска, лол. Про детали реализации.
Понятное дело что искать надо, понятное дело что оно ищется быстро - результат же видим, что двойных трат нет, и новые транзакции создаются быстро. А сборка блока по сравнению с майнингом почти бесплатная.
Василий Банников, Ну тогда скажем так, все номера купюр продавец вносит в некую базу. И других номеров, которые, он не записывал, он не принимает. И все остальные продавцы на рынке сверяются с базами этого продавца. т.е. У всех одинаковые базы. Так понятне. А про сам механизм поиска в leveldb можно почитать, документации масса. В приципе, когда обращаешся через функцию поиска, знать как именно что то ищется, не очень то нужно, если ты не разработчик баз данных. Главное что ищется. Ты же не задаёшся вопросом, каков механизм поиска в google. Просто пользуешся.
Так же на 20:00 в видео https://www.youtube.com/watch?v=uPKcaIFauY4&list=P... представлен json представление транзакции.
По поводу того, как определить время транзакции - я не понимаю, но информация, хранимая в транзакции находится по ссылкам
Простой
Средний
