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 ...
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 ...
9
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 to indicate ...
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
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
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 ...
8
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
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 ...
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
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
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
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
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 ...
4
For the segwit variants of an output (P2PKH becomes P2WPKH and P2SH becomes P2WSH), the witness contains the same data that would be found in the scriptSig. For P2PKH, in the scriptSig, you would have a signature and a pubkey. The same is in the witness for a P2WPKH.
For P2SH, you would have a redeemScript, signatures, and other stuff in the scriptSig. For ...
4
There are different types of addresses in Bitcoin. The simplest format is called pay-to-public-key-hash (p2pkh) which locks funds to a single private key. Another is called pay-to-script-hash (p2sh), which allows to lock funds to a script that encodes the spending conditions.
The recipient(s) of a p2sh output must reveal the redeemscript upon spending and ...
4
Yes, if you lose the redeemscript, the funds are going to be locked forever. In order to spend a p2sh output, you need to both reveal the redeemscript that hashed to the address and then satisfy the conditions of that redeemscript. If the script cannot be recovered, it cannot be satisfied and the funds will not be spendable.
3
Thomas Voegtlin , the developer of Electrum explains the reasoning in the first 10 minutes of this interview. I think he also posted same thing to Bitcoin dev mailing list some time ago.
https://letstalkbitcoin.com/blog/post/epicenter-bitcoin-69-thomas-voegtlin-electrum-spv-wallets-and-bitcoin-aliases
His main point against BIP39 is that it doesn't include ...
Only top voted, non community-wiki answers of a minimum length are eligible
