Version 0.3.15

[satoshi]

Version 0.3.15 is now available.

Changes:
- paytxfee switch is now per KB, so it adds the correct fee for large transactions
- sending avoids using coins with less than 6 confirmations if it can
- BitcoinMiner processes transactions in priority order based on age of dependencies
- make sure generation doesn't start before block 74000 downloaded
- bugfixes by Dean Gores
- testnet, keypoololdest and paytxfee added to getinfo

[1714220806]

1714220806

[1714220806]

1714220806

[1714220806]

1714220806

[1714220806]

1714220806

[hippich]

Thanks!

Could you provide link to list of "bugfixes by Dean Gores"? Can't find 'em.

[neofutur]

 Same here, providing some kind of changelog could be useful

[theymos]

Could you provide link to list of "bugfixes by Dean Gores"? Can't find 'em.

http://bitcoin.svn.sourceforge.net/viewvc/bitcoin?view=revision&revision=173

Nothing too exciting.

[ShadowOfHarbringer]

@satoshi

Does this version contain new blockchain "checkpoints" to secure the "official" chain ?

Could you please inform us about every checkpoint being inserted in news such as this ?

[Gavin Andresen]

ShadowOfHarbringer:  don't be lazy!  If you want to know if the lockins have been changed, it is easy to find out for yourself.

The blockchain checkpoints are in file main.cpp, around line 1,519:

Code:

    // Check that the block chain matches the known block chain up to a checkpoint                                                                        
    if (!fTestNet)
        if ((nHeight == 11111 && hash != uint256("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d")) ||
            (nHeight == 33333 && hash != uint256("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6")) ||
            (nHeight == 68555 && hash != uint256("0x00000000001e1b4903550a0b96e9a9405c8a95f387162e4944e8d9fbe501cd6a")) ||
            (nHeight == 70567 && hash != uint256("0x00000000006a49b14bcf27462068f1264c961f11fa2e0eddd2be0791e1d4124a")) ||
            (nHeight == 74000 && hash != uint256("0x0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20")))
            return error("AcceptBlock() : rejected by checkpoint lockin at %d", nHeight);

Even if you don't know C++ or don't know how to use subversion, you can check every release here: http://bitcoin.svn.sourceforge.net/viewvc/bitcoin/trunk/

[bitcoinex]

I understand correctly that these checkpoints are a step to the adding "chain cutter", for doesn't increase chain size indefinitely?

[ribuck]

Why is more than one checkpoint needed? Block 74000 (for example) is cryptographically linked to the earlier blocks, so if 74000 is OK aren't all the earlier blocks also OK?

[The Madhatter]

Think about what happens when a new Bitcoin install is downloading from block #1...

[jgarzik]

Think about what happens when a new Bitcoin install is downloading from block #1...

...you download blocks from 1 .. 74000 before being able to verify or generate coins.  Your point?

[The Madhatter]

Oh, well that's new. I haven't looked at the source since 0.3.10.

[eurekafag]

I understand correctly that these checkpoints are a step to the adding "chain cutter", for doesn't increase chain size indefinitely?

No, it doesn't cut the chain. Any client should have the full chain to verify transactions that depends on any block. It's just a security lock to prevent chain forgery.

[ribuck]

In that case I still don't understand the need for more than one checkpoint.

[zipslack]

In that case I still don't understand the need for more than one checkpoint.

The code snippet posted by gavinandresen is run against each block as it is verified. A new client will download and verify each block in the chain in order from the beginning. If only the most recent checkpoint is included, the client could download and verify a large number of 'incorrect' blocks before discovering that it has been following the 'wrong' fork of the chain, wasting a lot of bandwidth and CPU time. (A 'wrong' fork in this case is completely valid with the exception that it isn't the longest fork. If I understand correctly the client will eventually find the 'right' fork anyway, checkpoints will just ensure it happens as quickly as possible.)