We’re rewarding the question askers & reputations are being recalculated! Read more.

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


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

The security implication of removing a checksig operation from the encumbrance script is that the coins can be stolen while in flight by anybody, and especially by miners. Obviously, on testnet, only someone who's bored or interested enough to grab the coins will take the time to "attack" your transactions. There's not much sense in listing and analyzing ...


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

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

Keep in mind that the ledger itself, if compromised could leak the pk in other ways. These methods I outlined will only confirm to you that a given address belongs to the set of private keys you hold, not that you're the only person holding these pks like you said: one way you can cheaply verify that is to simply take the address and send a little bit of ...


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

When an input redeems a P2PKH output (pay to an address starting with a 1), the format of the input script (the scriptSig) is: [signature] [public key]. Because public keys are included in both standard input scripts (redeeming P2PKH outputs) and output scripts (P2PK), the Script.getPubKey() method has been written to return the public key in either input ...


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

Assuming that you are able to create the raw redeeming transaction yourself, it is possible to pass a signed transaction to bitcoin core's signrawtransaction (or signrawtransactionwithwallet on new releases), along with a json to describe the utxo being redeemed, to verify correctness. In this example I'm setting up a json for redeeming a p2wsh ...


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.


1

It's pretty simple, to do this conversion all you need to do is: decode the address using base58check change the first byte from 0x32 to 0x5 encode using base58check


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