Bitcoin Forum
May 26, 2024, 01:01:32 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Raw transactions  (Read 513 times)
vlees (OP)
Full Member
***
Offline Offline

Activity: 196
Merit: 100



View Profile
May 24, 2013, 06:24:04 PM
Last edit: May 24, 2013, 06:52:03 PM by vlees
 #1

I was looking into the createrawtransaction API with the help of some transactions done with the Bitcoin-QT client and I do not fully understand everything.

1. There is a vout parameter for the transactions. What do I have to set this value to?
2. How can I specify the transaction fee? Or do I just give inputs to cover all outputs + 0.005BTC which are not present in the outputs?
3. https://blockchain.info/address/19SxkCSLKKpyqrQZ4BAFbQVCGiVBVPDYWL
That address is mine, apparently, but it is not specified in the Bitcoin-QT client. But somehow it seems that whenever I send a transaction, the official client sends the remainder of input(s) to a new address (which I do not have in the list) and somehow does not lose track of it's public and private key. How/Why does this work/happen?

(tried to look on the wiki of bitcoin.it for this but it's not really helpful)

EDIT: found this, https://bitcointalk.org/index.php?topic=101525.0 At least that answers the fee question.
EDIT2: By trying I noticed the vout is the n parameter from the input transaction (which was an output).

Still wondering about number 3.

BEEP BEP
DannyHamilton
Legendary
*
Offline Offline

Activity: 3402
Merit: 4656



View Profile
May 24, 2013, 07:57:30 PM
 #2

3. https://blockchain.info/address/19SxkCSLKKpyqrQZ4BAFbQVCGiVBVPDYWL
That address is mine, apparently, but it is not specified in the Bitcoin-QT client. But somehow it seems that whenever I send a transaction, the official client sends the remainder of input(s) to a new address (which I do not have in the list) and somehow does not lose track of it's public and private key. How/Why does this work/happen?

These are "change" from any transactions you've sent in the past:

With the way bitcoin works, you can't partially spend a previous output that you received.  It has to be completely spent.  So, if you receive 10 BTC all in a single transaction from someone/somewhere at an address, then that address now has a single 10 BTC output.

Later if you want to send 2 BTC to somebody, the program can use the previous 10 BTC output as an input into the transaction, and create a 2 BTC output to the address where you want to send it.  This leaves 8 BTC leftover in the transaction.  If you don't send those 8 BTC somewhere, then they become miner fees and end up in the coinbase transaction of the new block for the miner to keep.  If you don't want to give those 8 BTC away as fees to the miner, then you need to include a second output in your transaction sending the 8 BTC back to your own wallet.  As an analogy, think of pulling a $10 bill out of your pocket to pay for something that costs $2, you get $8 back in "change".

The way Bitcoin-Qt does this is to create a new bitcoin address that it doesn't tell you about and keeps track of that address and the associated private key in your wallet.dat.  Since this isn't an address that you requested in the "Receive Coins" tab of the user interface, it doesn't show up in that list.  Bitcoin-Qt knows about the address since it is in the wallet.dat file, so it includes it in the balance that it shows you.  Bitcoin-Qt uses a new change address for every transaction.  So if you create 10 different transactions, each sending bitcoins somewhere, then your wallet will have used 10 different change addresses (although some of them may be empty if Bitcoin-Qt used the bitcoins associated with some of those address as inputs into other transactions).

You can get a list of unspent outputs that the wallet is tracking by using "listunspent".  It should give you the transactionID, the vout, and the BTC value of each unspent output in the wallet.  This should be everything you need to create your raw transactions, but if you want to choose particular "sending addresses", you'll need to look up each of the transactionID and vout to find out what address the bitcoins from the output are currently associated with.

* I've been working on a Perl script that makes a listunspent API call to Bitcoin-Qt and then parses the output presenting a list of all the useful information about each output.  It needs a lot of cleaning up and beautifying, but I think I got it working a couple days ago. This is step one of my attempt to create a perl program that will automate sweeping dust balances together in the wallet, as well as automating other processes (such as sweeping balances out of old addresses into a paper wallet).
vlees (OP)
Full Member
***
Offline Offline

Activity: 196
Merit: 100



View Profile
May 24, 2013, 09:36:13 PM
Last edit: May 24, 2013, 10:22:32 PM by vlees
 #3

Thank you. I managed to send my own custom transactions and I knew about the money not being merged as I receive it.
But I thought I had something wrong since Bitcoin-QT used completely random return addresses for me but you explained that one pretty well. Thanks again.

EDIT: Yes, it's quite easy. Combined multiple inputs with multiple outputs without a problem.

BEEP BEP
binaryFate
Legendary
*
Offline Offline

Activity: 1484
Merit: 1003


Still wild and free


View Profile
May 28, 2013, 07:29:36 PM
 #4

3. https://blockchain.info/address/19SxkCSLKKpyqrQZ4BAFbQVCGiVBVPDYWL
That address is mine, apparently, but it is not specified in the Bitcoin-QT client. But somehow it seems that whenever I send a transaction, the official client sends the remainder of input(s) to a new address (which I do not have in the list) and somehow does not lose track of it's public and private key. How/Why does this work/happen?

These are "change" from any transactions you've sent in the past:

With the way bitcoin works, you can't partially spend a previous output that you received.  It has to be completely spent.  So, if you receive 10 BTC all in a single transaction from someone/somewhere at an address, then that address now has a single 10 BTC output.

Later if you want to send 2 BTC to somebody, the program can use the previous 10 BTC output as an input into the transaction, and create a 2 BTC output to the address where you want to send it.  This leaves 8 BTC leftover in the transaction.  If you don't send those 8 BTC somewhere, then they become miner fees and end up in the coinbase transaction of the new block for the miner to keep.  If you don't want to give those 8 BTC away as fees to the miner, then you need to include a second output in your transaction sending the 8 BTC back to your own wallet.  As an analogy, think of pulling a $10 bill out of your pocket to pay for something that costs $2, you get $8 back in "change".

The way Bitcoin-Qt does this is to create a new bitcoin address that it doesn't tell you about and keeps track of that address and the associated private key in your wallet.dat.  Since this isn't an address that you requested in the "Receive Coins" tab of the user interface, it doesn't show up in that list.  Bitcoin-Qt knows about the address since it is in the wallet.dat file, so it includes it in the balance that it shows you.  Bitcoin-Qt uses a new change address for every transaction.  So if you create 10 different transactions, each sending bitcoins somewhere, then your wallet will have used 10 different change addresses (although some of them may be empty if Bitcoin-Qt used the bitcoins associated with some of those address as inputs into other transactions).

You can get a list of unspent outputs that the wallet is tracking by using "listunspent".  It should give you the transactionID, the vout, and the BTC value of each unspent output in the wallet.  This should be everything you need to create your raw transactions, but if you want to choose particular "sending addresses", you'll need to look up each of the transactionID and vout to find out what address the bitcoins from the output are currently associated with.

* I've been working on a Perl script that makes a listunspent API call to Bitcoin-Qt and then parses the output presenting a list of all the useful information about each output.  It needs a lot of cleaning up and beautifying, but I think I got it working a couple days ago. This is step one of my attempt to create a perl program that will automate sweeping dust balances together in the wallet, as well as automating other processes (such as sweeping balances out of old addresses into a paper wallet).


Nice explanation, thanks. Following your analogy, is it possible to set the receiving address for the 8 BTC to be the same as the sending one? So the second output to return the remaining output to your wallet would be directed to the same address. The consequence is that, appart from any other concerns, it would be feasible to have a fully working wallet containing a single address. If that's not the case, I guess two addresses should do it, right?

Monero's privacy and therefore fungibility are MUCH stronger than Bitcoin's. 
This makes Monero a better candidate to deserve the term "digital cash".
DannyHamilton
Legendary
*
Offline Offline

Activity: 3402
Merit: 4656



View Profile
May 28, 2013, 07:46:10 PM
 #5

Nice explanation, thanks. Following your analogy, is it possible to set the receiving address for the 8 BTC to be the same as the sending one? So the second output to return the remaining output to your wallet would be directed to the same address.

If you are building your own transactions (for example with createrawtransaction) then yes.  If you are leaving it up to the wallet to create the transactions for you, then it will depend on the wallet (Electrum, MultiBit, Bitcoin-Qt, etc.) that you use.  There are some wallets that send back to the same address where the input was previously received, others create a new address for every transaction.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
May 28, 2013, 07:48:50 PM
 #6

Nice explanation, thanks. Following your analogy, is it possible to set the receiving address for the 8 BTC to be the same as the sending one? So the second output to return the remaining output to your wallet would be directed to the same address. The consequence is that, appart from any other concerns, it would be feasible to have a fully working wallet containing a single address. If that's not the case, I guess two addresses should do it, right?

You can.  There is nothing prohibiting the "change" address from being the same as the sending address.  The Bitcoin protocol doesn't even have a concept of "change" it simply sees a transaction as having one or more inputs and one or more outputs with the difference being the fee to miners.  You must spend an entire output when spending how you achieve that is up to you.  The main reason for not doing that is you are making it trivial for someone to monitor your financial activities and that the public key is known which potentially could lead to an attack vector if/when quantum computing reaches a point where it can attack 256 bit ECDSA public keys (we are nowhere close yet).

TL/DR
At the protocol level there is no issue with a tx like this:

Input:     10 BTC from AddressA
Output1:  2 BTC to Address Z
Output2:  7.9999 BTC to Address A
(0.0001 tx fee to miners)

You must use raw transactions to accomplish this as by default the reference client abstracts all this from the user.  It determines the inputs to use and creates new addresses for "change" as needed.   If you plan to use rawtransactions I strongly recommend doing a lot of testing on testnet.  It is possible to lose all your funds if you incorrectly create rawtransactions.
 

binaryFate
Legendary
*
Offline Offline

Activity: 1484
Merit: 1003


Still wild and free


View Profile
May 28, 2013, 09:33:21 PM
 #7

DannyHamilton and DeathAndTaxes, thanks a lot for the clear explanations, I appreciate.  Smiley

Monero's privacy and therefore fungibility are MUCH stronger than Bitcoin's. 
This makes Monero a better candidate to deserve the term "digital cash".
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!