Here are some calculations based on the Protocol Documentation.
A Bitcoin Transaction is composed of the following:
Version (4 Bytes)
TxIn Count (1 ~ 9B)
For each TxIn:
Script Length (1 ~ 9B)
TxOut Count (1 ~ 9B)
For each TxOut:
Script Length(1 ~ 9B)*
Assuming a standard ...
Yes, you could send bitcoins directly to the public key: in fact, both Pay-to-PubKey (P2PK) and Pay-to-PubKey-Hash (P2PKH) were introduced in the first Bitcoin release.
IIRC, P2PK is still used for Coinbase transactions sometimes, today.
P2PK transactions are slightly bigger for outputs but significantly smaller for inputs.
One advantage of P2PKH is that ...
The original reason why addresses were a public key hashes is something you'll need to ask Satoshi. My guess however is that it was just shorter and more convenient (note that compressed public keys weren't known at the time).
When compressed public keys were discovered it was simply easier to stick to the existing address scheme (it didn't require any ...
Is it possible to covert a p2pkh adrress to a p2sh adress?
Addresses are determined by the wallet. It's the receiver's wallet saying "I will accept payment when it arrives at address X". Sending it to another address may mean the wallet doesn't recognize it. Worst case, if the receiver has some hardware security module that stores the key, it may ...
As @Murch correctly pointed out it is indeed possible to send bitcoin to either a public key or to the hash of a public key.
The original motivation for using hashes of public keys was to shorten the size of the address. Public keys in their uncompressed form are 64 bytes long whereas RIPE-MD outputs 20 bytes (+5 bytes of checksum and version).
Is it safe to receive funds at this 1FJJd... address?
Kind of. Your wallet knows the private key that corresponds to that address as it is the same private key for the bech32 address. However it does not necessarily know that it should be looking for coins sent to this address, so any transactions that send coins to that address may not appear in your ...
The first number does not include the prevout, sequence number, or the length byte for the scriptSig. It also uses 65 bytes for the public key (which is correct if it is uncompressed, but compressed keys of 33 bytes are more common now). Correcting it gives 139 + 36 + 4 + 1 + (33 or 65) = 148 or 180.
The developer in the third case forgot to include the ...
Pay to Public Key Hash has existed for the entirety of Bitcoin's life. P2PKH addresses have existed since the earliest release of Bitcoin. Creating P2PKH addresses and sending to P2PKH addresses was possible to do with Bitcoin 0.1.0.
However these early versions of Bitcoin also supported a Pay to IP address feature where your wallet would contact the ...
An algorithm called Public Key Recovery exists for ECDSA, which lets you construct the public keys for which a given pair of message and signature would be valid.
To explain the algorithm, remember that ECDSA signatures are pairs (r,s) for which sR = mG + rP. In this equation m is the message hash (which must be a hash of a known message), P is the public ...
The public key is first SHA256 hashed and then RipeMD160 hashed. A Bitcoin address is actually an encoded hash of the public key.
A public key is 65 bytes long (0x04 + 64 bytes public key) or 33 bytes when compressed (0x02 | 0x03 + 32 bytes public key).
However, why not RipeMD160 it and make it shorter? It'd become 20 bytes. Of course, it'd be great if it ...
Displaying two would be justified if you were asking about a BC1 p2wpkh vs a 3xxx p2sh(p2wpkh) because not everything supports BC1 but its pretty good to use when supported.
Displaying two isn't useful between p2pkh/p2sh as you've asked about because p2sh is supported everywhere and many wallets and services have used p2sh exclusively for a long time.
There are several reasons for this, some historical and some more recently:
At first, addresses were probably not intended to cover everything Bitcoin Script could do. They were a fallback for the case where the recipient was not online (we're calling addresses still addresses because they were originally IP addresses you'd connect to to request a ...
You can’t assume that any given software will be know to go searching for arbitrary encodings of the public key you’re “converting” to. Depending on the wallet software on the other end, your payment will likely to be missed or at worst lost entirely in the case of a hardware security module that can’t be altered.
There's no situation in which you should ...
The secret is that it is being interpreted as an opcode.
Opcodes 0x01 through 0x4b (decimal 1 to 75) are opcodes that specify the length of the data being pushed after them, as their own numerical value. That is to say, 0x01 means it is followed by 1 byte of data, 0x02 means 2 bytes, and so on.
This lets you push up to 75 bytes of data using a single op code ...
A transaction which spends from a P2PKH output provides both the signature and public key in the input script. So the public key is part of the transaction data, just the spending transaction, not the output creating transaction.
The signature is mathematically generated using the private key and the message, but is not the message itself (it uses the hash of the message during the signing process, the message is not recoverable from just the signature). It's just a value (specifically, it is 2 numbers, called r and s) which can be verified against the public key and the message to ...
A transaction contains a reference to the output that it is spending from. So all you would be doing is just rebroadcasting the same transaction over and over again. Since transactions are identified by the hash of the transaction, the transaction you are rebroadcasting is exactly the same thing as the one already broadcast, and all nodes will treat it as ...
The earliest client by satoshi had both.
P2PK was default for mining and payments received using the interactive IP-to-IP payment protocol; P2PKH was intended for use in non-interactive payments.
Compressed keys were discovered later and no change in software was required to support them.
A single private key can lead to different addresses, depending on the script it is used in - These include p2pkh, p2wpkh, p2sh-p2wpkh.
Electrum prepends the script type to the private key during export and import so that it knows which address to derive and check for outputs on.
The error hints that you're not signing the transaction correctly.
In fact, you're generating a signature with:
txHash := updater.Data.UnsignedTx.TxHash()
sig, err := privkey.Sign(txHash[:])
But the current transaction hash is not what you need to sign. Instead, you should use HashForSignature for legacy input types:
sigHash, err := updater.Data.UnsignedTx....
No, you are not missing anything. Yes using P2PKH obfuscates the public key, and yes the public key will be revealed when the UTXO is spent (the public key is needed to check the signature). Hence, the obfuscation of the public key only exists until the UTXO is spent and not after. This is why it is recommended not to use the same address twice. If you ...
So how we can verify this transaction is valid without having the public-key?
The signature includes the public key corresponding to the private key that made the signature.
If we attach the public-key with the message then why spending time finding hash of public-key in the first place?
It's not clear what you mean by "the public key". Whose public key ...
http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html explains manually signing a transaction, and helped me alot (next to the online readable book "Mastering Bitcoin" from Andreas). Looking at the example tx from before: https://blockchain.info/rawtx/e46a88ed211c1ee7f34f0f4828611da52404c3282416ae1e3b7096f9dddc6c4e?format=hex
one can see the ...
While I agree with Pieter that you generally should not do this, there is some technical understanding to be gained by knowing how this could be done. The following is for reference:
A P2PKH address A is created from the public key K by the following:
A = BASE58CHECK( 0x00 HASH160( K ) )
Where HASH160( K ) is equivalent to RIPEMD160( SHA256( K ) ...
Most bitcoin nodes only allow a few specific types of scriptPubKey, including P2PK, P2PKH, OP_RETURN, P2SH, native witness and multisig. Those are the 'standard types', others are not related by default (initially for security reasons due to bugs).
So addresses with non-standard pubKeyScripts would be basically unusable on the network as it is, and there is ...
There is spending condition and ownership condition. The spending condition is set by the previous sender of the funds in the pubkey script: “proof that you can create the hash which belongs to this address”. With the one way hash function this proofs, that only “you” can be the individual, to further spend the funds.
You explained it correctly with the ...
1) The addresses would obsolete after one use.
2) If someone does a Sybil attack, s/he can prevent the transactions from relaying (which may also happen now), but also s/he can make a fake transaction from that address and relay it, as the attacker knows what the preimage is.
3) Even without a Sybil attack, someone could take advantage from eventual ...
I'm afraid you have a bug in your mining software, and your coins are gone.
Instead of sending to the P2SH address, a block was created with a P2PKH output script, reinterpreting the script hash from the P2SH address as a public key hash. This happens somewhere in broken software that doesn't support P2SH and additionally also fails to check the address ...
Is it technically correct to say that if I share my address with the
network, nobody has access to my pubkey still?
Yes, if your address is a standard address, then deriving the public key from an address is practically impossible (because it is hashed). But as soon as a transaction is made which spends funds sent to that address, then the public key is ...