62
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 ...
24
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 ...
13
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 ...
11
The answers to your questions, in order:
The fee paid for a transaction is determined by the size of a transaction. Currently, if you want to do fancy things with bitcoins, you need to put a script in the transaction that sends them -- each output includes a script giving the conditions under which it may be used as an input. OP_EVAL, p2sh and CHV (check-...
9
Here's a working example that lays the groundwork for answering your question:
Alice wants to pay Bob, so she asks Bob for an address.
Bob wants to receive payment to a P2SH address.
So Bob creates the redeemScript and then uses that to create a redeemScript hash, which is then encoded into a P2SH address.
Bob gives the P2SH address to Alice, and Alice pays ...
9
Why does this document seem to imply that the birthday attack only works for multisig P2SH and then only for one of the signers?
The birthday attack (to the best of my knowledge) requires that the P2SH address is constructed from a script which involves both a key of the victim and the attacker. That is typically only the case for multisig, but is not ...
9
bech32 produces smaller transactions than P2SH segwit transactions.
one extra byte per output to create P2SH outputs than to create bech32 utxos (P2SH uses OP_HASH160 and OP_EQUAL in addition to a 20 byte hash in its script, whereas bech32 just uses a fixed 00 byte in addition to a 20 byte hash), and
23 extra bytes per input to spend from P2SH utxos than ...
8
You get this error because Bitcoin has tried to validate the script, and failed, because not all of the signatures necessary were added in the previous signrawtransaction. You can also tell this because complete is false.
You need to take it to clients that have the other keys necessary, and run signrawtransaction on the transaction there too.
8
You're correct so far, you just stopped before you were finished. As BIP16 says, it "defines additional validation rules that apply only to the new transactions" -- specifically, "{serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey."
So:
1) The ...
8
The script is maintained by the intended recipient; he is the one responsible to keep it and not to lose it. The nodes do not store any database of the scripts.
The script is provided by the spender upon spending the p2sh as part of the scriptSig data. For the exact specification of how this data is structured, see BIP 16 by Gavin Andresen. This allows the ...
7
Here is my personal opinion as to why:
1) There are no release binaries available for the new client, so it must be compiled from source. Some of the smaller pools and P2Pool users may not have the technical knowledge how to do this.
2) If you are running a modified client merging the changes from the latest P2SH code is not straight forward. Nobody wants ...
7
I've been hunting for this information myself, and had to dig to the bitcoin source code to find the answer - couldn't find it anywhere else.
There is a hardcoded logic in bitcoin for P2SH validation:
The stack is backed up between the steps 2 and 3 (generally - between scriptSig and scriptPubKey execution).
After both scripts are executed and verified, ...
7
The difference lies in the encoding and the underlying representation in the transaction data stored on the blockchain.
The 3-segwit addresses are known as P2SH-P2WPKH or P2SH-P2WSH. This stands for Pay-to-witness-pubkey-hash wrapped in pay-to-script-hash and pay-to-witness-script-hash wrapped in pay-to-script-hash respectively. This was done to provide ...
7
As you say, there are two separate concerns here:
There are some scripts that might cause harm to the network.
There are some scripts that might make future upgrades harder.
For the case of harm to the network, the non-standard transaction check was first implemented by Nakamoto before P2SH existed, so it couldn't be so easily circumvented. This gave ...
7
This structure contains data required to check transaction validity
but not required to determine transaction effects. In particular,
scripts and signatures are moved into this new structure.
The witness is a serialization of all witness data of the transaction.
Each txin is associated with a witness field. A witness field starts
with a var_int ...
6
No. A "multisig address" is really a hash of a redeem script encoded as a P2SH address. Redeem scripts can't be nested, which means you can't include one redeem script inside another redeem script, so it is impossible to implement the feature you describe under current Bitcoin consensus rules.
6
Yes, OP_HASH160 consumes the top stack element and replaces it with its hash.
So how does P2SH work, if the script is consumed after HASH160 runs?
Here's how P2SH transactions are processed:
Execute the input script (from this transaction)
This is the transaction that only contains push-data-onto-stack commands.
AKA scriptSig
Execute the output script (...
6
What are the specific changes which have been made (ie relaxed standards)?
Gavin Andresen made this pull request proposing the change, as well as this rationale document describing why he supported the change.
Does it only apply to P2SH Txns?
It applies only to P2SH redeem scripts, which is the script that is run to see if you have the data required to ...
6
Until a P2SH-P2WPKH UTXO is spent and the redeemScript is exposed, a P2SH-P2WPKH address is indistinguishable from a non-segwit P2SH address (such as a non-segwit multi-signature address)
Reference: https://bitcoincore.org/en/segwit_wallet_dev/
That's because a P2SH address is still a hash of the script, regardless of whether the script is an embedded ...
6
There's no big difference for users between the two. The fee is lower while using native Segwit address (bech32), and the address format differs.
Let's look at the motivations of bech32 address authors:
Old addresses (base58) need a lot of space in QR codes, as it cannot use the alphanumeric mode.
The mixed case in (old addresses) base58 makes it ...
6
OP_CHECKMULTISIG contains a bug which consumes one extra element from the stack. Due to this, an additional OP_FALSE (0x00) is pushed for multisig scripts to make the script evaluation valid.
5
The only security concern of P2PKH is that it only requires 1 key to spend coins paid to it. P2SH just lets you be even more secure by easily putting more conditions on the redemption of your coins, like requiring more than 1 key to spend.
So, let's say I'm a person that wants to keep my bitcoins really safe, and the way I want to do that is by requiring 3 ...
5
Upon looking at the source of a number of altcoins I have found that p2sh keys are built into all the ones I checked.
For P2SH, the first address byte will be:
bitcoin: '05'
litecoin: '05'
peercoin: '75'
dogecoin: '16'
beavercoin: '05'
freicoin: '05'
protoshares: '05'
megacoin: '05'
primecoin: '53'
auroracoin: '05'
The tricky bit ...
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.
...
5
A bit of a meandering answer to the question, and to answer a side question: fundamentally what is a scaling solution?
OP_CTV does not increase the block space. Transactions using generally will use more block space actually (although it need not be a large amount), and relay can be optimized to equivalent.
But scaling is more than just a block size ...
4
As mentioned in BIP0016, this proposal will cause a dangerous-to-the-network blockchain split in the following case:
"A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners."
Therefore, at least 51% of the miners (and probably more to be really safe) must confirm that they are aware of this problem and ...
4
It's not exactly "15 operations"...
The Bitcoin address is not really a public key, but a special script that is built from special commands. From those commands you could build really weird transactions, for example the ones mentioned here, that lock funds on an address that can be accessed only if someone manages to break SHA2.
Up until now the miners ...
4
Here is the example
of the transaction from the question
the redeem script is: 514104398184a2cef0d7b73ed7a3a1d4ad16296c3c6986bed0bd72775060aae9891979eaea1efb28d7eb1da3304ec38a98b42086e3be2ceba82b0e932128ec422a6fc2210250504b2d4245544120506565722d506565722d6e6574776f726b2062657461212102553432353135362e31323234202020202020202020202020202020202020202053ae
to ...
4
Does P2SH validation create a second stack using a copy of the redeem script, and then validate that stack before moving on to deserializing the redeem script (and then validating that script as normal)?
Kind of. It really isn't a second stack but rather a copy of the original stack. Once the scriptPubKey execution is completed, the original stack before ...
4
The same private key can be used to derive a couple of different addresses. For example, there will be a different address generated depending on whether you use a compressed or uncompressed public key in the derivation.
More relevant to your question, you can use a private key to derive a P2SH-wrapped segwit address (3ASaGJ.. in your example), or just a ...
Only top voted, non community-wiki answers of a minimum length are eligible
