13

DER The Distinguished Encoding Rules (DER) format is used to encode ECDSA signatures in Bitcoin. An ECDSA signature is generated using a private key and a hash of the signed message. It consists of two 32-byte numbers (r,s). As described by Pieter here the DER signature format has the following components: 0x30 byte: header byte to indicate compound ...


8

I don't know about the rest of the string but I think the leading bytes are ordered that way to make the types of "addresses" be human reconizable. From a quick look at the source I think the leading characters, rpshnaf map like so: r = public Ripple address p = node private s = Ripple secret h = ? n = node public a = address family generator or seed ? f = ...


7

The result you are getting (3251...) is the result of sha256 on the string 0450.... The expected output on bitcoin.it is the result of sha256 on the bytes that are currently hex-encoded. To resolve this, hex-decode before hashing your input. In Python 2: import hashlib in_data = "...


6

This is specified thoroughly on the Bitcoin Wiki. The first 4 bytes are the version number, the next 1-9 bytes are the number of inputs (almost never more than 1 byte) and so on. Programitically, there are a ton of libraries that take the raw text and spit out the json as the bitcoin RPC call does in your example. They all use the same specification, ...


6

It isn't clear to me from your question what your goal is. If you want to accept all transactions and only transactions that Bitcoin would accept, libsecp256k1 alone is what you want. (You may need to use the signature normalize call if you want to match consensus acceptance instead of standardness acceptance). If you want to validate historical signatures ...


4

Segregated Witness was already a large collection of changes that impacted several parts of Bitcoin (P2P, validation, fee estimation, sighashing, script execution, ...). Many small improvements could easily have been added to the proposal (including the signature encoding, the superfluous stack pop in OP_CHECKMULTISIG, the signature algorithm, various ...


3

There are different formats used to encode public keys and signatures into binary (octet-streams). They are defined in Standards for Efficient Cryptography 1 (SEC). A public key is a point on an elliptic curve, consisting of an x and y coordinate. There needs to be a standard way for serializing these parts and deserializing them later. The standard defines ...


3

The CVarInt format is implemented in serialize.h As the comment is extensive, I'll just quote it here: Variable-length integers: bytes are a MSB base-128 encoding of the number. The high bit in each byte signifies whether another digit follows. To make sure the encoding is one-to-one, one is subtracted from all but the last digit. Thus, the byte ...


3

I believe flickr uses a base 58 scheme for encoding picture IDs in URLs, though Bitcoin's Base58 isn't compatible with flickr's.


2

To sign a transaction (message) in Bitcoin system, you need to encode the message to a point of the curve y^2=x^3+7 Perhaps you're thinking of ElGamal encryption, whereby you do need to select a point on the curve which represents your plaintext. However for signing, Bitcoin uses ECDSA, and this has no such requirement. If you're interested, the code ...


2

Find it yourself with my preprocessed ASCII strings data At https://github.com/cirosantilli/bitcoin-strings-with-txids I have uploaded a dump of all ASCII strings of length 20 or greater, including scripts to generate that data from a local copy of the blockchain by using https://github.com/alecalve/python-bitcoin-blockchain-parser The main difference ...


2

Compressing a more-or-less random number is futile. Your best option is simply to use a more compact encoding. Base64 is better than Hex but there exists may other encodings that prform better Wikipedia lists many and ranks them in order of efficiency Encoding Data type Efficiency yEnc Arbitrary, mostly non-text ...


1

I saw this tweet in which it was mentioned that F2Pool included a message in coinbase transaction related to Elon Musk's tweet: https://twitter.com/zackvoell/status/1355152428903985157 Block: 668197 Use the below commands to get the message: getblockhash 668197 getblock 000000000000000000023c31edf49adb2306d0db74e6f1f032ef76deaa7a464a 2 The first tx that you ...


1

Grubles shared the reason why this didn't work and I had issues while decoding in this tweet thread: https://twitter.com/notgrubles/status/1336709747756724227 Required the hex to be divisible by 8 basically. If it wasn't the encoder would chop off the remainder. So when you would go to decode the words, you would end up with more or less the same result as ...


1

It was the case that python-bitcoinlib's script evaluation code did not handle SCRIPT_VERIFY_STRICTENC flag. I had to create additional method, verify_nonstrict(), and make the scripteval use it when STRICTENC flag is not specified. Handled in https://github.com/Simplexum/python-bitcointx/commit/d8ab8ff76de412f90480c3c68addbbb1791d3413


1

If you want to guarantee strict DER encoded signatures which are accepted by Bitcoind then they need to be bip66 compliant(low s values(ecdsa malleability), remove leading nulls (encoding malleability)). I am not sure you are guarding for that with your decode-encode-decode cycle. These do not enforce r,s value-space constraints.


1

0x30 is there it's '0' in ascii (second character in your bytes1) >>> b'\x30' b'0' You also want to extract the signature from the scriptSig before passing it to a decoder, right now it contains both the signature and the public key.


1

right?! Wrong. I think you have misunderstood what a private key is. Bitcoin's private keys are part of a pair of keys that are used for Public-key cryptography. The private key is randomly generated data, which you need to keep secret. The only thing it can "unlock" is something that was "locked" with the corresponding public key (which is used to ...


1

Bitcoin private keys (secp256k1) are just a random 256bits "number" (256 random zero and ones), or say 32byte random data. The only constraints are, that the random number must be between 0x1 and 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD. You can calculate the public key from your private key but not vice versa (it's not practical possible)...


1

The second case is a P2SH address. You must supply the version number/magic byte for the address, which is 5 for P2SH. >>> bitcoin.b58check_to_hex('3BRu7EhouApLkW1EZ64T9o9yMuX5Rexz6f') '6ad55439d8faab476bbc0f89183ce689f8f6985b' >>> bitcoin.hex_to_b58check('6ad55439d8faab476bbc0f89183ce689f8f6985b', magicbyte=5) '...


1

CompactSize Unsigned Integers are not used in Script, they are used on the Bitcoin protocol to signify the amount of bytes that the next data structure contains. You are confusing these with ScriptNumbers, which are interpreted for Arithmetic operations inside of the Script Interpreter. It should be noted that these actually can be 5 bytes, however if you ...


1

generic big endian MPI format bitcoin-specific little endian format, with implicit size python implementation https://github.com/petertodd/python-bitcoinlib/blob/master/bitcoin/core/_bignum.py


1

I wrote a node.js program to solve this in general. var cs = require('coinstring') var hash160L = "0000000000000000000000000000000000000000" //hash representing uncompressed var hash160H = "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF" //hash representing uncompressed function startsWith(version) { var hash160Buf = new Buffer(hash160L, 'hex') ...


1

Nothing is preventing any sort of data from using Base58Check encoding, but I'm not sure why you would want to. There's already a multitude of 'altcoins' using a variety of address prefixes though, so you might run into issues should one of them become a real-world success. In reality, I'd just avoid having users typing a UUID-type string at all, then you ...


Only top voted, non community-wiki answers of a minimum length are eligible