Я прочитал Контракты: будет ли это возможно? где часть вопроса касалась истечения срока транзакции, а в одном из ответов говорилось, что это никогда не будет возможно, поскольку это вызывает проблемы. К сожалению, в ответе не было указано, какие проблемы это вызовет.
Я не совсем понимаю из вопроса/ответа, был ли вопрос об истечении (неподтвержденной?) транзакции (что вполне может быть проблематично) или об истечении срока действия txout из ранее подтвержденной транзакции.
Является ли последнее совершенно невозможным с помощью любого существующего метода, например, сценариев и/или комбинации транзакций?
Один из способов, который, как я понимаю, может быть возможен (и я всего лишь новичок в биткойнах, поэтому, пожалуйста, сжальтесь надо мной и помогите мне понять, если это предложение явно нелепо для экспертов по биткойнам) состоит в том, чтобы иметь новую операцию биткойн-скрипта, которая могла бы использоваться в scriptPubKey txout для помещения " текущего " времени в стек, чтобы его можно было сравнить (используя OP_LESSTHAN, OP_GREATERTHAN, OP_LESSTHANOREQUAL или OP_GREATERTHANOREQUAL) с фиксированным временем истечения срока действия (которое находится в scriptPubKey и помещается в стек by scriptPubKey) и только если текущее время меньше времени истечения срока действия, остальная часть scriptPubKey позволит подтвердить транзакцию (т.е. платеж в биткойнах).
Примечание о том, что я имею в виду под « текущим » временем… могут быть длительные дебаты об источнике текущего времени и достоверности этого источника, но я бы предположил, что «текущее» время на самом деле не обязательно должно быть фактическое текущее время, если оно является достаточно близким приближением в сфере биткойнов (в среднем около 10 минут, но может быть дольше, может быть короче). Таким образом, это может быть отметка времени предыдущего блока в цепочке блоков; таким образом каждый узел (при условии отсутствия разветвления) будет оценивать истечение срока действия txout по одному и тому же «текущему» времени.
Нежелательным, но, возможно, приемлемым побочным эффектом является то, что если транзакция, расходующая txout, отправлена и подтверждена в коротком форке блокчейна, то она будет повторно поставлена в очередь на более длинном форке, и есть вероятность, что срок действия txout мог истечь до того, как транзакция будет повторно обработана, и, таким образом, транзакция не пройдет во второй раз.
Еще одна тонкость, повышающая удобство использования, может состоять в том, чтобы предложить два варианта новой «текущей» временной операции для отражения двух «вариантов» lock_time, один вариант для помещения метки времени предыдущего блока в стек, а другой вариант — для помещения метки времени предыдущего блока. высота в стеке. Таким образом, пользователь может писать транзакции, которые являются самосогласованными по временной привязке или самосогласованными по высоте.
Срок действия txout на самом деле не имеет смысла, так как это уничтожит монеты, а уничтожить монеты невозможно. (Монеты, о которых не было заявлено ни одним txout, вносятся в качестве комиссионных.)
В будущем вы можете создать транзакцию с lock_time, которая отправляет монеты на другой биткойн-адрес. Если вы передадите эту транзакцию контрагенту, у него будет возможность транслировать транзакцию в сеть после наступления срока ее оплаты, и она вступит в силу.
До этого времени можно было создать еще одну транзакцию без ограничения lock_time, переместить монеты и сделать транзакцию контрагента бесполезной.
Марч