Hot answers tagged

11

Is it acceptable to mix P2PKH and P2WPKH inputs in the same transaction as described above? Yes, absolutely. In the same way that you can mix multisig and P2SH and P2PK inputs in the same transaction. When would I encounter a situation where "all txins in a transaction are not associated with any witness data" When you're not spending any SegWit outputs....


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

Okay so I think I've figured it out for anyone else wondering what exactly you have to do to derive an address from this type. In the case of the already mentioned transaction, (coinbase of block 542748) we first start by looking at the full decoded output script. 0 PUSHDATA(20) 97cfc76442fe717f2a3f0cc9c175f7561b661997 The very first OP_0 in the decoded ...


5

Adopting any deposit change at all is not as simple as "just change regex". There are a few considerations: Addresses must be generated, and generated properly. All generated addresses that are passed to the frontend must be valid otherwise you have now black-holed future user deposits. Can your signing process sign for those new address types? ...


5

Taproot inputs are smaller but outputs are larger. Specifically, P2WPKH (Native SegWit) inputs and outputs take 67.75 and 31 vbytes in a transaction, respectively, while P2TR (Taproot) inputs and outputs take 57.25 and 43 vbytes, respectively. In terms of fees this makes Taproot transactions about 1.5% more expensive when you don't use multisig or scripting. ...


5

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


5

TL;DR: A P2WPKH input should be conservatively estimated with 68.0 vbytes. Standard P2WPKH inputs generally weigh 67.75 or 68.0 vbytes, depending on whether the r-value in the signature is low or high. A wallet using signature grinding (which is highly recommended) will always produce 67.75 vbyte inputs. 68.0 vbytes is the conservative estimate allowing for ...


3

are P2WPKH and Bech32 synonyms now? No. Bech32 is also used for P2WSH addresses. Native segwit and Bech32 are synonyms. Is there such a thing as Base58 P2WPKH address? No.


2

The execution order is: scriptSig/witness to construct the initial stack scriptPubKey (which may invoke redeemScript evaluation in case of P2SH, and witness script invocation in case of P2WSH) The scriptCode is simply a name for "the code being executed". Inside scriptPubKey evaluation, it is equal to the scriptPubKey. Inside redeemScript evaluation, it is ...


2

i don't think bitcoinj support BIP-173 but you can read more from Bitcoinj repo For Segwit Bitconj 0.14 branch is ~2 years old and has got no support for segwit at all. For receiving on native Segwit addresses, you can use the master branch. For receiving on P2WPKH-P2SH, I'm not sure. If master doesn't work you can try the segwit branch (but that one isn'...


2

Feb2018: an older request, I just answer it so that future research might reveal useful data :-) To compose the redeem script for a P2WPKH, there is a fairly simple structure, I copied this mostly from here: Start with OP_0, followed by the keyhash. Keyhash is calculated with RIPEMD160(SHA256(public key)), similiar to "std" PKH. Do not use uncompressed ...


2

I might be understanding this incorrectly, but it sounds like the users and/or wallet custodian (coinbase, blockchain.info, etc) must create a P2SH-P2WPKH addresses in order for the witness data to be segregated and save on block space. Correct, you first have to receive money to a SegWit address. Witness space can only be used when spending outputs ...


2

How to quickly find the private key from Segwit P2SH address? As per today, it is impossible to find the private key from any public key or address. Also from a SegWit P2SH address. There is always hashing involved, which is a one way function. I think you maybe wanted to ask, how to come to the public addresses (see below), so that you can extract ...


2

As the protocol is upgraded with soft-forks changing script interpreter behaviour, the script-machine is extended with additional runs. Each new upgrade brings a new script run with new rules, whilst previous script runs continue to be evaluated according to older rules. Arguments need to be supplied to determine whether the newer script runs are to be ...


2

The P2WPKH actually uses the HASH160 hashing algorithm, which is just RIPEMD160(SHA256(pubkey)). The reason for using SHA256 is mentioned in BIP141: The increased size improves security against possible collision attacks, as 2^80 work is not infeasible anymore (By the end of 2015, 2^84 hashes have been calculated in Bitcoin mining since the creation ...


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

For node > 0.13 is it a trigger the say to node, Hey, I'm a segwit transaction! check in Txinwitness! For node < 0.13 Push ScriptSig inside and that's it, the transaction is ANYONE_CAN_SPEND Almost exactly right. Segwit validation code was added in Bitcoin Core 0.13.0, but mainnet activation logic was only added in 0.13.1. That means that 0.13.0 will ...


2

I assume that you're referring to withdrawals, and I think that you're probably right if the company's backend relies on bitcoind to fully process transactions. If the company's backend manually builds transactions, then that code needs to be updated. Even if you use a stateless bitcoind's RPC interface to build and sign transactions, you still need to ...


2

No, you need the private key that the address in question was derived from. There is no mechanism for the wider network to determine that an address was derived from a private key, that was derived from a specific xpriv. The transaction signature must be created using the private key that is related to the address in question.


2

You could theoretically export the wallet to a new type by seed (p2pkh to p2wpkh) but it would not recognize any utxo that came into it as the derivation for p2pkh and p2wpkh are different. It's not like with some altcoins who created new "address standards" that are just different way of hashing public keys, in bitcoin p2pkh and p2wpkh are ...


1

It is not as simple as checking the address format. Different address formats represent different output types. An address that starts with a "1" is a legacy pay-to-public-key-hash output. When writing wallet software signing transactions for this type of output requires a different order of operations to spend than let's say a pay-to-script-hash ...


1

The extended private key (xprv) can derive all the individual WIF private keys associated with that HD account. So technically it is possible to parse through the xprv keychain until you find the individual WIF private key that corresponds with the output you want to spend from. For example, if you know the output address you want to spend from you could ...


1

Private keys are 256-bit numbers. The first "HEX" you list has 64 characters, which corresponds to 256 bit, while the other two have 66 characters. Since all three share the same first 64 characters, I surmise that the library you're using simply drops the additional data beyond the first 256 bit.


1

I understand that: in "asm" i have RedeemScript. In txinwitness i have my signature and the pubblic key. Correct? Correct. in a P2SH-P2WPKH the witness contains the signature and the public key, and the script signature contains the redeem script. is it correct to say that, as an additional condition, to unlock a UTXO P2SH-P2WPKH, compared to a P2PKH, ...


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

Only the private key for the second input is used in this signature as this signature is only for the second input. The first input is P2PK and is ignored in this example as it is non-segwit so the standard non-segwit sighash algorithm is used for it.


1

I'm not entirely sure, but I think the intent of that change is to allow non-segwit wallets to generate payments to segwit wallets. Imagine that you're a business that uses segwit, but 1% of your customers insist on paying using a wallet that doesn't support segwit.


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