Decoding Block Index 0

[deadserious]

I'm trying to call "getrawtransaction" on 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b.

When done via the JSON-RPC API, I am getting an HTTP error 500.

When done via bitcoind, I get the error:
error: {"code":-5,"message":"No information available about transaction"}

Is it possible to query for information on this?  It does seem to come back at blockchain.info.

[1714176264]

1714176264

[1714176264]

1714176264

[1714176264]

1714176264

[1714176264]

1714176264

[Pieter Wuille]

It is not known whether this is a bug or intentional, but the reference client never adds the genesis transaction to its index. Thus, its outputs cannot be spent.

Changing this would imply giving Satoshi an instant switch to fork the network. I'm sure we respect him a lot, but not enough for that

[deadserious]

It is not known whether this is a bug or intentional, but the reference client never adds the genesis transaction to its index. Thus, its outputs cannot be spent.

It seems that the BlockChain.Info site was able to get the info somehow. 

If not from the client, how can it be retrieved?

[MatthewLM]

It is not known whether this is a bug or intentional, but the reference client never adds the genesis transaction to its index. Thus, its outputs cannot be spent.

Changing this would imply giving Satoshi an instant switch to fork the network. I'm sure we respect him a lot, but not enough for that

I didn't know this. Better update my code !

[runeks]

[...]
Changing this would imply giving Satoshi an instant switch to fork the network. I'm sure we respect him a lot, but not enough for that

Interesting. How would this work exactly?

[MoonShadow]

Doesn't matter.  Satoshi has already made it clear that the genesis block coins are not to be spent.  If the private key to the bitcoin address that the genesis block grants 50 BTC to actually exists (which it may not) then Satoshi or his heirs could prove their legacy at any time.  If the regular client did include the genesis block in the database, an entire set of rules exceptions would be required because the genesis block does not conform to the structure rules.  It really only exists as an 'anchor' to the blockchain, and to allow block #1 to have something to chain off of so that it could conform to the ruleset without a bunch of exceptions.

[MysteryMiner]

The bitcoins in Genesis block are not spendable (but this did not prevent some well meaning halfbrains from sending additional coins to that address). But the private key for that genesis block exists (or at least existed) so Satoshi could prove his identity at any chosen moment if he wishes and if the key is not lost. I wonder if this is a bug or Satoshi was so bright to include this intentionally?

edit: Damn, my post was so similar to posts above even without reading them! Have we become drones in a hive mind?

[gmaxwell]

(but this did not prevent some well meaning halfbrains from sending additional coins to that address).

_Those_ coins, however, are spendable.

[MysteryMiner]

(but this did not prevent some well meaning halfbrains from sending additional coins to that address).

_Those_ coins, however, are spendable.

Does not they have been "fused" to 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa address and is spendable only with private key matching this receiving address? And since none can send 51 BTC (coinbase + Your "spendable" coins) out of this address they all are lost?

[Peter Todd]

(but this did not prevent some well meaning halfbrains from sending additional coins to that address).

_Those_ coins, however, are spendable.

Does not they have been "fused" to 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa address and is spendable only with private key matching this receiving address? And since none can send 51 BTC (coinbase + Your "spendable" coins) out of this address they all are lost?

The reason why the genesis block mining reward transaction can not be spent is because the reference bitcoin client doesn't add it to the list of known transactions at startup. If it were a normal block that would happen, but it's not a normal block and doesn't get loaded like a normal block would. Thus any attempt to spend it will look like someone is attempting to spend a transaction that was never made in the first place.

Spending subsequent transactions to the address the genesis transaction was made to is possible because those transactions are normal transactions that every bitcoin client knows about.

Remember that a transaction is basically a message stating that coins from one or more prior transactions are now spendable by whoever has the private keys to one or more public keys. (vastly simplifying here) Transactions to the destination address of the genesis block transaction simply state that whoever can sign messages with the public key "satoshi's genesis block key" is allowed to spend the transaction. The fact that the genesis block transaction itself is unspendable is irrelevant, and only an artifact of it not going into every nodes pool of known transactions.

In short, in Bitcoin every transaction is completely independent. All this stuff about addresses is just a convenience that the client calculates for you based on what public keys are designated as able to spend a given transaction.

[casascius]

It is not known whether this is a bug or intentional, but the reference client never adds the genesis transaction to its index. Thus, its outputs cannot be spent.

Changing this would imply giving Satoshi an instant switch to fork the network. I'm sure we respect him a lot, but not enough for that

It could be changed but made spendable only after some block in the distant future, such as block 500000, where the likelihood that all current clients have been abandoned and upgraded is overwhelming.  Once that block is reached and is long passed, the code enforcing the restriction can be abandoned.

A reason I would suggest that it should be changed is it represents an easily overlooked exception to the definition of a valid transaction.  In a future where there are as many choices of bitcoin client as there are SMTP servers today, I would submit that this is a risk that will grow on its own if not taken care of in the present "era", because many bitcoin clients will be written in the future that treat this as a spendable transaction.

[MysteryMiner]

It is not known whether this is a bug or intentional, but the reference client never adds the genesis transaction to its index. Thus, its outputs cannot be spent.

Changing this would imply giving Satoshi an instant switch to fork the network. I'm sure we respect him a lot, but not enough for that

It could be changed but made spendable only after some block in the distant future, such as block 500000, where the likelihood that all current clients have been abandoned and upgraded is overwhelming.  Once that block is reached and is long passed, the code enforcing the restriction can be abandoned.

A reason I would suggest that it should be changed is it represents an easily overlooked exception to the definition of a valid transaction.  In a future where there are as many choices of bitcoin client as there are SMTP servers today, I would submit that this is a risk that will grow on its own if not taken care of in the present "era", because many bitcoin clients will be written in the future that treat this as a spendable transaction.

We must know if that private key even exists anymore to do such efforts. Otherwise it is like serving fresh meal every day in front of White House in a case if alien spaceship lands some day and they want to eat. There is no other consequences of this first 50BTC being unspendable, right?

But if Casascius is Satoshi as I suspect he might have a motive to make these 50BTC spendable sometimes in future.

Spending subsequent transactions to the address the genesis transaction was made to is possible because those transactions are normal transactions that every bitcoin client knows about.

Does not Bitcoin require all coins in inputs to be spent? Or I must read the white paper and specs 4-th time?

[casascius]

We must know if that private key even exists anymore to do such efforts. Otherwise it is like serving fresh meal every day in front of White House in a case if alien spaceship lands some day and they want to eat. There is no other consequences of this first 50BTC being unspendable, right?

We cannot know that it does not exist for certain.

The utility isn't so much 50BTC more for Satoshi, but rather, a cleaner definition for a fundamental object in the design of the system, for the benefit of future implementers.

In other words, the difference is:

 * A valid transaction is any transaction that meets all of the following criteria: <blah blah blah blah>

versus

 * A valid transaction is any transaction that meets all of the following criteria: <blah blah blah blah>, and oh BTW, there is one exception: the one in the genesis block.  Not for any good reason, but because of an ancient mistake.

As Bitcoin evolves and the definition perhaps expands, that exception will continue to be a thorn that must always be worked around by any fully-compliant client.  From an engineering perspective, it's mindclutter.  It's like a car that, in order for you to change the oil, you must first press the rear defrost button three times or else there's a 1 in 100 chance the car will spontaneously explode within the next 5000 miles, because some engineer reversed two wires in the prototype of that car and it was determined that the mistake would be worked around rather than fixed.

Does not Bitcoin require all coins in inputs to be spent? Or I must read the white paper and specs 4-th time?

"Inputs" are transaction outputs, not addresses.  What is encumbered in the genesis block is the 50 BTC coinbase transaction and its single output, not the address.  Additional coins sent to the address are spendable without question given the private key.

[2112]

From an engineering perspective, it's mindclutter.

But from an artistic perspective, it's beauty.

https://bitcointalk.org/index.php?topic=46498.msg556688#msg556688

From the social perspective, the sacrifical good luck offerings paid to the address in the Genesis block are a confirmation of the importance of the religious thinking amongst the adopters of the Bitcoin.

Finally, from the eschatological perspective, the attempt to spend the initial 50 BTC will serve as an early warning for the return of our Creator/Saviour/Prophet. The ones who watch for this special case will know about this event about 5 minutes earlier than those who will wait for the split in the blockchain.

[DannyHamilton]

Does not Bitcoin require all coins in inputs to be spent? Or I must read the white paper and specs 4-th time?

"Inputs" are transaction outputs, not addresses. . .

It wasn't until I had spent 6 months reading and learning about bitcoin that I finally understood this concept.

Sometimes I wish that bitcoin-qt would allow me to choose which previous outputs I want to use as inputs for a given transaction.  Other times, I'm really glad that I don't have to deal with that mess and the program makes it so simple to just enter a total amount to transfer letting it decide how to go about finding enough inputs to satisfy the transaction requirements.

[casascius]

From an engineering perspective, it's mindclutter.

But from an artistic perspective, it's beauty.

If you could hold in amber the original moth that caused the malfunction of the Mark III computer which was removed and taped in a logbook on September 9, 1947, and resulted in the coining of the term "bug", then from a financial perspective, it'd be worth its weight in plutonium.

http://www.allthingsquality.com/2010/04/first-bug-report-september-9-1947.html

[deadserious]

I guess I'm just not understanding the reason why getrawtransaction should be disabled on this transaction.  The purpose of that call is to decode the details of the transaction, to get the inputs and outputs. 

What is the purpose of hiding this information? 

Maybe I'm just dense but I don't see how blocking the raw transaction from the api has anything to do with spending anything.

[MoonShadow]

I guess I'm just not understanding the reason why getrawtransaction should be disabled on this transaction.  The purpose of that call is to decode the details of the transaction, to get the inputs and outputs. 

What is the purpose of hiding this information? 

Maybe I'm just dense but I don't see how blocking the raw transaction from the api has anything to do with spending anything.

It's not that it's actively blocked.  It's that the whole block is non-standard and thus would not pass integrity checks anyway.

[deadserious]

I guess I'm just not understanding the reason why getrawtransaction should be disabled on this transaction.  The purpose of that call is to decode the details of the transaction, to get the inputs and outputs. 

What is the purpose of hiding this information? 

Maybe I'm just dense but I don't see how blocking the raw transaction from the api has anything to do with spending anything.

It's not that it's actively blocked.  It's that the whole block is non-standard and thus would not pass integrity checks anyway.

Well, what I really want is the raw detail of a transaction, regardless if it passed integrity checks or not. 

I thought that was the intention of getrawtransaction.

Is it going to come down to parsing the blockchain file directly to get the info?

[Peter Todd]

Well, what I really want is the raw detail of a transaction, regardless if it passed integrity checks or not. 

I thought that was the intention of getrawtransaction.

I forget, but does getblock 0 give you that block? If so, can it give you the serialized bytes for the transaction, as opposed to its hash? If the former, give those bytes to decoderawtransaction. If the latter the block itself is hard-coded in the source code, although I don't remember there being a decoderawblock RPC command to take a serialized block and spit out the corresponding JSON. Maybe adding one would be useful, assuming the statement "serialized block" makes sense.

It may be worthwhile to add a hard-coded path for getrawtransaction that would spit out the genesis transaction given that transaction's hash, even though it's not actually in the memory pool, to allow people like you to decode it. It'll be a common thing for beginners playing with the RPC interface to want to do. After all, the only person who would run into the problem that you can't actually use it as an input is Satoshi...

A related question: on testnet and other alt-chains, is the genesis transaction for those alt-chains also not added to the memory pool? In which case we should nix the hard-coded path idea as it would either add a whole lot of special-cases or a lot of complexity.

Is it going to come down to parsing the blockchain file directly to get the info?

Since the genesis block is a hardcoded thing, it may not even get stored in the blockchain file.