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? 
Topic: Decoding Block Index 0 (Read 5675 times)
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. 
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.
I find it funny how we are arguing about 50 bitcoins that is owned by a person who probably has more than a million.
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.
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. 
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.
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.
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 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
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
1d010000 <-- size = 285
0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c <-- header
0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000 <-- body (the initial 01 is the number of transactions, the rest is the genesis transaction)
Probably also the hand coded London Times headline in hexcode.
That is done in a completely standard way.
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.
Except for the fact that its hashPrev is 0, the genesis block is not special at all.
Here is the transaction.
Code:
01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000
Can you get this from the API? Or did you pull it from the source code?
For what it's worth, I decoded it by hand, and saw nothing unusual.
Code:
01000000 Version
01 Number of TXIns
00000000000000000000000000000000 Hash of input (0x00 for generate)
00000000000000000000000000000000 Hash of input (0x00 for generate)
ffffffff TxOutIndex (0xffffffff for generate)
4d length (77 bytes)
04ffff001d0104455468652054696d65 16
732030332f4a616e2f32303039204368 32
616e63656c6c6f72206f6e206272696e 48
6b206f66207365636f6e64206261696c 64
6f757420666f722062616e6b73 77 bytes, "Arbitrary Data"
ffffffff nSequence
01 number of TXOuts
00f2052a01000000 value =50*100000000
43 length of output script (67 bytes)
41 Push 65 bytes
04 key type
678afdb0fe5548271967f1a67130b710 16 X
5cd6a828e03909a67962e0ea1f61deb6 32 X
49f6bc3f4cef38c4f35504e51ec112de 48 Y
5c384df7ba0b8d578a4c702b6bf11d5f 64 Y
ac OP_CHECKSIG
00000000 nLockTime
Here is the transaction.
You can feed that to decoderawtransaction and get:
Code:
01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000
You can feed that to decoderawtransaction and get:
Code:
{
"txid" : "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"coinbase" : "04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73",
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 50.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f OP_CHECKSIG",
"hex" : "4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac",
"reqSigs" : 1,
"type" : "pubkey",
"addresses" : [
"1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa"
]
}
}
]
}
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.
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.
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"}
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"}
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 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.
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.
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?
Jump to: