Почему мы должны ссылаться на весь txid для каждого вывода, который мы хотим потратить?

Предположим, я хочу потратить из 3 неизрасходованных выходов. Я должен ссылаться на txid этих неизрасходованных выходов. Предположим, они:

eb36eca9a06fbe68278ad3e7d16d10ed02e22ad891ed59ef2b84ed4a49e8a6d2

e912d1d29c2daa30cee47a89329426d254aa1ca59927b2d2ae0a2c561a30c4ad

aec43a6a925e55a4f5aa3fdfa2df308912ae06636a7c92b2e19ba55e7d7fc689

Вместо того, чтобы указывать на все txids, не мог бы я указать на первые 7 цифр каждого, чтобы это было eb36eca, e912d1d, aec43a6?

Конечно, легко сгенерировать txid, который соответствует только 7 первым цифрам каждого из используемых txid. Но что, если мы также включили информацию о том, что, как только вы найдете эти 3 txid в базе данных, которые начинаются с eb36eca, e912d1dи aec43a6, хэш этих 3 полных txid должен быть равен hash(eb36eca9a06fbe68278ad3e7d16d10ed02e22ad891ed59ef2b84ed4a49e8a6d2 + e912d1d29c2daa30cee47a89329426d254aa1ca59927b2d2ae0a2c561a30c4ad + aec43a6a925e55a4f5aa3fdfa2df308912ae06636a7c92b2e19ba55e7d7fc689)(где + здесь конкатенация).

Таким образом, вместо того, чтобы включать все 3 txid, мы просто включаем первые n цифр каждого и объединяем хэш этих 3 txid.

Не освободит ли это много места? Это всего лишь один хэш + n*k, являющийся nколичеством первых цифр и kколичеством входных данных.

Кроме того, разве подписи Шнорра не позволят подписать все эти выходные данные всего одной подписью? Разве это не сделало бы все транзакции почти одинаковыми? Сегодня каждый новый вывод добавляет к размеру транзакции как минимум: это txid и подпись, которые являются самыми большими частями.

В связи с предложением Шнорра: bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation
Подписи на вход, а не на выход.

Ответы (2)

Сжимая txids до более короткого отпечатка пальца, вы снижаете уникальную идентифицируемость. Например, есть три транзакции, соответствующие префиксу eb36eca: tx1 , tx2 , tx3 .

Так что, по сути, это создание комбинаторной головоломки, особенно если учесть, что txid — это только часть минуса, вы также должны добавить вывод, в противном случае вы могли бы ссылаться, например, на любой из 51 вывода вышеприведенного tx3.

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

«Комбинаторная головоломка» Марча — хорошее замечание. Действительно, мне кажется, что это приводит к довольно катастрофической атаке типа «отказ в обслуживании».

Я, конечно, могу создать транзакцию, префикс из 7 полубайтов которой мне нужен, просто грубой силой: например, поместить некоторые случайные данные в вывод OP_RETURN и настроить его, пока я не получу префикс, который мне нравится. В среднем требуется 2 ^ 28 попыток, около 256 миллионов. Итак, позвольте мне сделать 200 транзакций, все с префиксом 1234567. Для этого нужно около 40 миллиардов операций — работа пары часов для приличного графического процессора. Если я вложу небольшую плату в каждый из них, по текущим ставкам, это может стоить около 2000 долларов США, чтобы подтвердить их все.

Теперь я выбираю 100 из них наугад и создаю транзакцию, используя их все как входы. Чтобы проверить, действительна ли моя транзакция, вам нужно начать пробовать все возможные комбинации из 100 из 200 возможных, пока вы не найдете правильные. C(200,100)составляет около 10^59. Удачи пройти через это до того, как солнце погаснет.

Таким образом, я могу относительно дешево поставить всю сеть Биткойн на колени, поскольку каждый узел работает над неразрешимой проблемой выяснения того, какие 100 транзакций я потратил.

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

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

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