Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: satoshi on November 13, 2010, 11:26:40 PM



Title: Version 0.3.15
Post by: satoshi on November 13, 2010, 11:26:40 PM
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


Title: Re: Version 0.3.15
Post by: hippich on November 15, 2010, 04:25:12 AM
Thanks!

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


Title: Re: Version 0.3.15
Post by: neofutur on November 15, 2010, 06:59:28 AM
 Same here, providing some kind of changelog could be useful


Title: Re: Version 0.3.15
Post by: theymos on November 15, 2010, 07:06:14 AM
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.


Title: Re: Version 0.3.15
Post by: ShadowOfHarbringer on November 16, 2010, 09:29:00 AM
@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 ?


Title: Re: Version 0.3.15
Post by: Gavin Andresen on November 16, 2010, 01:13:05 PM
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/


Title: Re: Version 0.3.15
Post by: bitcoinex on November 20, 2010, 02:02:26 AM
I understand correctly that these checkpoints are a step to the adding "chain cutter", for doesn't increase chain size indefinitely?


Title: Re: Version 0.3.15
Post by: ribuck on November 20, 2010, 11:22:35 AM
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?


Title: Re: Version 0.3.15
Post by: The Madhatter on November 20, 2010, 11:58:16 AM
Think about what happens when a new Bitcoin install is downloading from block #1... ;)


Title: Re: Version 0.3.15
Post by: jgarzik on November 20, 2010, 08:45:46 PM
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?


Title: Re: Version 0.3.15
Post by: The Madhatter on November 20, 2010, 10:06:01 PM
Oh, well that's new. :) I haven't looked at the source since 0.3.10.


Title: Re: Version 0.3.15
Post by: eurekafag on November 21, 2010, 12:30:10 PM
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.


Title: Re: Version 0.3.15
Post by: ribuck on November 21, 2010, 03:39:55 PM
In that case I still don't understand the need for more than one checkpoint.


Title: Re: Version 0.3.15
Post by: zipslack on November 21, 2010, 11:18:58 PM
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.)