Поле «значение» в необработанной транзакции: округленные биткойны (с плавающей запятой) или сатоши?

Меня смущает представление суммы биткойнов в "value"поле необработанной транзакции.

Например, если я хочу потратить 0,05 BTC, какое из этих значений является правильным?

"value" : 0.05
"value" : 50000000

Или оба разрешены? Похоже, что bitcoin-cli sendfrom ...генерируется первое представление, а быстрая проверка некоторых транзакций на blockchain.info только что показала транзакции, использующие второе.

В настоящее время я следую примеру траты-p2sh- txout.py из python-bitcoinlib, в котором создается необработанная транзакция, использующая представление Сатоши.

В моем приложении создается следующая транзакция в regtestрежиме декодирования через blockchain.info :

{
   "lock_time":0,
   "size":224,
   "inputs":[
      {
         "prev_out":{
            "index":0,
            "hash":"bf7a52d8ddbc2faf3f110fe7aef4fb2ef68058ab607c381a098062bc2f53d613"
         },
         "script":"483045022100dbbcce4fcf6ff6af11c5c365fe736a01ed6808e3a7369f5a54285f3cf7b91b7002202bc38a8b7631d0749ec519d28ae87885a3881afc52b741aec55b8952bda81ef501410468d77eb31494cb851898661e8359f7388283317c7e79cf979af7c99c379a5a641cc476663d0e8a91c458f6c86fdd8b76e3db3e0e06ba0527748690fae4673b13"
      }
   ],
   "version":1,
   "vin_sz":1,
   "hash":"985ca8c35dd2e0bd4c583a3254352f740445fb0c19cca6922a3f71458ede6246",
   "vout_sz":1,
   "out":[
      {
         "script_string":"OP_DUP OP_HASH160 cadcdc47fcdbeeb3ad212b4a4657d7b4da759a82 OP_EQUALVERIFY OP_CHECKSIG",
         "address":"1KVe5QTdQ4cXfqmtJBxqKQrei5zvCmRpWh",
         "value":10000000,
         "script":"76a914cadcdc47fcdbeeb3ad212b4a4657d7b4da759a8288ac"
      }
   ]
}

Эта транзакция предназначена для простого перевода средств, полученных предыдущей ручной транзакцией bitcoin-cli -regtest sendfrom alice mtx3RXD3DVgc1BDSeHRFkSVcmSw8BfdbS2 0.1, созданной через aliceсуществующую учетную запись. Сделка выглядит следующим образом:

{
    "hex" : "01000000021fe8d299c9a91892895a7cf1bd03519cc41e37deb723e32abd4d54b089be361000000000494830450221008ea7e7ab056daf158561329f7879c4cddb6dce741be106572902d50aab9e1c110220531e3cbfd2491412d9ddc6f04c77d2e9153b8e76df3676cd1d40cd81700c723901ffffffff9745aa1ff0c8d4f9079e93a30c08ac85f3c1dc6870a2272c59e2915d05f76c40010000006b48304502210085a3a69fdb2242bea5b7fa2bb3889e2d0c04d80614cde72053ba0b63e0acef9c022068b04f769a67ce896c09b0c43efd2d53542a6530f51b0d5144bea06e8ffea98a01210222485cf467f5359416d5dcf20293adce14bd6039cffc246ae7d6f49f541ae3b6ffffffff0227d80f00000000001976a9147b441644e981eaa7b9acbb66ddd029540ae3771388ac80969800000000001976a914935850c4a25f44f4e057aa2109a885537056727288ac00000000",
    "txid" : "bf7a52d8ddbc2faf3f110fe7aef4fb2ef68058ab607c381a098062bc2f53d613",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "1036be89b0544dbd2ae323b7de371ec49c5103bdf17c5a899218a9c999d2e81f",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "30450221008ea7e7ab056daf158561329f7879c4cddb6dce741be106572902d50aab9e1c110220531e3cbfd2491412d9ddc6f04c77d2e9153b8e76df3676cd1d40cd81700c723901",
                "hex" : "4830450221008ea7e7ab056daf158561329f7879c4cddb6dce741be106572902d50aab9e1c110220531e3cbfd2491412d9ddc6f04c77d2e9153b8e76df3676cd1d40cd81700c723901"
            },
            "sequence" : 4294967295
        },
        {
            "txid" : "406cf7055d91e2592c27a27068dcc1f385ac080ca3939e07f9d4c8f01faa4597",
            "vout" : 1,
            "scriptSig" : {
                "asm" : "304502210085a3a69fdb2242bea5b7fa2bb3889e2d0c04d80614cde72053ba0b63e0acef9c022068b04f769a67ce896c09b0c43efd2d53542a6530f51b0d5144bea06e8ffea98a01 0222485cf467f5359416d5dcf20293adce14bd6039cffc246ae7d6f49f541ae3b6",
                "hex" : "48304502210085a3a69fdb2242bea5b7fa2bb3889e2d0c04d80614cde72053ba0b63e0acef9c022068b04f769a67ce896c09b0c43efd2d53542a6530f51b0d5144bea06e8ffea98a01210222485cf467f5359416d5dcf20293adce14bd6039cffc246ae7d6f49f541ae3b6"
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 0.01038375,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 7b441644e981eaa7b9acbb66ddd029540ae37713 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a9147b441644e981eaa7b9acbb66ddd029540ae3771388ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "mrkiyR5zrvxZtCucHYZTXfs3t2Kz9UNuVS"
                ]
            }
        },
        {
            "value" : 0.10000000,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 935850c4a25f44f4e057aa2109a8855370567272 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914935850c4a25f44f4e057aa2109a885537056727288ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "mtx3RXD3DVgc1BDSeHRFkSVcmSw8BfdbS2"
                ]
            }
        }
    ],
    "blockhash" : "0000c177c89fab9ff7b59be7d38b61c94c3b8492a3633863c382fba73f0ede0c",
    "confirmations" : 6,
    "time" : 1420621337,
    "blocktime" : 1420621337
}

Транзакция, созданная моим приложением, отклоняется моим локальным bitcoindэкземпляром, debug.logговорит:

ERROR: CheckInputs() : 985ca8c35dd2e0bd4c583a3254352f740445fb0c19cca6922a3f71458ede6246 value in < value out

Прямо сейчас я подозреваю, что ошибка вызвана разными представлениями, или я упустил другую проблему?

Ответы (2)

Изучив комментарий Джорджа , я обнаружил, что действительно результаты парсинга необработанной транзакции отличаются при bitcoindлокальном использовании и разрешении парсинга транзакции blockchain.info.

Т.е. оба представления эквивалентны и нет никакой разницы между реальной транзакцией.

Поскольку моя транзакция была отклонена, я проверил это, используя:

bitcoin-cli -regtest decoderawtransaction 01000000012db211b32295f7ca3e9cdd9f3f0ea12bd938f8fc62c372f1147882dea35a197e000000008b4830450220772661303176b4505f16c512edfdc0dda7a480ace7f4dd23275902e0575c1e8b022100d356bd2e8b4abd366a6e71abaeb689f682edeae42355c638cbb0be4a3df5a924014104aa69850ffcdb48814354c2a9828611a54d9baafa215c8756eb2b53597f0beeef9a393071b12ab535282ae62778b103a8b3de4ecd4505f33343d58ca9bb4f1d2effffffff0180f0fa02000000001976a91426fc9e0484367d611996e0ccf583aa9976a0c98488ac00000000

Раньше я не знал об этой команде и использовал blockchain.info .

Я обновил и выделил это в своем вопросе.

Уяснив это, я обнаружил, что ошибка ( tx-hash value in < value out) была вызвана моим приложением. Я предполагал, что выходной адрес, который меня интересует, всегда является первым в транзакции (т . е "n" : 0. ).

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

В tx 985ca8c35dd2e0bd4c583a3254352f740445fb0c19cca6922a3f71458ede6246вы пытаетесь отправить 10 000 000 биткойнов на адрес 1KVe5QTdQ4cXfqmtJBxqKQrei5zvCmRpWh, тратя на это один вывод стоимостью 0,01038375 биткойнов.

createrawtransactionпо дизайну не будет проверять, равна ли общая сумма входов или больше по значению, чем общая сумма выходов. signrawtransactionна самом деле это тоже не волнует, поэтому все сводится к тому, sendrawtransactionкто выполняет эту проверку, и если inputs value< outputs valueона терпит неудачу с этим сообщением: CheckInputs() : tx-hash value in < value out.

Спасибо за ответ, но как насчет транзакций livenet, таких как blockchain.info/rawtx/… . Там я вижу "value" : 2249930000, т.е. представление Сатоши.
@Rmn, так это был blockchain.infoответ? Я бы посоветовал вам getrawtransaction tx-id 1выполнить этот запрос и обновить свой вопрос, и тогда, возможно, мы сможем найти решение вашей проблемы.
Проблема в том, что я не являюсь активным пользователем биткойнов, но все еще только развиваюсь , поэтому testnetу regtestменя нет файла Blockchain... чтобы получить его сейчас, потребуется довольно много времени. Однако я проверю testnetи обновлю свой вопрос.
Что касается regtest, блокчейн генерируется «на лету», поэтому вам не нужно больше ничего скачивать с других подключенных узлов (которые, если таковые имеются, в любом случае должны принадлежать вам).
Действительно, просто парсинг необработанных транзакций bitcoindvs. blockchain.infoотличается... Итак, я перефразирую весь свой вопрос.
Поле «значение» в необработанной транзакции: округленные биткойны (с плавающей запятой) или сатоши?
СпросиСетьПолитика конфиденциальности1y, 0v