5

Because unlike addresses, hex raw transactions aren't meant to be seen or used by end-users. Hex is easy to encode and decode (every two character in hex represents one byte*, whereas in base64 one character is 3/4 byte and Base58 is log(58)/log(256) = 0.7322476244 bytes) so it is convenient if you want to debug your implementation. *: which means if you ...


4

It is not invalid. The code you are looking it is unrelated to validation and relay of actual transactions. You are looking at the code for RPCs which are just things for users. The RPC disallows sending to an address multiple times because this is not efficient and usually a mistake by the user. But this is only for creating a raw transaction using the ...


4

There are currently three different ways to do this: raw transactions, PSBT in 0.17, and PSBT in 0.18. I recommend that you use PSBT in 0.18 as it is the least hassle, but I will describe all three here for you. Traditionally, you would do this with createrawtransaction, fundrawtransaction, and signrawtransactionwithkey/signrawtransactionwithwallet. One ...


3

To expand on Andrew's answer a little, many application that interact with the Bitcoin network include some kind of "sane defaults". For Bitcoin Core, this is visible in the form of not allowing very high fee transactions, ensuring there aren't any duplicate addresses in outputs, attempting to use change addresses of the same type as the address you are ...


3

You can only broadcast transactions if your node has synced to the point that it knows the outputs that were spent. This is because your node will always validate a transaction before it broadcasts it. If it has not synced to the point that it knows the outputs that your transaction spent, then it won't have the information necessary in order to validate the ...


2

The Bitcoin Wiki entry for OP_CHECKSIG answers your question. OP_CHECKMULTISIG works the same way, just applied to each signature in the sequence. First of all, it depends on the SIGHASH type you, as the signer, choose. Most likely you will use the default SIGHASH_ALL for each of the required signatures, but you could actually use different SIGHASH methods ...


2

You have to look up the previous unspent transaction output using the hash and txout-index, and this output contains the amount in satoshis which is provided in entirety as input for the transaction.


2

You can do this with 1 transaction, it will get more expensive, but it has nothing to do with whether you use separate addresses or not (or with whether or not you're using BIP32 in any way or form, for that matter). Bitcoin uses a UTXO model: every transaction has 1 or more inputs, and one or more outputs. Every output creates a UTXO (which you can think ...


2

and other input(s) should have "00" in place. Keep in mind that you replace the "scriptsig" with "empty" and the 0x00 is the size of the empty script. non-mandatory-script-verify-flag (Non-canonical DER signature) (code 64) The problem here is the DER encoding used in your signatures. r values in a signature are positive and since each r value that you ...


2

Scripts can be used to do a lot more thing than just pubkeys and signatures. There is an entire Bitcoin script language that can be used to specify things like multisigs, hashlocks, timelocks, conditionals, etc. It's pretty extensive, just hard to grasp and reason about. Such scripts do not map to addresses (before P2SH) so without having scripts in outputs, ...


2

Why raw Bitcoin transaction are in hex format? They are not. So far as I know and have read. Bitcoin raw format According to https://bitcoin.org/en/developer-reference Bitcoin transactions are broadcast between peers in a serialized byte format, called raw format. It is this form of a transaction which is SHA256(SHA256()) hashed to create the TXID ...


1

First of all, Script is a stacking programming language in which Bitcoin works. Script is pretty basic and limited for security reasons. For this same reason, Script is not Turing complete. Why does the bitcoin protocol opt for the use of this script-derivative in the transaction instead of just using the output address plainly? This is because locking ...


1

1) First you can add connect=1.1.1.1 to your bitcoin.conf. Your node won't search for other nodes and just try to connect to 1.1.1.1. Since 1.1.1.1 is not a node, your node will have 0 peers. 2) Then you can make the transaction, open the debug console and enter: gettransaction YOURTXID. (or getrawtransaction to get the hex encoded transaction) 3) Then you ...


1

A fully synced Bitcoin node is the only way to know without trust that the coins you think you own are really yours. Otherwise, someone can trick you into thinking you have money you don't. You can try to spend the counterfeit coins, but the network will reject your transaction. If disk space is your primary concern you can run your node with pruning active,...


1

You can use the command bitcoin-cli getrawmempool to get a JSON array of all transactions that are stored locally in your mempool. Since v0.9 release you can also pass a verbose boolean to get more info related to the transactions in your mempool like size, fees, or ancestor/dependent transaction within the mempool. Do note that there is no one global ...


1

In your script the previous ScriptPubKey is different. If you want create custom script you need to sign manually the transaction, you can't use signrawtransactionwithkey. Bitcoin core sign only the standard transaction


1

Does this mean that in order for me to test my segwit code, I will have to wait till I get a segwit input somehow? Yes. You have non-segwit inputs. You cannot create a segwit transaction when your transaction has only non-segwit inputs. To get a segwit input, just send some of your Bitcoin to a segwit address that you own.


1

Only segwit outputs can be spent using segwit inputs. A segwit transaction is a transaction with at least one segwit input. You'll first need to create a segwit output to test segwit spending.


1

I am very embarrassed, just circling back to share, the above workflow works perfectly. My problem was I had an incorrect vout value in one of my inputs. Basically I was trying to spend money I don't have (/facepalm). As soon as I corrected that, everything worked flawlessly. Here's my multi-wallet.dat file Coinjoin :) https://live.blockcypher.com/btc-...


1

You're only signing the first input? tx.sign(0, owner); Usually every input has to be signed somehow. I also struggled with the switch to Psbt. Biggest difference was basically requirement to have a full transaction hex of every input for non-segwit inputs. Segwit inputs can be simpler but they can also be created using the full hex of the tx using non-...


1

You have the wrong public key inside your SignatureScript: Sig: 48-304502210093b8ff9180a8a31a5ee7b0fb6c560aef888a3d53576e530cb4601dce2d3c51da02204fd8a28743f1d1100a2f56428e743501091e833550df6cf540bad4f5248a6d3c-01 pubkey: 21-02d794c7e1a8068782ef6ee68acf9f6ad9c84c78349671c1a7bf60418a8e1ed108 The outpoint you are spending (2611[...]fd57:0) has the following ...


1

The two preceding answers describe correctly that there is no network-wide requirement to order inputs or outputs, but I don't agree that the "order doesn't matter". Early on, many wallets did order their inputs and outputs, e.g. the inputs were in the order the addresses were created, in the order that they got picked by the wallet's coin selection, or ...


1

The convention is to have the outputs in random order. This is specifically done in an effort to conceal which output is the change output. The change is by default sent to a new address that is owned by the sender, and as such has no history associated with it. The majority of bitcoin's code is actually c++. Here is a link to the relevant transaction ...


1

The sequence number is always 4 bytes, it is a fixed size, little endian, 32 bit integer which makes it always 4 bytes. What you are missing is the scriptSig. The scriptSig always begins with the size of the script (as a compact size unsigned integer). If the scriptSig is empty, then the size must still be there to say that it is a 0 length byte. So the ...


1

You almost have it, you just need to make sure you are creating a transaction with an output that your wallet can sign. Example (on regtest) bitcoin-cli -regtest addmultisigaddress 2 '["02983a79d2de8e504d00ddd2343b582acef7e17ed91b308ade8dff027a92e7716d","03548ca1916957bc06dd1c6e3639ebf7b2c3c8b1715915433c1d37cab56fb26ef0","...


1

I suspect it's considered tacky in programmer circles to post an answer to one's own question, but in this case my mistake was rather dangerous so I'd like to share the details with y'all. RECAP: My question stated that the public 'push tx' APIs weren't giving viable error messages after refusing my hex-formatted raw transactions. The answer from Mr. Chow ...


1

It's valid. In fact, pasting the transaction here actually shows a little checkmark next to the "signed" icon indicating a proper signature. It is not valid. That website did not validate anything. It just checked whether there was something in the scriptWitness field, and if there was, it was marked as signed. That checkmark does not mean that it is valid....


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