listtransactions and generated coins

[nelisky]

Using the latest plain vanilla bitcoind (0.3.20.2) I'm testing the getwork interface for remote miners, but I miss one feature from the listtransactions call, and that's the generated blocks before they are confirmed. Can I do that at all with the plain bitcoind, is there a reason for that not being in there?

Thanks

[1713577006]

1713577006

[1713577006]

1713577006

[Gavin Andresen]

You can't see less-than-100-confirmation generations in listtransactions, but I agree, you should. 

[jgarzik]

Using the latest plain vanilla bitcoind (0.3.20.2) I'm testing the getwork interface for remote miners, but I miss one feature from the listtransactions call, and that's the generated blocks before they are confirmed. Can I do that at all with the plain bitcoind, is there a reason for that not being in there?

The xlisttransactions patch will show that to you.  It was built with the intention of showing precisely what the GUI shows, in the GUI transaction list.

[Gavin Andresen]

So...  I'm working on a patch to add < COINBASE_MATURITY-confirmation generation transactions to standard listtransactions, and trying to figure out the right way to handle immature generation transactions.

Either:
a) list them as 'generate' -- they'll just happen to have confirmations < 100 (100 is the COINBASE_MATURITY, although the GUI doesn't show them until confirmations>= 120).

b) list them as 'immature' -- a new transaction category.

I'm leaning towards (b), because that way apps don't have to know that COINBASE_MATURITY is 100, and it is easier to double-check that listtransactions agrees with the getbalance API calls (immature coins are never counted in balances, because they can't be spent until they mature).

The only drawback I can think of is that adding a new transaction category might confuse existing code.

[jgarzik]

b) list them as 'immature' -- a new transaction category.

I'm leaning towards (b), because that way apps don't have to know that COINBASE_MATURITY is 100, and it is easier to double-check that listtransactions agrees with the getbalance API calls (immature coins are never counted in balances, because they can't be spent until they mature).

The only drawback I can think of is that adding a new transaction category might confuse existing code.

xlisttransactions shows immature blocks as "mixed_debit":

Code:

    {
        "address" : "1111111111111111111114oLvT2",
        "label" : "",
        "txid" : "81862a4db4edb6b919355f5f70c32e5cecaae0c7f6f67f86ea586a9392ae33bd",
        "txtime" : 1301242706,
        "category" : "mixed_debit",
        "amount" : 0.00000000,
        "confirmations" : 10
    },

And so several miners already use a different transaction category in the field (those that patch it in, which apparently several big miners do).

[Gavin Andresen]

Pull request: https://github.com/bitcoin/bitcoin/pull/138/files

From a testnet-in-a-box test, here's what mature/immature blocks look like:

Code:

    {
        "account" : "",
        "category" : "generate",
        "amount" : 50.00000000,
        "confirmations" : 120,
        "txid" : "14da5ea78b6a1451ba11445be08c520808ddd185cf55d550f012dd4c16e2f67d",
        "time" : 1300074965
    },
    {
        "account" : "",
        "category" : "immature",
        "amount" : 50.00000000,
        "confirmations" : 119,
        "txid" : "8181f1760c208c84f06183f1145d3ad5a142340fd331e63466d5de8c406435aa",
        "time" : 1300075032
    },

PS:  There is a feature in the core bitcoin code that bothers me because I don't completely understand it:  coinbase transactions are technically spend-able after 100 confirmations (COINBASE_MATURITY in the code), but they aren't counted as spendable by the GUI or the RPC until 120+ confirmations (GetBlocksToMaturity() in the code).  I suppose a big block-chain re-org could run into problems if a just-barely-mature generation was spent at exactly the wrong time, but I need to think about that a bit more (and maybe ping satoshi...).

[nelisky]

b) list them as 'immature' -- a new transaction category.

I'm leaning towards (b), because that way apps don't have to know that COINBASE_MATURITY is 100, and it is easier to double-check that listtransactions agrees with the getbalance API calls (immature coins are never counted in balances, because they can't be spent until they mature).

The only drawback I can think of is that adding a new transaction category might confuse existing code.

xlisttransactions shows immature blocks as "mixed_debit":

Code:

    {
        "address" : "1111111111111111111114oLvT2",
        "label" : "",
        "txid" : "81862a4db4edb6b919355f5f70c32e5cecaae0c7f6f67f86ea586a9392ae33bd",
        "txtime" : 1301242706,
        "category" : "mixed_debit",
        "amount" : 0.00000000,
        "confirmations" : 10
    },

And so several miners already use a different transaction category in the field (those that patch it in, which apparently several big miners do).

So are we talking about 0 > mixed_debit > 100 > immature > 120 > generated? Why not mixed_debit all the way to 120, which is a transaction category miners already know (and what I was using on my custom miner, provided the listtransactions patch). I didn't even know about the 100 blocks maturity, I thought it was 120 just from what both the gui and the fact that balance was only accounted from those blocks at 120 confirmations on bitcoind.

In a nutshell, is there really a need for a new transaction category?

[Gavin Andresen]

No, there is no 'mixed_debit' in my pull request.  Coins are 'immature' until they have 120+ confirmations, then they are 'generate'.

[nelisky]

No, there is no 'mixed_debit' in my pull request.  Coins are 'immature' until they have 120+ confirmations, then they are 'generate'.

So just like jgarzik's patch, only instead of 'mixed_debit' you call it 'immature'... Ok, can't see why the change knowing many are already using a patched version with 'mixed_debit' but either works for me, so as long as I can know when I have generated blocks before maturity.

Any chance we get this on the mainline build anytime soon?

[TeraPool]

No, there is no 'mixed_debit' in my pull request.  Coins are 'immature' until they have 120+ confirmations, then they are 'generate'.

So just like jgarzik's patch, only instead of 'mixed_debit' you call it 'immature'... Ok, can't see why the change knowing many are already using a patched version with 'mixed_debit' but either works for me, so as long as I can know when I have generated blocks before maturity.

Any chance we get this on the mainline build anytime soon?

Bump.

Is this possible with the new client?

How can I get bitcoind to show unconfirmed generated coins?

[error]

No, there is no 'mixed_debit' in my pull request.  Coins are 'immature' until they have 120+ confirmations, then they are 'generate'.

So just like jgarzik's patch, only instead of 'mixed_debit' you call it 'immature'... Ok, can't see why the change knowing many are already using a patched version with 'mixed_debit' but either works for me, so as long as I can know when I have generated blocks before maturity.

Any chance we get this on the mainline build anytime soon?

Bump.

Is this possible with the new client?

How can I get bitcoind to show unconfirmed generated coins?

This was supposedly added in months ago, checking the pull request. Is it not working?

[Gavin Andresen]

This was supposedly added in months ago, checking the pull request. Is it not working?

Works for me (from a private testnet bitcoind):

Code:

    {
        "account" : "",
        "category" : "immature",
        "amount" : 50.00000000,
        "confirmations" : 2,
        "txid" : "0b1783e595b50580c6732c2891e92ad63b351a57a50e004013f7b60ecd89d337",
        "time" : 1310870932
    },
    {
        "account" : "",
        "category" : "immature",
        "amount" : 50.00000000,
        "confirmations" : 1,
        "txid" : "f4c244602f7d23951bd21abd89147312075a270286d1420d0bae0a1d8397597a",
        "time" : 1310871263
    }

[TeraPool]

Can anybody explain how to use it exactly then?

Do I need to patch bitcoind and then compile it myself or simple start bitcoind with a certain parameter or something?

[froggy]

As long as you've got a recent version of bitcoind installed just ensure bitcoind is running, then do:

Code:

bitcoind listtransactions

at the command line.

[TeraPool]

As long as you've got a recent version of bitcoind installed just ensure bitcoind is running, then do:

Code:

bitcoind listtransactions

at the command line.

Doink. So you can. Thanks for spoon feeding me!