Bitcointalk**Search**

Welcome, **Guest**

It was the Bitcointalk forum that inspired us to create Bitcointalksearch.org - Bitcointalk is an excellent site that should be the default page for anybody dealing in cryptocurrency, since it is a virtual gold-mine of data. However, our experience and user feedback led us create our site; Bitcointalk's search is slow, and difficult to get the results you need, because you need to log in first to find anything useful - furthermore, there are rate limiters for their search functionality.

The aim of our project is to create a faster website that yields more results and faster without having to create an account and eliminate the need to log in - your personal data, therefore, will never be in jeopardy since we are not asking for any of your data and you don't need to provide them to use our site with all of its capabilities.

We created this website with the sole purpose of users being able to search quickly and efficiently in the field of cryptocurrency so they will have access to the latest and most accurate information and thereby assisting the crypto-community at large.

Pages:

Author

Heh, now I'm curious. What happens when you specify a smaller/larger value before the colon? What happens if you just don't call CHECKSIG in the transaction?

This is a great question, I also want to understand the logic for this. Hopefully someone can answer. So, for example, here's an example of a GENERATED coin getting spent:

TxIn: 73:3046...0f01

Prev.TxOut: 65:046d...bb9c CHECKSIG

That's intepreted as:

PUSH a 73 byte value onto the stack

PUSH a 65 byte value onto the stack

call CHECKSIG. CHECKSIG pops two values off the stack (public key and digital signature), then does the digital signature thing using the OpenSSL ECDSA_Verify() function.

Could someone to the best of their ability please explain the transaction scripting language? That's the only thing I still don't fully understand now. I know it's for extensibility and that it will be static for now, but could someone explain how it works?

Here's what the current best-block (according to my bitcoin client) looks like, dumped in a geek-readable format:

BLOCK 68fa61ac1f55a5787dfa0c75bc83e67376ae8356e6887a2ab74cdb0900000000

Next block: 0000000000000000000000000000000000000000000000000000000000000000

Time: Mon Jul 5 15:51:22 2010

Previous block: c18adb50289393b5a995b3506f039ac75e8de79f511515448811510200000000

3 transactions:

1 tx in, 1 out

['TxIn: COIN GENERATED coinbase:0442310d1c029c00']

['TxOut: value: 50.00 pubkey: 17sdrb1X7qpjPMJortqaNwWtBbtouSoJn2 Script: 65:046d...bb9c CHECKSIG']

1 tx in, 1 out

['TxIn: prev(580a...e82e:0) pubkey: (None) sig: 71:3044...db01']

['TxOut: value: 50.00 pubkey: 1FeFgJRvCYUTCBj1u696eL23xpAdNB4B8p Script: DUP HASH160 20:a09d...6d81 EQUALVERIFY CHECKSIG']

3 tx in, 1 out

['TxIn: prev(c0a0...6bc3:0) pubkey: (None) sig: 73:3046...0f01', 'TxIn: prev(f909...2493:0) pubkey: (None) sig: 73:3046...1601', 'TxIn: prev(bc0a...fe64:0) pubkey: (None) sig: 72:3045...6201']

['TxOut: value: 150.00 pubkey: 1BHxjkqPmtNdmJxLZgneijvGszRxM9hPkz Script: 65:04ee...1d02 CHECKSIG']

So: that big long string of hex at the top is the block header's hash value. Note that it ends with 8 zeroes; that's the proof-of-work (my utility for dumping blocks doesn't bother dumping the Nonce values).

What's hashed in the block header? The Nonce. The block's generation time. The previous block's hash. And a hash of all the transactions in the block. (and probably some stuff I'm forgetting).

This block has three transactions in it. The first is the 50.00 (which is really 5,000,000,000 of the smallest possible units) reward for finding/creating the block. It can only be spent by whoever has the private key that matches the public key in the TxOut (17sdrb1X7qpjPMJortqaNwWtBbtouSoJn2 -- you can think of public keys and bitcoin addresses as equivalent), which will be whoever generated the block.

The second is a payment of 50.0 from.... somebody... to... somebody. How does Bitcoin know that transaction is valid? Well, it:

+ Looks up the previous transaction. That's the TxIn: prev(580a...e82e:0) stuff-- fetch TxOut zero (which will be a coin generated txn) from previous transaction 580a....

+ EVALUATE(TxIn.pubkey + previous transaction TxOut.pubkey) and make sure it evaluates to true. This is where the cryptography happens; the receiver uses the private key known only to them and provides a correct digital signature.

The third is a payment of 150.0 (three 50.0-value in, one 150.0-value out).

Clear as mud?

A bitcoin isn't exactly a nonce or hashed block (including the nonce) found by instense number crunching. Instead, think of a bitcoin as just an accounting record, like a number you might type into an excel spreadsheet to represent the amount of money that some account has.

Now, when when people transact bitcoins, they broadcast their transaction to every node on the network. Over time, a few of these transactions will build up. Here's where the computation comes in. All of the node computers will begin processing this "block" of transactions which have occurred since the last proof of work began, looking for a nonce that happens to generate the target when hashed. When a node successfully finds this nonce, there is essentially just a new accounting record that says that node computer gets a 50 bitcoin reward, which can be spent in future transactions.

One of the really weird things is that the number of transactions that need to be "blocked" doesn't actually affect how hard it is to find a nonce for that block. So, there's really no benefit to not including the transactions when searching for a nonce, like you might have thought when you said "...concentrate on the number crunching".

Now, the rewarded bitcoins must go to the node who found the nonce, because along with the transactions and the nonce, the block also includes the node operator's address. So, even though the proof-of-work can be publicly verified, nobody can "claim it as their own" because that nonce is only a solution for the block which includes the successful node's address.

I hope that helps clarify some things. Please continue to ask questions if it's not clear, this thread can be a great resource for other newcomers. Somebody else will have to clarify how bitcoins are divided, I'm not entirely clear on that myself.

http://sourceforge.net/projects/bitcoin/files/Design%20Paper/bitcoin.pdf/bitcoin.pdf/download

(and Wikipedia)

They detail the system in very general terms. What I don't understand in the money creation: A coin is a chain of transactions. So a „freshly minted“ coin is a coin that only contains a Nonce that Hashes to the goal, which is a Number smaller than a given $target. Where is the incentive for the user to Hash the Block? As I understand it, the incentive basically lies in: „If I calculate the Hash and it Hashes to a Number smaller $target, then I found a new coin“. But if the user wants to create coins, wouldn't it be more efficient to skip the Hashing and concentrate on Number crunching?

But by broadcasting this proof of work, anybody could claim the coin because the old Hash + Nonce = new Hash have to be available for the check of the proof of work?

A second question: How are coins subdivided? I thought a coin starts with a certain Nonce and is the smallest unit but gavinandresen

https://bitcointalksearch.org/topic/dying-bitcoins-198

says a coin can be subdivided again.

Is there an example how bitcoin works on a bit-level?

Richard

Pages:

Jump to: