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

[Hazard]

As a proof of concept, I'm trying to make an altered client that makes the genesis block spendable. I know this can be done with addUnchecked by sending it the TX and the block hash. I've started by trying to recreate the genesis block TX by pulling this code from InitBlockIndex:

Code:

        // Genesis block
        const char* pszTimestamp = "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks";
        CTransaction txNew;
        txNew.vin.resize(1);
        txNew.vout.resize(1);
        txNew.vin[0].scriptSig = CScript() << 486604799 << CBigNum(4) << vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));
        txNew.vout[0].nValue = 50 * COIN;
        txNew.vout[0].scriptPubKey = CScript() << ParseHex("04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef3 8c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f") << OP_CHECKSIG;

But it doesn't work. Thoughts?

[1715634625]

1715634625

[r3wt]

i have no farking idea man

[jackjack]

Did you try putting it at line 57?

[Hazard]

Did you try putting it at line 57?

Yeah, same error there too

[jackjack]

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

[Hazard]

CTransaction txNew;  works just fine.

[twobitcoins]

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).

[Hazard]

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

Code:

void CTxMemPool::addGenesis(const uint256& hash, CTransaction &txNew)
{
	{
        LOCK(cs);	
		addUnchecked(hash, txNew);
    }
}

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.

[jackjack]

How do you call addGenesis?

[Hazard]

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

Code:

          // Genesis block
        const char* pszTimestamp = "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks";
        CTransaction txNew;
        txNew.vin.resize(1);
        txNew.vout.resize(1);
        txNew.vin[0].scriptSig = CScript() << 486604799 << CBigNum(4) << vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));
        txNew.vout[0].nValue = 50 * COIN;
        txNew.vout[0].scriptPubKey = CScript() << ParseHex("04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef3 8c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f") << OP_CHECKSIG;

        uint256 hash("0x0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f");

        CTxMemPool::addUnchecked(hash, txNew);

[jackjack]

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

Code:

void static CTxMemPool::addGenesis(const uint256& hash, CTransaction &txNew)

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

Code:

        mempool.addUnchecked(hash, txNew);

[Hazard]

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.

[twobitcoins]

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:

Code:

    {
        LOCK(mempool.cs);
        mempool.addUnchecked(hash, txNew);
    }

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

Code:

    mempool.addGenesis(hash, txNew);

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]

[Hazard]

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

[twobitcoins]

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

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:

Code:

    CCoinsViewCache view(*pcoinsTip, true);
    view.SetCoins(txNew.GetHash(), CCoins(txNew, 0));
    view.Flush();

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:

Code:

    // Special case for the genesis block, skipping connection of its transactions
    // (its coinbase is unspendable)
    if (GetHash() == hashGenesisBlock) {
        CCoinsViewCache viewTmp(view, true);
        viewTmp.SetCoins(vtx[0].GetHash(), CCoins(vtx[0], 0));
        viewTmp.Flush();

        view.SetBestBlock(pindex);
        pindexGenesisBlock = pindex;
        return true;
    }

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.

[twobitcoins]

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):

Code:

{
    CTxDB txdb;
    txdb.TxnBegin();
    CBlockIndex* pindex = mapBlockIndex.find(hashGenesisBlock)->second;
    unsigned int nTxPos = pindex->nBlockPos + ::GetSerializeSize(CBlock(), SER_DISK, CLIENT_VERSION) - 1 + GetSizeOfCompactSize(block.vtx.size());
    CDiskTxPos posThisTx(pindex->nFile, pindex->nBlockPos, nTxPos);
    txdb.UpdateTxIndex(txNew.GetHash(), CTxIndex(posThisTx, txNew.vout.size()));
    txdb.TxnCommit();
}

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!

[scintill]

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

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.

[kjj]

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

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.

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.)

[scintill]

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.)

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.

[jackjack]

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.)

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.

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