Topic: error: txNew does name not a type (.1 BTC reward for solution) (Read 2052 times)

Well, I feel like that would have been helpful for everyone to know, to better understand what his goal was.  Maybe it was obvious to everyone else.  I missed where kjj guessed Hazard was using his own genesis block.

So, since you're talking about confirmations, I'm guessing you have some other nodes trying to mine the spend of the genesis block reward.  Do those miners give any error messages in their debug.log?  I'm looking at main.cpp, CTransaction::FetchInputs function in bitcoin-qt 0.6.2 and see several checks that could be relevant.  I would add printouts to trace through that function (if it's being called by the miners, which I am assuming) and figure out which branches it's going down.  Also, twobitcoins's suggestion about CTxDb sounds correct, or at least the type of thing that would need to be done to make FetchInputs() pass.

Just because this is a bitcoin forum, and more people know what the bitcoin genesis block look like rather than some random genesis block that I create.

That's not the point of the thread, but Hazard works on his own blockchains

Thanks for the info.  I am confused as to why he's using talking about the Bitcoin genesis block (or at least the Bitcoin genesis timestamp message) if he's using litecoin.  In any case, if the litecoin genesis block is also unspendable, the same thing applies -- you can't spend it without a hard-forking modification of the rest of the network clients' code, and also knowing the private key for the pubkey the block reward went to.

Initially, it was unspendable because of a quirk in the indexing.  That quirk has been found, studied, named, and must now be faithfully reproduced.  If I recall correctly, the current client now has special case code specifically to make those coins unspendable.

Of course, he isn't running on bitcoin, but on litecoin.  Litecoin is fee to choose whatever rules they wish to follow and enforce.  Litecoin is already not-bitcoin, so bitcoin's rules do not apply.  Also, I suspect he is running on a testnet, perhaps even his own testnet, with his own genesis block.  (Or perhaps he's the guy that has the litecoin genesis block key.  It would be easy to look his name up, but it is late, and I'm lazy.)

The meaning of a confirmation is that a miner has checked your transaction and agrees it's valid.

My understanding is that the genesis block coinbase tx is unspendable because it is not indexed, as twobitcoins says.  (I could be wrong on this.)  So, you will never get a confirmation because no miners have modified their client like you have.  When they see your attempt to spend it, they won't even know what transaction you're talking about because it's not in their index, so they'll never confirm it.

Also, unless you have cracked the key Satoshi sent his genesis block reward to, you will never be able to produce a valid signature to spend it, any more than you can steal anybody else's coins by hacking your client.  So even if the miners knew what transaction you were talking about, they won't agree that you've made a valid signature for it.

Oh... the code was quite different back then.  I think the way to proceed in general is to extract the parts of ConnectBlock that are needed to add the transaction to the index.  I think it will look something like this (without error checking):


You could try putting that in LoadBlockIndex inside "if (mapBlockIndex.empty())" right at the end.  Again, I'm just copying bits of code from here and there, so no guarantees it will work.  Thanks for the coins, though!

Yes, I don't think adding to the memory pool is going to help with what you are trying to do.

The memory pool is for transactions that are not yet in blocks.  When a new transaction is created, it gets relayed to nodes across the network and stored in their memory pools.  Mining nodes use the memory pool to find transactions to include in mined blocks.  The genesis block transaction doesn't really belong there since it is already part of a block (and also since it is a coinbase transaction).

You need to add the transaction to the set of unspent transaction outputs.  I don't know exactly how to do it properly, but the critical piece of code seems to be the call to SetCoins in CTransaction::UpdateCoins().  You might be able to do it like this:


I'd recommend putting that code right where the genesis block is created: in main.cpp, in InitBlockIndex(), inside "if (!fReindex)", right at the end.  I can't guarantee that it will work, but it might.  Make sure you start with a fresh data directory.

To make reindexing work, I think you'll also need to do the same thing in CBlock::ConnectBlock inside this special case for the genesis block:


Or maybe you can simply remove the special case and let the rest of the function run, but I don't know if any of the rest of the code in that function will create problems.

Interesting behavior now... I can send the coins from the genesis block, but they never confirm.

I would not recommend skipping the lock.  Locks prevent conflicts between multiple threads.  That kind of thing would not be detected by the compiler, but can create very hard to debug problems.

If you don't want to add a member function to CTxMemPool, you can do something like this directly in AppInit2:


Or if you have a non-static member function in CTxMemPool, you can call it like this:


As for whether adding the genesis block coinbase transaction to the memory pool is the right way to solve your problem, I am skeptical, but I'm not familiar enough with the "proper" way to do it to give better advice.

Here is an address you can send coins to: [removed]

Leads to more errors, this function can't be static.

Also, LOCK(cs); needs to be called before trying to add it to the memory pool, which is why I created a new member function. Just running addunchecked by itself would results in errors.

I don't have much knowledge in the bitcoin-qt code, but I would make your addGenesis static:


Wait
Looks like there's a mempool global variable...
Try that instead then:

Here's what I'm using. This is within init.cpp:

How do you call addGenesis?

Yeah, I want it to run at the start. I tried running it from init.cpp, and it seemed to fix at least part of the problem. It appears the TX gets created now. I created a member function within main.cpp

Where hash is the genesis block hash. But trying to call it with CTxMemPool::addGenesis(hash,txNew) gives the error:

src\init.cpp: In function 'bool AppInit2()':
src\init.cpp:781:39: error: cannot call member function 'void CTxMemPool::addGenesis(const uint256&, CTransaction&)' without object

Any ideas? Also post your address, thanks.

You have to put that code inside a function.  Executable statements can't be at file scope.

I'm not sure when you want the code to run, but for example if you are trying to run it on startup, you could place it at the end of AppInit2 in init.cpp (before the return statement).

CTransaction txNew;  works just fine.

Could you paste the exact error?
I'd like to know if "CTransaction txNew;" goes well

Yeah, same error there too

Did you try putting it at line 57?