Topic: BTC, BCH, and Coinbase Transactions (Read 1391 times)

Danny - I really appreciate you put in the time to help me to understand all these. 

Blockchain is an incredible and interesting technology.  New implementations and ideas that derive from it continues to come out.  There are still much for me to learn.

So if you are not a miner, are you a blockchain developer?  Blockchain developers are in high demand nowadays.

Are you familiar with Lightning Network and cross-chain technology called COMIT (by the TenX team)?   If you are, do you think they will work?

Correct.


Not exactly.

As an analogy, think of it like this...

Alice receives a small lump of gold worth 2 BTC from Mike.
Alice receives a small lump of gold worth 0.75 BTC from Nancy.
Alice received a small lump of gold worth 0.8 BTC from Oscar.
Alice wants to pay Bob 1 BTC.
Alice takes the lump of gole from Nancy and the lump of gold from Oscar and melts them together in a crucible.
Alice pours out a lump of gold worth 1 BTC.
Alice pours out a lump of gold worth 0.55 BTC.
Alice gives Bob the new 1 BTC lump of gold.
Alice keeps the remaining 0.55 BTC lump of gold.

Notice in the above, there were 2 inputs into the crucible, providing the crucible with a total of 1.55 BTC of value.
Notice in the above that there are 2 outputs from the crucible (one worth 1 BTC, and the other worth 0.55 BTC)
Notice in the above that it is impossible to tell how much of Nancy's lump of gold and how much of Oscar's lump of gold Bob ended up with.

Transactions have a list of inputs (supplying value to the transaction) and a list of outputs (assigned value). There is no indication in a transaction of which output value came from which input value.


Correct.

Most wallets do not give the user the ability to choose which unspent outputs will be used to fund the transaction.


Some wallets (such as Bitcoin Core) provide a feature commonly called "coin control".  This feature will list the unspent outputs that the wallet has control over and allow the user to pick the outputs they want to use to fund the wallet.  However, if Alice isn't using such a wallet, or isn't using the coin control feature of the wallet, then the wallet will make the decision about which outputs to use.

If Alice wants to send a new transaction that pays a transaction fee and wants to be certain that only 1 of the two transactions will confirm, then she MUST use at least 1 input in the new transaction that is identical to an input in the previous transaction.  As such, she must either build the raw transaction data herself or use a wallet that provides the "coin control" feature.


I've never done any mining.  The hardware and the electricity are too expensive. It has always been cheaper for me to just buy the bitcoins that I want to have.


Yes.  If you can afford it, your best option at the moment (until better hardware is created) is probably the "AntMiner S9" from Bitmain.com. It can accomplish approximately 14000000000000 hashes per second (14.0 TeraHashes per second), and uses only about 1.372 kiloWatts. So for every continuous 30 days that you operate it, you'll need to pay for a bit more than 1000 kiloWattHours of electricity.  At my local rate of about $0.13 per kiloWattHour, that would cost me a bit more than:
0.13 * 1000 = $130


When its not running, its not mining.  Since you'll invest quite a bit of money to purchase the equipment, you'll want to generate as much Bitcoin as you can in as short an amount of time as possible before the difficulty increases too much.  Therefore, you'll want to keep it running continuously if possible.

NOTE: If you are just wanting to learn what it's like to install and configure mining equipment, then you can buy MUCH cheaper (older) bitcoin mining equipment.  You can probably also find equipment that will use much less electricity. You'll spend a lot less money on it, but it will generate a LOT less bitcoins as well.
 

I don't know anything about any altcoins.  I'm not interested in them at all.  You'll have to ask someone else for information about altcoins.


That depends on what altcoin you want to mine.


That depends on what equipment you buy.


There are two types of cost.

There is the upfront cost to purchase everything, and then there is the net cost after you subtract out what you've earned after a year or two.

If you are mining bitcoins, then the AntMiner S9 is likely to have the smallest net cost after operating it for a year or two, but if you stop after a few days (or weeks), then it is likely to have a rather high cost since you won't have generated enough bitcoins to cover the initial cost yet.

Other older equipment will have a much lower initial cost, but might not generate enough bitcoins to even cover the electricity costs of running it. In that case, the longer you run it, the higher your net cost.

Thank you for your info.  Originally, Coinbase said that they would not support BCH, but after seeing the price went up and people threatened to sue, they changed their mind and decided to allow people to withdraw BCH by Jan 1st 2018. They are currently working on it - perhaps, they will also include BCH in their platform.

For all these times, I thought that Coinbase is not an exchange, until I checked online after reading your post.  Here is what's on Wikipedia about Coinbase:

Coinbase has two core products: a Global Digital Asset Exchange (GDAX) for trading a variety of digital assets on its professional asset trading platform, and a user-facing retail exchange of Bitcoin, Ether, and Litecoin for fiat currency.  The second one might be what most people are referencing as "Coinbase".  It is a product which offers exchange services and online wallets from Coinbase.

Coinbase is an online wallet, not a exchanger site.If you deposit 1 btc trading site you get 1 bch.Example if you have 1 btc bittrex,livecoin, faucethub same get 1 bch.

On a second thought, no need to answer my mining questions because it will probably be very costly.  Also, it costs about $0.092 per kWh.  It is probably relatively high. 

Danny - Thanks again!  I do not know how you can always answer with very thorough and detailed contents so quickly!

In order to understand your answers on the base conversion better (not that your answer is not good enough ), I had to review some sites and youtube videos (not easy to find good ones that suit me).  Now I understand this topic much better.  

Good to know that 1 byte = 8 bits and  8 bits is with 8 "0" and "1" in binary like 01010101.  


This is very interesting!

Your explanation on the transactions is very well put.  The inputs and outputs concept can be a little confusing, but your example nailed it.

As I do not manage my own private key and hard wallet and have to rely on company like Coinbase, the concept of creating a transaction and send BTC out is very foreign to me.

So Alice creates a transaction which subsequently creates two inputs (that were outputs with 0.75_a BTC and 0.8_b BTC, respectively, in a prior block).  The transaction creates two outputs via the program logic.  The program takes 0.75 BTC from input_a and 0.25 BTC from input _b to send to Bob and takes the remaining 0.5 BTC from input _b to send back to Alice.  Is this flow correct?  

You used "If" in "If Alice's new transaction...", is it because the transaction is program driven and Alice has no control (and does not care) on how it arrages the inputs and outputs internally once it is executed by her?  If that is the case, then it is not necessary that Alice can be sure that a tranaction can spend the 0.75 BTC output from Nancy because the transaction may spend the 0.8 BTC output from Oscar instead and 0,2 BTC output from Nancy.

Not sure if you can help on this, but if I were want to mind coins just to gain educational experience, what suggestions would you have for me?  I know I need to get hardware and software and the machine will probably need to run all day long.  Which of the coins is worth mining with the high per unit electricity cost in a big US city?  The info I need is probably the following:

Where to get a hardware?  
Where to get software?  
How to put everything together?
How to store coins earned?
Where and how to sell the coins?

It may not be profitable for me to mine, but I will like, at least, to minimize the cost.  

This is not computer science.  This is mathematics.

Those are just two different ways of representing numbers.

The first "6b483045022100f57111d73ea20dc7d989bef2d8c4a2fc" is hexadecimal (or base₁₆).  The second "0000011000100100000001" is binary (or base²).  The way you are probably most familiar with is decimal (or base₁₀).

Comparing:
base₁₀ -> base₂ -> base₁₆


Note that:
binary only has 2 digits to work with (0 and 1)
hexadecimal has 16 digits to work with (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, and f)
decimal has 10 digits to work with (0, 1, 2, 3, 4, 5, 6, 7, 8, and 9)


Perhaps you'll recall from maths back when you were about 12 years old or so that our decimal numbering system can be represented as follows:
5462 = (5 X 10³) + (4 X 10²) + (6 X 10¹) + (2 X 10⁰)

Noticing in the conversions that I showed you up above, "a" represents a decimal value of "10" and "b" represents a decimal value of "11", we can represent the base₁₆ number "ab" as:
ab = (10 X 16¹) + (11 X 16⁰)

Therefore, in our common decimal system "ab" = 171

You can represent that same number in binary by figuring out which of the binary digits will work in the following formula to result in a value of 171:
(? X 2⁸) + (? X 2⁷) + (? X 2⁶) + (? X 2⁵) + (? X 2⁴) + (? X 2³) + (? X 2²) + (? X 2¹) + (? X 2⁰)

The answer is:
10101011

Conversion from hexadecimal to binary has this nice mathematical property that every 4 binary digits represents one hexadecimal digit, so if you look in my example above:
a = 1010
and
b = 1011

And looking at the conversion of ab you see that it is just those two values concatenated together.


No.  The block consists of a list of transactions and an 80 byte header with the following information:

• Version (4 bytes)
• Hash of previous block in the chain (32 bytes)
• Merkle root (32 bytes)
• Timestamp (4 bytes)
• Representation of the current difficuty target (4 bytes)
• Nonce (4 bytes)

It is this set of 80 bytes that the miners are hashing to see if they can find a hash result that is low enough.


The timestamp is ALWAYS included in the input to the hash.  The Merkle Root is also ALWAYS included in the input to the hash.

Therefore, by changing the values of the first transaction (which would change the Merkle Root) or the timestamp, the input to the hash is changed for another 4294967296 possible nonce values.


A byte consists of 8 bits.  Each bit represents binary position. So a 4 byte number can be anything between:
00000000 00000000 00000000 00000000
and
11111111 11111111 11111111 11111111

You can start with a nonce value of
00000000 00000000 00000000 00000000
and then try
00000000 00000000 00000000 00000001
and then try
00000000 00000000 00000000 00000010
and then try
00000000 00000000 00000000 00000011
and then try
00000000 00000000 00000000 00000100
and then try
00000000 00000000 00000000 00000101
and so on until after 4294967296 tries you end up at:
11111111 11111111 11111111 11111111

At that point, any other combination of 32 1's and 0's will simply be a repeat of a number you already tried.  To get a different 80 byte header, you'll need to change something else in the header. If something else in the header is different, then you can try all 4294967296 possible nonce values again and you'll get 4294967296 new hash results.


Make certain that they refer to the same previous unspent outputs.


No.

In layman's terms...

Alice receives 2 BTC from Mike in a single transaction output.
Alice receives 0.75 BTC from Nancy in a single transaction output.
Alice receives 0.8 BTC from Oscar in a single transaction output.

(The total is 3.55 BTC, but alice actually has control over 3 separate currently unspent outputs).

Alice creates a transaction that spends the 0.75 BTC that she received from Nancy AND the 0.8 BTC that she received from Oscar (these are the inputs to the transaction).
The total value that these inputs have provided to the transaction is 1.55 BTC

Alice's transaction creates 2 outputs.
One of them is a 1 BTC output that requires a signature from the private key that is associated with Bob's bitcoin address.
The other is a 0.55 BTC output that requires a signature from a private key that Alice's wallet is storing internally.
Since the entire 1.55 BTC of value supplied by the inputs has been used up by the outputs, there is no remaining value for the miner to be able to assign to himself. There is no transaction fee.

Now, Alice decides to "submitted the same transaction (says pay Bob with 1BTC) with fee after the no-fee transaction was submitted"...

If Alice's new transaction...
Lists the 2 BTC output from Mike as an input
Lists 1 BTC output that requires a signature from the private key that is associated with Bob's bitcoin address as one output
Lists 0.99 BTC that requires a signature from a private key that Alice's wallet is storing internally as the other output.

Then this second transaction will have a 0.01 BTC transaction fee, and will pay Bob 1 BTC.  However, both transactions to Bob can confirm. If they both do, then he will receive 1 BTC from each transaction.

On the other hand if Alice's new transaction...
Lists the 0.75 BTC output from Nancy as an input
Lists the 2 BTC output from Mike as an input
Lists 1 BTC output that requires a signature from the private key that is associated with Bob's bitcoin address as one output
Lists 1.74 BTC that requires a signature from a private key that Alice's wallet is storing internally as the other output.

Then this second transaction will have a 0.01 BTC transaction fee, and will pay Bob 1 BTC.
In this case, since the original 0-fee transaction AND this new 0.01 BTC fee transaction BOTH try to spend the 0.75 BTC output from Nancy, only one of those two transactions can confirm.  Once one of them confirms, the other one becomes invalid and is discarded by all participants in the system.  An output can only be spent as an input once in the blockchain.  Once it is spent, any other transaction that tries to spend the same output is considered to be an invalid transaction by all participants in the system.  Any block that contains such an invalid transaction would be an invalid block and would be discarded by all participants in the system (regardless of how long the chain is that contains that block).


The only BTC that exist are the outputs in the transactions in the chain.

If Alice received BTC in a transaction in the "winning" chain, then she will get those BTC.  If Alice does not receive BTC in a transaction in the "winning" chain, then she doesn't have bitcoins.

Did you finally get the issue resolved?  They are very slow.

Danny - I am back again!

After watching the video you shared plus some other videos I previously watched on blockchain, I have a much better understanding.

Example, when you said "By changing the first transaction, only the final step of building the tree needs to be repeated, so it is much faster than changing any transaction later in the block.", without understand the merkle tree, it is hard to understand why.  The reason why is because the merkle tree process starts from the bottom up when it pairs the transactions together.

More questions:

1. Could you explain why the hash is in "6b483045022100f57111d73ea20dc7d989bef2d8c4a2fc" and the example in the video is in "0000011000100100000001"?  This is computer science.   (I made the 01 string up.)

2. How does one byte of info like "ab" translate into the "01" string?

3. When you said, "Once all those different nonce values have been tried, then the miner (or pool) needs to change something else in the block header.  Typically this would either be the timestamp, or the first transaction in the block.", isn't the block header is just the nonce?  Do you mean that if all the different 4294967296 nonce values have been tried and still cannot solve the block, it will include the timestamp or the first transaction into the hash?   I know this part is probably very technical.

4. Technically or mathematically, how does 4 bytes create 2³², 4294967296 of combinations?

5. To follow up with the following:
Q: 3. If I submitted the same transaction (says pay Bob with 1BTC) with fee after the no-fee transaction was submitted, and it got executed, would the no-fee transaction get executed later and led Bob to receive 2BTC (assuming I have 2BTC in the same wallet)?

A: That depends on how you build the transaction.  If you use at least one of the same inputs in both transactions, then only one of the transactions can confirm. Once one of them confirms, the other becomes invalid (since it has an input that has already been spent). If there are no inputs that exist in both transactions, then they can both confirm.

How to generate the same inputs in multiple transactions?  In a layman term, the input hash would come from "Alice send 1 BTC out" and output hash would come from "Bob should receive 1 BTC"?

6. Back to the "voting" issue.  I read that the miners will continue on the longest chain when there are a split.  The video you shared also demonstrate that when Alice try to double spend her money, two chains occurred and the miners would eventually accept the longest one.  When this happened, what the temporary split happened, does Alice receive BTC reward from solving blocks in her own chain?

Thanks again in advance.

This will be my must watch video tonight.  Even though I am not doing anything with it, but learning blockchain technology has been my hobby.  I will follow up later.   

Remember from earlier in our discussion that an input is a reference to an output from a previous transactions.  An input is "identical" if it references the same output from the same previous transaction.

Coinbase and Kraken do not provide "wallets".  They provide "accounts".  The difference is that with a "wallet", you have control over your private keys and you are responsible for your bitcoins. You use wallet software to create, sign, and broadcast transactions, as well as to monitor the blockchain and identify which outputs you have control over.

With an "account", you send your bitcoins to the account provider.  The account provider maintains control over the private keys and has full control over the bitcoins.  Then they provide you with information about how many bitcoins they are managing for you.  When you want to send bitcoins somewhere, you ask them to send the bitcoins on your behalf. They send some of THEIR bitcoins where you ask them to. They provide you with one (or more) of THEIR bitcoin addresses that you can share with others to have bitcoins credited to your account with them. Whenever THEY receive bitcoins on that address, they update in their records how many bitcoins they are managing for you.

As such, Coinbase and Kraken have full control over the inputs and the outputs.  They decide wether to re-use an input or not.  You don't have any control over that if you have an account with them.


Because once you've validated the transaction, only the outputs matter.  That is the information that is needed for validating future transactions.



Because once you've validated the transaction, only the outputs matter for the intended purpose of validating future transactions.


Correct.  The list of values and requirements that those values are encumbered with in order to be spent.


They are not valid.  They  are not kept.

By the way, have you seen this video yet. It doesn't really do a good job of describing how Bitcoin transactions work at the technical level, but it does a GREAT job of explaining how the concepts of a blockchain and cryptocurrency work in general:
https://www.youtube.com/watch?v=bBC-nXj3Ng4

Danny - Thanks again!  Here are more questions for you.  I will need to digest your answers for 5(a-d) a little.  So more questions coming up afterward.

1. How to replicate an input and what piece of data makes input identical?  Example, if I send Bob 1 BTC to his Coinbase wallet from my Kraken wallet twice, is that enough to produce the same input?

2. Could you elaborate "As they process each and every transaction in the blockchain, they add any new outputs to their UTXO and they remove any inputs from the UTXO"? Why add outputs and remove outputs and not remove the transactions as a whole?

3. Why UTXO is keeping only the outputs?  When you said "Outputs" you mean the part of the code in a transaction, correct?

4. Where are the invalid transactions being kept?

Correct. The protocol doesn't have any rules about how long an unconfirmed transaction can or should be remembered. That is left up to any developer that creates client software to decide for themselves.  So long as the transaction remains valid, anyone that received it could always re-broadcast it to remind all the other client software about if they want to.


Once a transaction is signed and shared, there is no mechanism for cancelling it.  Anyone can keep that transaction in their mempool for so long as it is valid and can re-broadcast it at any time.

However, if a different transaction that spends any of the same inputs gets confirmed, then the pending transaction becomes invalid (because the protocol rules only allow an input to be spent once). Therefore, you could create a different transaction that is funded with at least one fo the same inputs and that pays the entire value (less any transaction fee) to yourself. If you can get that replacement transaction confirmed (by paying a high enough fee perhaps), then the original transaction becomes invalid (which is not exactly the same as "cancelling" a transaction but has a similar effect).

It can, however, be difficult to get the replacement transaction confirmed while the original transaction is still in the mempool of most of the client software on the network.  This is because most client software will reject the replacement transaction as invalid (since the inputs are already spent in the transaction in their mempool). Therefore, they will refuse to relay it to any other clients.

A recent version of the Bitcoin Core software did create a mechanism for wallets to mark a transaction as replaceable when it is created so that other clients know to accept the replacement transaction, but that functionality is turned off by default in most wallet software.
 

That depends on how you build the transaction.  If you use at least one of the same inputs in both transactions, then only one of the transactions can confirm. Once one of them confirms, the other becomes invalid (since it has an input that has already been spent). If there are no inputs that exist in both transactions, then they can both confirm.


All full nodes on the network keep an indexed list in RAM of all the unspent outputs that they know about. This is commonly called the UTXO (Unspent Transaction Output) list. They can look up the inputs from the transaction in that list to see if they exist, and then immediately know what the value of the input is and as well as the script that must be satisfied. Building this list is the reason that full node clients (such as Bitcoin Core) need to synchronize the entire blockchain before they work properly. As they process each and every transaction in the blockchain, they add any new outputs to their UTXO and they remove any inputs from the UTXO. Once the entire blockchain has been processed, they have a list of every unspent output that exists. Then they just do the same for each transaction as they hear about it to keep the list up to date.

This work isn't just done by miners. It is done by every peer-to-peer full node on the network. The transaction is validated before accepting it into the mempool, and before relaying it on to any other peer.


Sure.

First the solo miner (or mining pool) does the following two steps:

• The two transactions are each hashed individually and those two hashes are used to build a merkle tree.
• The block header is then built including the merkle root.
• If it is a mining pool, then the block header is given to a pool participant to handle the hashing
• If it is a solo miner, then they handle the hashing of the header themselves

The solo miner (or the pool participants) do the following:

• 1. Calculate the SHA256 hash of the block header
• 2. Calculate the SHA256 hash of the result of step 1
• 3. Check to see if the result of step 2 is less than the current difficulty target value.
• 4. If it is less, then the block is "solved". The resulting block header is broadcast to all connected peers
• 5. If it is not less, then change something in the block header, and return to step 1.

There are 4 bytes in the block header that exist only so that the block header can be quickly and easily modified. This set of 4 bytes is called the "nonce".  4 bytes is enough to allow the miner to create 2³² (that is 4294967296) different block headers (each identical except for a different nonce value).

Once all those different nonce values have been tried, then the miner (or pool) needs to change something else in the block header.  Typically this would either be the timestamp, or the first transaction in the block.

Changing the timestamp effects only the header and results in another 4294967296 possible block headers to try.

Changing any transaction in the block requires the computation of a new merkle tree and as such, the merkle root in the block header will be different. By changing the first transaction, only the final step of building the tree needs to be repeated, so it is much faster than changing any transaction later in the block.


There are 32 bytes in the block header that are used to store the SHA256 hash (actually the hash of the hash) of the previous block.

For any block in the chain, this "previous block hash" identifies which block comes immediately before it in the chain.


The solo miner (or mining pool) sends the solved block to every peer that they are connected to.  Each peer checks to make sure the block and transactions are valid, then then relays the block to every peer that they are connected to. The processes of validating and relaying continues until every client on the network has heard about the block.


There is no voting.  They check every transaction to make sure there are no invalid transactions in the block, and they check the block to make sure it is valid.  If it is not valid, they reject it and refuse to relay it to anyone else. If it is valid, then they accept the block, add it to their own copy of the blockchain, and relay it to all the nodes that they are connected to

Thanks again for your help, Danny!

1. So if a no-fee transaction is "floating" in the pool for a while, does it get removed?

2. Is there a way to cancel that no-fee transaction? 

3. If I submitted the same transaction (says pay Bob with 1BTC) with fee after the no-fee transaction was submitted, and it got executed, would the no-fee transaction get executed later and led Bob to receive 2BTC (assuming I have 2BTC in the same wallet)?

4. How do the miners detect if a transaction is a good one (ex: has enough money to pay) to be included into the block?  That verification process has to be very fast, right?

5a. Could you also explain how a make believe two transactions block get processed?   b. How the hash work in this and how blocks are linked?  c. How the miner submit the solved block for consensus?  d. How other miners verify to see if the block is indeed solved and how they vote (need >50%)?

Most of the block explorer websites provide a list of unconfirmed transactions from their memory pool. Here are a few examples:
https://blockchain.info/unconfirmed-transactions
https://live.blockcypher.com/btc/

And here's a website that gives a visual representation of the unconfirmed transactions from it's mempool and the fees paid by those transactions:
https://jochen-hoenicke.de/queue/#24h

Also, here is a website that monitors the transactions and fees, and then suggests a reasonable fee for fast confirmation:
https://bitcoinfees.21.co/


Yes.


A bit smaller than that.  The block header is always 80 byte, but other than that yes it should be possible.



The number of transactions does not significantly change the time to solve a block.

It may take a few milliseconds longer to build the 80 byte block header for a block with 2000 transactions than it takes for a block ith 1 transaction. Once the block header is built, the solving process involves repeatedly calculating SHA256 hash on that 80 byte block header. That is where all the time is spent and that process isn't any faster if less transactions were used when building the block.


Correct.  The time it takes to solve a block is completely random, but the difficulty is adjusted regularly to try and keep the average time close to 10 minutes.


No.  The difficuly changes only based on the amount of time it took to complete the previous set of 2016 blocks.

After each set of 2016 blocks, all the nodes look at the timestamp of the current block subtract the timestamp of the block at the beginning of that set. If the difference is more than 1,209,600 seconds (20,160 minutes), then it is taking too long and the difficulty is adjusted proportionally to make mining easier. If the difference is less than 1,209,600 seconds (20,160 minutes), then it isn't taking long enough and the difficulty is adjusted proportionally to make mining more difficult.

Danny - You are awesome!  Your examples are very practical and reflect the real life scenario.

Could you share which free website services, if any, that allow someone like me (just a curious learnser) to see the current available transactions and each of their fees? 

I have the following new questions for you:

1. Is it possible for a transaction with no fee whcih will never got processed?

2. I know that an average transaction size is about 375 bytes, but in therory, one transaction size could get as high a 1MB, correct?

3a. Would it be possible for a miner to include only few profitable but low bytes transactions to speed up the solving process to beat other competitors? 
  b. Is there a rule for this, as on average, it should take about 10 mins to solve a block? 
  c. Does the difficulty change based on the number of total bytes in the block?

The number of characters you provided in the prior example has 748 characters (374 byts) which mirrors the average size you mentioned.  I do understand that the average size probably flecturate between 500 to 750.

Miners do not determine the fee.  The sender of the bitcoins decides what fee they want to pay when they create their transaction.

Solo miner (or mining pool) decides which transactions they want to include in the blocks they build. They can include whatever valid transactions they want to.  The protocol requires that only valid transaction be included in the block, but it does not put any restrictions on the miner's (or pools') choice beyond that.

Since most miners (and pools) do their mining to try and earn a profit, and since they are currently limited to 1 megabyte per block, they can maximize their profit by choosing the transactions that pay the highest fee per byte.  Therefore, they will generally sort the transactions by fee-per-byte and then choose choose transactions until they've filled the 1 megabyte limit, leaving the rest of the transactions from someone else to include in a later block.


Given what I just explained above...

Imagine that it is very important to you to get your transaction confirmed soon (within the next block or two).

Next, imagine that you're running a program that keeps track of all the transactions that are relayed to you on the bitcoin peer-to-peer network.

Now imagine that you've noticed that there a a bit more than 1 megabyte of transactions that have been sent in the past few minutes that are not in a block yet and are all paying a fee of 0.01 BTC per byte.

Imagine that you've also noticed an additional 1 megabyte of transactions that are not in a block yet and are all paying a fee of 0.009 BTC per byte.

If you were going to create a transaction, you could:

• Pay a fee of 0.00001 BTC per byte, expecting that at least the two blocks will be filled with higher fee transactions, and hoping that eventually there will be less transactions waiting and your transaction will hopefully be confirmed in 3 more blocks, or perhaps not for a few hours or longer depending on what other transactions are sent after you send yours
• Pay a fee of 0.0099 BTC per byte and hope to get your transaction in the next 2 blocks as long as there aren't too many higher paying transactions sent after yours
• Pay a fee of 0.0101 BTC per byte and assume that it is likely that you'll get in the next block as long as an additional megabyte worth of transactions don't get sent with a higher fee than yours after you send yours
• Pay a fee of 0.02 BTC per byte, and feel pretty confident that nobody in the next 10 minutes or so is likely to be willing to pay that much, so it is extremely likely that you transaction will be confirmed in the next block or two

There are wallets that keep track of the transactions in the blocks and on the network and make fee suggestions so you can increase the likelihood of getting confirmed soon without paying excessively more than needed.  There are also website services that give fee advice using similar methods.



Yes.  They MUST pick only valid transactions.  If they pick invalid transactions, then their block will be invalid and nobody will accept it.  If they include an invalid transaction, then they will waste their time, money, and effort working on a block that will not earn them anything.


Note that when you say "the mempool" you mean "their mempool". There isn't just 1 mempool.  Every node on the network maintains their own mempool of transactions that they have heard about which have not yet been included in a valid block.

The miner can include no more than 1 megabyte worth of transactions in the block right now.  They can include less if they want to.  There is no requirement that they include ANY transactions other than the reward transaction that pays them, and they aren't even required to pay themselves the full reward if they don't want to (although it would be rather foolish not to pay themselves everything they are entitled to).


The wallet software chooses as many inputs as it needs to in order to supply enough value to the transaction. Then it creates all the outputs needed for the purposes of the transaction.


That person that is sending you 1 BTC might not have a single output valued at 1 BTC to send you.

Perhaps they received 0.75 BTC from someone in the past, and then later they received another 0.8 BTC from someone else.

0.8 BTC isn't enough value to send you 1 BTC. In order to send you 1 BTC, their wallet will need to use BOTH as inputs.  That will supply a total of 1.55 BTC of value to the transaction in the input list.

Then their wallet can create an output for you with 1 BTC of value, but that leaves 0.55 BTC of value left over.

If they don't want to pay a 0.55 BTC fee, then will need to send that additional value somewhere.  Their wallet software can create a new private key and address that keeps track of internally, and create a second output of 0.549 BTC to that second address.  This is commonly called a "change address" or "change output", since the wallet is receiving this value back from the transaciton much like how you'd receive $5 back in "change" if you paid with a $10 bill for something that cost $5.

As you can see, this seller is sending you just 1 BTC, but the transaction has 2 inputs (one with 0.75 BTC value, and one with 0.8 BTC value) and 2 outputs (1 BTC to you, and 0.549 BTC back to their own wallet as "change").  The remaining 0.001 BTC of value that isn't accounted for in the outputs is available for the miner that includes the transaction in a block.


Any scenario where more than one input is needed to provide enough value, or where more than one output is needed to accomplish the goals of the transaction.


Hashes are generally displayed to humans in hexadecimal.  The transaction data that I supplied above is also displayed in hexadecimal. There are 16 possible characters in hexadecimal (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F)

Typically in hexadecimal, each character is half of a byte.  



I haven't calculated the exact average size, but 375 bytes sounds pretty close.

Therefore, yes, the total number of transactions in one average block would be somewhere around 1000000/375.

1000000 / 375 = 2667

(Notice that, since the average time between blocks is 10 minutes, this means that the Bitcoin blockchain system can currently handle an average of about 2667 transactions / 600 seconds = 4.4 transactions per second. Any more than that, and a backlog begins to build up as transactions need to wait for later blocks)

Looking at the 10 most recent blocks as I am writing this response, I see they contained the following numbers of transactions:

1591
1360
1896
2302
1999
1374
2288
1812
2844
1843

So, my estimate of average transaction size might have been a bit small. Using those 10 blocks, it appears that the average transaction size is closer to:

1000000 bytes / 1930 transactions = 518 bytes per transaction

Most of my transactions have only 1 or two inputs and only 1 or 2 outputs, but I suppose exchanges, and other businesses can reduce their cost per transaction by batching up any payments they need to make and including more outputs in their transactions.

Danny - I'm back. 

You got to be a developer in order to be able to share all these info.  They are deep!

Hope you can answer more of my questions below.

1. How do miners determine the amount of the fee?  Let's say if I made a buy transfer for 1 BTC, what is the maximum fee that a miner can include?  I heard that some high transactions fee were included by the sellers to induce miners to process them first?

2. Can miners pick the transactions to be included in their block?  Says there are 5000 transactions in the mempool and a miner selects 1000 transactions to be included in his or her block.

3. How do multiple inputs and outputs get created from someone?  Example, if I buy 1 BTC, that transaction would only create 1 input and 1 output.  In what type of  scenario would multiple inputs and outputs be created?  ( I refer the scenario as the "base" in question five in my previous post.) 

4. So each of the characters in the hashcode is one byte and there are an average of 375 bytes in one transaction, therefore, the total number of transactions in one average block is 1000000/375?

Thank you in advance.

Danny - Thanks again for being so help.  I need some times to digest the information you provided in order to get back to you.   There are some technical terminologies that I am not familiar with and will need to look it up. 

That is the public bitcoin address.


It does not.

Addresses are an abstraction that wallet software creates for us so that we humans can more easily talk about the transfer of control over value.

The address has a "version number" included in it (that's why all the typical P2PKH addresses start with a 1).  The wallet knows that the version number is telling it to create a specific type of output script.

For example, if you decode the address "1EbhwDFq9JXPTnEX5nQU6Zs5PHqazyns6F" from base₅₈ back into hexadecmial you'll get the following 25 bytes:


The first byte "00" tells the wallet what type of transaction output script to create (in this case a P2PKH script).

The next 20 bytes "9529F2CCD600CCB40FEE8D56715839B6FF5D0F08" is the RIPEMD160 hash of the SHA256 hash of the ECDSA public key.

The final 4 bytes "EB4289A0" are a checksum used to catch any typos when you enter the address.  This is why you can't just mistype a bitcoin address.  Any well written wallet will verify the checksum and tell you that you've entered an invalid address.

Those 20 bytes in the middle, "9529F2CCD600CCB40FEE8D56715839B6FF5D0F08" are in the transaction output when the script is built.  You can see it in the description I gave you earlier:



That "1976a914" and the "88ac" in the code box above are the script commands that tells all the nodes on the network what requirements this output is encumbered with.


It doesn't.

The inputs are listed which supply a total of 100674373 of value to the transaction.
The outputs are listed which assign a total of 100487373 of value from the transaction.

The remaining amount of value that was supplied to the transaction and not assigned to any output is called a "transaction fee".  The rules of bitcoin allow the miner that included the transaction in his block to assign this extra value to himself.


Correct.  A single transaction can contain many outputs.


Your wallet software creates it when you ask it to.  It uses the bitcoin address and amount that you want to pay to create the output list, and the knowledge that it has stored about transaction outputs with requirements that it can satisfy to create the input list.


Base?

There is a version number, then a number indication the quantity of inputs, then the list of inputs, then a number indicating the quantity of outputs, then the list of outputs, then the locktime.  That's it.  The wallet software then sends those bytes of data in that format to all the peers that it is connected to.


They are the signature and public key that are needed to satisfy the requirements of the output that was referred to.  I explained that here:


Lets avoid segwit for now.  That adds new script types and new address types.  Once you are confortable in your understanding of how bitcoin works in general, you can start investigating other transaction types such as P2PK, P2SH, and SegWit.


You heard incorrectly.  Blocks are currently limited to 1 megabyte maximum per block.  If transactions were 1 MB each, then each block would only have 1 transaction.  Average transaction size is closer to 370 bytes.

Specifically, using modern compressed key addresses, there are about 10 bytes total for the combined:

• version (4 bytes)
• quantity of inputs (typically 1 byte)
• quantity of outputs (typically 1 byte)
• lock time(4 bytes)

Then each input itself adds approximately 148 bytes to the transaction, and each output adds 34 bytes to the transaction.


The other way around.

Each input is a reference to value that you are able to spend.  It adds that value to the transaction.

Each output then assigns that value to someone else's control.


Transactions don't know anything about senders or recipients.  Transactions just have inputs and outputs.

So, you could create a single transaction that has 3 inputs that are each supplied by a different sender.  Each sender would need to have their wallet software supply the signature and public key portion of their input.

Then the transaction could have 3 outputs that are each under the control of a different recipient.  You'd need to get the addresses (or at least the RIPEMD160 hash value) from each recipient so that you could structure the output scripts appropriately.

The process if building a single shared transaction and then sending it around to the multiple senders so that they can each satisfy the requirements in their input makes such transactions rare since they require an amount of coordination between the various senders.

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.