double spending questions

[icehouse]

Hi guru,

I understand that a coin is
previous coin +  my public key -> hash
signed by prev owner.

I also understand a block is a collection of transactions + previous block hash + nouce -> hash

when I use blockchains explorer to look at a block.
I can see a transaction like
send from wallet address to another wallet address and amount of coin.

the wallet address are people public key. am i correct?

but I don't understand how the double spending can be prevented?

Can anyone explain?
Thanks!

[ranochigo]

A transaction contains the inputs, together with its public key, a signature and the requirements to spend its output.

The wallet address are the public key hash, public keys are a lot longer than that.

Double spending cannot be prevented, no one said it could be. The network functions on the fact that anyone with a longer proof of work is the correct person. As a result, block reorgs could essentially 'remove' a transaction from the blockchain while adding another transaction with the same inputs but spent elsewhere. Double spending would get harder and harder with the number of confirmations. Number of confirmations would not be affected if the attacker owns 51% of the network's hashrate.

[MrCrank]

What you mean ..

how the double spending can be prevented?

It's impossible because TXs uses similar inputs and modify output.. for confirmation double spend TX has higher fees.

[Colorblind]

Any attempt to create output from already spent coin will result in tx rejection by virtually anyone in the network. Normal miners will reject this tx and never put it into block. If some abnormal miner will actually dare to do so, others will reject such block as invalid anyway. It's bulletproof in terms of double spend.

The only case where it can occur is while tx is still in mempool (never got into block) you can create another tx with different outputs and higher fee. This way only one of those tx will eventually be confirmed. That's why most of services wait until 1-6 confirmations before they actually credit your coins to account.

[HeRetiK]

Any attempt to create output from already spent coin will result in tx rejection by virtually anyone in the network. Normal miners will reject this tx and never put it into block. If some abnormal miner will actually dare to do so, others will reject such block as invalid anyway. It's bulletproof in terms of double spend.

The only case where it can occur is while tx is still in mempool (never got into block) you can create another tx with different outputs and higher fee. This way only one of those tx will eventually be confirmed. That's why most of services wait until 1-6 confirmations before they actually credit your coins to account.

Note that even after the first confirmation a double-spend could still be successful, hence the requirement of services to wait until a predetermined count of confirmations. It's only that with each additional confirmation the odds of a successful attack shrink, with 6 confirmations being considered fairly safe from a probabilistic point of view. In reality for most transactions even 1-2 confirmations should be sufficient.

The "trick" behind PoW is that each block / confirmation requires a considerable amount of computation thus resources, making any sort of attack a costly manner while rewarding every miner that "behaves well" using the block reward and miner fees.

[icehouse]

What you mean ..

how the double spending can be prevented?

It's impossible because TXs uses similar inputs and modify output.. for confirmation double spend TX has higher fees.

What i mean is... when I look at the block using blockchain explorer. in a transaction, I only see
from wallet address, to wallet address and the amount of coin. I don't see any coin data.
I don't understand how the double spending can be prevented because
this amount of coin, which is a double number won't able to identify a coin.

[icehouse]

A transaction contains the inputs, together with its public key, a signature and the requirements to spend its output.

The wallet address are the public key hash, public keys are a lot longer than that.

Double spending cannot be prevented, no one said it could be. The network functions on the fact that anyone with a longer proof of work is the correct person. As a result, block reorgs could essentially 'remove' a transaction from the blockchain while adding another transaction with the same inputs but spent elsewhere. Double spending would get harder and harder with the number of confirmations. Number of confirmations would not be affected if the attacker owns 51% of the network's hashrate.

Do you mean the transaction that I saw in blockchain explorer doesn't show all info of the transaction?

[icehouse]

to clarify my questions.

from blockchain explorer what I see is:

from wallet         to wallet              amount
-------------        ----------             ---------
wallet_address1  wallet_address2      0.1
.....
.....

I don't see anything associate to a crypto coin.

if blockchain explorer doesn't show all transaction info, then what exactly a transaction looks like?

Thanks

[icehouse]

A transaction contains the inputs, together with its public key, a signature and the requirements to spend its output.

The wallet address are the public key hash, public keys are a lot longer than that.

Double spending cannot be prevented, no one said it could be. The network functions on the fact that anyone with a longer proof of work is the correct person. As a result, block reorgs could essentially 'remove' a transaction from the blockchain while adding another transaction with the same inputs but spent elsewhere. Double spending would get harder and harder with the number of confirmations. Number of confirmations would not be affected if the attacker owns 51% of the network's hashrate.

from the white paper
https://bitcoin.org/bitcoin.pdf
A coin is  (previous coin + my public key) -> hash, then signed by previous owner.

when we do transaction, I pass my wallet address only to previous owner. how the previous owner know my public key?

[DannyHamilton]

if blockchain explorer doesn't show all transaction info, then what exactly a transaction looks like?

Thanks

When I decode a transaction here https://blockchain.info/decode-tx

For example,

https://blockchain.info/tx/9021b49d445c719106c95d561b9c3fac7bcb3650db67684a9226cd7fa1e1c1a0?format=hex

0100000002d8c8df6a6fdd2addaf589a83d860f18b44872d13ee6ec3526b2b470d42a96d4d00000 0008b483045022100b31557e47191936cb14e013fb421b1860b5e4fd5d2bc5ec1938f4ffb1651dc 8902202661c2920771fd29dd91cd4100cefb971269836da4914d970d333861819265ba014104c54 f8ea9507f31a05ae325616e3024bd9878cb0a5dff780444002d731577be4e2e69c663ff2da92290 2a4454841aa1754c1b6292ad7d317150308d8cce0ad7abffffffff2ab3fa4f68a512266134085d3 260b94d3b6cfd351450cff021c045a69ba120b2000000008b4830450220230110bc99ef311f1f8b da9d0d968bfe5dfa4af171adbef9ef71678d658823bf022100f956d4fcfa0995a578d84e7e913f9 bb1cf5b5be1440bcede07bce9cd5b38115d014104c6ec27cffce0823c3fecb162dbd576c88dd7cd a0b7b32b0961188a392b488c94ca174d833ee6a9b71c0996620ae71e799fc7c77901db147fa7d97 732e49c8226ffffffff02c0175302000000001976a914a3d89c53bb956f08917b44d113c6b2bcbe 0c29b788acc01c3d09000000001976a91408338e1d5e26db3fce21b011795b1c3c8a5a5d0788ac0 0000000

But when I try any hex decoder online, I get gibberish.

Isn’t the raw hex transaction in hexadecimal? If so, how do you encode / decode other than the blockchain decoder?

As HCP has indicated...

It is NOT hex encoded ASCII.  You can't just convert the hex values into ASCII character representations and expect to get anything useful out of it.

It is hex encoded binary data.

If you are aware that a single BYTE of data is represented with 2 hex characters, and you know how to convert from hexadecimal to decimal, then we can walk through that transaction you posted together to see exactly what is happening.  Follow along...

The first 4 bytes (8 characters) are ALWAYS a transaction version number.  In this case that is:

Code:

01000000

Note that bitcoin uses "little-endian" byte order, so converting those bytes to the format in which you might commonly see a hexadecimal number written we get 0x00000001. Converting that to decimal we see that this is a version 1 transaction type.

The next byte indicates the number of inputs in the transaction.  In this case that is:

Code:

02

As a hexidecimal number that would be commonly be written as 0x02. Converting that to decimal we see that there are exactly 2 inputs in this transaction.

The next thing in the transaction is the inputs. Each input consists of:

• Transaction ID of the output being spent
• Offset of the output in that transaction
• Script length
• Txin-script  (Also known as: scriptSig)
• sequence_no

So, we should have 2 sets of that information.

A bitcoin transaction ID is a 256 bit hash, so it is 32 bytes long. Therefore the next 32 bytes should be the transaction ID from the first input...

Code:

d8c8df6a6fdd2addaf589a83d860f18b44872d13ee6ec3526b2b470d42a96d4d

Remember that bitcoin uses little-endian byte order.  Typically when transaction IDs are shown to humans they are placed in big-endian byte order, so we'll need to reverse the order of these bytes to see the transaction ID in the format that most people are generally familiar with...

Code:

4d6da9420d472b6b52c36eee132d87448bf160d8839a58afdd2add6f6adfc8d8

Next is the index into that transaction of the output that is being spent as an input in this transaction.  This is a 4 byte value.

Code:

00000000

Looks like the index value is 0

Following that we have the a value that indicates how long (in bytes) the script is:

Code:

8b

Converting the value 0x8b from hex to decimal we see that the script will be the next 139 bytes.

Next we have the Txin-script of the first input:

Code:

483045022100b31557e47191936cb14e013fb421b1860b5e4fd5d2bc5ec1938f4ffb1651dc8902202661c2920771fd29dd91cd4100cefb971269836da4914d970d333861819265ba014104c54f8ea9507f31a05ae325616e3024bd9878cb0a5dff780444002d731577be4e2e69c663ff2da922902a4454841aa1754c1b6292ad7d317150308d8cce0ad7ab

If we want to analyze that script, we can break it into its component parts...

The first byte we see is:

Code:

48

Looking at the bitcoin scripting language, we see that this is an indication to push that quantity of the following bytes onto the script processing stack. Since 0x48 is 72 in decimal, the next 72 bytes will be pushed to the processing stack.  In the case of the typical P2PKH address, this will end up being the digital signature.  As such, we can see that the signature is represented in the transaction as:

Code:

3045022100b31557e47191936cb14e013fb421b1860b5e4fd5d2bc5ec1938f4ffb1651dc8902202661c2920771fd29dd91cd4100cefb971269836da4914d970d333861819265ba01

The next byte we see is:

Code:

41

Looking at the bitcoin scripting language, we see that this is an indication to push that quantity of the following bytes onto the script processing stack. Since 0x41 is 65 in decimal the next 65 bytes will be pushed to the processing stack.  In the case of the typical P2PKH address, this will end up being the public key.  As such, we can see that the public key is represented in the transaction as:

Code:

04c54f8ea9507f31a05ae325616e3024bd9878cb0a5dff780444002d731577be4e2e69c663ff2da922902a4454841aa1754c1b6292ad7d317150308d8cce0ad7ab

We've now reached the end of the Txin-script details.  Next comes the sequence_number which is always 4 bytes:

Code:

ffffffff

That's the end of the first input. The next byte therefore starts the next input...

Inputs start with a A bitcoin transaction ID. A transaction ID is a 256 bit hash, so it is 32 bytes long. Therefore the next 32 bytes should be the transaction ID from the second input...

Code:

2ab3fa4f68a512266134085d3 260b94d3b6cfd351450cff021c045a69ba120b2

Remember that bitcoin uses little-endian byte order.  Typically when transaction IDs are shown to humans they are placed in big-endian byte order, so we'll need to reverse the order of these bytes to see the transaction ID in the format that most people are generally familiar with...

Code:

b220a19ba645c021f0cf501435fd6c3b4db960325d0834612612a5684ffab32a

Next is the index into that transaction of the output that is being spent as an input in this transaction.  This is a 4 byte value.

Code:

00000000

Looks like the index value is 0

Following that we have the a value that indicates how long (in bytes) the script is:

Code:

8b

Converting the value 0x8b from hex to decimal we see that the script will be the next 139 bytes.

Next we have the Txin-script of the second input:

Code:

4830450220230110bc99ef311f1f8bda9d0d968bfe5dfa4af171adbef9ef71678d658823bf022100f956d4fcfa0995a578d84e7e913f9bb1cf5b5be1440bcede07bce9cd5b38115d014104c6ec27cffce0823c3fecb162dbd576c88dd7cda0b7b32b0961188a392b488c94ca174d833ee6a9b71c0996620ae71e799fc7c77901db147fa7d97732e49c8226

You can walk through the steps from the first Txin-script if you want to break this one apart, I'm not going to repeat that here.

Next comes the sequence_number which is always 4 bytes:

Code:

ffffffff

We've now reached the end of both inputs.  The next part of the transaction is the outputs...

The next byte is an indication of the number of outputs in the transaction:

Code:

02

Converting this from hex to decimal, we see there will be 2 outputs.

Each output consists of:

• A value
• Script length
• A Txout-script (Also known as scriptPubKey)

The value is always 8 bytes. So the next 8 bytes is the value of the first output:

Code:

c017530200000000

Converting this to big-endian byte order we get:

Code:

00000000025317c0

Converting 0x025317c0 to decimal we see that the value of the first output is 39000000 satoshi (or 0.39 BTC).

Next comes a value indicating how many bytes long the Txout-script is.

The next byte is:

Code:

19

Indicating that the script is 0x19 (which is decimal is 25) bytes long.

Code:

76a914a3d89c53bb956f08917b44d113c6b2bcbe0c29b788ac

We can break this script into its components if we like. The first byte we see in the script is:

Code:

76

Looking at the bitcoin scripting language, we see that this is the OP_DUP code.

Next we see:

Code:

a9

We can see that this is the OP_HASH160 code.

Next we see:

Code:

14

We can see in the scripting language that this is an indication to push that many bytes onto the processing stack.  Converting the hex 0x14 to a decimal value we see that we need to push the next 20 bytes to the stack.

That would be these 20 bytes:

Code:

a3d89c53bb956f08917b44d113c6b2bcbe0c29b7

Notice that is the 160 bit (20 byte) RIPEMD160 hash value that the bitcoin address is built from.

The next byte is:

Code:

88

We can see that this is the OP_EQUALVERIFY code.

Finally at the end of the script we see:

Code:

ac

We can see that this is the OP_CHECKSIG code.

So, the 25 byte output script of this transaction is:

Code:

OP_DUP OP_HASH160 OP_Push20Bytes (20 byte hash) OP_EQUALVERIFY OP_CHECKSIG

That's the end of the first output. The next byte therefore starts the next output...

As we saw earlier, the first thing in an output is an 8 byte value.

Code:

c01c3d0900000000

Converting this to big-endian byte order we get:

Code:

00000000093d1cc0

Converting 0x093d1cc0 to decimal we see that the value of the first output is 155000000 satoshi (or 1.55 BTC).

Next comes a value indicating how many bytes long the Txout-script is.

The next byte is:

Code:

19

Indicating that the script is 0x19 (which is decimal is 25) bytes long.

Code:

76a91408338e1d5e26db3fce21b011795b1c3c8a5a5d0788ac

You can walk through the steps from the first Txout-script if you want to break this one apart, I'm not going to repeat that here.

Once we get past all the outputs, the only thing left in the transaction is a 4 byte lock_time.  As we can see from your transaction:

Code:

00000000

The lock time is 0.

That's it.  That's the entire transaction decoded.  Hope this was helpful

[ranochigo]

from the white paper
https://bitcoin.org/bitcoin.pdf
A coin is  (previous coin + my public key) -> hash, then signed by previous owner.

when we do transaction, I pass my wallet address only to previous owner. how the previous owner know my public key?

A transaction is a lot more complex than that, I just stated the main components of a transaction.

Let me rephrase that for you. For a transaction, it consist of a reference to UTXO + your public key and a signature that can be validated against your public key. I'm confused over what you meant by the previous owner. The transaction is signed by whoever that is control of the UTXO.

The UTXO consist of the information needed to redeem it. You're right in a sense that the creator of the transaction cannot know the public key as the address is just the hash of it. Most of the people currently uses P2PKH in their transaction and the UTXO contains the information about the hash. Nodes can easily get the address using the public key. If the signature matches the public key and the public key matches the address, the transaction will be valid.

[DannyHamilton]

from the white paper
https://bitcoin.org/bitcoin.pdf
A coin is  (previous coin + my public key) -> hash, then signed by previous owner.

The white paper goes on to explain that such a model is insufficient and that additional features are needed:

In the case of the final implementation of Bitcoin, a "coin" could be thought of as an unspent transaction output.

That would be a value which is encumbered with a requirement that must be met before that value can be spent.  There is a scripting language which is used to place the encumbrance on the value.  The most common script used (version 1 addresses) is a script that requires the spender to supply BOTH a valid public key which hashes to a value supplied in the script AND a signature which can be validated using the supplied public key.

when we do transaction, I pass my wallet address only to previous owner. how the previous owner know my public key?

He does not.

His wallet software uses the "address" to do 4 things to "send the bitcoins to you" in the transaction:

• Extracts a hash value, version number, and checksum from the address
• Uses the checksum to make sure that the address was entered correctly (this allows the wallet software to prevent sending to a mis-typted address)
• Uses the address version to identify which encumbering script to build
• Builds the encumbering script in the transaction with the extracted hash value

When you ask someone to send you some bitcoins, their wallet software choose some unspent transaction outputs for which they can satisfy the encumbrance requirements.  They assemble these as a list of inputs to the transaction to supply value to the transaction.  Then they use the Bitcoin Scripting language to meet the requirements of each input.  They then create an output with the value that you requested, and encumbered with the version 1 script using the hash from the address that you supplied.  As such, nobody can spend that output unless they can satisfy the encumbrance requirements.  The version 1 script requires BOTH a public key that hashes to the same value as stored in the script AND a signature that can be validated with THAT public key.

Since you provided the address, you know the public key and you have the private key.

When you want to spend that "coin", your wallet software lists it in the inputs to your transaction to supply your transaction with value.  Your software then meets the encumbrance requirements by supplying the appropriate script using BOTH the public key that hashes to the value from the output you are spending AND the digital signature that can be validated with THAT public key.  Your software then creates an output with the value that you are paying which is encumbered with a script that is built based on the rules of the address version that was supplied to you when the payment was requested from you.

[icehouse]

Thank you, ETFbitcoin, DannyHamilton and ranochigo

Now I can see what exactly in a transaction. I think I need to spend sometime on it.