Hot answers tagged

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

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


3

Once an address has been spent from, the script that is used to create the P2SH address will be revealed in the spending transaction. So any addresses that have the 'm-of-n' information listed on that page will be addresses that have been spent from in the past. Interestingly, a BIP for something called Taproot was just published by @PieterWuille, which ...


2

These two things are actually not related. There are no restrictions to address reuse in the protocol. You could get away with never using more than a single address ever (although that is not recommended especially for privacy reasons) and p2sh addresses are no exception there. The redeem script encodes the conditions that have to be fulfilled in order to ...


2

A P2SH locking script on an output has the following structure: Output (scriptPubKey) -------------------------------- OP_HASH160 <scripthash> OP_EQUAL The address comes for this comes from the <scripthash>, creating a "3address". This is the standard format for a P2SH, so you can identify it and work out the address from there. That'...


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.


2

Your redeemScript contains the length byte for it. The redeemScript is really just a script without any prepended length byte. So for your script, it is 522103e07f96e5ba598431c0c994493a4ae988c9854c171d5d4bb140db0a27a4c853e421031b63f964d8c65d1d1136dcfe5033dedea88c2d411934ea48c9708410be84e5ee52ae Note how it begins with 52 and not 47. How P2SH works is that ...


1

You are computing just the P2SH address for the segwit script. However it is not just P2SH, it is a Segwit script wrapped inside of a P2SH. You actually have to first take the witnessScript (the multisig script or segwit redeemScript) and make a P2WSH output script with it. Then this script becomes the redeemScript for the P2SH script. So given ...


1

From what I understand, a non-SegWit P2PH address is obtained by hashing the redeem script ScriptPubKey I had the same problem and I have resolved it with this C++ code, and I think this code is self-describing. If you have the ScriptPubKey extract from the blk file, this is code calculate the correct address P2SH. string opcode = hex.substr(0, 2); ...


1

Let's go over this step by step. Suppose say you want to lock some bitcoins in a 2-of-3 multi-sig. Locking steps Create a multi-sig script: OP_2 <pub_key 1> <pub_key2> <pub_key3> OP_3 OP_CHECKMULTISIG. Hash the multi-sig script with HASH160 which gives you multi-sig_scripthash. Base58Check the multi-sig_scripthash with version 0x05 ...


1

You are not deriving hardened child keys. You cannot derive hardened keys from an xpub. Just because the xpub itself is hardened does not mean that its children are.


1

You might want to review BIP16 (pay to script hash) https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki The signature is not included in the redeem script, typically just the public key. (Your script could be anything, all I know is it has a CHECKSIGVERIFY in it, so I'm answering broadly...) The INPUT SCRIPT aka scriptSig of the transaction ...


1

There is no way to check the transaction separately for each signature. Either the entire transaction is valid or it is invalid. When you receive the partially signed transaction, you would need to sign it with your own private key using the signrawtransaction command in bitcoind. It would give you two outputs (1) hex which is the serialized transaction and (...


1

A Bitcoin address prefix is a function of the locking script type for a particular transaction output. Older Bitcoin Pay-to-Public Key Hash (P2PKH) scripts are associated with addresses that start with the number 1, resulting from a one byte version prefix prior to base58check-encoding being set to 0x00. Newer Pay-to-Script Hash (P2SH) transactions start ...


1

The reason you are getting a different address is because you are appending the same checksum that you got from using the 03 prefix to the new prefix + payload. You need to double hash the new prefix + payload and then append the first four bytes and then encode it in base58. If I decode your result MANDhrctLRAygo3dFckfWvEaWeQiti143C to hexadecimal, I get ...


1

The inputs of a transaction have absolutely no ability to effect the outputs in any situation. They can only define who can spend, not the conditions for how they go about spending it.


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