Hot answers tagged

58

Assuming all the inputs you are spending are from regular "pay to address" transactions, each input will contribute 180 (plus or minus 1) bytes to the transaction. Each output adds 34 bytes to the transaction. And there's a fixed extra 10 bytes which are always present. The "plus or minus 1" comes from the fact that each input needs a signature to be ...


23

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: Outpoint (36B) Script Length (1 ~ 9B) ScriptSig(?) Sequence (4B) TxOut Count (1 ~ 9B) For each TxOut: Value (8B) Script Length(1 ~ 9B)* Script (?)* LockTime (4B) Assuming a standard ...


19

It is important to understand that the transaction fee you have to pay to make a payment is based on how you received the funds you are using to make the payment. The outgoing payment (assuming it's only to one place) is always going to be the same size. So the 'out' part will always have two standard "pay to address" scripts. The size of the 'in' part will ...


17

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 ...


13

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). ...


13

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 ...


12

Is it possible to covert a p2pkh adrress to a p2sh adress? Don't. 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 ...


9

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 ...


8

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 ...


7

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 ...


7

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 ...


5

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. ...


4

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 ...


3

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 ...


3

I recently had the same question and made a small script to compute it (using this python library). Here you have a cumulative plot showing the number of transaction outputs of each kind over time:


3

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 ...


3

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 ...


3

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.


3

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 ...


3

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.


2

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 ...


2

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 ...


2

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 ...


2

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 ...


2

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 ...


2

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: P2PKH 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 ) ...


2

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 ...


2

The execution order is: scriptSig/witness to construct the initial stack scriptPubKey (which may invoke redeemScript evaluation in case of P2SH, and witness script invocation in case of P2WSH) The scriptCode is simply a name for "the code being executed". Inside scriptPubKey evaluation, it is equal to the scriptPubKey. Inside redeemScript evaluation, it is ...


2

Is it safe to only give them the option of receiving to a "compatibility" address? Yes. All modern wallet software understand P2SH and can create transactions that send to such addresses.


1

There is a bit of a misunderstanding of what an address is here. When Bitcoin are sent, they're not moved "to an address" so much as they're locked to the fulfillment of some authentication requirement. The standard scheme hereby is "pay-to-public-key-hash (p2pkh)" which could be described as "to spend these funds, you need to reveal a public key which ...


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