Topic: Bitcoin protocol - need explanation of couple of things. (Read 1732 times)

The signature is over a hash of a simplified form of the transaction. See the SignatureHash() method in C++ or Transaction.hashForSignature in BitcoinJ

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

That will explain point 2 very well. Thank you! How about 1? Is it right?

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.

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

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

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?

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.

Hi there again beautiful Bitcoin Community

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 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 ) - how will double spending check work?

As vector76 explained in one of his posts:

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