Topic: BTC, BCH, and Coinbase Transactions - page 2. (Read 1405 times)

Danny - Again, thank you so much for the detailed tutorial.  It is very helpful.  it took me hours to follow it through.

You have opened a pandora box.    Now more questions for you and hope that you would answer them.

1. Is the ID starts with "1JSkkAq" a public address?  Where does it get mentioned in the transaction code?
2. Where does the 0.00187 BTC fee got mentioned?
3. Please confirm that one transaction can contains multiple payments?
4. How does a transaction get created?
5. What is the base on how the inputs and output get put together?
6. You did not mention what the follow code is:
    6b483045022100f57111d73ea20dc7d989bef2d8c4a2fc
    2bcf1348b67b633090cc353757017fb502206515c5c3c059bd3dd7d144b8fb48
    1dfc25d715b4bab439a7a67b018ab1d1bedf012102759f9014f1179299dc78c1
    114f9872492561aa2a6490f330d7c64ab67646cbd6fffffffff
What are they? 
7. In Segwit, where is the "witness" data in this code?
8. I heard that an average transaction is about 1MB on average, the code does not look 1MB in size to me.  Would you explain why?
9. Could I say Input is like where the BTC go to and "Output" is where it came from or is it another way around or neither?
10. Can one transaction direct payments from different senders and to different receipients?  Or how does it work?

Thank you in advance! 

Danny - great stuffs.  Thank you for the education!  I will read them in detail tomorrow. 

I haven't used a Bitcoin ATM, so I'm not certain how they operate.  I would assume that you would provide the ATM with your bitcoin address, and the ATM would just send a transaction. There shouldn't be any need for you to handle private keys.


It might be possible that an ATM would provide you with a private key and that you would then need to import that private key into a wallet, but that would not be a good way for an ATM to operate.  I think I would avoid using an ATM that did that.


Private keys and addresses are just numbers.  You can't delete them any more than you can delete the number 5 from existence.

You can remove them from your wallet, and an ATM could remove a private key or address from its own wallet, but why?  There is no benefit to removing a private key or an address from your wallet.


From the user's viewpoint, that's a reasonable way to think of it.  At the technical level its a bit more complicated than that, but you seem to already have enough confusion about how bitcoin operates. I don't see a need yet to confuse you more with the details of how transactions actually work.


The blockchain has a transaction that indicates that the BTC have been sent to that address.

---

Ok, sounds like we're going to get into the technical details after all...

Each transaction consists of 2 lists.

One list is called "outputs".  The list of outputs assigns the value that has been provided to the transaction.  Each output in the list is encumbered (in the form of a script) with a requirement that must be met in order to be allowed to use that value to fund some other transaction.

The other list is called "inputs". The list of inputs is a list of previously unspent outputs created by earlier transactions. Each input in the list has a script that meets the requirements that previous output was encumbered with.  It then supplies the entire value of that previous output to the transaction so that the transaction can assign that value to new outputs. Once an output has been referenced by an input, and that transaction is included in a block in the blockchain, the output is considered to be "spent" and can never be referenced by any other input ever again.

Lets take a look at an actual transaction:
https://blockchain.info/tx/93d4a526737d59ba29aeb450cd66071f07ecf5575dbd7dcdae33f7ddbb2a7d09

Here is the transaction in its raw hexadecimal format (I've added line breaks every 32 bytes so that it will hopefully fit better on your computer screen instead of extending off the screen to the right):

That's what is actually sent over the network and stored in the blockchain.

I'll use some line breaks to break that up into its component pieces for you:



Ok lets label those so you know what you're looking at:

First we have a transaction version number.  When converted from hexadecimal to base₁₀ (using little-endian byte order), we see that these 4 bytes of data represent a value of 1. This lets all the nodes know that this transaction is using the rules associated with transaction version 1:

Next we have a number that says how many items are in the input list. Converting from hexadecimal we see that the this byte represents a value of 2. This lets all nodes know that they should look for 2 inputs immediately following this:

After that we have the list of 2 inputs.  We'll break this apart later, but for the sake of keeping everything in the same order as the transaction above so you can follow along here's the data representing those inputs:

Following the list of inputs we next have a number that says how many items are in the output list. Converting from hexadecimal we see that the this byte represents a value of 2. This lets all nodes know that they should look for 2 outputs immediately following this:

After that we have the list of 2 outputs.  We'll break this apart later, but for the sake of keeping everything in the same order as the transaction above so you can follow along here's the data representing those outputs:

Finally, we have 4 bytes that represent a lock time.  If these 4 bytes are not zeros, then they are an indication to all nodes that they should not accept the transaction as being valid until after the blockheight or timestamp indicated by their value.  In most cases for the typical transactions that the typical bitcoin user would send, these 4 bytes will always be zeros.

That's it.  That's the whole transaction.  There is nothing else in there, nothing else transmitted as part of the transaction, and nothing else stored in the blockchain as part of the transaction.

To get a better understanding of how the transaction works, lets take a closer look at those two lists (the inputs and the outputs)...

I'll break the list of inputs into it's two inputs.

Here's the first input, I've broken its components apart with line breaks (you can compare to the list of inputs above):

That first piece, "cbdc5bc140ff336abb9db2674c0521a75c1e4527295362fb97d59cb0840e755d", is the transaction ID of an earlier transaction.  It tells the system, "I'm spending the value that was previously assigned in one of the outputs of transaction ID cbdc5bc140ff336abb9db2674c0521a75c1e4527295362fb97d59cb0840e755d."

That next piece, "04000000", is commonly called the index or the offset.  It tells the system, "I'm spending output number 4 in the list of outputs from that transaction that I just listed."

(note that outputs are numbered starting at 0, so the first output is output number 0, the second output is output number 1, the third output is output number 2, and so on.  Therefore, this input spends the fifth output (output number 4) from transaction cbdc5bc140ff336abb9db2674c0521a75c1e4527295362fb97d59cb0840e755d.

Every node on the network knows now to go look at the fifth output of transaction cbdc5bc140ff336abb9db2674c0521a75c1e4527295362fb97d59cb0840e755d when validating this transaction.

Here's a link to that transaction with the fifth output highlighted in yellow:
https://blockchain.info/tx-index/273813243/4

You can see there that that output provides a total of 0.00674373 BTC (674373 satoshis) in value that this transaction now has available to it to be reassigned.

We'll see later when we look at outputs that they also include a script that must be satisfied with some data in order to be allowed to use them in a list of inputs.  This input satisfies that requirement with the ECDSA digital signature and the ECDSA public key which is that final string of data above.


Here's the second input, I've broken its components apart with line breaks (you can compare to the list of inputs above):

That first piece, "a2e7b484496f7b82432cf9926fb074ba5318c3150232ea903ad5b03b900a896", is the transaction ID of an earlier transaction.  It tells the system, "I'm spending the value that was previously assigned in one of the outputs of transaction ID a2e7b484496f7b82432cf9926fb074ba5318c3150232ea903ad5b03b900a896."

That next piece, "19000000", is commonly called the index or the offset. When converted from hexadecimal to base₁₀ (using little-endian byte order) we see that it represents a value of 25. It tells the system, "I'm spending output number 25 (the twenty-sixth output) in the list of outputs from that transaction that I just listed."

Therefore, this input spends the twenty-sixth output (output number 25) from transaction a2e7b484496f7b82432cf9926fb074ba5318c3150232ea903ad5b03b900a896.

Every node on the network knows now to go look at the twenty-sixth output of transaction a2e7b484496f7b82432cf9926fb074ba5318c3150232ea903ad5b03b900a896 when validating this transaction.

Here's a link to that transaction with the fifth output highlighted in yellow:
https://blockchain.info/tx-index/259879311/25

You can see there that that output provides a total of 1.0 BTC (100000000 satoshis) in value that this transaction now has available to it to be reassigned.

This input satisfies the output's script requirement with the ECDSA digital signature and the ECDSA public key which is that final string of data above.

We can see that a total of:
0.00674373 + 1.0 = 1.00674373 BTC (100674373 satoshis) of value has been provided by the list of inputs.  Next, the list of outputs will assign that value.

I'll break the list of outputs into it's two outputs.

Here's the first output, I've broken its components apart with line breaks (you can compare to the list of outputs above):

That first part, "cd6f070000000000" says how many satoshis are being assigned to the output.  If we convert from hexadecimal to base₁₀  (using little-endian byte order) we see those 8 bytes represent a value of 487373 satoshis (0.00487373 BTC).

The second part is the script that encumbers that value with a requirement that must be met by any input in the future that tries to spend this output.  In this case, that script effectively says, "Supply an ECDSA public key that hashes to the value of "f918ffff345192ae9f3878d49344a7ad99a543f7", also supply an ECDSA digital signature that can be validated with the public key that you supply".  Therefore, when this output is later spent by being referred to by an input in a future transaction, that input will need to supply both the public key and the signature.

Here's the second output, I've broken its components apart with line breaks (you can compare to the list of outputs above):

That first part, "00e1f50500000000" says how many satoshis are being assigned to the output.  If we convert from hexadecimal to base₁₀  (using little-endian byte order) we see those 8 bytes represent a value of 100000000 satoshis (1.0 BTC).

The second part is the script that encumbers that value with a requirement that must be met by any input in the future that tries to spend this output.  In this case, that script effectively says, "Supply an ECDSA public key that hashes to the value of "9529f2ccd600ccb40fee8d56715839b6ff5d0f08", also supply an ECDSA digital signature that can be validated with the public key that you supply".  Therefore, when this output is later spent by being referred to by an input in a future transaction, that input will need to supply both the public key and the signature.

---

So, if you followed along, you should see that the list of two inputs provided a total of 1.00674373 BTC (100674373 satoshis) of value to the transaction, and that the transaction created two new outputs assigned with a total of:
487373 + 100000000 = 100487373 satoshis (1.00487373 BTC).

The remaining unassigned value is:
100674373 provided by inputs - 100487373 used by outputs = 187000 satoshis (0.00187 BTC)

When the transaction gets included into a block in the blockchain, the miner that creates that block is allowed to assign that extra 0.00187 BTC to themselves along with the current block subsidy as their block reward.  That is how transaction fees are handled by the bitcoin system.

Danny - Looks like I got a failing grade on this one!!  (How did you know all these?)

I will go do some more reading before I can continue to have an educational chat with you.

But just to help me out to get a good start, if I get a BTC from a Bitcoin ATM, I will be given a hash code generated (one of the 7.9 X 10²⁸
from using the SHA256), right?  That hashcode is the private key of a new address associated to the BTC I purchased?  And if I spent all the BTC in that address, the address will be deleted?

In the receipient's wallet, that BTC is added to the public address of the wallet?  How does the blockchain know that the public address now own the BTC?  I watched a video about how transactions are connected through hashing process and how new keys are created, but have never understand how it actually work.  Is there any good reference for this kind of info?  (I am asking this more technical question because you seems technical enough to answer it.)

I already explained...


That's up to you.  Did you send all those bitcoins to 1 address, or did you send them to 10 different addresses?


No.  Bitcoins do not have private keys.  Addresses do.

The recipient will create their own address.  That address will have it's own private key.  You will create and broadcast a transaction that removes control over those bitcoins from your address and adds control to their address.  You will still have your address (with 0.5 less BTC), with your private key.  The recipient will still have their address (with 0.5 more BTC) with their private key.


No.  BTC don't have private keys. You should not send them your private key.  That would be a very bad idea.


You'll have to talk to a a tax preparation expert that is familiar with the laws in your jurisdiction. Laws vary and I am not qualified to tell you how your laws require you to report BTC transactions.


They might be in different addresses with different keys.  They might be in the same addresses with the same keys.  It really doesn't matter, as long as you trust Coinbase to keep their private keys secure.  If you do not trust them to do that, then you should not be using their service.


Assuming you are talking about P2PKH addresses (the addresses that always start with a 1), then realistically no.

A P2SH address (the addresses that always start with a 3) can have multiple private keys, but P2PKH addresses only ever have at most 1 private key that anyone has access to.

(At a technical level, each P2PKH address mathematically has about 7.9 X 10²⁸ different private keys that would work, however it is not possible to calculate any of those other private keys, and therefore the only known private key associated with an address is the private key that was used to generate the address in the first place.)

So if I buy 1 BTC now, one private key is created for that purchase. And if I buy the second BTC, another private key is created for that purchase?  In another word, If I bought 10 times (not necessary 1 BTC each), I will have 10 addresses with 10 private keys?  

What if I send .5 BTC to someone, does the private key associate to the BTC get sent over to the recipient?  Won't the person gets the rest of the BTC as he or she has the same private key to half of the BTC?

If I sent a BTC to someone in Coinbase, which purchase of BTC did I send?  (For tax filing purpose.)

So the BTC and BCH are all in different addresses with different keys and I should not be concerned for losing my BCH after sending out BTC via Coinbase?

Am I correct that one public address can contain many private keys?

Bitcoins do not have private keys.  Addresses do.

At the moment of the fork back on August 1, the blockchain forked and Coinbase suddenly had BCH coins associated with the the same addresses where they had BTC.  It is up to Coinbase to decide how they want to manage those BTC and BCH.  Perhaps they left them at the address where they were, perhaps they sent some to new addresses.  In the end, they are all under the control of Coinbase to do what they want with.


It is not actually contrary, although he got the date wrong. I believe that the fork happened around noon or so (UTC) on August 1.

If you sent your bitcoins to Coinbase and relied on them to store the bitcoins during the fork then, as Mekar stated, the BCH came into existence only where the bitcoins were stored.  So Coinbase has full control of those BCH. Coinbase has announced that early in 2018 they will make those BCH available to those that had BTC on account with them at the time of the fork. Until then you will only have access to your BTC at Coinbase.


They shouldn't.  You've chosen to trust Coinbase to manage your cryptocurrency appropriately.  Hopefully they will live up to that commitment.  If you don't trust them to do so, then you shouldn't have given them your bitcoins.

Danny - It is 90% clear now.  Thanks.  Just one follow up question, even the BTC and the BCH are detached, I would assume that their private keys are the same - one for the BTC blockchain and one for the BCH blockchain.  Is that correct?

Barcode - Coinbase has one of the worst customer services in the world - they do not normally respond to inquiries within several weeks, that is if they even respond.  It is incredible!  They got spoiled because they have too many new customers and they can get away from doing no service or doing inferior service.

Mekar - this is in contrary from what Danny was saying.  We may need answer from Coinbase to clarify.

My problem is that I have bitcoins purchased prior to August 1st which entitle me for the same number of BCHs at Coinbase.  But I want to invest $500 in EOS coins.  Since, no exchanges that supports EOS also supports my area, I'm taking tip from some suggestions online to buy $500 of Bitcoin on Coinbase, transfer it to Exodus, and buy EOS with the bitcoin in Exodus.  My concern is that if I send the $500 newly purchased worth of Bitcoin, would Coinbase mess up my BCHs that they are currently holding?

You will only get BCH on the 2nd of August, you will get it where you saved BTC on that date, if you send your BTC now you will not get any

Coinbase is an online wallet and you do not have access to your own private keys to the wallet, how would you be able to get Bitcoin Cash at this moment, I do read about an article on Coinbase planning to integrate Bitcoin Cash onto their platform next year, but I did not really read all the details about it, maybe the best way would be to confirm with the support from Coinbase.

They have not yet said how exactly they will handle that.  However, the most likely result would be to think of the BTC and BTC as already being separated.

So,

On July 31 you have 1 BTC at Coinbase.
On Aug 2, you not have 1 BTC at Coinbase, AND 1 BCH at Coinbase, but they are not allowing you to access your BCH and are not showing it to you when you log into the account. The 1 BTC is no longer "attached" to the BCH, they have been separated and are stored securely.
Today, you buy 1 BTC. You now have 2 BTC at Coinbase, and 1 BCH.

If you transfer 1 BTC from the "BTC Wallet" in Coinbase to a different Wallet, say an Exodus wallet, you will receive 1 BTC.  There will be no BCH attached to it.


That depends on where you transfer it.

If you send it to someone else's Coinbase wallet, or to a merchant that uses Coinbase to process transactions, then it will not be handled by a miner.  The transaction will occur entirely internal at Coinbase.  They will simply reduce the total balance information in their database for your account, and increase the total in their database for the receivers account.

If you send it somewhere outside of Coinbase, then they will need to broadcast the transaction so it can be confirmed.


No.  You do not have access to the private keys of a Coinbase account.

If I have 1 BTC before Aug 1st in Coinbase, I now have 1 BTC and 1 BCH.

If I bought the second BTC today at Coinbase, I will only have 1 BTC.

Both BTCs are stored in "BTC Wallet".

Now, if I transfer 1 BTC from the "BTC Wallet" in Coinbase to a different Wallet, say an Exodus wallet, which of the BTC (1st or 2nd) am I transferring?  Notice that the 1st BTC has BCH attached to it.

Also, does transfer considered as a transaction?  Does miner need to process it or it is just like moving the private key from one place to another?

I should have asked Coinbase support on this question, but their customer services is the worst I have ever encountered and I know they are not going to answer my questons.


Thank you in advance for anyone tries to help.