Really an unusual set of trx. Looking here, and "turning on" the scripts, indeed show HASH_256 as the first two hex chars of the script: https://blockchain.info/tx/af32bb06f12f2ae5fdb7face7cd272be67c923e86b7a66a76ded02d954c2f94d?show_adv=trueOP_HASH256 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f OP_EQUAL The TX_Out script would be : AA20000000000019D6689C085AE165831E934FF763AE46A2A6C172B3F1B60A8CE26F87 so 0xaa is interpreted as HASH256. I have once created a picture of the most common used scripts, and those with HASH160 are well known, but this is the first time I see HASH256. Hope the picture helps.  |
|
|
|
this can be closed. After several backups and restores, it is quite likely, that a mismatch of versions has happened. I had a deeper look and found some files with versions pre-2.5.   Meanwhile I updated to 2.7, and all works as expected. No more issues with "too high S-Value.". |
|
|
|
just to verify, if my script is working correctly: is it " 33f7emzpgYE4JC5Wo4Gk8HZKYRu1Cqcguu" ? I tried to decode the scriptsig, and get this result: 47: OP_DATA_0x47: push hex 47 (decimal 71) bytes as data
30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
44: OP_LENGTH_0x44: length of R + S
02: OP_INT_0x02: type tag indicating INTEGER
20: OP_LENGTH_0x20: *** this is SIG R
0CF183787D2F7EF3:87E14046E7F38D94
42B316D690B3116D:A6C60D4B8D1BB543
02: OP_S_INT_0x02
20: OP_LENGTH_0x20: *** this is SIG S
301693BA31B5AAD8:D7542A673E6B96F4
830152EC6D26F3A8:BF1D3776F39DE51D
01: OP_SIGHASHALL: *** This terminates the ECDSA signature (ASN1-DER structure)
48: OP_DATA_0x48: push hex 48 (decimal 72) bytes as data
30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
45: OP_LENGTH_0x45: length of R + S
02: OP_INT_0x02: type tag indicating INTEGER
21: OP_LENGTH_0x21: *** this is SIG R
009CD1C1B3E1EC93:CD5852B42FA56B6A
F706A09B00E056D1:FD1313FAB423BB79
43
02: OP_INT_0x02: type tag indicating INTEGER
20: OP_LENGTH_0x20: *** this is SIG S
1327347F6C9BC810:6DCA4EB84DE36BD2
42F0970388AB7CD5:86E1843B84B04520
01: OP_SIGHASHALL: *** This terminates the ECDSA signature (ASN1-DER structure)
47: OP_DATA_0x47: push hex 47 (decimal 71) bytes as data
52: OP_2
52: OP_2
###### we go multisig, ( 2 out of n multisig ?) #######
21: OP_DATA_0x21: compressed pub key
02309D6A9D97A3E8:14247D471DDC2C47
6C046F9C07D98079:D861E34479C19497
EA
* This is MultiSig's Public Key (X9.63 COMPRESSED form)
* corresponding bitcoin address is:
1H7GTVGAm911rBx5myQv7EeACizgY81MWL
21: OP_DATA_0x21: compressed pub key
03C511B8FE3A5E60:AD16BB14B0865F8A
3F192DDB386C4F8D:23F72EDD24764E0E
23
* This is MultiSig's Public Key (X9.63 COMPRESSED form)
* corresponding bitcoin address is:
1NrTw95nWtA9iVZg2FLge64Y3Ei9fdhqpC
52: OP_2: push 2 Bytes onto stack
AE: OP_CHECKMULTISIG
########## Multisignature end ###########
* This terminates the MultiSig's redeem script
* corresponding bitcoin address is:
33f7emzpgYE4JC5Wo4Gk8HZKYRu1Cqcguu
|
|
|
|
>> i have spend a couple of days on understanding only a raw "unsigned" transaction >> and make a little code for it and i have not yet started on the signing part and that >> is the scariest, not because of losing money (i am just testing things here) but >> because it is so complicated and also since it is cryptographic, it is very unforgiving! >> but it is at least good kind of scary+enjoyable no need to fear  Draw a picture, and then go through the details, what is required. A single input signing process is not that difficult. You create your unsigned raw trx, and leave the PKScript (76A914 + previous trx script + 88AC) in its position. You sign the whole structure. And then you replace this PKScript with the generated signature, which is then just a string concatenation. Pay attention to the length fields, they almost always change... Where it get's a bit more advanced is with two or more inputs, cause all signatures have to be done specifically, see here: http://bitcoin.stackexchange.com/questions/41209/how-to-sign-a-transaction-with-multiple-inputsgood luck! (btw: which coding language are you using?) |
|
|
|
Hi team(s), I had installed some time ago an Electrum Wallet on my OSX as online system, and also on my SuSE Linux cold storage system. Both versions use Electrum 2.6.x. I had sent many trx to the cold storage, now I wanted to spend some. So I copied the (cold storage) master PUBLIC key to my online OSX system, created an unsigned transaction, brought it onto a USB stick, and turned on the Linux offline storage system. I opened Electrum, and loaded the (unsigned) transaction file to the cold storage wallet. I signed the transaction, and saved it to USB stick. Brought the USB stick back to my online OSX system, and opened Electrum to send it. Electrum gave me an error, saying I am using a function that requires version 2.5.1 ( , I am on 2.6.x)... I then analyzed the signed trx with my CLI tool (see also here: https://bitcointalk.org/index.php?topic=1505958.0), just to find out I had too big S-Values in the signature. I did the check with a smaller set of inputs, just to receive same result. I thought I had a problem with my scripts, so went to blockchain.info, and verified the trx ( https://blockchain.info/de/decode-tx). Verification went well, so wanted to send it ( https://blockchain.info/pushtx), just to find out, that the sysem refused to do so. I rewrote my script a bit, to precisely show, where strict signature checking shows too big S-Values, and there you go: out of 6 inputs, only input 3 was ok, all other input sigs had a too high S-Value. The Electrum generated trx code is here (added some line breaks for better readability): 01000000065d01ca223f2308644dcf3cdcb1abbebb15c8f8f923ba6e79d398e69ca0cef2363a000 0006b 48304502204608918e8d135eecd982b822c99439a0f1c073394548ab5244aa40e596bdd29702210 0a739a436608530c27fbe7b16ee017472bfd63049570c9797620ed6fda984822101210297b7974c37520054aa48eea16531bd12710c65ccae0b8f310215e808c9b79f93ffffffff9f4 b8c7f4ac20338c1a555ee1e22c6298b2cb7e257e72925531c96b9a0200e41010000006c 493046022100ea04b4243c51983b150c356064da3211006ee2ebec9ca2b56fd079077405ba85022 100b98e0c80f59bbbadec70f0c062c39158756602a706add18ca787ad5ce0e7ce9001210297b7974c37520054aa48eea16531bd12710c65ccae0b8f310215e808c9b79f93ffffffff8ee 4e6f8d271d8be1f14faa3ca7de68e317a3fdee9dceecd4270f005726e6e50f10000006b 483045022100d5a2d3a11eda6685383ad9e00917e76f656c9259bfee2f86e29111e3b653431e022 072d70f44b3ebb810b1e11fc3ecf2d9ae36b688711c835c6451eac18d1e4ff38801210297b7974c37520054aa48eea16531bd12710c65ccae0b8f310215e808c9b79f93ffffffffd58 1fb833d6cc08ade1fb6ddec166736e3737f394919c3b1457d83944c5cd8b4130100006b 48304502202ae249af840dab290e0ac8f088b975b55772fdb2bc29911a3354f701326f067102210 092abf4eb8346f509c82624d8586e87ae0bcd95dcc36b4b094b0cc381d1e6b4d401210297b7974c37520054aa48eea16531bd12710c65ccae0b8f310215e808c9b79f93ffffffff997 a0eeb12b0ee24ed45a44346bc7522ed954a428a6131bf99e86611581ca1d6010000006b 4830450220361a02ee5b56e94a925a57c125cf0d568fcc99da03d8f5457eb4a8b7793a023502210 09cea77afbe60275c288f2cec66c498c7d3b64e65e69aa1f81f4e2b640b27108d01210297b7974c37520054aa48eea16531bd12710c65ccae0b8f310215e808c9b79f93ffffffff931 935c63a33c328ad1786b4bae296d29da8721378715def05554ff4a62181f44c0100006b 48304502203503b58673c329bdb04bfe396d946bede5fe4795ad65722a55f088a04afa1e5902210 0ed60b811c067a3e8a1d240abc444734c64dbbd8e655e69ac4c883fd933bd7c8201210297b7974c37520054aa48eea16531bd12710c65ccae0b8f310215e808c9b79f93ffffffff025 c5d0000000000001976a914284d39d05e3600ddb07bc668d8257a64a1dc868588ac20a107000000 00001976a914c2df275d78e506e17691fd6f0c63c43d15c897fc88ac00000000 I then corrected the high S-Values via my script tools, and adapted the length fields (a trx analyzer is really helpful here). I then handed it again into blockchain.info, and it went out without issues: https://blockchain.info/de/tx/811848214a52c823f53eaaa302eaddb7dd2b03874174c9202d291ac35868fb74 Any hints? (also: I am unsure, if this is the right forum to post to, or if this needs to go somewhere else. If so, please direct me to the right section). thx |
|
|
|
I meant to understand from the forum, that using multisig helps to increase security. It adds a layer of complexity, but reduces the risk, if your private keys are partially compromised, that bitcoins can be stolen easily. So one could even think of having one set of keys in an online wallet, the others offline, and both must sign a trx (or 2 out of 3; and so on...). |
|
|
|
Hi, just my two cents: I wanted to have cold sorage without any dependencies to other libraries. Just rely on OpenSSL. So I created a set of shell scripts, which would run on a standard Unix-type platform (I have OpenBSD, OSX and SuSE Linux). I could manage to do the whole cycle with some scripts, see here in this forum: https://bitcointalk.org/index.php?topic=1505958.0The script relevant for this would be "trx_create_sign.sh", use '-h' param for explanation, and the README.md. It is currently limited to a single previous trx, prev output, and a single P2PKH out. Generally: when using this approach, you HAVE TO BE very, very careful on the amounts (input - output = trx fee !). rgds, Volker |
|
|
|
Hi, The main issue is to understand, how to come from hex to PEM keys, to be able to sign offline with openssl from the shell. With some support over here I got it working: http://bitcoin.stackexchange.com/questions/46455/verifying-a-bitcoin-trx-on-the-unix-cmd-line-with-opensslThe second thing to remember is to always work on binary/raw data, and not hex representation of data. And maybe third, understanding the double hashing with sha256. I have then created a raw transaction, following the 19 steps logic from here: http://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-txThen I used openssl as decribed before, to verify the trx. It finally gave me a transaction, that I could copy and paste into https://blockchain.info/de/pushtx. I haven't had any error checking code implemented (yet), so every now and then I got an „S-value to high error“. Per specs, an s value greater than N/2 is not allowed (N is the curve order). Also I had not added strict DER checking. This is work in progress. Happy cold wallet user now  |
|
|
|
I want to further understand the signing process, especially when it comes to cold storage, so I built a set of shell scripts for OpenBSD/OSX/Linux. I know about Armory, javascript libraries, ciyam, or other webpages for cold storage and signing… not the goal here. Based on some old message by Pieter Wuille (September 29, 2012, "why OpenSSL?") here: https://bitcointalk.org/index.php?topic=114064.0 --> "We use it for ECDSA signing and verification..." I thought I’d use OPENSSL to sign and verify my code. (Is this still a valid approach?) I created a raw trx, following the first 13 steps here: http://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-txand of course supported by https://en.bitcoin.it/wiki/Protocol_specification#txExamination with the different offline tools shows the raw trx "looks ok". The raw trx produces the same sha256 hash as on the webpage. Then I wanted to use "my own keys" to build a raw trx, and get it signed with OpenSSL. My unsigned raw trx would look like this: 010000000167cc10a3b7c5c52435770b6a1cb34a6a783803f028c42e95f9364d21e64b43c301000 0001976A9147A8911A06EF9A75A6CB6AF47D72A99A9B6ECB77988ACffffffff01EC8A0100000000 001976A9140DE4457D577BB45DEE513BB695BDFDC3B34D467D88AC00000000 To sign it, OPENSSL requires DER/PEM key for doing this at the command line. How to get them? I used a (throw away) wallet, and dumped priv key. I converted the wif-c privkey via base58 conversion into hex. On the public key: in a shell script, I didn’t want to re-create the EC math to derive pubkey from privkey (maybe later, using bc and dc). So I looked up a previous trx (5a62b8697e33b59255ddab10b8f66ece0d5efec91c72134d07d90e03db61e051), what the hex code for the pubkey was… I appended this hex string with all the ASN1 fuzz, and then created via base64 conversion the OpenSSL PEM format. I verified the PEM file with "openssl asn1parse". And tested "openssl sign" with an example sha256.txt file. After signing, I "openssl verify"’d it. Result from openssl is "Signature Verified Successfully". So internally openssl "works" correctly, priv/pub key pair match (see the code below). When I then assemble the trx and sign with OpenSSL, I get this: 010000000167cc10a3b7c5c52435770b6a1cb34a6a783803f028c42e95f9364d21e64b43c301000 0006A47304402206548cb4429b40f314711d46aa2e582b71041091f70064b276f2cbb800bb73d43 022011b6fe802a4f25dfe73a0c764add96011e43a02c41d2dd65164e2a4f0177ca8b01210293ccb 70fee4d33179c93bade0a9fefd62fde5ac53adc017649f513eec599509cffffffff01EC8A010000 0000001976A9140DE4457D577BB45DEE513BB695BDFDC3B34D467D88AC00000000 And when I try to broadcast via blockchain.info/de/pushtx, I get the message "Script resulted in a non-true stack: []". Obviously OP_EQUALVERIFY and then OP_CHECKSIG don't get the expected result. So I assume my OpenSSL key conversion is "somehow" wrong. I double checked the exactly same unsigned raw trx in bitcoin-QT, and tried to sign it manually in bitcoin-QT, and broadcasted successfully : signrawtransaction '010000000167cc10a3b7c5c52435770b6a1cb34a6a783803f028c42e95f9364d21e64b43c301000 0001976A9147A8911A06EF9A75A6CB6AF47D72A99A9B6ECB77988ACffffffff01EC8A0100000000 001976A9140DE4457D577BB45DEE513BB695BDFDC3B34D467D88AC00000000' '[{"txid":"c3434be6214d36f9952ec428f00338786a4ab31c6a0b773524c5c5b7a310cc67","vout":1,"scriptPubKey":"76A9147A8911A06EF9A75A6CB6AF47D72A99A9B6ECB77988AC"}]' ‚[„$my_privkey“]‘ { "hex": "010000000167cc10a3b7c5c52435770b6a1cb34a6a783803f028c42e95f9364d21e64b43c301000 0006a47304402203d15e12271521adb6e42c3f6a5eb5020883dd2042f23783e11385fb895fa1890 02200a84ba8e8055123abb22400b5dd90dbe670a1fa1cbbc206d5da59e54f4cc9c3501210293ccb 70fee4d33179c93bade0a9fefd62fde5ac53adc017649f513eec599509cffffffff01ec8a010000 0000001976a9140de4457d577bb45dee513bb695bdfdc3b34d467d88ac00000000", "complete": true } Any help appreciated…  The code I use to assemble the PEM Key to sign with OpenSSL: #!/bin/sh
# example keys from webpage:
hex_privkey=18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725
hex_pubkey=0450863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b23522cd470243453a299fa9e77237716103abc11a1df38855ed6f2ee187e9c582ba6
sha256_string=9302bda273a887cb40c13e02a50b4071a31fd3aae3ae04021b0b843dd61ad18e
# ASN1 structure fill-ups:
pre_string=$( echo "30740201010420" )
mid_string=$( echo "a00706052b8104000aa144034200" )
echo "use pre defined ASN.1 strings to concatenate PEM keyfile:"
echo " a pre_string : $pre_string"
echo " the privkey : $hex_privkey"
echo " a mid_string : $mid_string"
result=$( echo $hex_pubkey | cut -b 1-66 )
echo " the pubkey : $result"
result=$( echo $hex_pubkey | cut -b 67- )
echo " $result"
# assemble the hex key
result=$( echo $pre_string$hex_privkey$mid_string$hex_pubkey | sed 's/[[:xdigit:]]\{2\}/\\x&/g' )
printf "$result" > tmpfile
echo " "
echo "and base64 this file. PEM keyfiles also want some nice surroundings: "
result=$( base64 tmpfile )
echo "-----BEGIN EC PRIVATE KEY-----" > privkey.pem
echo $result | cut -b 1-64 >> privkey.pem
echo $result | cut -b 65-128 >> privkey.pem
echo $result | cut -b 129- >> privkey.pem
echo "-----END EC PRIVATE KEY-----" >> privkey.pem
cat privkey.pem
echo " "
echo "corresponding pubkey.pem (openssl ec -in privkey.pem -pubout -out pubkey.pem)"
openssl ec -in privkey.pem -pubout -out pubkey.pem > /dev/null 2>&1
cat pubkey.pem
echo " "
echo "verifying the signing process with test data (openssl asn1parse -in privkey.pem)"
echo $sha256_string > sha256.txt
openssl asn1parse -in privkey.pem
echo "-->openssl pkeyutl -sign -in sha256.txt -inkey privkey.pem -keyform PEM > privkey_pem.sig"
openssl pkeyutl -sign -in sha256.txt -inkey privkey.pem -keyform PEM > privkey_pem.sig
echo "-->openssl pkeyutl -verify -in sha256.txt -inkey privkey.pem -sigfile privkey_pem.sig"
openssl pkeyutl -verify -in sha256.txt -inkey privkey.pem -sigfile privkey_pem.sig
echo " "
|
|
|
|
when looking at http://offlinebitcoins.com/, the secret that can be entered is the 32bit HEX string, that effectivly is the private key. I assume that you want to convert it into a WIF key, so it can be used in a wallet - this is what http://offlinebitcoins.com/ can do for you, one after another ... There are seven steps behind, as explained here: https://en.bitcoin.it/wiki/Wallet_import_format. There is the bitcointools and botg (bitcoin of the grid: https://bitcointalk.org/index.php?topic=23081.0). These are shell scripts running on unixoid OS, with a bit fiddling around (it has base58; sha256 and ripemd160 can be coming through openssl), so you'd quickly get what you are looking for. I am not aware of a Windows shell script suite. |
|
|
|
|
removed old link to zipped file, everything on github now.
Added a cool feature to directly load trx from network (blockchain.info):
./trx2txt.sh -vv -t 7264f8ba4a85a4780c549bf04a98e8de4c9cb1120cb1dfe8ab85ff6832eff864
have fun :-)
Volker
|
|
|
|
Hi, thought I share my command line tool with the audience. I wrote the script to better understand the transaction details. I wanted to start with the python tools and perl tools, but had several issues on versions, links, required subtools, dependencies - after a day I got tired. I wanted to be able to analyze my trx on OpenBSD, MAC OS X and SuSE Linux. No tool could provide this, so I thought I'd give it a try. Need some POSIX compliance here... - the script (trx2txt.sh) produces a transaction output similiar to the JSON outputs that can be found on blockchain.info. - it shows the OpCodes of the TRX_IN sig scripts and TRX_OUT public key scripts (hex values) - shows type of transaction script (P2PKH, P2SH, MULTISIG, ...) - it shows the corresponding bitcoin address (hash). - there is a detailed README with the file, supporting doc and state machine picture (and each script is heavily commented) - there are test cases included The link is here: nowarra.ch/Volker/160610_TRX2TXT.zip (removed 15June2016) The code is not (yet?) beautified, nor made for performance reasons... And yes, there is room for improvement enjoy! |
|
|
|
This post shows the steps I did to have a RaspberryPi2 with OpenSuSE running "pruned" Bitcoin 12 as a Full Node. this is not a howto for beginners  RaspberryPi2 is an ARM architecture, so no precompiled packages exist. I wanted to realize a node with pruned Bitcoin 12 client. I am a long time openSuSE user, so wanted to get this on the RPi2. At the beginning I had issues with the images from openSuSE Tumbleweed - see here: https://www.raspberrypi.org/forums/viewtopic.php?f=87&t=105697&p=915156&hilit=Tumbleweed#p915156… which were finally solved. So logged in as root, and created the user „bitcoind“. As the Tumbleweed JeOS comes as a minimal install, I was prepared to do several updates with YaST or zypper. I started with the firewall, just to be on the save side. I only allowed ssh and port 8333 from internal network. I don’t want to go into details of all software packages, but you need/want firewall, lynx, git … After all was installed, my next issue was „git clone“: git clone -b 0.12 github.com/bitcoin/bitcoin.git It gave me a hard time. Always this error message on SSL keys. All help messages to download certificates from your webbrowser and save as PEM… didn’t work for me. Maybe an issue on the ARM platform. So I took it from a working Linux box, were "git clone" was working. I copied into a subfolder called "bitcoin" to my RPi2. The description on how to proceed is here: https://bitcoin.org/en/full-node#other-linux-distributionsI worked through it, and then went on with the "Bitcoin Core Deamon". So before being able to start "bitcoind", we obvioulsy to compile the core deamon. You may find info here: less doc/README.md less doc/build-unix.md To be able to run through this cycle, you need again yast or zypper: automake, libtool, gcc-c++, openssl, boost, libdbd4.8 devel (berkeley DB), make, boost-devel, libevent-devel, and maybe some more … ./configure --disable-wallet --without-gui make -j2 After approx. 2hours and 15min the compile was done. When I start bitcoind, I can see with "du -h -s" in the .bitcoin directory, that "pruning" works. I had added a line in the config file for 2Gig and later for 5 Gig, and it worked quite fine. Things todo: create a separate user partition, and make root mounted readonly. Happy bitcoining  |
|
|
|
|
Show Posts
