Topic: BTC, BCH, and Coinbase Transactions (Read 1390 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.