Как завещать свои биткоины?

[Balthazar]

Отлично, буду ждать.

Краткий ликбез P2SH timelock.

Допустим, нам надо заблокировать монеты. Простейший скрипт для блокировки будет выглядеть так:

<таймстамп или номер блока> OP_CHECKLOCKTIMEVERIFY OP_DROP <публичный ключ> OP_CHECKSIG

Пусть будет блок 606800 и адрес 129h9Nj3iKZPMG3qMmHR3fcsNN4qGqUxAD.

Дампим приватный ключ и декодируем с помощью bitaddress.org, или иного инструмента, получается следующее:

770A37063E3E4D0BD76E24F0585C4A56566278BE897C1581AA6DA99DC0F27FD7

Ему соответствует публичный ключ:

021F9AB9E432320627F162B5D9627E02CEF8EE392AD4A986573B1C882B55F82549

606800 в сериализованном виде будет 504209. Подставляем это значение и публичный ключ, собираем скрипт по таблице опкодов:

03504209b17521021F9AB9E432320627F162B5D9627E02CEF8EE392AD4A986573B1C882B55F82549ac

Что эквивалентно этому:

606800 OP_CHECKLOCKTIMEVERIFY OP_DROP 021F9AB9E432320627F162B5D9627E02CEF8EE392AD4A986573B1C882B55F82549 OP_CHECKSIG

Байты, выделенные этим цветом - префиксы, означающие длину последующего вектора в 16-ричном формате.

Это и будет redeem скрипт. Считаем p2sh адрес для него:

$ btc decodescript 03504209b17521021F9AB9E432320627F162B5D9627E02CEF8EE392AD4A986573B1C882B55F8254 9ac
{
  "asm": "606800 OP_CHECKLOCKTIMEVERIFY OP_DROP 021f9ab9e432320627f162b5d9627e02cef8ee392ad4a986573b1c882b55f82549 OP_CHECKSIG",
  "type": "nonstandard",
  "p2sh": "39LkFZvuM3My1r1bdQKyaLRrKL9nr66Ge9",
  "segwit": {
    "asm": "0 f51002c06d11cf6bcac51594bacb588c11b92ea5741ff6af0621307eda9911bf",
    "hex": "0020f51002c06d11cf6bcac51594bacb588c11b92ea5741ff6af0621307eda9911bf",
    "reqSigs": 1,
    "type": "witness_v0_scripthash",
    "addresses": [
      "bc1q75gq9srdz88khjk9zk2t4j6c3sgmjt49ws0ldtcxyyc8ak5ezxlsj4a784"
    ],
    "p2sh-segwit": "346mg8ETWSqtQXgtteKhPjRVtY8T7FmUPU"
  }
}
$

Отправляю на него монетки:

Code:

$ btc sendtoaddress 39LkFZvuM3My1r1bdQKyaLRrKL9nr66Ge9 0.001
acebe7707eebf6ac66271f0c9f8343d90f8362fa18ba95622e4e26723a0ccc0b
$

https://blockstream.info/tx/acebe7707eebf6ac66271f0c9f8343d90f8362fa18ba95622e4e26723a0ccc0b

Теперь надо потратить. Посмотрим, что оно нам нагенерировало в транзакции.

Code:

$ btc getrawtransaction acebe7707eebf6ac66271f0c9f8343d90f8362fa18ba95622e4e26723a0ccc0b
02000000000101105284e1fa54095164f472edf1ea9af961bd4e01d441272ffefb8190edc7e4ea000000001716001485db6ba29e11f75a1f96ea4a69898d1c939f2f3ffeffffff0271a70a000000000017a9140cf4c70fb2750ff640f799ec206534e2835bbe3487a08601000000000017a91453eb9acee2a540e7ef1678f4b46ddaf571940a6887024730440220263aa894cbace0f042943681ef2acf0b7171793f5becbb76309bbe9b847ac43a02206d3deadeec3f46e625c189a77a4f15bbf07793305d5a99f5fda08f86f5e9c2630121037ca5e2097fb8d8b35c3633a2b58e89a45d3ff46ea8b6f0783dcdd681444aaad980420900
$ btc decoderawtransaction 02000000000101105284e1fa54095164f472edf1ea9af961bd4e01d441272ffefb8190edc7e4ea000000001716001485db6ba29e11f75a1f96ea4a69898d1c939f2f3ffeffffff0271a70a000000000017a9140cf4c70fb2750ff640f799ec206534e2835bbe3487a08601000000000017a91453eb9acee2a540e7ef1678f4b46ddaf571940a6887024730440220263aa894cbace0f042943681ef2acf0b7171793f5becbb76309bbe9b847ac43a02206d3deadeec3f46e625c189a77a4f15bbf07793305d5a99f5fda08f86f5e9c2630121037ca5e2097fb8d8b35c3633a2b58e89a45d3ff46ea8b6f0783dcdd681444aaad980420900
{
  "txid": "acebe7707eebf6ac66271f0c9f8343d90f8362fa18ba95622e4e26723a0ccc0b",
  "hash": "7340f97dfc3e9fd2af227f9e7f5bcedf4a9e8db81a2905684390e224b8920395",
  "version": 2,
  "size": 247,
  "vsize": 166,
  "weight": 661,
  "locktime": 606848,
  "vin": [
    {
      "txid": "eae4c7ed9081fbfe2f2741d4014ebd61f99aeaf1ed72f464510954fae1845210",
      "vout": 0,
      "scriptSig": {
        "asm": "001485db6ba29e11f75a1f96ea4a69898d1c939f2f3f",
        "hex": "16001485db6ba29e11f75a1f96ea4a69898d1c939f2f3f"
      },
      "txinwitness": [
        "30440220263aa894cbace0f042943681ef2acf0b7171793f5becbb76309bbe9b847ac43a02206d3deadeec3f46e625c189a77a4f15bbf07793305d5a99f5fda08f86f5e9c26301",
        "037ca5e2097fb8d8b35c3633a2b58e89a45d3ff46ea8b6f0783dcdd681444aaad9"
      ],
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 0.00698225,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 0cf4c70fb2750ff640f799ec206534e2835bbe34 OP_EQUAL",
        "hex": "a9140cf4c70fb2750ff640f799ec206534e2835bbe3487",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "32sXGHo3LCMiADZuqLR7Bui3SppFc7eiDq"
        ]
      }
    },
    {
      "value": 0.00100000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_HASH160 53eb9acee2a540e7ef1678f4b46ddaf571940a68 OP_EQUAL",
        "hex": "a91453eb9acee2a540e7ef1678f4b46ddaf571940a6887",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "39LkFZvuM3My1r1bdQKyaLRrKL9nr66Ge9"
        ]
      }
    }
  ]
}
$

Итого, у нас есть транзакция acebe7707eebf6ac66271f0c9f8343d90f8362fa18ba95622e4e26723a0ccc0b, в которой нас интересует выход 1.

Создаем шаблон транзакции траты:

Code:

$ btc createrawtransaction '[{"txid": "acebe7707eebf6ac66271f0c9f8343d90f8362fa18ba95622e4e26723a0ccc0b","vout": 1}]' '[{"129h9Nj3iKZPMG3qMmHR3fcsNN4qGqUxAD":0.0009}]' 606800
02000000010bcc0c3a72264e2e6295ba18fa62830fd943839f0c1f2766acf6eb7e70e7ebac0100000000feffffff01905f0100000000001976a9140c9cf6de1a55f192f2e8fc33279c9bfa92678d4988ac50420900

В этой транзакции есть всё нужное, но поле scriptSig не заполнено. Подписывание транзакции делается в 4 этапа:

1. Создается версия транзакции со scriptSig, включающим только redeemScript и не содержащим подписи.
2. Считается её двойной sha256 хэш.
3. Производится подписывание хэша с помощью приватного ключа, который мы ранее получили.
4. Аналогично первому шагу, только собирается полный scriptSig, включающий подпись.

Для выполнения 1 и 4 шага разбираем транзакцию на составные части:

Code:

02000000 <- Версия схемы
01 <- Количество входов
0bcc0c3a72264e2e6295ba18fa62830fd943839f0c1f2766acf6eb7e70e7ebac <- txid входа
01000000 <- номер входа
00 <- Префикс пустого вектора, именно вместо него нужно вставить scriptSig c префиксом
feffffff <- nSequence
01 <- Количество выходов
905f010000000000 <- Сумма выхода
1976a9140c9cf6de1a55f192f2e8fc33279c9bfa92678d4988ac <- Запирающий скрипт выхода
50420900 <- lockTime

Выполняем первый шаг, подставляя redeemScript:

Code:

02000000 <- Версия схемы
01 <- Количество входов
0bcc0c3a72264e2e6295ba18fa62830fd943839f0c1f2766acf6eb7e70e7ebac <- txid входа
01000000 <- номер входа
2903504209b17521021F9AB9E432320627F162B5D9627E02CEF8EE392AD4A986573B1C882B55F82549ac <- префикс + redeemScript
feffffff <- nSequence
01 <- Количество выходов
905f010000000000 <- Сумма выхода
1976a9140c9cf6de1a55f192f2e8fc33279c9bfa92678d4988ac <- Запирающий скрипт выхода
50420900 <- lockTime

Собираем транзакцию, объединяя строки в том же порядке, в каком разбирали:

Code:

02000000010bcc0c3a72264e2e6295ba18fa62830fd943839f0c1f2766acf6eb7e70e7ebac010000002903504209b17521021F9AB9E432320627F162B5D9627E02CEF8EE392AD4A986573B1C882B55F82549acfeffffff01905f0100000000001976a9140c9cf6de1a55f192f2e8fc33279c9bfa92678d4988ac50420900

Добавляем флаг SIGHASH_ALL в Little Endian:

Code:

02000000010bcc0c3a72264e2e6295ba18fa62830fd943839f0c1f2766acf6eb7e70e7ebac010000002903504209b17521021F9AB9E432320627F162B5D9627E02CEF8EE392AD4A986573B1C882B55F82549acfeffffff01905f0100000000001976a9140c9cf6de1a55f192f2e8fc33279c9bfa92678d4988ac5042090001000000

Считаем sha256(sha256(tx + flag)):

Code:

$ echo 02000000010bcc0c3a72264e2e6295ba18fa62830fd943839f0c1f2766acf6eb7e70e7ebac010000002903504209b17521021F9AB9E432320627F162B5D9627E02CEF8EE392AD4A986573B1C882B55F82549acfeffffff01905f0100000000001976a9140c9cf6de1a55f192f2e8fc33279c9bfa92678d4988ac5042090001000000 | xxd -r -p | openssl dgst -sha256 -binary | openssl dgst -sha256 -hex
(stdin)= aca8b6ef49f50b328365ad0d17e3b9affcd91765000ad36513ed37f165b42933
$

Хэш данных для подписи aca8b6ef49f50b328365ad0d17e3b9affcd91765000ad36513ed37f165b42933.

Выполняем подписывание:

Code:

$ python
Python 2.7.12 (default, Oct  8 2019, 14:14:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib, binascii, ecdsa
>>> txhash = bytearray.fromhex('aca8b6ef49f50b328365ad0d17e3b9affcd91765000ad36513ed37f165b42933')
>>> privkey = bytearray.fromhex('770A37063E3E4D0BD76E24F0585C4A56566278BE897C1581AA6DA99DC0F27FD7')
>>> signingkey = ecdsa.SigningKey.from_string(privkey, curve=ecdsa.SECP256k1)
>>> sigbytes = signingkey.sign_digest(txhash, sigencode=ecdsa.util.sigencode_der_canonize)
>>> binascii.hexlify(sigbytes)
'304402205fcd53ba8c4d58d46c110d3ce545c6eef37dfb309625d94ddfa5a45a601ee6a202203b18ee2a35a644b809cdd06ef851a8f795f70ed2aa0878de08ed121f84d28059'
>>> exit()

Наша подпись

Code:

304402205fcd53ba8c4d58d46c110d3ce545c6eef37dfb309625d94ddfa5a45a601ee6a202203b18ee2a35a644b809cdd06ef851a8f795f70ed2aa0878de08ed121f84d28059

К ней нужно добавить флаг SIGHASH_ALL, и тогда она будет выглядеть так:

Code:

304402205fcd53ba8c4d58d46c110d3ce545c6eef37dfb309625d94ddfa5a45a601ee6a202203b18ee2a35a644b809cdd06ef851a8f795f70ed2aa0878de08ed121f84d2805901

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

Сначала считаем префикс байты:

Code:

47 304402205fcd53ba8c4d58d46c110d3ce545c6eef37dfb309625d94ddfa5a45a601ee6a202203b18ee2a35a644b809cdd06ef851a8f795f70ed2aa0878de08ed121f84d2805901
29 03504209b17521021F9AB9E432320627F162B5D9627E02CEF8EE392AD4A986573B1C882B55F82549ac

Теперь объединяем и проверяем:

Code:

47304402205fcd53ba8c4d58d46c110d3ce545c6eef37dfb309625d94ddfa5a45a601ee6a202203b18ee2a35a644b809cdd06ef851a8f795f70ed2aa0878de08ed121f84d28059012903504209b17521021F9AB9E432320627F162B5D9627E02CEF8EE392AD4A986573B1C882B55F82549ac

Code:

$ btc decodescript 47304402205fcd53ba8c4d58d46c110d3ce545c6eef37dfb309625d94ddfa5a45a601ee6a202203b18ee2a35a644b809cdd06ef851a8f795f70ed2aa0878de08ed121f84d28059012903504209b17521021F9AB9E432320627F162B5D9627E02CEF8EE392AD4A986573B1C882B55F82549ac
{
  "asm": "304402205fcd53ba8c4d58d46c110d3ce545c6eef37dfb309625d94ddfa5a45a601ee6a202203b18ee2a35a644b809cdd06ef851a8f795f70ed2aa0878de08ed121f84d2805901 03504209b17521021f9ab9e432320627f162b5d9627e02cef8ee392ad4a986573b1c882b55f82549ac",
  "type": "nonstandard",
  "p2sh": "3CkKRxxvGxWUa9zk3DnbBS7fPgBJYWhuDt",
  "segwit": {
    "asm": "0 34277eb829c1589343f8ccd261ea531b9392c52849c5537168a5766fdb3d6e7e",
    "hex": "002034277eb829c1589343f8ccd261ea531b9392c52849c5537168a5766fdb3d6e7e",
    "reqSigs": 1,
    "type": "witness_v0_scripthash",
    "addresses": [
      "bc1qxsnhawpfc9vfxslcenfxr6jnrwfe93fgf8z4xutg54mxlkeadelq772sq5"
    ],
    "p2sh-segwit": "3Lc5zXYZRsvW25crtbUjjGZHQ31icN2v4Q"
  }
}
$

Судя по содержимому поля asm, скрипт соответствует нашим желаниям. Считаем префикс байт для скрипта в целом, получается 0x72. Объединяем со скриптом:

Code:

7247304402205fcd53ba8c4d58d46c110d3ce545c6eef37dfb309625d94ddfa5a45a601ee6a202203b18ee2a35a644b809cdd06ef851a8f795f70ed2aa0878de08ed121f84d28059012903504209b17521021F9AB9E432320627F162B5D9627E02CEF8EE392AD4A986573B1C882B55F82549ac

Всё. Теперь у нас есть scriptSig для нашей волшебной транзакции, тратящей заблокированный выход.

Как? Очень просто, берем разобранную ранее на части неподписанную транзакцию и подставляем скрипт:

Code:

02000000 <- Версия схемы
01 <- Количество входов
0bcc0c3a72264e2e6295ba18fa62830fd943839f0c1f2766acf6eb7e70e7ebac <- txid входа
01000000 <- номер входа
7247304402205fcd53ba8c4d58d46c110d3ce545c6eef37dfb309625d94ddfa5a45a601ee6a202203b18ee2a35a644b809cdd06ef851a8f795f70ed2aa0878de08ed121f84d28059012903504209b17521021F9AB9E432320627F162B5D9627E02CEF8EE392AD4A986573B1C882B55F82549ac <- префикс + scriptSig
feffffff <- nSequence
01 <- Количество выходов
905f010000000000 <- Сумма выхода
1976a9140c9cf6de1a55f192f2e8fc33279c9bfa92678d4988ac <- Запирающий скрипт выхода
50420900 <- lockTime

Объединяем строки:

Code:

02000000010bcc0c3a72264e2e6295ba18fa62830fd943839f0c1f2766acf6eb7e70e7ebac010000007247304402205fcd53ba8c4d58d46c110d3ce545c6eef37dfb309625d94ddfa5a45a601ee6a202203b18ee2a35a644b809cdd06ef851a8f795f70ed2aa0878de08ed121f84d28059012903504209b17521021F9AB9E432320627F162B5D9627E02CEF8EE392AD4A986573B1C882B55F82549acfeffffff01905f0100000000001976a9140c9cf6de1a55f192f2e8fc33279c9bfa92678d4988ac50420900

Все, у нас теперь есть подписанная транзакция

Отправляем в сеть:

Code:

$ btc sendrawtransaction 02000000010bcc0c3a72264e2e6295ba18fa62830fd943839f0c1f2766acf6eb7e70e7ebac010000007247304402205fcd53ba8c4d58d46c110d3ce545c6eef37dfb309625d94ddfa5a45a601ee6a202203b18ee2a35a644b809cdd06ef851a8f795f70ed2aa0878de08ed121f84d28059012903504209b17521021F9AB9E432320627F162B5D9627E02CEF8EE392AD4A986573B1C882B55F82549acfeffffff01905f0100000000001976a9140c9cf6de1a55f192f2e8fc33279c9bfa92678d4988ac50420900
4878dc56a7d29d342c8653582ba9a123036a76a2ea022a8cec8cd8f3427d88e0

Результат:

https://blockstream.info/tx/4878dc56a7d29d342c8653582ba9a123036a76a2ea022a8cec8cd8f3427d88e0

При желании, этот процесс не проблема автоматизировать скриптом из 5-10 строчек. Однако же, это вовсе не сложно сделать руками.
Кроме прочего, вместо консоли питона для подписывания можно использовать утилиту openssl.

P.S. Современный биткойн не принимает неканоничные подписи, которые иногда генерируются openssl и обвязками вокруг него. Самое простое решение - это проверить, встречаются ли в подписи байты 022100 и, если да, то повторять операцию sign_digest до тех пор, пока их в подписи не будет. Иногда, бывает, надо повторить подписывание хэша 2-3 раза, прежде чем получится хорошая подпись.

P.P.S. Если у тратящей транзакции несколько входов, то подписывание каждого из них делается независимо. То есть, для каждого входа подписывается отдельно формируемая болванка, redeemScript или scriptpubKey подставляются только на место для scriptSig подписываемого входа, остальные оставляются пустыми. После получения подписей для всех входов точно так же формируются скрипты и далее добавляются в болванку.

[1579796861]

1579796861

[1579796861]

1579796861

[1579796861]

1579796861

[igor72]

Спасибо! Попробую как-нибудь. Особенно интересно с openssl попробовать. Если не трудно, напишите еще, плиз, как в openssl подписывать?

[Balthazar]

Спасибо! Попробую как-нибудь. Особенно интересно с openssl попробовать. Если не трудно, напишите еще, плиз, как в openssl подписывать?

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

[johhnyUA]

Спасибо! Попробую как-нибудь. Особенно интересно с openssl попробовать. Если не трудно, напишите еще, плиз, как в openssl подписывать?

https://raymii.org/s/tutorials/Sign_and_verify_text_files_to_public_keys_via_the_OpenSSL_Command_Line.html
И вот еще - https://www.zimuel.it/blog/sign-and-verify-a-file-using-openssl
Но у open ssl свой формат ключей, там надо будет переводить в них.

А вообще жаль что скрипты по P2PKH лучше не использовать (как я понял из сообщений Бальтазара)

[Balthazar]

Забыл вчера сказать. Смысл транзакций на такой адрес отличается от смысла голого lockTime.

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

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

[johhnyUA]

Забыл вчера сказать. Смысл транзакций на такой адрес отличается от смысла голого lockTime.

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

Об этом вроде бы выше уже писали. Обычный локтайм это просто невозможность отправить транзакцию в сеть до определенного блока. А OP_CLTV это блокирование выходов транзакции до определенного блока/времени.

А собственно OP_CSV это возможность тратить выходы в будущем после определенного количества блоков с момента майнинга указанного блока (ну или невозможность тратить до момента в будущем который определяется  временем после майнинга определенного блока)

[stmar]

Приоритет считается исходя из количества уничтоженных монетодней. Если у двух транзакций одинаковый виртуальный размер и одинаковая комиссия, то среди них выше будет та, которая потратила более старые монеты.

Прошу прощения. Что означает более старые монеты?

[Balthazar]

Приоритет считается исходя из количества уничтоженных монетодней. Если у двух транзакций одинаковый виртуальный размер и одинаковая комиссия, то среди них выше будет та, которая потратила более старые монеты.

Прошу прощения. Что означает более старые монеты?

Это означает монеты с бОльшим количеством подтверждений.

[FontSeli]

Приоритет считается исходя из количества уничтоженных монетодней. Если у двух транзакций одинаковый виртуальный размер и одинаковая комиссия, то среди них выше будет та, которая потратила более старые монеты.

Прошу прощения. Что означает более старые монеты?

Приоритет считается исходя из количества уничтоженных монетодней. Если у двух транзакций одинаковый виртуальный размер и одинаковая комиссия, то среди них выше будет та, которая потратила более старые монеты.

Прошу прощения. Что означает более старые монеты?

Это означает монеты с бОльшим количеством подтверждений.

Вот здесь можно дополнительно почитать об этом. Там нужно будет дополнительно сделать несколько переходов по ссылкам.

[TechPriest]

В клиенте bitcoin core есть захардкоденный список шаблонов скриптов, которые считаются стандартными. По умолчанию клиент принимает в memory pool только транзакции, скрипты которых совпадают с одним из шаблонов в этом списке. Не используйте нестандартные скрипты. В противном случае вашу транзакцию надо будет ещё постараться подтвердить, если у вас нет прямого выхода на майнинговые мощности. Для этой цели давно придумали P2SH, пользуйтесь им и не будет проблем.

Здравствуйте.
А где в клиенте можно откопать список этих скриптов для P2PKH? Так то мне кажется можно под каждый новый скрипт открывать ишью на github, думаю добавят в клиент. Я бы и сам открыл, надо вот только сначала разобраться с этим списком.

[Balthazar]

В клиенте bitcoin core есть захардкоденный список шаблонов скриптов, которые считаются стандартными. По умолчанию клиент принимает в memory pool только транзакции, скрипты которых совпадают с одним из шаблонов в этом списке. Не используйте нестандартные скрипты. В противном случае вашу транзакцию надо будет ещё постараться подтвердить, если у вас нет прямого выхода на майнинговые мощности. Для этой цели давно придумали P2SH, пользуйтесь им и не будет проблем.

Здравствуйте.
А где в клиенте можно откопать список этих скриптов для P2PKH? Так то мне кажется можно под каждый новый скрипт открывать ишью на github, думаю добавят в клиент. Я бы и сам открыл, надо вот только сначала разобраться с этим списком.

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

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

Для примера, пулл реквест вашего покорного слуги:

https://github.com/bitcoin/bitcoin/pull/9893

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

[johhnyUA]

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

Значит, по твоим же словам, OP_CHECKLOCKTIMEVERIFY и OP_CHECKSEQUENCEVERIFY должны быть в стандартных скриптах, так как на них есть успешные BIP-ы:

https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki

Ыыыыыыы. Значит все должно получиться, и не обязательно юзать именно P2SH. Кому слабо проверить в мейн нете, а? 

[Balthazar]

https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki

Упомянутые бипы описывают только новые опкоды и их реализацию в скрипт машине. Хоть они и не предписывают обязательное использование в контексте P2SH, они неявно подразумевают это. То есть, использование для скриптов либо P2SH, либо его более современного аналога, на сегодня это P2WSH. Посмотрите приложенные в бипах примеры и увидите это.

Ыыыыыыы. Значит все должно получиться, и не обязательно юзать именно P2SH. Кому слабо проверить в мейн нете, а?  

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

Так что использовать в мейн нете без P2SH/P2WSH можно, но только есть свой пул, и немаленький. И настоящий, а не прокси обвязки всякие. Ну или если у кого из друзей есть пул, и он согласится отмайнить транзакцию. Иначе транзакция если и будет подтверждена, то только в случае сильного везения. Без этого она даже в мемори пул к майнерам не попадёт.

В общем, оплата на скрипты напрямую - это решение не для смертных юзеров.

[johhnyUA]

Посмотрите приложенные в бипах примеры и увидите это.

Смотри, цитата из самого бипа:

In addition to using cold storage, hardware wallets, and P2SH multisig outputs to control funds, now funds can be frozen in UTXOs directly on the blockchain. With the following scriptPubKey, nobody will be able to spend the encumbered output until the provided expiry time. This ability to freeze funds reliably may be useful in scenarios where reducing duress or confiscation risk is desired.

Code:

    <expiry time> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG

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

[Balthazar]

Смотри, цитата из самого бипа:

In addition to using cold storage, hardware wallets, and P2SH multisig outputs to control funds, now funds can be frozen in UTXOs directly on the blockchain. With the following scriptPubKey, nobody will be able to spend the encumbered output until the provided expiry time. This ability to freeze funds reliably may be useful in scenarios where reducing duress or confiscation risk is desired.

Code:

   <expiry time> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG

Ну тут же по структуре видно что P2PKH. И из контекста такое понимание приходит.

Язык юридический, а равно как и язык описания стандартов, заметно отличаются от языка человеческого. Там написано "can be frozen", так что с точки зрения скриптовой машины никакого противоречия текущей ситуации нет. Ведь ты действительно можешь заморозить выходы таким скриптом и авторов документа не волнует, что они по умолчанию не майнятся. Это описание логики скрипт машины, а не клиента в целом.

Если бы доступность такого формата в качестве стандарта была обязательной, то использовались бы ключевые слова must или should. Так и было бы написано "Clients must treat these outputs as standard ones" или аналогично.

В реализации проверки на стандартность чётко определён шаблон скрипта P2PKH:

https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.cpp#L60
https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.cpp#L138

Определённые опкоды должны находиться на заданных смещениях, длина скрипта тоже фиксирована, шаг вправо или влево - расстрел.

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

Люди в транзакции манделу запихивают через data carrying выходы, это отдельный тип выхода транзакции, и через P2SH redeem скрипты. Эти транзакции стандартны с точки зрения текущей реализации протокола, потому и майнятся.

[igor72]

Скрипт же гарантирует, что отправитель утратил контроль над отправленным на него средствами до даты, которая в нем указана.

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

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

На мой взгляд, в таком скрипте нужно обязательно предусматривать ветвление с возможностью траты наследодателем без локтайма. Это дает несколько плюсов:
1. Можно протестировать мелкой суммой вручную созданный скрипт/адрес - если деньги выводятся, то уже не страшно загрузить и крупняк. Иначе, например, я бы не рискнул ).
2. Дает возможность "аварийного выхода" в случае изменения протокола (хардфорка). Маловероятно, что понадобится, но всё-таки...
3. Выше упомянуто про возможность увеличения суммы наследства, в данном варианте ее можно также и уменьшать при необходимости. Такая опция тоже ведь должна быть, для лишения наследства хотя бы ).

[Balthazar]

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

[igor72]

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

Конечно. Но, имхо, использовать вариант со скриптом лишь ради OP_CLTV (как в примере в вашем гайде) не оправдано - "множим сущее без необходимости", по-моему.

Тем не менее, имхо, добавление черных ходов в скрипт косвенно делает схему более уязвимой. Вдруг у деда поедет крыша и он решит спустить все деньги на бесполезные бумажки? Как самый простой, но довольно частый пример развития событий.

Ну тут смотря с какой стороны посмотреть... Наследник, имея в руках "неотменяемую" транзакцию, тоже может оборзеть и плюнуть на деда ).

[Balthazar]

"множим сущее без необходимости", по-моему.

Навряд ли, потому что у этой схемы нет аналогов, реализуемых без OP_CLTV. Транзакция с локтаймом не является аналогом в силу причин, озвученных ранее.

Ну тут смотря с какой стороны посмотреть... Наследник, имея в руках "неотменяемую" транзакцию, тоже может оборзеть и плюнуть на деда ).

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

[igor72]

"множим сущее без необходимости", по-моему.

Навряд ли, потому что у этой схемы нет аналогов, реализуемых без OP_CLTV. Транзакция с локтаймом не является аналогом в силу причин, озвученных ранее.

Каких причин? Невозможность пополнения адреса? Ну и что, нетрудно и полностью переделать транзакцию.

Кстати, если создать скрипт без "аварийного выхода", то как тогда отодвинуть срок вступления в наследство?

Ну тут смотря с какой стороны посмотреть... Наследник, имея в руках "неотменяемую" транзакцию, тоже может оборзеть и плюнуть на деда ).

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

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