The issue here is that the two transactions are different, and combinerawtransaction does not operate on different transactions (it apparently just silently does nothing). It sounds like you expect combinerawtransaction to take two separate transactions and create a new one which has the inputs and outputs of both transactions. (or perhaps take two ...
Yes, once the PSBT is finalized you can extract a fully-signed raw transaction from it (using the finalizepsbt RPC). As your PSBT does not have signatures yet, there is no point in constructing an actual transaction from it yet.
If you create a raw transaction yourself, then that is the raw transaction. Whatever you put in it is exactly what the transaction will be, in the same order.
There are some conventions around output ordering. Some software will randomly permute the outputs; other software uses BIP69 which specifies a deterministic ordering. There is however no requirement ...
I believe the intention of your push_int(1) is to add SIGHASH_ALL to the transaction.
However, one of Script's many needless inflexibilities is that the sighash flag actually needs to be part of the signature itself, rather than as a separate stack element in the script.
This means that you need to take the Vec<u8> returned from Signature::...
In raw transaction, bitcoin using bytes of the public key, like:
Technically the raw transaction contains the Script, which usually is written with Bitcoin script that is a stack-based language. It can contain the PubKey in the ...
How to set the absolute fee
The transaction fee is implicitly defined by the difference between the sum of input and the sum of output amounts.
fee = Σ(inputs) - Σ(outputs)
Since you are building your transactions explicitly, you can set the exact transaction fee by defining the corresponding specific amounts of the outputs for the recipient(s) and the ...
Compressing a more-or-less random number is futile. Your best option is simply to use a more compact encoding. Base64 is better than Hex but there exists may other encodings that prform better
Wikipedia lists many and ranks them in order of efficiency
Encoding Data type Efficiency
yEnc Arbitrary, mostly non-text ...
Bitcoin core just rolled out descriptor wallet implementation (PR here). Descriptors are modeled as functions. They take input a public key, and return the corresponding scriptPubKey,describing its spending conditions in engineer-readable format. For example, sh(wpkh(03fff97bd5755eeea420453a14355235d382f6472f8568a18b2f057a1460297556)) describes a P2SH-P2WPKH ...
Enter output address, amount and click on pay:
Decide the fee rate and click on finalize:
You can export the transaction hex from bottom-left before or after signing the transaction:
Make sure "Advanced Preview" is active in the preferences:
What you're seeing is the extended transaction serialization format introduced in BIP144 (segregated witness). It adds a marker 0x0001 to indicate the presence of a witness after the version number, and a list of witness stack items after the transaction inputs.
There are currently 3 address types defined in Bitcoin:
The satoshi-era P2PKH format, which is Base58 encoding of (1 byte version prefix) + (20 bytes pubkeyhash) + (4 bytes checksum). The checksum is the first 4 bytes of the double-SHA256 hash of the 21 bytes that precede it. The version number is 0 for mainnet; it's easy to find lists of prefixes for other ...
signrawtransactionwithwallet is used to sign transactions for your wallet in which you can avoid entering private keys for spending different UTXOs as the private keys are in your wallet. You may need to enter passphrase using walletpassphrase
signrawtransactionwithkey is used to sign transactions for spending any UTXO using private keys
I create ...
This appears to be a bug in BitcoinIDE. The issue is that it is computing the hash differently from what it actually is. Because it finds a different hash, the comparison that checks that the hashes match (the OP_EQUALVERIFY) fails.
However the hash does match. If you compute the hash manually, you get a different hash than what BitcoinIDE is showing.
In this approach, Bitcoin Core is used to create the transaction offline without the hassle of manually creating the transaction:
How to move/sweep your Bitcoin Core bitcoins safely and air-gapped to your new fancy cold storage?
assuming I know in advance how much bitcoin a UTXO has
createrawtransaction in Bitcoin Core requires tx id and vout, if you know it and the address which will be used for output then transaction can be created offline.
Then I also need to sign that tx, also offline
Signing will require private key or a wallet with private key depending on which of these ...
This number is encoded as a variable-length integer, see the txn_count in the block protocol message.
The idea is the following:
Read the first byte as marker
If marker < 0xFD
marker is the number
If marker == 0xFD
read the next 2 bytes as the number
If marker == 0xFE
read the next 4 bytes as the number
If marker == 0xFF
read the next 8 bytes as ...
Or is that attribute added "later" by blockchain.info to give the reader a bit more context?
I'm pretty sure that is what is happening.
If you look at that transaction in a different explorer, for example https://blockchair.com/bitcoin/transaction/c52b5df64f10463fbe4f46d7b9da3464449849b7e542d533575a927366b52b09 and click "raw tx" you'll ...
It's most likely because nLocktime is based on the "mediantime" of the previous block... not "exact" unix time.
Due to delays in finding a new block, it is not unusual for "mediantime" and "current time" to end up out of sync by quite a significant amount (1+ hr).
If you don't have access to a Bitcoin Node to check the ...
This is a P2PKH (Pay-to-public-key-hash) address which means a2fd2e039a86dbcf0e1a664729e09e8007f89510 is the hash of your public key. Here is a step by step guide on how to go from public key to address
Do I understand correctly that both inputs are to be signed
So first, we sign the first one, then the second one. To sign an input
we replace scriptSig for this input with the scriptPubKey, that locks
this input. ScriptSig for the other one remains blank. It this
But in both threads in step 13 something is appended at the end ...
The "01" byte at the end is the sighash type byte (specifically, 01 means SIGHASH_ALL, indicating that all inputs and outputs are signed). Such a byte is required for all signatures in Bitcoin scripts (both in legacy and segwit signatures). However, that byte is part of the DER-encoded signature; it's appended to it.
Presumably your hardware wallet ...
A very useful RPC is the testmempoolaccept RPC. This will tell you whether the transaction would be accepted by the node. You can use this to determine whether the transaction is correctly signed. It will also tell you what the transaction fee is so you can determine whether the fee is what you expect it to be. If the transaction would not be accepted, it ...
Grubles shared the reason why this didn't work and I had issues while decoding in this tweet thread: https://twitter.com/notgrubles/status/1336709747756724227
Required the hex to be divisible by 8 basically. If it wasn't the encoder would chop off the remainder. So when you would go to decode the words, you would end up with more or less the same result as ...
You're missing the sighash flag byte at the end of the signature.
"Signature" objects in Bitcoin Script consist of the actual DER-encoded ECDSA signature, plus the sighash type byte (in your case, 0x01 for SIGHASH_ALL).
You're trying to spend a 25.04826416 BTC output that was created by mining in May 2015, which was spent a few days after its creation: https://blockstream.info/tx/45fd1c838a56798fe027f61bdfdab83845399175a3b9cced397c5a38e669bb49?input:14
Even if you have the private key for the address that output used at the time, the coin can't be spent again.
I don't know ...