Hot answers tagged

8

It's a Segwit output and hence does not have the address associated with it. The locking script for a Segwit transaction includes the witness version (0 in this case) and the redeem script (which is 43aac20a116e09ea4f7914be1c55e4c17aa600b7). Given that the length of the redeem script is 20-byte, this locking address is pay-to-witness public key hash (P2WPKH)....


7

P2WPKH - This stands for "Pay To Witness Public Key Hash" and the scriptPubkey is OP_0 0x14 {20-byte-hash}, where OP_0 is the version, byte 0x14 is the size of the data, and the {20-byte-hash} is a HASH160(PubKey). P2WSH - This stands for "Pay To Witness Script Hash" and the scriptPubkey is OP_0 0x20 {32-byte-hash}, where OP_0 is the version, byte 0x20 is ...


6

Other than the total value needing to be correct (no more than the block reward plus fees), the outputs of a coinbase transaction are completely unrestricted and act the same as any other transaction.


6

As far as I can tell, P2TR is better than P2WSH in almost every way. I cannot think of a case in which it would be a significant advantage to use P2WSH over P2TR, except that P2WSH is already established. Privacy P2TR outputs will stand out at first since there will be few of them. In the long term, the anonymity set of P2TR is likely to be larger since both ...


6

First of all, what are you trying to do? Why do you need a P2WSH address? A P2WSH address (and P2SH addresses earlier) send coins to a script, which requires satisfying that script to decode. A script of the form <key> CHECKSIG is wasteful - you should be using P2WPKH instead. In general, you use P2WSH when you have more complex spending requirements ...


5

bitcoin-cli's signrawtransaction expects a few arguments. You got most of them right, but forgot to add the details for redeeming the actual p2wsh part. Specifically for p2sh(p2wsh), you'd need to provide both : $ bitcoin-cli -tesnet signrawtransaction \ ...


4

In addition to the rationale given in BIP 341, I know of two arguments for not supporting P2SH-wrapped taproot outputs: backwards-compatibility: P2SH-wrapped segwit outputs were included in BIP 141 as a way to allow unupgraded wallets to send outputs to upgraded segwit wallets[0]. Segwit activation happened around 4 years ago, and almost all wallets/...


4

Because P2SH addresses are too short to provide typically desirable levels of security security level we expect from Bitcoin, against certain attacks. On top of that, they use bech32 encoding rather than base58, which means they're slightly longer for the same amount of data, but are case insensitive instead. For any kind of "multi party" address (...


3

P2PKH addresses are 33-34 characters long, use Base58Check encoding, and (on mainnet) start with "1". P2SH addresses are 34 characters long, use Base58Check encoding, and (on mainnet) start with "3". P2WPKH addresses are 42 characters long, use bech32 encoding, and (on mainnet) start with "bc1q". P2WSH addresses are 62 ...


3

When you push items on the stack you must use an opcode to state how long the item you are pushing is. In this case you want to push 33 bytes so OP_PUSH33 Your script would be: OP_PUSH33 0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 OP_CHECKSIG or 210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac. Then your ...


3

To generate a P2WSH address, you need to have some script. The most easiest one you can use is a multisig script. You can do this with the addmultisigaddress. If you do something like addmultisigaddress 1 '["37Ju7oTbPfe5qNAHYiAKfdTtVvCSP3TTdL"]' "" "bech32" you should get a P2WSH address.


2

Native segwit outputs (P2WSH and P2WPKH) do not currently have an address type, so there are no addresses for these outputs.


2

For signatures in P2WPKH and P2WSH spends, the sighash algorithm is described in BIP143. It is very different from the one used in legacy spends.


2

I found the problem, in the bip143 tx digest preimage, the scriptCode needs to be preceded by the length of the scriptCode. In this case 0x47


2

The encoding is bech32 not base58, which is slightly longer but vastly easier to type due to a lack of capital letters, and the inclusion of error correction rather than error detection. SegWit scripts use SHA256 not RIPEMD160 for the hash function, which is longer and stronger.


2

This is a transaction with three P2WPKH (native segwit v0 single-sig) inputs and a single P2WPKH output. For P2WPKH, the scriptPubKey (the locking script encoded in an output) contains a witness program that commits to the hash of a public key. The witness in the input therefore reveals the corresponding pre-image of the hash in the form of the public key (...


2

Bech32 encoding, apart from the checksum, is a simple matter of converting base-256 (8-bits) to base-32 (5-bits). Base-256 is the byte array (octet string) that you get from a hash function. Only focusing on first 3 bytes of the hash: as hex = 0x18 0x63 0x14 as bytes = 24 99 20 as binary = 00011000 01100011 00010100 In order to ...


1

TL;DR: A 2-of-2 P2WSH input should be conservatively estimated with 96 vbytes. Standard 2-of-2 P2WSH inputs generally weigh 95.5, 95.75 or 96.0 vbytes, depending on whether the r-values in the signatures are low or high. A wallet using signature grinding (which is highly recommended) will always produce 95.5 vbyte inputs. 96.0 vbytes is the conservative ...


1

I just realized that there are in fact these two lines which takes into account the size of CTxOut: size_t nSize = GetSerializeSize(txout); ... ... nSize += (32 + 4 + 1 + (107 / WITNESS_SCALE_FACTOR) + 4); so based on this, a p2wsh output (43 bytes) would have a dust limit of: = 43 + (32 + 4 + 1 + (107 / WITNESS_SCALE_FACTOR) + 4) = 110 bytes then using ...


1

Yes, the scriptCode would be that multisig script.


1

As there are no known preimage attacks on RIPEMD160 and SHA256, it is impossible to know what the contents of a redeemScript are given just the scriptHash. So yes, it is impossible to know what conditions are necessary to spend from an address given just the address. That is one of the main points of using scriptHashes: it hides the redeemScript from others ...


1

This is indeed an error in the book: https://github.com/bitcoinbook/bitcoinbook/issues/440 See this diff for the correct steps.


1

Seems to me that ... creating a Pay-to-Witness-Script-Hash (P2WSH) output that would look like this: 0 9592d601848d04b172905e0ddb0adde59f1590f1e553ffc81ddc4b0ed927dd73... means that this hash is an example not derived from the data above


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