|
Title: Decoding Block Index 0 Post by: deadserious on October 20, 2012, 11:15:48 PM 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. Title: Re: Decoding Block Index 0 Post by: Pieter Wuille on October 20, 2012, 11:20:45 PM 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 :) Title: Re: Decoding Block Index 0 Post by: deadserious on October 20, 2012, 11:36:43 PM 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? Title: Re: Decoding Block Index 0 Post by: MatthewLM on October 21, 2012, 12:06:34 AM 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 ! Title: Re: Decoding Block Index 0 Post by: runeks on October 21, 2012, 02:19:01 AM [...] Interesting. How would this work exactly?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 :) Title: Re: Decoding Block Index 0 Post by: MoonShadow on October 21, 2012, 02:50:40 AM 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.
Title: Re: Decoding Block Index 0 Post by: MysteryMiner on October 21, 2012, 04:21:50 AM 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? Title: Re: Decoding Block Index 0 Post by: gmaxwell on October 21, 2012, 04:51:58 AM (but this did not prevent some well meaning halfbrains from sending additional coins to that address). _Those_ coins, however, are spendable.Title: Re: Decoding Block Index 0 Post by: MysteryMiner on October 21, 2012, 05:45:11 AM (but this did not prevent some well meaning halfbrains from sending additional coins to that address). _Those_ coins, however, are spendable.Title: Re: Decoding Block Index 0 Post by: Peter Todd on October 21, 2012, 06:11:07 AM (but this did not prevent some well meaning halfbrains from sending additional coins to that address). _Those_ coins, however, are spendable.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. Title: Re: Decoding Block Index 0 Post by: casascius on October 21, 2012, 10:53:01 PM 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. Title: Re: Decoding Block Index 0 Post by: MysteryMiner on October 22, 2012, 01:59:26 AM 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. But if Casascius is Satoshi as I suspect he might have a motive to make these 50BTC spendable sometimes in future. Quote 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?Title: Re: Decoding Block Index 0 Post by: casascius on October 22, 2012, 02:15:45 AM 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. Title: Re: Decoding Block Index 0 Post by: 2112 on October 22, 2012, 02:58:39 AM 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. :) Title: Re: Decoding Block Index 0 Post by: DannyHamilton on October 22, 2012, 09:02:04 AM 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. . .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. Title: Re: Decoding Block Index 0 Post by: casascius on October 22, 2012, 12:50:33 PM 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 Title: Re: Decoding Block Index 0 Post by: deadserious on October 22, 2012, 03:14:10 PM 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. Title: Re: Decoding Block Index 0 Post by: MoonShadow on October 22, 2012, 03:49:41 PM 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. Title: Re: Decoding Block Index 0 Post by: deadserious on October 22, 2012, 04:09:19 PM 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? Title: Re: Decoding Block Index 0 Post by: Peter Todd on October 22, 2012, 05:15:34 PM 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. Title: Re: Decoding Block Index 0 Post by: deadserious on October 22, 2012, 05:35:07 PM 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. I can get the block, I can't get the transaction. Quote C:\Program Files (x86)\Bitcoin\daemon>bitcoind getblockhash 0 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f C:\Program Files (x86)\Bitcoin\daemon>bitcoind getblock 000000000019d6689c085ae1 65831e934ff763ae46a2a6c172b3f1b60a8ce26f { "hash" : "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f", "confirmations" : 204493, "size" : 285, "height" : 0, "version" : 1, "merkleroot" : "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afded a33b", "tx" : [ "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b" ], "time" : 1231006505, "nonce" : 2083236893, "bits" : "1d00ffff", "difficulty" : 1.00000000, "nextblockhash" : "00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf1 8eb6048" } C:\Program Files (x86)\Bitcoin\daemon>bitcoind getrawtransaction 4a5e1e4baab89f3 a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b error: {"code":-5,"message":"No information available about transaction"} Title: Re: Decoding Block Index 0 Post by: MoonShadow on October 22, 2012, 05:47:32 PM https://en.bitcoin.it/wiki/Genesis_block
Yes, if you want to see the genesis block on your own client, you're probably going to have to dive into the code with a hex editor. Title: Re: Decoding Block Index 0 Post by: kjj on October 22, 2012, 07:56:26 PM Here is the transaction.
Code: 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000 You can feed that to decoderawtransaction and get: Code: {Title: Re: Decoding Block Index 0 Post by: kjj on October 22, 2012, 08:23:20 PM For what it's worth, I decoded it by hand, and saw nothing unusual.
Code: 01000000 Version Title: Re: Decoding Block Index 0 Post by: deadserious on October 22, 2012, 09:01:34 PM Here is the transaction. Code: 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000 Can you get this from the API? Or did you pull it from the source code? Title: Re: Decoding Block Index 0 Post by: Pieter Wuille on October 22, 2012, 09:07:04 PM Except for the fact that its hashPrev is 0, the genesis block is not special at all.
Title: Re: Decoding Block Index 0 Post by: MoonShadow on October 22, 2012, 09:52:40 PM Except for the fact that its hashPrev is 0, the genesis block is not special at all. That does make it un-verifiable. Probably also the hand coded London Times headline in hexcode. Title: Re: Decoding Block Index 0 Post by: Pieter Wuille on October 22, 2012, 10:09:37 PM Probably also the hand coded London Times headline in hexcode. That is done in a completely standard way. Title: Re: Decoding Block Index 0 Post by: kjj on October 22, 2012, 11:18:31 PM Here is the transaction. Code: 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000 Can you get this from the API? Or did you pull it from the source code? The "format" of blk000x.dat is very simple. 4 bytes for the magic code, "f9beb4d9". 4 bytes for the block size. 80 bytes for the header. [size-80] bytes for the block body. And the block body is very simple too, a varint that says how many transactions follow, and then the transactions themselves. What I pasted above is nearly the whole block. Code: f9beb4d9 <-- magic Title: Re: Decoding Block Index 0 Post by: runeks on October 23, 2012, 04:31:13 PM 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. I still don't get the highlighted part above. Why would adding the genesis block to the block index give Satoshi "an instant switch to fork the network"?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 :) Title: Re: Decoding Block Index 0 Post by: blueadept on October 23, 2012, 04:34:52 PM Because the block in which he redeems the output of the genesis block would be rejected by nodes running old code but not new code.
Title: Re: Decoding Block Index 0 Post by: runeks on October 23, 2012, 04:40:38 PM Ah, ok. I guess I understood it to mean that if spending the transaction was enabled from the beginning, it would allow him to fork the network. I see how enabling it later on has that effect.
Title: Genesis transaction fork Post by: Yurock on July 12, 2013, 10:59:52 PM Changing this would imply giving Satoshi an instant switch to fork the network. No. First, nodes would check if the majority of miners is ready for the change and then all would add the transaction to the index at the same time. This would leave no time frame for the attack. So, technically the change can be done in a safe manner. Although, recovering 50 BTC from the first block may not worth the effort.Title: Re: Genesis transaction fork Post by: gmaxwell on July 13, 2013, 05:14:14 AM Changing this would imply giving Satoshi an instant switch to fork the network. No. First, nodes would check if the majority of miners is ready for the change and then all would add the transaction to the index at the same time. This would leave no time frame for the attack. So, technically the change can be done in a safe manner. Although, recovering 50 BTC from the first block may not worth the effort.What you're describing is how a soft-forking or backwards compatible change can be safely made. But this change is not backwards compatible. Doesn't matter if most— or even 80% of the miners are happy with it, the blocks would be rejected by all full nodes no matter how many miners are on it. Such a change can not be made safe by having mining on it. Title: Re: Decoding Block Index 0 Post by: 🏰 TradeFortress 🏰 on July 13, 2013, 05:19:02 AM I find it funny how we are arguing about 50 bitcoins that is owned by a person who probably has more than a million.
Title: Re: Decoding Block Index 0 Post by: kjj on July 13, 2013, 05:44:08 AM I find it funny how we are arguing about 50 bitcoins that is owned by a person who probably has more than a million. Then you should probably read the thread again. It isn't about the coins, it is about making sure that the entire network treats those coins in the same way if they ever move. Title: Re: Decoding Block Index 0 Post by: bitspill on July 13, 2013, 05:49:16 AM I find it funny how we are arguing about 50 bitcoins that is owned by a person who probably has more than a million. I find it funny this thread was last posted in October 2012 before getting bumped yesterday. Title: Re: Genesis transaction fork Post by: Yurock on July 13, 2013, 09:35:42 AM Doesn't matter if most— or even 80% of the miners are happy with it, the blocks would be rejected by all full nodes no matter how many miners are on it. Such a change can not be made safe by having mining on it. Why do you think that nodes will not upgrade in a timely fashion? If there is no safe path, how would you increase the block size limit? |
