Bitcoin Forum
December 05, 2016, 12:44:02 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Bitcoin protocol - need explanation of couple of things.  (Read 1499 times)
kstepyra
Jr. Member
*
Offline Offline

Activity: 52


View Profile
February 03, 2012, 03:31:30 PM
 #1

Hi there again beautiful Bitcoin Community Smiley

I am making IT project explaining how does Bitcoin work, with simple client (using BitcoinJ) on my university, and i got stuck on couple of things - probably i am too dumb to find answer Tongue i googled problems multiple ways, and also wiki doesn't explain me them well. I really appreciate any help for any of those questions.

1. Fetching blocks - how does it work?
I know there is possibility to fetch simple blocks by their hash, but to fetch any blocks i need to KNOW these hashes - thats why other option was implemented (getblocks).  Here comes problem - how does algorithm of block fetching works? As far as i've read - i got it this way(for example i am at block 10 000 and network is on 19 900):
i issue getblocks packet by sending block locator hash as hash of block 10 000 and i get in response inv packet with list of blocks 10 001 - 10 500? And i repeat that with hash 10 500 to get another 500 pack etc etc until i hit 19 900?
Also - when i get any invalid blocks in my chain (lets say it is block 10005 and network is also on 10005, but mine 2 newest blocks are invalid) i send getblocks packet with newest block hash as locator (mine 10005) and in response i get block 10005 hash that i dont know, so i send hash of block 10004 and in response again i get hash i don't know, then i send good block hash #10003 which then comes with an inv packet for 2 last blocks?
To be sure - MSG_BLOCK in Inventory Vector is exactly hash of block that i download then just by using getdata, right?


2. I dont get algorithms in transactions - how does bitcoin:
a) check that someone really have coins stating all transactions behind to prove they really exist
b) check that someone isn't spending same bitcoins 2nd time?

The problem for a) is mainly - how does TxIn in one block locate TxOut from other block having only hash of it? It can't go through all the blocks to finally find proper transaction because it will be too time consuming for HDD! And there comes other problem - even if we could just JUMP from one transaction to another(locating transaction by BLOCK number where it is located to prevent consuming hdd - probably it is done that way, i hope you people help me find answer Smiley ) - how will double spending check work?

As vector76 explained in one of his posts:
Quote
Example:
Tx1 input 1 comes from a previous tx with a value of 1
Tx1 input 2 comes from a previous tx with a value of 2
Tx1 output 1 has a value of 2.5 and requires key A to be claimed.
Tx1 output 2 has a value of 0.5 and requires key B to be claimed.

Person with key A creates a transaction and submits it to the miners:
Tx2 input 1 comes from Tx1/output 1.
Tx2 output 1 has a value of 2.0 and requires key C to be claimed
Tx2 output 2 has a value of 0.5 and requires key A to be claimed

Other nodes observe that Tx1/output 1 has not yet been spent and has a value of 2.5.  They verify that the outputs are not greater than 2.5.  They mark Tx1/output1 as used.

Person with key A creates another (double spend) transaction:
Tx3 input 1 comes from Tx1/output 1
Tx3 output 1 has a value of 1.0 and requires key D to be claimed
Tx3 output 2 has a value of 1.5 and requires key E to be claimed

Other nodes observe that Tx1/output 1 has already been spent, and they reject this transaction.

I've got in bold word "observe" because i don't know what it does really mean here? Let's say:
I spend cash from Tx1/output 1(which is for example in block 5 000) in block 10 000(Tx2), and then i try to spend again in block 15 000(Tx3) - what does miners really do? They check ALL blocks (and transactions in them) starting from block 5 000 from whom it is spent to find any inputs for that output? That would consume HDD a LOT for every transaction verification, and i can't imagine how it would work in future with a lot of transactions per second and milions of blocks.

Thanks in advance for any replies, probably i will have other problems again, i hope i get them resolved in here (not only for me! Smiley )
1480898642
Hero Member
*
Offline Offline

Posts: 1480898642

View Profile Personal Message (Offline)

Ignore
1480898642
Reply with quote  #2

1480898642
Report to moderator
1480898642
Hero Member
*
Offline Offline

Posts: 1480898642

View Profile Personal Message (Offline)

Ignore
1480898642
Reply with quote  #2

1480898642
Report to moderator
1480898642
Hero Member
*
Offline Offline

Posts: 1480898642

View Profile Personal Message (Offline)

Ignore
1480898642
Reply with quote  #2

1480898642
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480898642
Hero Member
*
Offline Offline

Posts: 1480898642

View Profile Personal Message (Offline)

Ignore
1480898642
Reply with quote  #2

1480898642
Report to moderator
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
February 03, 2012, 05:57:20 PM
 #2

Quote
Example:
Other nodes observe that Tx1/output 1 has already been spent, and they reject this transaction.
I've got in bold word "observe" because i don't know what it does really mean here? Let's say:
I spend cash from Tx1/output 1(which is for example in block 5 000) in block 10 000(Tx2), and then i try to spend again in block 15 000(Tx3) - what does miners really do? They check ALL blocks (and transactions in them) starting from block 5 000 from whom it is spent to find any inputs for that output? That would consume HDD a LOT for every transaction verification, and i can't imagine how it would work in future with a lot of transactions per second and milions of blocks.

They search their local database for transactions that include Tx1.out1 as an input.  If they find a match, that transaction has already been redeemed, and they reject the new one.

Currently the entire block chain, including each and every transaction ever since the beginning of time is under a gigabyte.  If it ever grows to the point where it becomes unwieldy, there are things we can do.  But scaling up to the "all commerce in the world" level isn't yet a solved problem.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
kstepyra
Jr. Member
*
Offline Offline

Activity: 52


View Profile
February 03, 2012, 07:24:15 PM
 #3

Hm, after thinking a bit and taking your explanation i came across this:
When transaction is spread to miner, he:
1. checks where prev_out hashes are located in block chain (starting from newest block in chain and going backward) - i.e. chain is on block 150000 and prev_out hash for our new TxIn is in 130000 so app starts at block 150000 and goes backwards till he hit 130000 block and proper hash in it. After that he checks TxOuts in that transaction adiacent for our new TxIn
2. checks whether there are any double spends by checking any TxIns (starting from TxOuts locations and going forwards till newest block in chain) that spent already coins in TxOuts - i.e. TxOut is in block 130000 and transaction is already spent in block 140000 so it goes from block 130000 until it finds proper TxIn in block 140000.

I am right in these assumptions? Or prev_out is a hash of block (+ additional necessary stuff) where transaction is located to find it really fast?
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
February 03, 2012, 07:44:48 PM
 #4

Hm, after thinking a bit and taking your explanation i came across this:
When transaction is spread to miner, he:
1. checks where prev_out hashes are located in block chain (starting from newest block in chain and going backward) - i.e. chain is on block 150000 and prev_out hash for our new TxIn is in 130000 so app starts at block 150000 and goes backwards till he hit 130000 block and proper hash in it. After that he checks TxOuts in that transaction adiacent for our new TxIn
2. checks whether there are any double spends by checking any TxIns (starting from TxOuts locations and going forwards till newest block in chain) that spent already coins in TxOuts - i.e. TxOut is in block 130000 and transaction is already spent in block 140000 so it goes from block 130000 until it finds proper TxIn in block 140000.

I am right in these assumptions? Or prev_out is a hash of block (+ additional necessary stuff) where transaction is located to find it really fast?

It isn't necessary to walk the chain.  There are indexes in the database so you can just search by ID.  And you never need to check the chain for double spends because you check the blocks as they come in and you don't store them if they are invalid (like if they include a transaction that spends an output that you already have seen used).

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
kstepyra
Jr. Member
*
Offline Offline

Activity: 52


View Profile
February 03, 2012, 08:13:53 PM
 #5

About double spends - i know that it is just checking new transactions, i am just curious how it works exactly.
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
February 03, 2012, 08:22:04 PM
 #6

Right, but you don't need to start at the current block and step backwards until you find it.  You can just ask "Does this transaction exist my database?" and the database will tell you.

The database is probably using a btree to index things so that it doesn't need to walk from block to block either, but what happens in the database is unimportant.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
kstepyra
Jr. Member
*
Offline Offline

Activity: 52


View Profile
February 04, 2012, 10:24:22 AM
 #7

That will explain point 2 very well. Thank you! Smiley How about 1? Is it right?
kstepyra
Jr. Member
*
Offline Offline

Activity: 52


View Profile
February 04, 2012, 06:08:58 PM
 #8

3. What is the data input for making signatures of transactions?


I am running soon out of time, i really count for any replies. If topic is in bad section of forum, i will really appreciate moving it to proper one Smiley
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
February 05, 2012, 04:47:15 PM
 #9

The signature is over a hash of a simplified form of the transaction. See the SignatureHash() method in C++ or Transaction.hashForSignature in BitcoinJ
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!