Bitcoin protocol questions

[Scientist]

1. How bitcoin wallet knows how much money I have? : it count it on the basis of the bit coin chains or i just uses some variable to keep the info?

2. If I understand it correctly,  every time when I make a transaction, I also send my public key so that the others could verify that it's done by me?
If yes, lets imagine the following situation:

Bob creates bit coin wallet and gets some bit coins.
Alice steals Bob's public key(which is not a secret) and simulates the bit coin message which says that Bob transfers Alice 1 bit coin. She uses Bob's public key to validate it.
Actually here we have 2 situation: a) when Bob's public key was already used in some of the transactions. b) he never used it before.

3.
Verifycation whether a sender has the money:
 
Bob does not just confirms Alice's transaction. Instead he transfers her message to the whole network. The others check whether Alice has the money or not for this transaction. If positive, they send a message "Yes, Alice has the money". The transaction is complete when the necessary number of the members confirm this. And after that, everyones chain list will show that now Bob has 1 coin Alice transferred him.

a) What if we have 100K members or even 1 million, all of them have to verify each other's transaction?
b) what it means "the necessary number of the members"? How many?
d) When the others change the chain list on their PCs? : let's say Bob received a request to verify some transaction. Ok. Done. So should Bob immediately change the chain after that? What if Bob confirms and changes but John does not confirm?
e) What will happen if 50% of the fake members(the bots) would have their own chain list?
f) Imagine that there is a million or even 100 millions of the bots and they send each other some extremely small amount of the bit coin. They do it without any purpose. So it means we get a kinda Dos attack?

4
I understand that "enough number of the members" simply uses the following idea:
Anybody can confirm the transition only in the case if he resolves a "task". And for this job he gets 25bitcoins.
 
So David checks the list of his block chains and sees that transaction is correct. He wants to share the news over the network: the trans action is correct.
But before he does it, as a part of verification task, David must resolve some "task". Without it the others will not consider his confirmation.
Schematically we have a kinda box with unconfirmed transactions. And this box is locked with a key. So the task for David is to find this key to unlock the box and confirm the transactions.
Thus, having the following questions:

 
a) how the others know whether David resolved the task or not?
b) as far as I understand, confirmation is nothing but mining! If so, then in the case if we have let's say only 10 members in the network and none of them mines, we will get the huge list of unconfirmed transactions and this confirmation job will never be done unless one of them will be convinced to start mining?
c)  If so and only a miner can confirm the transactions, then in the case if Alice will confirm the fake transaction everyone will accept it?
d) Imagine we have only 2 miners in the network. The first miner found the key first.Does it mean the second one will not get coins for his job? If so we have a situation that only a miner with the most powerful PC will always earn and consequently the other miners will eventually stop mining.

e) How the miner gets his reward for finding a key? I mean what is the source of this money? :
Is it sth like his mining app simply checks the condition: if result==key then balance+=25 coins?
If so then anybody can hack such the app.

f) Who creates and locks the "box" of transactions and composes a key for the boxes?

g) Where does this box is located? As far as we are talking about a p2p network, there is no special place where we could keep the queue, etc. Or maybe each wallet, on each PC, automatically creates a queue and automatically increments its number after the box is full? Then how they synchronise the work and what if Alice hacked her app and it uses a weak key?


5) In the case if our bin coin chain has a split, the others consider the one which is longer and this "road" is considered as a real one.  We know that each chain has the id of the previous one and so on.
So what if Alice would generate a longer chain?  In this case her chain will be considered as the correct one, no?
 

6) Bitcoin can be decided into lots of the pieces. For example, let's say Alice has 1 bit coin and it's serial number is 123456
Now Alice sends 0.5 bit coin to Bob 
Before this transaction, Bob already had 0.5 bit coin (presuming that even a part of bit coin has a serial number, the serial number of Bob's 0.5 bit coin was 98765)
So now Alice has 0.5 bit coin with a serial number 123456
And Bob has :
   0.5 bit coin with serial number 98765 and 0.5 bit coin with a number 98765 ?
So each member has to keep the huge number of the small pieces instead of merging them?
       

[Buffer Overflow]

*A lot* of questions here. I'll answer a few.

1. How bitcoin wallet knows how much money I have? : it count it on the basis of the bit coin chains or i just uses some variable to keep the info?

It retrieves the data from the global blockchain.

2. If I understand it correctly,  every time when I make a transaction, I also send my public key so that the others could verify that it's done by me?
If yes, lets imagine the following situation:

Bob creates bit coin wallet and gets some bit coins.
Alice steals Bob's public key(which is not a secret) and simulates the bit coin message which says that Bob transfers Alice 1 bit coin. She uses Bob's public key to validate it.
Actually here we have 2 situation: a) when Bob's public key was already used in some of the transactions. b) he never used it before.

Alice cannot change Bob's transaction because she is unable to sign it without Bob's private key. Well actually she can change it, but the digital signature won't match, so the network will ignore it.
Only transactions with valid digital signatures will be accepted into the blockchain.

[cr1776]

If you haven't already read it, which seems likely, you might start here:
https://bitcoin.org/bitcoin.pdf


edit:

e.g.  Here are a few answers
3.f. They will spend a lot in fees if these bots try to spam the network.
4.d. See the paper - each is working simultaneously so that is not the case.
4.e. See the paper.

6. " serial number" - think about it as inputs and outputs. see https://bitcoin.org/en/developer-guide

[DannyHamilton]

You clearly have not read the bitcoin whitepaper.  You are making a lot of guesses about how bitcoin works from things you have heard unknowledgeable people say, and many of your guesses are just wrong.  This is leading you to a very invalid understanding of the system.  Please throw out everything that you think you know about bitcoin and read the bitcoin whitepaper at least once before you try to understand how bitcoin works:
https://bitcoin.org/bitcoin.pdf

1. How bitcoin wallet knows how much money I have?

There are many wallets.  Exactly how it is accomplished depends on what wallet you are using.  Generally though, your private keys and the associated address hash is stored by the wallet.  The wallet maintains a list of unspent outputs from the blockchain that are associated with those addresses and adds them up.

: it count it on the basis of the bit coin chains or i just uses some variable to keep the info?

Like I said, it depends on the wallet you are choosing to use.  Generally though, a wallet will add up the values of the unspent outputs and store this total in a variable so that it doesn't have to repeat the sum every time it wants to display the total.

2. If I understand it correctly,  every time when I make a transaction, I also send my public key so that the others could verify that it's done by me?

There are several different types of transactions, but in the most common transaction type, yes the public key is sent.  The key isn't sent so that others can verify that it's done by you.  That verification is done with the signature which is computed from the private key.  The public key is just sent to save some computing time so that the software doing the verifying doesn't need to compute the public key from the signature.

If yes, lets imagine the following situation:

Bob creates bit coin wallet and gets some bit coins.
Alice steals Bob's public key(which is not a secret) and simulates the bit coin message which says that Bob transfers Alice 1 bit coin. She uses Bob's public key to validate it.
Actually here we have 2 situation: a) when Bob's public key was already used in some of the transactions. b) he never used it before.

This is not possible. The public key is not used to validate the transaction, the signature is.  It is only possible to create a valid signature with the private key.  The private key is never included in any transactions, it is just used to calculate the signature.

3.
Verifycation whether a sender has the money:
 
Bob does not just confirms Alice's transaction. Instead he transfers her message to the whole network. The others check whether Alice has the money or not for this transaction. If positive, they send a message "Yes, Alice has the money". The transaction is complete when the necessary number of the members confirm this. And after that, everyones chain list will show that now Bob has 1 coin Alice transferred him.

No.  This is not how bitcoin works at all.  You should probably take some time to read the bitcoin whitepaper:
https://bitcoin.org/bitcoin.pdf

Alice creates a transaction that specifies exactly which unspent outputs she is spending.  Bob's software can check his own list of unspent outputs to verify that those outputs are actually unspent.  In the transaction Alice includes a digital signature for every unspent output that she includes as an input.  Each unspent output is encumbered with a requirement to supply a digital signature from a private key that is associated with a specific public key hash.  Bob's software can confirm these signatures and know that Alice has met the requirement and therefore has the right to reassign the value associated with those unspent outputs to him by creating a new unspent output which is encumbered with a requirement to supply a signature from a private key that is associated with Bob's public key hash (also known as a Bitcoin Address).  This allows Bob to verify the transaction without any assistance from anybody else.

Since it is possible that Alice might have sent another transaction that spends those exact same unspent outputs to somebody else, and Bob might not know about it, the system needs a distributed timestamp system that can determine which transaction happened "first".  This is the purpose of mining.  Miners perform a time consuming task, and when they complete that task successfully they get to broadcast a block of transactions that is linked to the previous block.  If Bob sees Alice's transaction in that block, then he knows that miner saw that transaction "first" (before any other transaction that might try to spend the same unspent outputs).  All miners that see that block will then ignore any other transaction that Alice tries to send spending the same unspent outputs.

a) What if we have 100K members or even 1 million, all of them have to verify each other's transaction?

No.  Only those that are running "full nodes" (which store and share the entire blockchain) have to verify every transaction.  There are lightweight wallets that don't store the entire blockchain, and services that can provide wallets with an interface.

b) what it means "the necessary number of the members"? How many?

I don't know what you are asking.  That's probably because you don't understand what you are asking about.

d)

You skipped "c"

When the others change the chain list on their PCs? : let's say Bob received a request to verify some transaction. Ok. Done. So should Bob immediately change the chain after that? What if Bob confirms and changes but John does not confirm?

No, if Bob is running a full node, then his software keeps a list of "unconfirmed" transactions.  These are transactions that Bob's software has seen, but which a miner has not yet included in a block.  His software also stores the blockchain (the list of every valid block that he has received so far).  Bob's software immediately adds valid new transactions to his list of "unconfirmed" transactions as he receives them, and then removes the transactions from the list of "unconfirmed" transactions when he sees the transaction in a block.

e) What will happen if 50% of the fake members(the bots) would have their own chain list?

Then they will have created their own alternative coin.  Since their chain won't have completed enough work on the time consuming task, the rest of the network won't recognize their chain as being valid.

f) Imagine that there is a million or even 100 millions of the bots and they send each other some extremely small amount of the bit coin. They do it without any purpose. So it means we get a kinda Dos attack?

Yes.  However, most nodes on the network will refuse to accept or relay a transaction with an extremely small amount of bitcoin unless the transaction also pays a transaction fee of at least 0.0001 BTC.  That means the DDOS attack will cost the attacker 1 BTC for every 10,000 transactions that they send.

4
I understand that "enough number of the members" simply uses the following idea:
Anybody can confirm the transition only in the case if he resolves a "task". And for this job he gets 25bitcoins.

Again I'm not sure what you are talking about when you say "enough of the members".
With mining though you are correct that the protocol requires the miner to prove that they have completed a time consuming task.  Once they can provide this proof, they can broadcast the associated block of transactions.  In exchange for this service, the miner gets to include a special transaction that pays him 25 BTC that didn't exist before the block as well as paying him all the transaction fees from all the transactions that are included in the block.

So David checks the list of his block chains and sees that transaction is correct. He wants to share the news over the network: the trans action is correct.
But before he does it, as a part of verification task, David must resolve some "task". Without it the others will not consider his confirmation.
Schematically we have a kinda box with unconfirmed transactions. And this box is locked with a key. So the task for David is to find this key to unlock the box and confirm the transactions.

That really isn't a very good way to look at it.  You really, Really, REALLY should read the bitcoin whitepaper:
https://bitcoin.org/bitcoin.pdf

David's software looks at the list of transactions that are not yet in any block that David's software knows about.  David's softwware chooses which of these unconfirmed transactions it would like to confirm.  It collects all the chosen unconfirmed transactions together into a block and computes a block header that is specific only to that exact list of transactions.  It includes a special transaction that will pay David 25 BTC plus the sum of the transaction fees from all the chosen transactions.  Then David's software attempts to complete some provable work on that header.  If David is able to complete the provable work before any other miner completes provable work on the block they are working on, then David gets to broadcast his completed block.  If someone else completes a block first and David hears about it, then he starts all over again.

Thus, having the following questions:

a) how the others know whether David resolved the task or not?

The task is to calculate a hash that has a low enough value.  The calculated hash is included in the header fo the block.  Everybody that receives the block that David broadcasts can verify that it is the correct hash for the block and that the value is low enough. If it is not a correct hash for the block or if it is not low enough value, then David's block is rejected by everyone on the network.

b) as far as I understand, confirmation is nothing but mining! If so, then in the case if we have let's say only 10 members in the network and none of them mines, we will get the huge list of unconfirmed transactions and this confirmation job will never be done unless one of them will be convinced to start mining?

Correct.  Confirmations will not occur unless there is at least one node that is "mining".

c)  If so and only a miner can confirm the transactions, then in the case if Alice will confirm the fake transaction everyone will accept it?

Which fake transaction?  If Alice sends 2 transactions that both spend the same previously unspent outputs, and neither of the transactions is confirmed yet, then the "real" transaction is whichever transaction is included in a block first, and the other transaction becomes invalid and disappears.

d) Imagine we have only 2 miners in the network. The first miner found the key first.Does it mean the second one will not get coins for his job?

Correct.  Once one miner broadcasts a valid block, all miners will generally start all over working on a new block.

If so we have a situation that only a miner with the most powerful PC will always earn and consequently the other miners will eventually stop mining.

Having the most powerful PC does not guarantee that you will solve the block first.  It simply increases your chances.  It is impossible to know how many hashes it will take to solve a block that a miner is working on, and every miner is working on a different block with a different set of hashes.  A very slow PC might successfully find a hash after computing the 5th hash on their block, while an extremely powerful PC might need to compute 100,000,000 hashes on their block before they successfully find one with a low enough value.

e) How the miner gets his reward for finding a key? I mean what is the source of this money? :
Is it sth like his mining app simply checks the condition: if result==key then balance+=25 coins?
If so then anybody can hack such the app.

No.  As I've stated, the protocol allows every block to include exactly 1 transaction that has outputs, but which doesn't have an equivalent or greater value in inputs.  The protocol requires that the outputs of this transaction be less than or equal to the sum of the current block subsidy and the transaction fees of all the transactions in the block.  If the outputs are larger than that, then every other node on the system will reject the block as invalid and will refuse to accept it into their copy of the blockchain.

f) Who creates and locks the "box" of transactions and composes a key for the boxes?

There is not box, and there is no key.  Every node on the system verifies that the block is valid before they accept it or relay it to anyone else.

g) Where does this box is located?

There is not "box"

As far as we are talking about a p2p network, there is no special place where we could keep the queue, etc.

Every peer on the network keeps their own list of unconfirmed transactions and their own copy of the blockchain.

Or maybe each wallet, on each PC, automatically creates a queue and automatically increments its number after the box is full?

There is no box.  There is nothing to "fill".

Then how they synchronise the work

Each node accepts the first block that they receive.  If they receive a block that does not belong to their chain, then they compare the total work for their chain to the total work of the chain with the new block and accept whichever chain has more total work.

and what if Alice hacked her app and it uses a weak key?

There is not key.  There is a proof of work that must be accomplished.  If Alice does not complete the appropriate proof of work, then the rest of the network will ignore her invalid block.

5) In the case if our bin coin chain has a split, the others consider the one which is longer and this "road" is considered as a real one.  We know that each chain has the id of the previous one and so on.
So what if Alice would generate a longer chain?  In this case her chain will be considered as the correct one, no?

As long as her chain completed the appropriate proof of work?  Then her chain would be accepted as the correct one.  In Bitcoin when talking about "longest chain" what is really meant is the chain with the largest amount of valid proof of work.

6) Bitcoin can be decided into lots of the pieces.

Correct.  The smallest integer unit of value within the protocol right now is equivalent to 0.00000001 BTC.  It is not currently possible to transfer amounts smaller than this within the bitcoin protocol.

For example, let's say Alice has 1 bit coin and it's serial number is 123456

There are no serial numbers in the bitcoin protocol.

Now Alice sends 0.5 bit coin to Bob  
Before this transaction, Bob already had 0.5 bit coin

Ok.

(presuming that even a part of bit coin has a serial number, the serial number of Bob's 0.5 bit coin was 98765)

There are no serial numbers in the bitcoin protocol.

So now Alice has 0.5 bit coin with a serial number 123456
And Bob has :
   0.5 bit coin with serial number 98765 and 0.5 bit coin with a number 98765 ?

No.  This is not how bitcoin works.  There are no serial numbers in bitcoin.

So each member has to keep the huge number of the small pieces instead of merging them?

Pieces can be merged.  Transactions have inputs (which supply value to the transaction from previously unspent outputs), and new unspent outputs.  A transaction can have multiple inputs and a single output.  This would combine multiple previously unspent outputs and would create a single new unspent output with the combined value of all the previously unspent outputs.

[Scientist]

DannyHamilton, thanks a lot for answering so many questions. Yes, I indeed have to read the official document. When I created my questions I used some article, that was explaining how bitcoins works but it seems that the article was incorrect.
And I will probably ask other questions when I finish reading, but before I'd like to ask some questions about your answers.

No.  Only those that are running "full nodes" (which store and share the entire blockchain) have to verify every transaction.  There are lightweight wallets that don't store the entire blockchain, and services that can provide wallets with an interface.

Let's imagine that every1 uses only "full" wallets. Does it mean that if the network includes 1million members, each of them has to verify the transactions of 999,999 members?

Then they will have created their own alternative coin.  Since their chain won't have completed enough work on the time consuming task, the rest of the network won't recognize their chain as being valid.

How do you know if their chain completed enough work on the task or not? : I guess there is a time field in the block right?
But what if they do in the following way:
each block has some property "previous_block_id", so schematically it looks sth like this:
1<--2<--3<--4
Imagine that block id number 4 is the latest one in the list. Then, they could simply manually create block with a property previous_block_id =4 and suggest this block to the others.
How can you recognise that this last block is invalid? If has a reference to the previous block which can be verified.

Yes.  However, most nodes on the network will refuse to accept or relay a transaction with an extremely small amount of bitcoin unless the transaction also pays a transaction fee of at least 0.0001 BTC.  That means the DDOS attack will cost the attacker 1 BTC for every 10,000 transactions that they send.

a) who gets the fee? Let's say Bob sends coins to Alice. David is verifying their transaction. Will David get the fee?
b) So the wallets have some kind of verification section: if (transaction_amount < 0.0001) refuse_transaction() ?
c) What happens to the refused transaction? Will Bob get some notification or he will wait in vain?
d) If some reach person is in charge of the DDOS attack, so he can pay 1 BTC for 10K transaction, or if he uses the minimum amount of the BTC where no fees are charged, then BTC network could be stopped?

Speaking about the fees:
I understand that each transaction has a priority field: a transaction with lots of the money will be implemented first and transaction with small amount of the money will wait for its turn a lot of time, is it correct?
And if every new block is created every 10 mins, does it mean that in order to implement transaction , a sender has to wait at least 10 mins?

With mining though you are correct that the protocol requires the miner to prove that they have completed a time consuming task.  Once they can provide this proof, they can broadcast the associated block of transactions.

In general terms it's clear but I'm trying to understand how it really works in the world full of hackers.
Bob "takes" a block he wants to "unlock".
a) Bob does not see the transactions in the block? e.g. the transactions are maybe encrypted?
b) Who is this person who gets the proof of Bob that the task was done?
In the case if it's only Bob's mining application that works in the following way:
while(true)
{
        ...
   if (check_key(suggested_key))
           return suggested_key;
}
And nobody else checks Bob's solution, then Bob can easily modify his software. So I guess somebody checks his answer, right?

 In exchange for this service, the miner gets to include a special transaction that pays him 25 BTC that didn't exist before the block as well as paying him all the transaction fees from all the transactions that are included in the block.

so Bob's mining software has some kinda flow:

Stamp_block(){
 include_transactions_into_block();
 include_25BTC_into_block_forMiner();
}
?

If this is the case, why Bob can't hack his software and request only include_25BTC_into_block_forMiner() ?

Correct.  Confirmations will not occur unless there is at least one node that is "mining".

So eventually we will come to the point when it will not be profitable to mine. And consequently the network will stop?
unless somebody fully artificially will mine in order to keep the network working

David's software looks at the list of transactions that are not yet in any block that David's software knows about.  David's softwware chooses which of these unconfirmed transactions it would like to confirm.  It collects all the chosen unconfirmed transactions together into a block and computes a block header that is specific only to that exact list of transactions.  It includes a special transaction that will pay David 25 BTC plus the sum of the transaction fees from all the chosen transactions.

a) There is a public queue with unconfirmed transactions. How David works with these transactions: he only marks them that now he works on them or he removes them from the public queue?
What if David marks/remove the transactions and then turns off his PC, what will happen next with the marked/removed transactions? They will be lost?
b) I understand that each block of transactions has a reference to the previous block.
So David and Alice are mining and both of them started "building" their blocks. They both know that the id of the last block is 5. What happens next? - they both create a new block with a reference to the block #5 ?

Correct.  Once one miner broadcasts a valid block, all miners will generally start all over working on a new block.

So, eventually we will come to the point where only some organisation with the most powerful computers is able to confirm the transactions and earn on transactions. Is it Federal Reserve System?

Every peer on the network keeps their own list of unconfirmed transactions and their own copy of the blockchain.

These lists which each node has, are they equal?

There is not key.  There is a proof of work that must be accomplished.  If Alice does not complete the appropriate proof of work, then the rest of the network will ignore her invalid block.

But you said that miner creates a block, populates it with the transactions he wants to confirm and "locks" it with some hash and then starts searching for the answer for this hash.
So is it possible that Alice(miner) will create a very easy hash or the hash depends on the included transitions and consequently can not be "adjusted" by Alice?

[Buffer Overflow]

No.  Only those that are running "full nodes" (which store and share the entire blockchain) have to verify every transaction.  There are lightweight wallets that don't store the entire blockchain, and services that can provide wallets with an interface.

Let's imagine that every1 uses only "full" wallets. Does it mean that if the network includes 1million members, each of them has to verify the transactions of 999,999 members?

All nodes on the network assume that any data received from another node is malicious. That's why every node independently checks all incoming transactions/blocks. It doesn't need to trust any data from anyone else as it can verify the data is valid itself.

[cr1776]

Yes, I indeed have to read the official document. When I created my questions I used some article, that was explaining how bitcoins works but it seems that the article was incorrect.

...

Definitely read the paper, if you read it and understand it, it will answer many (all?) of your questions about how the network works.  Clearly the article was full of misconceptions and bad information if it was talking about "boxes" and "serial numbers"

...
And if every new block is created every 10 mins, does it mean that in order to implement transaction , a sender has to wait at least 10 mins?

Blocks are created on average every ten minutes.  It may be 10 seconds apart or an hour.  That is only for a confirmation of a transaction.  It depends on what you mean "implement a transaction" but you can create a transaction at any time and broadcast it to the network.  

Correct.  Confirmations will not occur unless there is at least one node that is "mining".

So eventually we will come to the point when it will not be profitable to mine. And consequently the network will stop?
unless somebody fully artificially will mine in order to keep the network working
...

No, there will be transaction fees that compensate people for mining.

Correct.  Once one miner broadcasts a valid block, all miners will generally start all over working on a new block.

So, eventually we will come to the point where only some organisation with the most powerful computers is able to confirm the transactions and earn on transactions. Is it Federal Reserve System?

No, anyone can confirm transactions at any time.  The power of your computer is related, but a powerful computer won't overwhelm the rest,  if your computer has "power 1" and someone else has "power 10", statistically they will get about ten times the number of blocks you do, but you will still be getting blocks in proportion to your contribution to the network, but it will occur randomly.  Your "power 1" computer could get 100 in a row to their one, but that is unlikely.

PLEASE read the paper, once you have done so more people will be inclined to help you understand it if there are points you are unclear on.  

:-)

[DannyHamilton]

No.  Only those that are running "full nodes" (which store and share the entire blockchain) have to verify every transaction.  There are lightweight wallets that don't store the entire blockchain, and services that can provide wallets with an interface.

Let's imagine that every1 uses only "full" wallets. Does it mean that if the network includes 1million members, each of them has to verify the transactions of 999,999 members?

Yes.

Then they will have created their own alternative coin.  Since their chain won't have completed enough work on the time consuming task, the rest of the network won't recognize their chain as being valid.

How do you know if their chain completed enough work on the task or not?

Bitcoin uses the SHA256 hash function to provide a proof of the work completed.

Since it is impossible to predict what the result of a SHA256 hash will be for a given input, the only way to find out is to do the actual work and compute the hash.  The results are expected to be evenly distributed between 0 and 1.1579209 X 10⁷⁷.  The amount of work that must be "proven" can be adjusted by setting a target value.

Think of this as an analogy:

You are given 1000 coins.  You toss them all up in the air and when they land you look to see how many have landed with the heads side up.  I can assign a "work" that says you have to repeat the process until you get less than 999 heads.  Obviously this is pretty easy "work" and you will almost always succeed on your first attempt.  I can now adjust the "difficulty" of the work by adjusting the number of heads you need to get. If I assign "work" that requires that you repeat the process until you get less than 400 heads, you'll probably be tossing those coins for a while.  Now I can assign that same "work" difficulty (less than 400 heads) to a group of people.  Some people will be able to repeat the process very fast, and some will be slower.  The faster people will have a better chance of succeeding first since they will have more attempts, but the slower people can still get lucky and succeed with fewer attempts.

With Bitcoin, the "work" is to repeatedly modify the header of the block and calculate the SHA256 hash of that modified header until the hash value is less than a target that all full nodes and miners on the  entire network have agreed on.  The "difficulty" of the "work" can be adjusted by changing the target value.  If the target isn't difficult enough, then blocks arrive too fast, and the target is made lower to force the participants to try longer.  If the target is too difficult, then the blocks don't arrive fast enough, and the target is made higher to allow the participants to find a solution faster.  By providing a header that hash a SHA256 hash value that is lower than the target, the miner proves that they did the "work" (they repeatedly modified the header and calculated the resulting hash until they found a low enough value).

I guess there is a time field in the block right?

There is, but it is just used to make sure that the blocks are coming at the right pace.  Every 2016 blocks the difficulty is adjusted based on the amount of time it took for those 2016 blocks to be created.  The time field in the block is not reliable since miners can lie about the time when they create the block.  It is even possible for later blocks to have a time field that is earlier than the previous few blocks.  The protocol requires that the time field be within a certain range of the most recent blocks to keep it from drifting too far from reality.  If it is outside of the acceptable range then all peers will reject the block.

But what if they do in the following way:
each block has some property "previous_block_id", so schematically it looks sth like this:
1<--2<--3<--4
Imagine that block id number 4 is the latest one in the list. Then, they could simply manually create block with a property previous_block_id =4 and suggest this block to the others.
How can you recognise that this last block is invalid? If has a reference to the previous block which can be verified.

It has to meet various requirements to be accepted.  A few of those conditions are:

• If you calculate the SHA256 hash of the block then it has to be less than the target value.
• It is only allowed to include valid transactions.
• The timestamp must be within a set range of the most recent previous blocks.
• The block reward cannot exceed the sum of the current subsidy plus the transaction fees of all the transactions in the block.

Yes.  However, most nodes on the network will refuse to accept or relay a transaction with an extremely small amount of bitcoin unless the transaction also pays a transaction fee of at least 0.0001 BTC.  That means the DDOS attack will cost the attacker 1 BTC for every 10,000 transactions that they send.

a) who gets the fee? Let's say Bob sends coins to Alice.

The miner that includes the transaction in a block and successfully completes the proof-of-work.

David is verifying their transaction. Will David get the fee?

It is important to understand that in bitcoin the words "verify" and "confirm" do NOT mean the same thing.  Every full node peer on the network "verifies" every transaction.  The only one that "confirms" the transaction is the miner (or mining pool) that first includes the transaction in a block where they have successfully completed the proof-of-work.

b) So the wallets have some kind of verification section: if (transaction_amount < 0.0001) refuse_transaction() ?

Yes.  All peers have a verification process.  If transactions don't meet necessary requirements then the transaction may not be accepted, relayed, or confirmed.

c) What happens to the refused transaction? Will Bob get some notification or he will wait in vain?

That depends on the reason for refusal.  Most well written wallet software will protect a user from sending transactions that don't meet the well known conditions on the network.  The wallet software would in that case refuse to even try to send the transaction and would report to Bob that he is attempting to send a problematic transaction.  If Bob writes his own wallet software and doesn't check for the conditions, then his software would wait in vain.

d) If some reach person is in charge of the DDOS attack, so he can pay 1 BTC for 10K transaction, or if he uses the minimum amount of the BTC where no fees are charged, then BTC network could be stopped?

Even when sending transactions that are above the minimum amount, there are other fee conditions to make DDOS attacks expensive.  If the attacker is willing to pay those fees, then yes they could theoretically create a situation where everyone else's transactions would take longer to confirm and they could potentially create a situation where peers are flooded with more transactions than they can handle in a short period of time.  Of course doing so would cost them a LOT of bitcoins in fees which would be paid to the miners that are solving the blocks, so their attack would result in increased profits for the miners.

Speaking about the fees:
I understand that each transaction has a priority field: a transaction with lots of the money will be implemented first and transaction with small amount of the money will wait for its turn a lot of time, is it correct?

It is not a "field"  it is a calculation that miners are encouraged to make when they are deciding which transactions to include in the blocks that they are mining.  Miners are allowed to use any criteria that they like, but there are some "best practices" recommendations that most miners adhere to.  You are correct though.  To prevent a DDOS from someone that is sending amounts that are larger than the "required fee" minimum, miners are encouraged to give priority to transactions that are moving larger amounts of bitcoins and to give priority to transactions that spend bitcoins that were received longer ago.

And if every new block is created every 10 mins, does it mean that in order to implement transaction , a sender has to wait at least 10 mins?

No.  A transaction can be sent immediately.  It is then relayed as an "unconfirmed transaction" throughout the network immediately. The recipient is generally likely to receive the "unconfirmed transaction" within a few seconds.  If the recipient wants to be confident that there isn't a competing transaction spending the same outputs elsewhere on the network that they haven't seen, then they should wait for a confirmation before providing whatever product or service they were exchanging for the bitcoins.  However, due to the difficulty in propagating a "double-spend" unconfirmed transaction, there are many scenarios where the risk involved in treating the unconfirmed transaction as complete is acceptable.  In most cases it is best to wait the average 10 minutes for the transaction to be confirmed before re-sending those same bitcoins elsewhere.

With mining though you are correct that the protocol requires the miner to prove that they have completed a time consuming task.  Once they can provide this proof, they can broadcast the associated block of transactions.

In general terms it's clear but I'm trying to understand how it really works in the world full of hackers.
Bob "takes" a block he wants to "unlock".

There is no "unlocking".  Bob creates a block by choosing which unconfirmed transactions he wants to "confirm".  Then he generates a block header specific to that list of transactions.  Then he starts repeatedly modifying that block header and calculating the resulting SHA256 hash of the block header until he finds a header that has a SHA256 hash with a value that is lower than the current target.

a) Bob does not see the transactions in the block? e.g. the transactions are maybe encrypted?

Bitcoin transactions are not encrypted.  Bob does see the transactions in the block, since Bob chose which transactions to include.

b) Who is this person who gets the proof of Bob that the task was done?

All full node peers on the network.  Every peer verifies for itself that Bob's block is valid and is the first valid block that they received for its position in the chain.  Full node peers NEVER trust any other peer.  They verify EVERY transaction and EVERY block that they receive before accepting it or relaying it to any other peers.

In the case if it's only Bob's mining application that works in the following way:
while(true)
{
        ...
   if (check_key(suggested_key))
           return suggested_key;
}
And nobody else checks Bob's solution, then Bob can easily modify his software. So I guess somebody checks his answer, right?

I'm not sure what you mean by "suggested_key", but as I've explained, EVERY full node peer checks EVERY block that they receive.

In exchange for this service, the miner gets to include a special transaction that pays him 25 BTC that didn't exist before the block as well as paying him all the transaction fees from all the transactions that are included in the block.

so Bob's mining software has some kinda flow:
Stamp_block(){
 include_transactions_into_block();
 include_25BTC_into_block_forMiner();
}
If this is the case, why Bob can't hack his software and request only include_25BTC_into_block_forMiner() ?

He can, but then he will miss out on all the transaction fees from all the transactions that paid fees.  Other miners will get those fees instead in the next block after Bob's.  This will result in lower revenue for Bob.  Since mining is competitive, it tends to increase in costs until the costs for the most efficient miners are only slightly less than their revenues.  As such, Bob will find that his reduced revenue results in his business operating at a loss.  He will either need to:

• Continue operating at a loss until he is bankrupt.
• Start including transactions so that he can collect the transaction fees to improve profitability
• Quit mining

Correct.  Confirmations will not occur unless there is at least one node that is "mining".

So eventually we will come to the point when it will not be profitable to mine. And consequently the network will stop?
unless somebody fully artificially will mine in order to keep the network working

If the least efficient miners stop mining (since they are no longer profitable) and no new miners enter the network, then blocks will occur more slowly.  The network will then adjust the target difficulty to be lower.  This will result in increased profitability for the remaining miners.  Eventually the network will reach an equilibrium where the remaining miners are earning enough to continue mining.

David's software looks at the list of transactions that are not yet in any block that David's software knows about.  David's software chooses which of these unconfirmed transactions it would like to confirm.  It collects all the chosen unconfirmed transactions together into a block and computes a block header that is specific only to that exact list of transactions.  It includes a special transaction that will pay David 25 BTC plus the sum of the transaction fees from all the chosen transactions.

a) There is a public queue with unconfirmed transactions.

All transactions are broadcast to all connected peers on the network.  Those peers then relay the transaction to the peers they are connected to, and so on until nearly all peers on the network know about the transaction.  Each peer keeps track of its own list of unconfirmed transactions.

How David works with these transactions: he only marks them that now he works on them or he removes them from the public queue?

No.  All miners are allowed to simultaneously work on whatever unconfirmed transactions they want to.  Typically many different miners are all working with the same group of unconfirmed transactions.  Each miner can re-order those transactions however they like in their list as long as all of the inputs of each transaction occur earlier in the blockchain (or earlier in that block).

What if David marks/remove the transactions and then turns off his PC, what will happen next with the marked/removed transactions? They will be lost?

Peers do not generally remove a transaction from their list of unconfirmed transactions until they see the transaction in a block.  The pool of unconfirmed transactions is limited in size though. Therefore, if a transaction is not confirmed yet after an extended time (typically a few days), then a peer will eventually drop the older unconfirmed transaction from its own list.  The original sender of the transaction can either re-broadcast the transaction (which is what Bitcoin Core does), or they can drop the transaction from their own list which will result in those bitcoins once again being spendable in their wallet (which is what blockchain.info/wallet currently does).
 

b) I understand that each block of transactions has a reference to the previous block.

Correct.

So David and Alice are mining and both of them started "building" their blocks. They both know that the id of the last block is 5. What happens next? - they both create a new block with a reference to the block #5 ?

Yes.

Correct.  Once one miner broadcasts a valid block, all miners will generally start all over working on a new block.

So, eventually we will come to the point where only some organization with the most powerful computers is able to confirm the transactions and earn on transactions.

Far more likely is that multiple competing organizations with powerful computers are confirming transactions.  Only time will tell exactly how it will play out though.

Is it Federal Reserve System?

Not at all.  There are a variety of very important differences. For example a Federal Reserve System is allowed to print as much money as they like whenever they like, while the bitcoin miners cannot create invalid blocks.  Any competitor is allowed to start mining anytime they like.  You can't just start up your own Federal Reserve System to compete with the existing one if you want.

Every peer on the network keeps their own list of unconfirmed transactions and their own copy of the blockchain.

These lists which each node has, are they equal?

I don't understand the question.

There is not a key.  There is a proof of work that must be accomplished.  If Alice does not complete the appropriate proof of work, then the rest of the network will ignore her invalid block.

But you said that miner creates a block, populates it with the transactions he wants to confirm and "locks" it with some hash and then starts searching for the answer for this hash.

No.  He doesn't "lock" it with a hash, he repeatedly modifies the header and computes a new hash until he finds one that is lower than the target. Then he broadcasts the resulting block to all his connected peers.

So is it possible that Alice(miner) will create a very easy hash or the hash depends on the included transitions and consequently can not be "adjusted" by Alice?

Alice also must repeatedly modify the header of her block and calculate the hash until she finds a hash that has a value lower than the current target.  Her block will be different than his, but there is no way to know who is going to stumble across a header with a low enough hash first.
 

[Scientist]

So the miner places some transactions he wants to confirm into the block. The miner does not know all the addresses.
Imagine that the list of transactions has some invalid address.
What will happen next? The miner who works on finding some solution either confirms or unconfirms all the transactions in the block.
Does it mean he would work in vain?
 

There is, but it is just used to make sure that the blocks are coming at the right pace.

But earlier you said:
"Since their chain won't have completed enough work on the time consuming task, the rest of the network won't recognize their chain as being valid."
So I understand it as in order to confirm your solution, I should see that you spent 10 mins on it. In the other words: even if you solution is correct, I can not accept it because you did not spent time on it. This is how I understood it.

That depends on the reason for refusal.  Most well written wallet software will protect a user from sending transactions that don't meet the well known conditions on the network.  The wallet software would in that case refuse to even try to send the transaction and would report to Bob that he is attempting to send a problematic transaction.  If Bob writes his own wallet software and doesn't check for the conditions, then his software would wait in vain.

So in the other words, the theory that I can divide 1 coin into the smallest pieces like 0.00000001 and operate with them is nothing but a theory?
And also, in the case of enormous increase of the popularity, the cost will also go up what means that what costs now 0.00000001 will cost more and consequently there will be a need to break the rules…How breaking the rules match "decentralisation"?

Even when sending transactions that are above the minimum amount, there are other fee conditions to make DDOS attacks expensive.

Ok, but what if the hacker will try to send lots of the wrong/incorrect messages/transactions using their own software?
What I mean: they know the structure of the transaction, so they can create such the structure, populate it with some information that does not reflect on their money and broadcast such the transactions. Surely, sooner or later such the transactions will be refused, but if there is a huge stream of such the transactions, they will surely spam the transactions queue of the nodes and the system will stop, is it correct?

miners are encouraged to make when they are deciding which transactions to include

So theoretically we might have the huge-huge list of transactions which none of the miners wants to take? What happens next? These unprocessed transactions will act like a kinda spam?

No.  A transaction can be sent immediately.  It is then relayed as an "unconfirmed transaction" throughout the network immediately. The recipient is generally likely to receive the "unconfirmed transaction" within a few seconds.  

So Alice sends 1 coin to Bob. Initially Bob has 5 coins in his wallet. What Bob's wallet will show in a second after Alice clicked a send button?
Will it show: 5 coins and 1 unconfirmed coin?

so Bob's mining software has some kinda flow:
Stamp_block(){
 include_transactions_into_block();
 include_25BTC_into_block_forMiner();
}
If this is the case, why Bob can't hack his software and request only include_25BTC_into_block_forMiner() ?

He can, but then he will miss out on all the transaction fees from all the transactions that paid fees.  Other miners will get those fees instead in the next block after Bob's.  This will result in lower revenue for Bob.  Since mining is competitive, it tends to increase in costs until the costs for the most efficient miners are only slightly less than their revenues.  As such, Bob will find that his reduced revenue results in his business operating at a loss.  He will either need to:
   •   Continue operating at a loss until he is bankrupt.
   •   Start including transactions so that he can collect the transaction fees to improve profitability
   •   Quit mining

Here we have a strange situation.
1) Imagine that for simplicity sake we have only 2 transactions for the block. According to the fee table, a miner has to charge N coins for each of them.
So he starts building the block:

Block block = new Block();
block.transations.Add(trans1);
block.transations.Add(trans2);

What happens next? - he creates 2 additional transactions for the fee?, e.g:
block.transations.Add(trans_fee1);
block.transations.Add(trans_fee2);


And only after that starts doing the calculation work?

2) If Miner's software has such the function/method like include_25BTC_into_block_forMiner() that automatically grants 25 coins to the miner,
then miner does not really care about the fees, he can simply modify his software like this:

while(true)
{
include_25BTC_into_block_forMiner() ;
}

I guess it won't work because there is some kinda protection mechanism. How this mechanism prevents such the miner from modification of his software (not granting a miner 25 coins without doing a real work)?

No.  All miners are allowed to simultaneously work on whatever unconfirmed transactions they want to.

I don't understand it.
Let's say we have 5 unconfirmed transitions
trans 1
trans 2
trans 3
trans 4
trans 5

And only 2 miners.
The block size is only 2 transactions.

The first miner picks up trans1 and trans 5
The second miner then picks trans 1 and trans 2

So both of them work on trans 1 too.

The first miner does the job first and releases the new block that includes trans 1 and trans 5

What happens to the second miner? He understands that he worked for nothing and he has to "re-populate" his block again and start all over again?
 

Peers do not generally remove a transaction from their list of unconfirmed transactions until they see the transaction in a block.  

I've just installed the wallet for the very first time and the size of the current transactions is around 25Gb!
So in order to implement the constant check whether some unconfirmed transaction is still unconfirmed or not, I have to loop all the 25Gb?
Or maybe it keeps in memory the confirmed transactions from only some latest period of time and checks only this small list?

So David and Alice are mining and both of them started "building" their blocks. They both know that the id of the last block is 5. What happens next? - they both create a new block with a reference to the block #5 ?

Yes.

But in this case we will have a split of the block chain..

1<-2….5<-new block1-<new block2
            <-some alt block1<- some alt block 2

The only solution I see: I can populate the field prev_block_id only when I resolve the work. But in this case this field does not effect on the block hash and I still have a situation that somebody else will release some other block with the same prev_block_id at the same time as me…

I don't understand the question.

Imagine we have 1million members in the network. They are all over the world. Does it mean that when Bob makes transaction somewhere in Africa, Alice who is in China immediately gets this transaction in her list of unconfirmed transactions ? Or maybe the whole network is decided into several clouds and each cloud processes the transactions corresponding to some region assigned to this cloud?

Since it is impossible to predict what the result of a SHA256 hash will be for a given input

This is only the assumption, not a fact. How do you know?
Do you think hundreds thousands guy from NSA would let it go uncontrolled?, having the budget which is around 50% of the total budget of more than 20 spying organizations in the states?  What means: saying : our budget is too high, we don't do anything, you can reduce it.

Also: kennedy wanted to control Federal Reserve System (FRS) and they killed him. Do you want to say that the guys would allow somebody to take their "right" to print the money from the air  and they would give it to somebody else? To some "uncontrolled" and "decentralised" network?
Do you truly believe this?
Don't you think that they intend to control it from behind of the scene, placing in front the puppies called "enthusiasts" (where only some of them play the role of "enthusiasts")?
Don't you think that this is an attempt to replace dying dollar with a new ether that could allow to get real gold for nothing?

[Buffer Overflow]

Can we do one question/topic at a time? This is too much.

[DannyHamilton]

So the miner places some transactions he wants to confirm into the block. The miner does not know all the addresses.
Imagine that the list of transactions has some invalid address.
What will happen next? The miner who works on finding some solution either confirms or unconfirms all the transactions in the block.
Does it mean he would work in vain?

Yes.

The miner should verify all transactions before including them in the block. The miner should only include valid transactions in the block.  If he includes invalid transactions, then any work he does on that block is in vain.

There is, but it is just used to make sure that the blocks are coming at the right pace.

But earlier you said:
"Since their chain won't have completed enough work on the time consuming task, the rest of the network won't recognize their chain as being valid."
So I understand it as in order to confirm your solution, I should see that you spent 10 mins on it. In the other words: even if you solution is correct, I can not accept it because you did not spent time on it. This is how I understood it.

You understood it incorrectly.  The amount of work is determined by the target difficulty.  Finding a hash that is lower than the target takes time.  It is a time consuming task. It doesn't matter how much time it takes. It only matters that the miner performed enough "work" to find such a hash.

That depends on the reason for refusal.  Most well written wallet software will protect a user from sending transactions that don't meet the well known conditions on the network.  The wallet software would in that case refuse to even try to send the transaction and would report to Bob that he is attempting to send a problematic transaction.  If Bob writes his own wallet software and doesn't check for the conditions, then his software would wait in vain.

So in the other words, the theory that I can divide 1 coin into the smallest pieces like 0.00000001 and operate with them is nothing but a theory?

No.  It is perfectly possible to send 1.00000001 bitcoins.  It is not just a theory.

It is even possible to create a transaction that only transmits 0.00000001 bitcoins, but it will be much more difficult to get it confirmed. You would need to find miners that are willing to confirm such a transaction for you, and you would need to send the transaction directly to them (since most peers will refuse to relay it).  There aren't currently many useful reasons to send such a small amount.  In the future, if the value of bitcoin increases, then 0.00000001 bitcoins could become a more useful amount.  In that case, the relay rules that most peers use would be adjusted.

And also, in the case of enormous increase of the popularity, the cost will also go up what means that what costs now 0.00000001 will cost more and consequently there will be a need to break the rules…

The relaying rules are voluntary.  Each person that runs a full node peer can choose which software they run.  There is nothing in the protocol that forces them to adhere to any particular relay rules.  Because of the DDOS risk, most peers have voluntarily chosen to run software that has a particular set of relay rules.  If the value of 0.00000001 bitcoins increases in the future, then people will likely choose less strict relay rules.

How breaking the rules match "decentralisation"?

There is no centralized entity that forces the users to use any particular set of relay rules.  Each person can modify their own software if they want less strict (or more strict) relay rules.

Even when sending transactions that are above the minimum amount, there are other fee conditions to make DDOS attacks expensive.

Ok, but what if the hacker will try to send lots of the wrong/incorrect messages/transactions using their own software?

Peers will not relay invalid messages.  In most full node software, if a peer receives too many invalid messages from another peer, then the connection to the attacking peer will be dropped.

What I mean: they know the structure of the transaction, so they can create such the structure, populate it with some information that does not reflect on their money and broadcast such the transactions. Surely, sooner or later such the transactions will be refused, but if there is a huge stream of such the transactions, they will surely spam the transactions queue of the nodes and the system will stop, is it correct?

No.  Peers that are connected to the attacker will refuse to accept invalid transactions into their own queue.  They will also refuse to relay the invalid transactions.  If too many invalid transactions are received from the attacker, then the peers that he is connected to wil just drop their connection to him.

miners are encouraged to make when they are deciding which transactions to include

So theoretically we might have the huge-huge list of transactions which none of the miners wants to take?

Theoretically?  Sure.  But most miners use a pretty well known set of rules, and most peers won't relay transactions that don't meet those rules.

What happens next? These unprocessed transactions will act like a kinda spam?

The transactions either eventually become confirmed, or they are dropped from the list of unconfirmed transactions by peers to make room for newer transactions.  If a transaction is dropped from the list of unconfirmed transactions, then the sender will need to re-broadcast the transaction if he still wants it confirmed.  If enough miners all change their rules for confirming to be more strict than the current relaying rules, then most people running full nodes would very likely change their relaying rules.

No.  A transaction can be sent immediately.  It is then relayed as an "unconfirmed transaction" throughout the network immediately. The recipient is generally likely to receive the "unconfirmed transaction" within a few seconds.  

So Alice sends 1 coin to Bob. Initially Bob has 5 coins in his wallet. What Bob's wallet will show in a second after Alice clicked a send button?
Will it show: 5 coins and 1 unconfirmed coin?

It depends on the wallet software that he is running. Generally with most of the well written software that exists? Yes, it will show 5 confirmed and 1 unconfirmed.

so Bob's mining software has some kinda flow:
Stamp_block(){
 include_transactions_into_block();
 include_25BTC_into_block_forMiner();
}
If this is the case, why Bob can't hack his software and request only include_25BTC_into_block_forMiner() ?

He can, but then he will miss out on all the transaction fees from all the transactions that paid fees.  Other miners will get those fees instead in the next block after Bob's.  This will result in lower revenue for Bob.  Since mining is competitive, it tends to increase in costs until the costs for the most efficient miners are only slightly less than their revenues.  As such, Bob will find that his reduced revenue results in his business operating at a loss.  He will either need to:
   •   Continue operating at a loss until he is bankrupt.
   •   Start including transactions so that he can collect the transaction fees to improve profitability
   •   Quit mining

Here we have a strange situation.
1) Imagine that for simplicity sake we have only 2 transactions for the block. According to the fee table, a miner has to charge N coins for each of them.

Miners don't "charge" fees.  The fees are voluntarily paid by the users to encourage miners to confirm their transactions.  Miners choose which transactions they want to confirm and then keep whatever fee the transaction paid.

So he starts building the block:

Block block = new Block();
block.transations.Add(trans1);
block.transations.Add(trans2);

What happens next? - he creates 2 additional transactions for the fee?, e.g:
block.transations.Add(trans_fee1);
block.transations.Add(trans_fee2);


And only after that starts doing the calculation work?

The miner does not pay the fee.

The miner creates a special transaction that assigns the total block reward however he wants.  The block reward is the sum of the block subsidy plus all the fees that were paid by all the transactions that were included in the block.

2) If Miner's software has such the function/method like include_25BTC_into_block_forMiner() that automatically grants 25 coins to the miner,
then miner does not really care about the fees, he can simply modify his software like this:
while(true)
{
include_25BTC_into_block_forMiner() ;
}

First thing to understand is that the block subsidy isn't ALWAYS 25 BTC.  It is 25 BTC today, but for the first four years it was 50 BTC. Approximately every four years the block subsidy is cut in half and rounded down to the nearest 0.00000001 bitcoins.  In a few more years the block subsidy will shrink to 12.5 BTC.

That being said, the miner can create a block that ONLY pays the block subsidy and does not include any transactions. He will generate less revenue than all the other miners who are also earning transaction fees for their blocks. Since mining is a competitive business, the cost of mining will increase until the most efficient miners are earning just a bit more revenue than their costs.  This will increase the cost of mining for the miner that doesn't include any transactions to the point where it exceeds his revenue.  We already answered this question in the previous post.

I guess it won't work because there is some kinda protection mechanism.

The protection is the cost of mining.  As the cost increases, it becomes costly for the miner to confirm a block.  If the block doesn't include enough transaction fees, then the miner won't earn enough revenue.

How this mechanism prevents such the miner from modification of his software (not granting a miner 25 coins without doing a real work)?

The work that must be done on a block that only pays the block subsidy is exactly the same as the work that must be done on a block that includes hundreds of transactions.  The miner still needs to do the required work to find the necessary hash.  They just don't get paid as much for that work (since they missed out on all the fees they could have earned).

No.  All miners are allowed to simultaneously work on whatever unconfirmed transactions they want to.

I don't understand it.
Let's say we have 5 unconfirmed transitions
trans 1
trans 2
trans 3
trans 4
trans 5

And only 2 miners.
The block size is only 2 transactions.

The first miner picks up trans1 and trans 5
The second miner then picks trans 1 and trans 2

So both of them work on trans 1 too.

The first miner does the job first and releases the new block that includes trans 1 and trans 5

What happens to the second miner? He understands that he worked for nothing and he has to "re-populate" his block again and start all over again?

Correct.  But he would have "worked for nothing" and would have to "re-populate his block again and start all over again" even if he was working on trans 2 and trans 3.  Since his block contains a reference to the previous block, and now the first miner has created a new block that needs to be the previous block.

Peers do not generally remove a transaction from their list of unconfirmed transactions until they see the transaction in a block.  

I've just installed the wallet for the very first time and the size of the current transactions is around 25Gb!

No.  That 25GB is the blockchain.  That contains all of the blocks that have ever existed since bitcoin was created.  The current unconfirmed transaction list is much smaller.

So in order to implement the constant check whether some unconfirmed transaction is still unconfirmed or not, I have to loop all the 25Gb?

No, your node only has to compare its unconfirmed transaction list to the blocks it receives as it receives them.  If the transaction was in an older block, then it would already have been removed from the unconfirmed list when that block arrived.  There is no need to go back and look at old blocks again.

Or maybe it keeps in memory the confirmed transactions from only some latest period of time and checks only this small list?

Confirmed transactions are not kept in memory.  The list of unspent outputs, and the list of unconfirmed transactions are both generally held in memory in well written wallets.

So David and Alice are mining and both of them started "building" their blocks. They both know that the id of the last block is 5. What happens next? - they both create a new block with a reference to the block #5 ?

Yes.

But in this case we will have a split of the block chain..

1<-2….5<-new block1-<new block2
            <-some alt block1<- some alt block 2

The only solution I see: I can populate the field prev_block_id only when I resolve the work. But in this case this field does not effect on the block hash and I still have a situation that somebody else will release some other block with the same prev_block_id at the same time as me…

The "split" can only occur for as long as both miners repeatedly solve and broadcast their blocks at nearly the exact same time.  Eventually one of the miners will solve their block faster than the other.  This block will then be propagated through the network and all nodes will see that this leg of the chain is now longest.  All nodes will switch over to the longest chain and the shorter chain will be abandoned.

I don't understand the question.

Imagine we have 1million members in the network. They are all over the world. Does it mean that when Bob makes transaction somewhere in Africa, Alice who is in China immediately gets this transaction in her list of unconfirmed transactions ?

Yes. As long as they are both well connected in the network.

Or maybe the whole network is decided into several clouds and each cloud processes the transactions corresponding to some region assigned to this cloud?

This can happen if there is a disruption that prevents communication between different parts of the network. Eventually the divided portions of the network will communicate with each other and the transactions will all be shared.

Since it is impossible to predict what the result of a SHA256 hash will be for a given input

This is only the assumption, not a fact. How do you know?

It is well accepted by those that study and understand the hash function that it is very fast and easy to compute the hash and effectively impossible to predict its result without calculating it.  If this is ever false, then the proof-of-work system that bitcoin uses will be broken, and a new proof-of-work mechanism will need to be chosen.

Do you think hundreds thousands guy from NSA would let it go uncontrolled?, having the budget which is around 50% of the total budget of more than 20 spying organizations in the states?  What means: saying : our budget is too high, we don't do anything, you can reduce it.

I don't think they have a choice.  There isn't much they can do to stop it.

Also: kennedy wanted to control Federal Reserve System (FRS) and they killed him.
Do you want to say that the guys would allow somebody to take their "right" to print the money from the air  and they would give it to somebody else? To some "uncontrolled" and "decentralised" network?
Do you truly believe this?
Don't you think that they intend to control it from behind of the scene, placing in front the puppies called "enthusiasts" (where only some of them play the role of "enthusiasts")?
Don't you think that this is an attempt to replace dying dollar with a new ether that could allow to get real gold for nothing?

Sorry, I can't seem to find my tin-foil hat.  This thread is in the "Technical Discussion" area of the forum.  I will not waste time addressing your paranoia.  If you have such questions, you can take them to the "Speculation" or "off-topic" sections.

[Scientist]

Yes.

The miner should verify all transactions before including them in the block. The miner should only include valid transactions in the block.  If he includes invalid transactions, then any work he does on that block is in vain.

How can you check if address in a transaction is correct? You can of course loop the chains you have on your PC but what if it's a new address? - you can not say whether address exists or not if it conforms the format. No?

You understood it incorrectly.  The amount of work is determined by the target difficulty.  Finding a hash that is lower than the target takes time.  It is a time consuming task. It doesn't matter how much time it takes. It only matters that the miner performed enough "work" to find such a hash.

I understood your correctly. What I mean is: imagine I have the answers to all of your blocks, I will immediately throw them on the floor once I see your block. I will not consume time for this. Will you still consider such the solution valid?
 

Miners don't "charge" fees.  The fees are voluntarily paid by the users to encourage miners to confirm their transactions.  Miners choose which transactions they want to confirm and then keep whatever fee the transaction paid.

How it happens?: Alice makes some transaction. Bob is a miner and processes her transition. When transaction is processed, Bob's software sends Alice a message "done". And now Alice's software should automatically reward Bob?
If this is the case, then Alice can modify her software and her software will never send reward to the person who processes.
Also, reward is also a transition. What means that David will process now the reward Alice is trying to send?
And if Alice has to pay Bob for processing  let's say 0.000001 coin then David who is processing this will charge much more from Alice? Or even such the small fee will not be processed at all and Bob will never get reward.
How bit coin protocol resolves such the situation?

First thing to understand is that the block subsidy isn't ALWAYS 25 BTC.  It is 25 BTC today, but for the first four years it was 50 BTC. Approximately every four years the block subsidy is cut in half and rounded down to the nearest 0.00000001 bitcoins.  In a few more years the block subsidy will shrink to 12.5 BTC.

I know. I mentioned 25 BTC only in order to make my message more clear.

That being said, the miner can create a block that ONLY pays the block subsidy and does not include any transactions. He will generate less revenue than all the other miners who are also earning transaction fees for their blocks. Since mining is a competitive business, the cost of mining will increase until the most efficient miners are earning just a bit more revenue than their costs.  This will increase the cost of mining for the miner that doesn't include any transactions to the point where it exceeds his revenue.  We already answered this question in the previous post.

I think we have a kinda misunderstanding. I'm trying to understand how it works in the details: in the code.

Because if the code/software (of the miner) has such the function : Create25BTC()
Then you can easily hack this software and write sth like:
while(true) {
Create25BTC()
}
And you don't need any mining since then. You will be rewarding in the amount of 25BTC every microsecond.
But I guess this is not how it works. So there must be some protection mechanism. This is what I'm asking about.

Also talking about the fees: you pay the fee if your transaction is very small. If your transaction is not small you pay nothing.
It means that for a miner it's profitable to pick up the small transactions then.

Eventually one of the miners will solve their block faster than the other.  This block will then be propagated through the network and all nodes will see that this leg of the chain is now longest.  All nodes will switch over to the longest chain and the shorter chain will be abandoned.

I don't think so. There is no proof of this. Statistically it's very possible that 2 miners would release a new block at the same time and these 2 new blocks will reference to the same previous block. And then the whole network would split.
I read that in this case the porticol considers "the longest road". So in the example:

1<-2….5<-new block1-<new block2
            <-some alt block1<- some alt block 2 <-some alt block 3

It would consider the second road.

But if it does so, then what happens to the money from new block1 and new block2 …?

Yes. As long as they are both well connected in the network.

I read in the documentation that address has several very strange bytes: called network identifier
but I did not understand much because in the schema there were only 3 options:
Main network 0x00, Test network 0x6f, Namecoin network 0x34
What is this? And is it possible that they specify your geo location/ geo cloud?

It is well accepted by those that study and understand the hash function that it is very fast and easy to compute the hash and effectively impossible to predict its result without calculating it.  If this is ever false, then the proof-of-work system that bitcoin uses will be broken, and a new proof-of-work mechanism will need to be chosen.

I read the same about the bunch of the previously propagated methods like md5, etc. All of them became hacked.
And every time when somebody hacks a method, a new one immediately gets released.
Every crypto method is based on "random" number. You can get a random number in one of the following ways only:
call for a builtin random function, create your own random function that implements one of the well know algorithm, use some 3rd party component which is the same as option N2, or you should plug a special and expensive physical device.
All the options except the physical device will give you pseudorandom number, not a random. This number can be easily obtained by NSA.
The method also uses async encryption, however for Pentagon it's strictly prohibited to use any async crypto method because they consider that they can be hacked, although officially there is no proof.
Every1 heard a lot about reliable RSA method however, finally it was broken.

I will not waste time addressing your paranoia.

Are you a doctor?


http://media-cache-ak0.pinimg.com/736x/1e/88/ce/1e88ce31f4bb32a40f5496ce0491c1ba.jpg

[Scientist]

Forgot to mention: I guess it uses OpenSSL? If this is the case then there an interesting thing I read about it: it contained some specially made bug that allowed somebody to read ALL the encoded internet.

[cbeast]

There are a lot of bitcoin tutorial resources available. I recommend the Youtube videos called "Bitcoin 101"

[Buffer Overflow]

Forgot to mention: I guess it uses OpenSSL? If this is the case then there an interesting thing I read about it: it contained some specially made bug that allowed somebody to read ALL the encoded internet.

That was the heartbleed bug. It wasn't ALL encryption at all. It was serious though.

[Buffer Overflow]

I think we have a kinda misunderstanding. I'm trying to understand how it works in the details: in the code.

Because if the code/software (of the miner) has such the function : Create25BTC()
Then you can easily hack this software and write sth like:
while(true) {
Create25BTC()
}
And you don't need any mining since then. You will be rewarding in the amount of 25BTC every microsecond.
But I guess this is not how it works. So there must be some protection mechanism. This is what I'm asking about.

I could easily change the source code and courageously award myself 1000000BTC. Easy.

But...

I must persuade everyone else to change their source code to my new version. If they don't (which they won't), my unearned coins will just be ignored.

[DannyHamilton]

Yes.

The miner should verify all transactions before including them in the block. The miner should only include valid transactions in the block.  If he includes invalid transactions, then any work he does on that block is in vain.

How can you check if address in a transaction is correct? You can of course loop the chains you have on your PC but what if it's a new address? - you can not say whether address exists or not if it conforms the format. No?

Actually there are no addresses at the protocol level.  Addresses are a feature of wallet software that makes it easier for humans to work with transactions.  What an address at the user level actually represents at the protocol level is a very specific script.  The script encumbers the output with a specific requirement.  As long as the user meets the requirement of the script in their transaction, then they are allowed to re-assign the value to whatever new output scripts they like.  The software running in full nodes is able to verify that all inputs have satisfied the script requirements and that all outputs are valid scripts.

You understood it incorrectly.  The amount of work is determined by the target difficulty.  Finding a hash that is lower than the target takes time.  It is a time consuming task. It doesn't matter how much time it takes. It only matters that the miner performed enough "work" to find such a hash.

I understood your correctly. What I mean is: imagine I have the answers to all of your blocks, I will immediately throw them on the floor once I see your block. I will not consume time for this. Will you still consider such the solution valid?

If it is a valid solution?  Then yes.  However, it is not possible for you to have the answer to any block without first expending the effort required to find that solution. This is why the hash is called a proof of work.

Miners don't "charge" fees.  The fees are voluntarily paid by the users to encourage miners to confirm their transactions.  Miners choose which transactions they want to confirm and then keep whatever fee the transaction paid.

How it happens?: Alice makes some transaction. Bob is a miner and processes her transition. When transaction is processed, Bob's software sends Alice a message "done". And now Alice's software should automatically reward Bob?

No.  Alice includes the fee in her transaction when she creates the transaction. Bob includes the value of that fee in the block reward when he chooses her transaction and creates the block that he will work on.

More specifically:

• Alice's transaction lists all of the previously unspent outputs that she will be using to supply value.
• Alice's transaction satisfies the requirements of the scripts associated with each of those unspent outputs
• Alice's transaction lists all of the new outputs that she is creating and encumbers each output with a script that must be satisfied to re-assign the value of that output.
• If the sum of the value of all the inputs in Alice's transaction is less than the sum of the value of the outputs in the transaction, then the transaction is invalid and is rejected by all peers.
• If the sum of the value of all the inputs in Alice's transaction is equal to the sum of the value of the outputs in the transaction, then the transaction is not paying a transaction fee.  (It is free).
• If the sum of the value of all the inputs in Alice's transaction is greater than the sum of the value of the outputs in the transaction, then the difference between the two sums is the transaction fee that Bob is allowed to add to his block reward transaction.

If this is the case,

It is not.  You need to stop assuming that your guess about how it might work is correct.  You are only causing yourself confusion and adding to the number of unnecessary questions that need to be answered.  Have you even read the whitepaper yet?  If not you are wasting a huge amount of time on completely invalid assumptions.

then Alice can modify her software and her software will never send reward to the person who processes.

Alice can transmit free transactions if she wants to, but the miners don't have to include her free transactions in their blocks if they don't want to.

Also, reward is also a transition. What means that David will process now the reward Alice is trying to send?

What?  Alice pays a transaction fee.  She does not "send a reward".  The reward is the sum of the current block subsidy plus the transaction fees from all the transactions that are included in the block.  I've said this several times now.  You appear not to be able to retain the things I say.  Perhaps this is because you have not yet read the whitepaper AND you are asking more questions at once than you can keep track of?  I'd suggest first reading the whitepaper, and then limiting yourself to just a few questions per post so you don't keep re-asking the same questions over and over.

And if Alice has to pay Bob for processing  let's say 0.000001 coin then David who is processing this will charge much more from Alice?

Ok, now I've lost track?  Why is Alice paying both Bob and David for processing? She includes a transaction fee in her transaction. Then either Bob or David will include the transaction in the block that they solve.  Whichever of them successfully mines the block gets the fee.

Or even such the small fee will not be processed at all and Bob will never get reward.

Miners choose if they want to include the transaction in their blocks or not.  We've already discussed what happens if a transaction goes a long time without being included in a block.

How bit coin protocol resolves such the situation?

There is no "situation" .  This has all already been explained to you more than once.  If you are confused about anything specific to this explanation, please limit your questions to this one area so you can better focus on what is being said.

First thing to understand is that the block subsidy isn't ALWAYS 25 BTC.  It is 25 BTC today, but for the first four years it was 50 BTC. Approximately every four years the block subsidy is cut in half and rounded down to the nearest 0.00000001 bitcoins.  In a few more years the block subsidy will shrink to 12.5 BTC.

I know. I mentioned 25 BTC only in order to make my message more clear.

Certainly, but your pseudo-code included a function:

Code:

include_25BTC_into_block_forMiner() ;

I'm just pointing out that it would be more accurate for your pseudo-code to use the following function instead:

Code:

include_subsidy_into_block(calculate_current_subsidy());

That being said, the miner can create a block that ONLY pays the block subsidy and does not include any transactions. He will generate less revenue than all the other miners who are also earning transaction fees for their blocks. Since mining is a competitive business, the cost of mining will increase until the most efficient miners are earning just a bit more revenue than their costs.  This will increase the cost of mining for the miner that doesn't include any transactions to the point where it exceeds his revenue.  We already answered this question in the previous post.

I think we have a kinda misunderstanding. I'm trying to understand how it works in the details: in the code.

Because if the code/software (of the miner) has such the function : Create25BTC()

It does not.

Then you can easily hack this software and write sth like:
while(true) {
Create25BTC()
}
And you don't need any mining since then. You will be rewarding in the amount of 25BTC every microsecond.
But I guess this is not how it works.

It is not.

I've already explained to you multiple times that the block subsidy is paid to the miner in a special transaction in the block.  They only get the reward if their block is successfully mined sooner than someone else mines a block at the same height in the chain.  In order to successfully mine the block, they must perform the "work" and provide a valid "proof" of work. The difficulty for this process is set high enough that with all the miners in the entire world working on it as fast as they can, there is only 1 block solved every 10 minutes on average.

So there must be some protection mechanism. This is what I'm asking about.

There is.  It is the proof of work.  this has been explained to you several times now.

Also talking about the fees: you pay the fee if your transaction is very small. If your transaction is not small you pay nothing.

Incorrect.

You are provided a very strong incentive to pay a fee if your transaction is very low value.  You can still refuse to include the fee, but your transaction might not be seen by much of the network and might not be confirmed for a very long time (if ever).

If your transaction is a larger value, then the only incentive you have to include a fee is to encourage miners to choose your transaction instead of someone else's. You have the option of paying nothing, but then you are depending on the charity of generous miners to include your transaction in their block.  It is generally a good idea to include a small fee if you want your transaction to be included in the next block.

It means that for a miner it's profitable to pick up the small transactions then.

It is most profitable for miners to pick up the transactions tht pay the highest fee per byte since the number of bytes in a block are limited.

Eventually one of the miners will solve their block faster than the other.  This block will then be propagated through the network and all nodes will see that this leg of the chain is now longest.  All nodes will switch over to the longest chain and the shorter chain will be abandoned.

I don't think so. There is no proof of this. Statistically it's very possible that 2 miners would release a new block at the same time and these 2 new blocks will reference to the same previous block. And then the whole network would split.
I read that in this case the porticol considers "the longest road". So in the example:

1<-2….5<-new block1-<new block2
            <-some alt block1<- some alt block 2 <-some alt block 3

It would consider the second road.

Yes, this is exactly what I said.  Eventually one of the miners will be first.  In your example that "eventual" time was when alt block 3 was solved.

But if it does so, then what happens to the money from new block1 and new block2 …?

Which money?

If you are asking about the block rewards, they vanish.  The cease to exist.  This is often referred to as "orphan" blocks.  This is the reason that the protocol does not allow users to spend block rewards until there are at least 100 more blocks added to the chain.

If you are asking about the transactions that were "confirmed" in block1 and block2, then many of those same transactions were very likely also in "alt block 1" and "alt block 2".  Those transactions that were in blocks in both paths get to stay confirmed.  Those that were included in blocks in path 1, but not included in blocks in path 2 are returned to the list of unconfirmed transactions, and need to continue to wait for someone to confirm them.  This is why it is often recommended that people wait for 5 blocks to be added to the chain after their transaction is first confirmed before they consider the transaction to be very unlikely to become unconfirmed.

Yes. As long as they are both well connected in the network.

I read in the documentation that address has several very strange bytes: called network identifier
but I did not understand much because in the schema there were only 3 options:
Main network 0x00, Test network 0x6f, Namecoin network 0x34
What is this?

This is a mechanism to prevent collisions between two different cryptocurrency networks.

And is it possible that they specify your geo location/ geo cloud?

They don't.

It is well accepted by those that study and understand the hash function that it is very fast and easy to compute the hash and effectively impossible to predict its result without calculating it.  If this is ever false, then the proof-of-work system that bitcoin uses will be broken, and a new proof-of-work mechanism will need to be chosen.

I read the same about the bunch of the previously propagated methods like md5, etc. All of them became hacked.

md5 is not "hacked". It is only weak.  md5 in its current state of weakness would still work perfectly well for the needs of bitcoin.

And every time when somebody hacks a method, a new one immediately gets released.

Actually newer methods typically exist long before a weakness is discovered in a currently popular method.  People just typically don't bother switching to newer less tested methods until a substantial weakness is discovered in their current method.

Every crypto method is based on "random" number.

This is not true.  There are no random numbers in the SHA256 algorithm.  Cryptogrphically secure hashes are based on math that is easy to do in one direction and VERY difficult and time consuming to do in the opposite direction.

You can get a random number in one of the following ways only:
call for a builtin random function, create your own random function that implements one of the well know algorithm, use some 3rd party component which is the same as option N2, or you should plug a special and expensive physical device.

This is not true.  I can get a random number by rolling dice, or shuffling a deck of 52 playing cards, or any of dozens of other methods if I like.

All the options except the physical device will give you pseudorandom number, not a random.

This is not true.  Modern random number generators can use non-deterministic input from multiple sources to generate a random number.

This number can be easily obtained by NSA.

I told you already, this is the "Technical Discussion" section of the forum.  If you continue to try to discuss non-technical concerns, then I will consider you a troll and mark your userID for "ignore".  You will receive no further assistance from me in that case.

The method also uses async encryption,

There is no encryption in the bitcoin protocol.  There are async digital signature algorithms used to prove that you have the rights to spend value in unspent outputs.

however for Pentagon it's strictly prohibited to use any async crypto method because they consider that they can be hacked, although officially there is no proof.
Every1 heard a lot about reliable RSA method however, finally it was broken.

I repeat.  Keep your concerns technical, or I will not be responding to you.  This is your last warning.

I will not waste time addressing your paranoia.

Are you a doctor?

I am The Doctor. Why do you ask?

[DannyHamilton]

there an interesting thing I read about it: it contained some specially made bug that allowed somebody to read ALL the encoded internet.

You either didn't understand what you read, or you read something from someone that didn't understand what they were writing.

[cr1776]

...
I'm trying to understand how it works in the details: in the code.
...

It is a good thing the code is available.  If you REALLY want to understand the details in the code, go here and related resources such as the developer guide and paper which I linked to way up thread:

https://github.com/bitcoin/bitcoin
https://bitcoin.org/en/developer-guide
https://bitcoin.org/bitcoin.pdf

I am not sure why I am replying more to this, it seems clear you haven't read the paper, haven't looked at the code, haven't look at very much at all.  

[CIYAM]

Whilst I am *amazed* at the patience of Danny Hamilton I think you guys need to perhaps consider that the OP might just be trolling to waste your time (as he clearly isn't even interested in reading the whitepaper or properly considering your answers - he just keeps asking more silly questions based upon not even trying to understand how Bitcoin works).

As the forum member chose the name "Scientist" it seems pretty odd that he isn't interested in using any "scientific method" to understand Bitcoin.