Bitcoin Forum
December 11, 2019, 12:05:58 PM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Simple Transaction Signing Question  (Read 902 times)
dbell
Newbie
*
Offline Offline

Activity: 59
Merit: 0


View Profile
January 19, 2014, 12:29:14 AM
 #1

I am trying to jot down some notes and diagrams on how simple Bitcoin transactions take place. 

One of the simplest is sending some Bitcoin to an address and receiving back the change to an address in your wallet.  From reading material on-line, I can't tell if the sub-transactions are signed together or separately.  See the picture below.  Which one is correct?

Surely the coding experts can tell me.

Thanks

http://i.imgur.com/Rkk8fIX.png
1576065958
Hero Member
*
Offline Offline

Posts: 1576065958

View Profile Personal Message (Offline)

Ignore
1576065958
Reply with quote  #2

1576065958
Report to moderator
Best ratesfor crypto
EXCHANGE
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1576065958
Hero Member
*
Offline Offline

Posts: 1576065958

View Profile Personal Message (Offline)

Ignore
1576065958
Reply with quote  #2

1576065958
Report to moderator
1576065958
Hero Member
*
Offline Offline

Posts: 1576065958

View Profile Personal Message (Offline)

Ignore
1576065958
Reply with quote  #2

1576065958
Report to moderator
1576065958
Hero Member
*
Offline Offline

Posts: 1576065958

View Profile Personal Message (Offline)

Ignore
1576065958
Reply with quote  #2

1576065958
Report to moderator
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1006


Gerald Davis


View Profile
January 19, 2014, 12:42:58 AM
Last edit: January 19, 2014, 07:10:28 AM by DeathAndTaxes
 #2

It is complicated and probably better to look at the code directly as trying to explain it in English at a high level abstracts some of it away so while this gets you closer it may still leave some parts ambiguous.  The second image is closer to the correct scenario however remember a tx can have multiple inputs as well.

A hash of the simplified transaction consisted of a SINGLE INPUT and ALL outputs is created, this is then signed by the private key for that input and stored in the "sig & pubkey" portion of that tx input.  
See here: https://en.bitcoin.it/w/images/en/e/e1/TxBinaryMap.png  

Bitcoin has no concept of "owners" or "wallets" so the change output isn't special, it is an output just like any other.  If you are going to create an illustration for explaining then creating one with only a single input is a poor choice because the next questions becomes how to dI handle n inputs where n >1.  An example with 2 inputs is better because 3, 20, or 4,000 inputs are handled exactly the same as 2.  

The other thing you need to divorce yourself from is you aren't sending funds from a public key, you are using a SPECIFIC unspent output of a prior tx as an input.  Yes in conversation we may say "he paid me from address 123..." but when trying to explain Bitcoin's working that falls apart and trying to understand anything becomes impossible.  An input is a specific unspent output.  It is referred to (in the Tx input) by the tx hash (of the prior tx) and index (which output of that tx is being used here).

So in more general form.   Lets assume you have a tx which consists of 3 unspent outputs (which become inputs for this tx) A, B, C and two new outputs Y & Z (it doesn't matter if one of these is a change address or you just happened to pay two different receivers with the exact amount of coins, an inputs is an input and an output is an output).

First the output scripts are created.  The "normal" Bitcoin tx is a PayToPubKeyHash, so likely the user provided you a Bitcoin Address.  This is reversed into the PubKeyHash and a script which locks that output of a specific value to a specific PubKeyHash is created.  The outputs are arranged in a sequence randomly (to avoid leaking which one is the "change").  Lets say Z become TxOut0 and Y becomes TxOut1.  The inputs are then arranged in a sequence randomly.  Lets say A becomes TxIn0, B becomes TxIn1, and C becomes TxIn2.

We now have a tx which looks like this:
TxIn0
Txin1
TxIn2
TxOut0
TxOut1


A simplified version of the tx is created (TxIn0, TxOut0, TxOut1) and hashed.  The hash is signed by the private key for A and stored in the Sig & PubKey section for TxIn0.
A simplified version of the tx is created (TxIn1, TxOut0, TxOut1)and hashed.  The hash is signed by the private key for B and stored in the Sig & PubKey section for TxIn1.
A simplified version of the tx is created (TxIn2, TxOut0, TxOut1) and hashed.  The hash is signed by the private key for C and stored in the Sig & PubKey section for TxIn2.

One last thing which may not be obvious.  There is no 1:1 relationship between inputs and private keys.  For example if you have two unspent outputs to the same address (say A & C) then they share the same private key however they are still unique and discrete inputs so the tx above would still have 3 inputs.

I likely am overlooking or misstating something here so I would double check all this against the code.



dbell
Newbie
*
Offline Offline

Activity: 59
Merit: 0


View Profile
January 19, 2014, 01:32:35 AM
 #3

Thanks much!!  Your description was clear and makes sense.

Got it on the unspent outputs as being more correct.  As I understand it, this is what provides a unique and valid attachment of the current transaction to the graph of previous transactions (of unspent outputs) which going backwards, leads all the way back to mined coins.   Of course "final" validation for the transaction is not resolved until the block containing the transaction is back some TBD amount from the head of the blockchain.

I figured there would be at least one signature per input but was not sure if Bitcoin implemented M = (#inputs  *  #outputs)  signatures or just M = (#inputs)  signatures.  Looks like it is the latter.

If I may, one follow up.   How are transaction fees handled since the final output "owner" for the fees are not known until the block is solved.  What is the output address for a fee at the time the transaction is submitted?  Is it just a temporary address and how is it transferred to the Block solver? 

Thanks again... and at some point I may get around to reading the code
DannyHamilton
Legendary
*
Offline Offline

Activity: 2282
Merit: 1584



View Profile
January 19, 2014, 03:01:44 AM
 #4

- snip -
How are transaction fees handled since the final output "owner" for the fees are not known until the block is solved.  What is the output address for a fee at the time the transaction is submitted?  Is it just a temporary address and how is it transferred to the Block solver? 
- snip -

Transaction fees do not have an output address.

Transactions do not specify transaction fees.

Transactions specify inputs and outputs.

If the value of the sum of the outputs is less than the value of the sum of the inputs, then the difference is considered to be a "transaction fee".

When a miner (or mining pool) builds a block, they create a special "coinbase" transaction that has no inputs and assigns outputs to any addresses they want.

To be considered a valid block, the value of the sum of the outputs in the coinbase transaction must be less than or equal to the sum of the current block subsidy (25 BTC right now) plus all the transaction fees of all transactions that were included in the block.


ning
Full Member
***
Offline Offline

Activity: 173
Merit: 100



View Profile
January 19, 2014, 03:57:09 AM
 #5

Thank you, DeathAndTaxes and DannyHamilton! This is an example where words beat graphs.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1006


Gerald Davis


View Profile
January 19, 2014, 04:46:32 AM
Last edit: January 19, 2014, 07:12:22 AM by DeathAndTaxes
 #6

The handling of tx fee is a pretty ingenious solution.  The tx fee and the miner reward are loosely coupled.

There is one potential concern, since tx fees are implied not explicitly defined, a bug in a client could result in a loss of coins for a user.

For example say a flawed client created this tx:
TxIn0 (value 100 BTC)
TxOut0 (value 1 BTC)
TxOut1 (value 9 BTC)

You just paid 90 BTC as a fee to miners.  Likewise a flawed miner could actually "erase" coins permanently.  If the sum of all txs in a block is 1 BTC and the block reward is 25 BTC but due to a bug the miner makes the coinbase tx 25.1 BTC then the money supply would be reduced by 0.9 BTC permanently.

The major clients are at this point pretty extensively tested so the risk is more in custom implementations or using the rawtx RPC call (which is very low level and will let you do lots of dangerous things).

Bitcoin likely can't be changed at this point however for an altcoin the only (hindsight being 20/20) changes I would recommend would be:
a) make the tx fee explicitly defined in the tx header and thus a tx is invalid if the sum(inputs) =/= sum(outputs) + txfee
b) make a block invalid if coinbase =/= sum(tx_fees) + current_block_subsidy

DannyHamilton
Legendary
*
Offline Offline

Activity: 2282
Merit: 1584



View Profile
January 19, 2014, 06:19:48 AM
 #7

For example say a flawed client created this tx

TxIn0 (value 100 BTC)
TxOut0 (value 1 BTC)
TxOut1 (value 9 BTC)

guess what you just paid 90 BTC to miners.

And in case it wasn't obvious, this isn't just a theoretical problem. This has occurred to multiple developers while working on software that builds transactions (including myself).

Likewise a flawed miner could actually "erase" coins permanently.  If the sum of all txs in a block is 1 BTC and the block reward is 25 BTC but due to a bug the miner makes the coinbase tx 25.1 BTC then the money supply would be reduced by 0.9 BTC permanently.

Again, not a theoretical problem.  This also has happened in the past, though not nearly as often as the excessive fee problem.

The major clients are at this point pretty extensively tested so the risk is more in custom implementations or doing things like the rawtx RPC call (which is very low level and will let you do things like pay 90 BTC to miners on a 9 BTC tx).

I'm not certain, but I think the most recent version of Bitcoin-Qt (0.8.6) prevents users from transmitting a block that has an excessively large fee to protect them from such an error.

DannyHamilton
Legendary
*
Offline Offline

Activity: 2282
Merit: 1584



View Profile
January 19, 2014, 06:29:05 AM
 #8

Lets say Z become TxOut0 and Y becomes TxOut1.  The inputs are then arranged in a sequence randomly.  Lets say A becomes TxIn0, B becomes TxIn1, and C becomes TxIn2.

We now have a tx which looks like this:
TxIn0
TxIn1
TxIn2
TxOut0
TxOut1

A simplified version of the tx is created (TxIn0, TxOut0, TxOut1) and hashed.  The hash is signed by the private key for A and stored in the Sig & PubKey section for TxIn0.
A simplified version of the tx is created (TxIn1, TxOut0, TxOut1)and hashed.  The hash is signed by the private key for B and stored in the Sig & PubKey section for TxIn1.
A simplified version of the tx is created (TxIn2, TxOut0, TxOut1) and hashed.  The hash is signed by the private key for C and stored in the Sig & PubKey section for TxIn2.

FTFY.

D&T, If you happen to come back to this thread, you may want to edit your post to prevent confusion for others who read it but don't make it this far in the discussion. (As a matter of fact, if I notice that you've fixed your post, I'll delete this one since it will no longer be necessary)

amaclin
Legendary
*
Offline Offline

Activity: 1260
Merit: 1002


View Profile
February 02, 2014, 02:20:22 PM
 #9

Quote
A simplified version of the tx is created (TxIn0, TxOut0, TxOut1) and hashed.  The hash is signed by the private key for A and stored in the Sig & PubKey section for TxIn0.
A simplified version of the tx is created (TxIn1, TxOut0, TxOut1)and hashed.  The hash is signed by the private key for B and stored in the Sig & PubKey section for TxIn1.
A simplified version of the tx is created (TxIn2, TxOut0, TxOut1) and hashed.  The hash is signed by the private key for C and stored in the Sig & PubKey section for TxIn2.

Please help. What is "simplified version of the tx" for hashing?
I have working example from http://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx
But it works only with one input.
Can you explain, please how to create transaction with more than one input?
DannyHamilton
Legendary
*
Offline Offline

Activity: 2282
Merit: 1584



View Profile
February 08, 2014, 07:43:14 PM
 #10

Quote
A simplified version of the tx is created (TxIn0, TxOut0, TxOut1) and hashed.  The hash is signed by the private key for A and stored in the Sig & PubKey section for TxIn0.
A simplified version of the tx is created (TxIn1, TxOut0, TxOut1)and hashed.  The hash is signed by the private key for B and stored in the Sig & PubKey section for TxIn1.
A simplified version of the tx is created (TxIn2, TxOut0, TxOut1) and hashed.  The hash is signed by the private key for C and stored in the Sig & PubKey section for TxIn2.

Please help. What is "simplified version of the tx" for hashing?
I have working example from http://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx
But it works only with one input.
Can you explain, please how to create transaction with more than one input?

https://en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!