Topic: Bitcoin protocol questions (Read 2970 times)

A gentleman and a scholar. Yeah, I guess that's why I'm still here too, although I still enjoy the mud fights sometimes.

The trick is to remember that I'm not actually writing a response to the OP.  I'm writing a response to all the truly curious people that actually want to understand how it all works and will stumble across this thread from a Google search.  My patience, and carefully written responses are for them.  The OP's poorly thought out questions and silly assumptions are simply a launching-off point for me to have fun writing detailed descriptions about a technology that I find fascinating and entertaining.

You have the patience of Job.

It doesn't.

There are no addresses at the protocol level.  (I thought you said you wanted to understand this at the "code level".)  If you want to understand this at the code level, then you need to understand that the code does not check whether ay address exists.  At the user interface level any well written wallet will check to make sure that the address you are sending to is formatted correctly.  After that the "address" is converted to specific script and the script is used in the transaction.


What?  No.  Just no.  Stop saying "Maybe" and then inventing your own useless idea about how it doesn't work. That is not helping you understand and is wasting my time.  Please re-read the multiple times that I have explained to you that there are no addresses at the protocol level.


No.  The bot doesn't connect to every peer on the entire network.  It only connects to a limited number of nodes.  It can create some annoyance for those specific nodes by ip hopping, but since those nodes will refuse to relay anything they receive from the bot, it won't effect the rest of the network.  Eventually, the nodes being annoyed will simply hard code their connections and stop accepting new connections from any other ip.


Correct.  Bitcoin is based on the best understanding of cryptography at the time.  If any of the cryptographic functions are later found to have any weaknesses, then those functions will be replaced with newer and more secure functions.  Of course to effect mining, the SHA256 function will have to be VERY broken. Small weaknesses, or even very big weaknesses will not prevent SHA256 from filling the necessary need (which is why md5 would work fine for Bitcoin if we wanted to use it).


Correct.


He doesn't "convince" anybody of anything.  He sends the block to all the peers that are connected to him.  Each of those peers then verifies that that the block only pays a reward that is less than or equal to the 25 BTC subsidy plus the fees.  Each of those peers also verifies that every transaction in the block is valid.  Peers do not trust Bob at all.  They always verify everything themselves.


This is the "Development & Technical Discussion" section of the forum.  You are talking to IT guys (I'm not so sure that I'm talking to an IT guy though).  You didn't just make it simple, you made it wrong.  I am correcting you because you claim that you want to understand.


Yes, there is a function when creating a block that creates the block reward transaction in that block for anybody that calls that function.  You can change that function if you want, but if you do then your block will be invalid and nobody will accept it.


It depends on the wallet software you are running.  Some wallets allow you to adjust the fee, others have a hard-coded minimum fee and let you increase the fee if you want, and then some are hard-coded to specific fee rules and don't allow the user any control at all.


Correct.  This is the distributed consensus mechanism that Satoshi "discovered".  This is the method that Bitcoin uses to solve the Byzantine Generals problem.  If you have a better way to arrive at a distributed consensus, then you can build a better cryptocurrency.  At the moment, nobody has ever discovered a better way to arrive at a consensus in a distributed (non-centralized) manner.  Fortunately, the difficulty on solving blocks is maintained at a high enough level and the hash output is random enough that orphans a a minor annoyance and not a serious problem.


No.  Not all the transactions.  Most of the transactions that are in the first branch were also in the second branch, therefore they remain confirmed.  The remaining few transactions are not "invalid", they are simply "unconfirmed".  They can then be confirmed again in a future block in the second branch.  The only transactions from the first branch that would be "invalid" would be transactions where BOTH of the following occur:

• A transaction is included into a block in path 1
• A competing transaction that spends at least one of the same previously unspent outputs is included into a block in path 2

Most well written software keeps track of the outputs that it spends, and therefore it isn't possible for the average user to accidentally create this situation.  If an attacker had enough control over the network and mining, they might be able to accomplish this attack.  This is most commonly considered to be  a threat if a single entity acquires more than 50% of all the total network hash power, and it often called a "51% attack".  This is a well known risk in the protocol design.


Correct.


Any well written wallet will keep track of these outputs for you and let you know when they are spendable.  At the code level, the code can keep track of which block the output came from and then compute how many more blocks have been added to the chain.


Yes.


I don't think so.  You'd have to explain what you mean better.


No.  When I say VERY difficult, what I mean is difficult beyond any possibility with the current understanding of mathematics in the world.


Clearly.


An assumption established by significant amounts of study and years of testing in many real world situations.


I don't think you understand the difference between probability and randomness.  I don't have the time or inclination to teach you that difference.  You are welcome to either educate yourself or to maintain any flawed believe you like.


And if I deal out the entire deck of well shuffled cards?  I'll give you a hint, it's less than  1 / (8 X 10⁶⁷)
Such a random number is NOT "a very and very easy number from brutforce".


It is true that many people misunderstand the concept of random and that what they think is random actually is not.  You seem to be one of those people.


You wrote wrongly. Your understanding of random number generators seems to have stopped some time in the 1980's.  Computers have advanced beyond that.


Then you read some false information.


No. They weren't.


They were either wrong or exaggerating.


Plonk!

Agreed.  Trolling and he can't understand why this should be limited to "development & technical" here?  If he wants to learn, he'd at least do some reading.

You give people the benefit of the doubt and they abuse it.

Danny's patience was/is amazing.

What the point of trying to learn if your just going to argue with your teacher?
Troll confirmed. What a time waste.  

Sure, it's impossible to leave such the thing without a back door ))



 

My friend, I understand it. And that is why I asked how the protection mechanism works. Because if you reward yourself for finding a solution, then you can easily change the code and reward yourself without doing any work at all.

 

I still do not understand how it checks whether the address exists. Maybe initially it makes some pending transaction and only after that it's possible to build the blocks including this already pending transaction?

Also, we were talking about DDos attack and you said that a node will simply drop connection with another node if it finds too many incorrect messages.
Imagine that or bot can change it's IP address using the list of the proxies, etc. So after connection is dropped, the node will change it's IP and will try to connect to the network again and continue sending the wrong messages. Aventually the network would stop. Right?

This thesis is correct only if we assume that from the cryptographical point of view the used algorithm is unbreakable. So this is nothing but the assumption.


So, if my understanding is correct, Bob includes into the block all the transactions, then the fee related transactions for himself, then some special transaction called "block reward".
And then if he finds the hash, he convince the others that he earned 25 BTC as a reward, N BTC as the fees, and that the other transactions are valid.

I could if I knew I'm talking to IT guy, but the topic is read not necessarily by IT guys, so I'm trying to make it as simple as possible.

Yes, you did. If I wanted to understand it only on the high level then that explanation would be enough. But I want to understand it on the low level that is why I asked how this rewarding transition works. Because from your initial explanation it looked like there is just a function that rewards anybody who calls this function.

I see. So now it comes to paying for priority of your transitions. I did not see how it works, so I presume there is an option where you can select whether you want to pay for your transition or not and if you pay, there is a field where you can specify how much you want to pay. Right?


This is a strange solution then. Because there is a split and one part of the network updated their data according to the first branch, and the second part of the memebers updated their data according to the second branch. Eventually they might resolve the longest branch and re-update their data. But it means that all the transactions from the first branch are now considered as invalid and the work of the miner from the first branch is also considered as invalid.

Ok, here's the solution comes…
The only problem: how do you separate the money obtained as reward from the money you have in your wallet?

So this is a kinda id for Bitcoin currency. What means that it's also one of the options for DDos attack.

But still possible, especially if you have enough resources or if you control the most of the resources or if you make the others to separately search for some "solutions" helping you to find some other solution. I don't do cryptanalysis as a part of my work, so I can't specify the exact ways of breaking SHA256 but it's "strength" is only the assumption.



This is NOT true. It's not random and it can be calculated. If your dice has only 6 options, the probability of your dice will be 1/6; If you have 2 dices with 6 options in each then your probability is only 1/36; If you use 52 cards then the probability of 1 card is only 1/52 if you take 2 cards from the deck of 52 cards then you probability is 1/2652 which is a very and very easy number from brutforce. And very often what you think is random is not random at all and statistically will be repeated.

This is not true again. I wrote earlier.


Is "NSA" a forbidden word? Why it makes you so nervous? Come on, you act like you work for them and of course you don't



My friend, why are you so nervous? Is "pentagon" another forbidden word? I just notify the facts: pentagon does not use async methods of encryption because does not consider them as absolutely reliable. Should we also forbid "encryption" word? Why are you trying to limit people's thought?
And of course, I don't force you to respond me and this "blackmail" sounds strange


My friend, you specified that I have paranoia, so as a doctor you made the diagnosis over the internet which is absolutely amazing! And why can't I ask you about this? - isn't it the diagnosis you addressed to me? I care a lot about my health, so I could not help from asking you, a doctor, about my health. Especially taking into the account that it's very easy: I don't have to come to your clinic, you do the job remotely over the internet. It's amazing.

--------


I perfectly understood what I read. Some1 who knew about the "bug" was able to read all the "encrypted" traffic in the internet from March 2012 when the first version OpenSSL 1.0.1 was released. Some readers of that news even wrote that with such the "bug" you can kneel any country.

----


And surely you think so because I mentioned 2 forbidden words: "NSA", "Pentagon" and the idea that FRS and NSA are behind the bit coin )) I expect the bunch of your colleagues with the new diagnosis now ))) the propaganda machine can't take it so easily!

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.

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.  

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

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.


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.


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.

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.


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.


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.



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.


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.


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.


Certainly, but your pseudo-code included a function:

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


It does not.


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.


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


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 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.


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.


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.


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


They don't.


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.


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.


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.


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.


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


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.


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.


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


I am The Doctor. Why do you ask?

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.

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

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

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.

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?


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?
 

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?

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


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.


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-            <-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 …?

Quote

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?

Quote

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.

Quote

I will not waste time addressing your paranoia.

Are you a doctor?


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

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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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).


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.


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.


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.


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.


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.


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


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.


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 don't think they have a choice.  There isn't much they can do to stop it.


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.

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

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?
 

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.


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"?


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?

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?

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?



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)?


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?
 


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?



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

1<-2….5<-new block1-            <-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…

Quote

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?

Quote

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?

Yes.


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).


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.


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.

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


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.


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


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.


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.


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.


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.


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.


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


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.


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.


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

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.


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.


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).


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).
 

Correct.


Yes.


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.


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.


I don't understand the question.


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.


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.