Please test (if you dare): next-test 2012-11-25

[Luke-Jr]

Superceded with next-test 2013-04-12

next-test is a branch of the master bitcoind & Bitcoin-Qt code with as many pull requests merged as possible, to aid in testing them. This branch can be used to test many pull requests in your daily Bitcoin use. The goal is to help pull requests get the testing they need to be merged into the main tree, so once you test a change, please comment in the relevant pull request (ideally with details).

Due to Coin Control's poor design and abandonment, it has begun to bitrot rapidly. This will probably be the last next-test supporting it, unless someone steps up to maintain it.

Please note these might possibly corrupt your wallet. No warranty of any kind of provided. BACKUP YOUR WALLET

Also note that this is based on code that will become 0.8 including the "ultraprune" block storage rewrite. The master code does not support upgrading from older versions yet, but this next-test includes a HACKY upgrader if it detects such a condition. Note that in any case, the block chain of both your old client and this new one will be saved on your disk. That means about 5 GB for the old one and about 5 GB for the new one (unless your OS supports hard links, which the HACK will use if possible). Wallet is currently considered to be forward and backward compatible, but please still back it up!

• Windows: installer ‖ zip (sigs)
• Source code: git ‖ tar.gz ‖ zip

Today's next-test includes the following pull requests (green are merged now; red are disputed):

• Parse URIs with non-BTC amounts
• -acceptnonstdtxn option to skip "non-standard transaction" checks
• Support for Tonal Bitcoin units (ᵇTBC, ˢTBC, and TBC)
• Issue1234
• Who doctored.... never was very useful, now only for the debuggers...
• getblocktemplate: longpolling support
• Coin Control
• Show how long AcceptBlock() takes to process.
• Add new P2P command and response: "getcmds", "cmdlist"
• improve dust spamming prevention algorithm
• RPC: Add per-message statistics to 'getpeerinfo'
• Addnode optimization and addnode access via RPC
• JSON-RPC method: prioritisetransaction <txid> <priority delta>
• A set of build scripts on top of gitian and vagrant for automating gitian builds...
• Change window titles to "Bitcoin-Qt - <purpose>" / misc related renames
• Specify fees explicitly via JSON-RPC
• CreateNewBlock: Child-pays-for-parent / Add transaction fee later
• Relay and accept transactions that personally benefit the user
• Bitcoin-Qt: add a Reset button to the options dialog
• enhance proxy support / network init
• Replace ThreadDumpAddresses with a timer.
• Bloom filters
• Add small-data OP_DROP transactions as standard transactions.
• FreeBSD and OpenBSD build fixes
• Support for specific BIP 22 rejection reasons and BIP 23 block proposal
• Base58 en-/de-coding
• Fixes for when listtransactions encounters non-standard outputs
• Add new RPC "lockunspent", to prevent spending of selected outputs
• In listaddressgroupings push down the IsMine check to run on each input.
• let user select wallet file with -wallet=foo.dat
• Add NATIVE_WINDOWS
• Add signfile/verifyfile RPC calls.
• Add -walletnotify to call an external script on wallet transactions
• Add wget(1)-friendly crypted key dump via GET /wallet-ckeys.json
• Normalize wallet RPC commands (refillkeypool, unlockwallet, lockwallet, setpassphrase)
• RPC: Avoid cleartext passwords by default
• update CClientUIInterface and remove orphan Wx stuff
• Documented locking part 1+2
• Change 'make' to $(MAKE) in leveldb make command line
• Restore FIRST_CLASS_MESSAGING
• P2P: parse network datastream into header/data components in socket thread
• P2P: improve RX/TX flow control
• reformat OS X build instrcs, add 10.8 + Homebrew
• Deploy properly with Nokia Qt installer's Frameworks on OSX
• Fix duplicate shortcut usage in sign/verify message dialog.
• Bugfix: remove conflicting transactions from memory pool

[hazek]

8min for 30% synchronization, was this always this fast?

[Luke-Jr]

8min for 30% synchronization, was this always this fast?

No, that's a combination of ultraprune and the upgrade hack...

[hazek]

and the upgrade hack...

Does that affect me if I'm doing a fresh install? I didn't have QT or the blockchain on my HDD before.

EDIT: ~50% = ~20min

EDIT2: ~60% = ~35min

EDIT3: :/ it really slowed down now, ~62.5% = ~60min

EDIT4: ~66.5% = ~90min

EDIT5: ~75% = ~110min

EDIT6: ~85.5% = ~130min taking up 800mb of my ram and from time to time really slowing down my laptop

EDIT8: Well I fked it up. I foolishly started to play around with QT and encrypted the wallet which I didn't know would prompt a restart and so I lost connection with 50 peers and probably some time before I get those back. ~87,5% = ~150min

EDIT9: ~88.5% = ~180min

EDIT10: ~91.5% = ~210min

EDIT11: ~92.5% = ~230min For some reason the system is becoming unresponsive every 30seconds or so for a couple of seconds, and my laptop really should be able to handle this without breaking a sweat.

EDIT12: woke up to a crashed QT, when I ran it again it showed ~96% = ~640min

EDIT13: ~98% = ~700min

EDIT14: 100% = ~740min and this is with 1 restart and 1 crash

[prezbo]

8min for 30% synchronization, was this always this fast?

I thought this was going to be synchronized in no time. Then at around 15k to go it almost slowed down to a halt.

[Bitexchange]

let user select wallet file with -wallet=foo.dat

gmaxwell commented 2 months ago

Eh. The functionality is desirable, but the ability to filesystem split the wallet and data dir is a surefire way to end up with a corrupted wallet. This is subtle and I suspect hard to warn people out of doing, esp since it would mostly work. (until it eats your keys for lunch).

Whats the problem with using multiple wallet files with the same bitcoin client?

Ok you could miss recieved coins if you update the blockchain when there is the wrong wallet loaded, but if you make sure that doesnt happen, is there any technical reason why i cant make 10 wallets and load them when needed?

Because im already doing that and didnt have any problem so far 

[Pieter Wuille]

Whats the problem with using multiple wallet files with the same bitcoin client?

None at all, it just isn't implemented.

What is a problem, is separating the wallet and the database environment. If your client (or your computer) crashes, you must have the database environment (the files in $DATADIR/database) to recover the data. If those are not available, the wallet may get corrupted. BDB isn't really intended to be used with free-floating database files - it expects them to be part of such an environment.

Now, we are slowly moving away from BDB. 0.8 (and this next-test build) do not use it anymore for the block chain indexes (it uses LevelDB instead), and we'll likely stop using BDB for wallet files as well. At that point, it will be perfectly safe to select any file/location for your wallet.

[Luke-Jr]

let user select wallet file with -wallet=foo.dat

gmaxwell commented 2 months ago

Eh. The functionality is desirable, but the ability to filesystem split the wallet and data dir is a surefire way to end up with a corrupted wallet. This is subtle and I suspect hard to warn people out of doing, esp since it would mostly work. (until it eats your keys for lunch).

Whats the problem with using multiple wallet files with the same bitcoin client?

Ok you could miss recieved coins if you update the blockchain when there is the wrong wallet loaded, but if you make sure that doesnt happen, is there any technical reason why i cant make 10 wallets and load them when needed?

Because im already doing that and didnt have any problem so far 

You won't even miss received coins since the client automatically detects when it needs to rescan. The problem gmaxwell mentions is only if you do something stupid like -wallet=/mnt/usbdrive/wallet.dat, since the database/ directory it depends on is still on the main hard drive. So long as you keep all your wallets on the same disk it should be fine.

[Bitexchange]

Ok nice, didnt know that, thanks.

So the wallet.dat contains puplic/private keys, transactions, and the block count where it got all previous transactions ?

If i didnt use a wallet for some time, it will rescan the blockchain i got on my disk without downloading it again? Is there any status shown on the client which tells me if the wallet is up to date with the blockchain dat files?
Because i didnt really notice something like that so i guessed its better not to recieve coins on wallets which arent currently 'loaded' while updating the blockchain with another wallet.

[hazek]

Is it normal for QT to take up 900mb of ram?

[Vitalik Buterin]

Make on Linux (Xubuntu) does not work without libminiupnpc8-dev installed.

[Dezeer]

Indexing advanced rapidly, 50 blocks per second, into the remaining 17000-16800 and its now indexing at pace one per second. Memory usage is at this point, before indexing has completed, normal at 150MB.

[Luke-Jr]

Make on Linux (Xubuntu) does not work without libminiupnpc8-dev installed.

You mean with USE_UPNP=- (don't compile support)?

[rabit]

Make on Linux (Xubuntu) does not work without libminiupnpc8-dev installed.

You mean with USE_UPNP=- (don't compile support)?

Its set to USE_UPNP=- in line 41 of makefile.unix .

[Luke-Jr]

Make on Linux (Xubuntu) does not work without libminiupnpc8-dev installed.

You mean with USE_UPNP=- (don't compile support)?

Its set to USE_UPNP=- in line 41 of makefile.unix .

No, it's set by default to USE_UPNP=0 (compile support, but disable by default) on line 5, and changed from (null) to - on line 41. So eg, USE_UPNP= will work also (but there is no way to support this syntax with -Qt)

[rabit]

Make on Linux (Xubuntu) does not work without libminiupnpc8-dev installed.

You mean with USE_UPNP=- (don't compile support)?

Its set to USE_UPNP=- in line 41 of makefile.unix .

No, it's set by default to USE_UPNP=0 (compile support, but disable by default) on line 5, and changed from (null) to - on line 41. So eg, USE_UPNP= will work also (but there is no way to support this syntax with -Qt)

The problem is that the README states that libminiupnpc is optional but make -f makefile.unix doesnt work without it, so maybe the default setting should be USE_UPNP=-. But probably its not that important.

[Luke-Jr]

Make on Linux (Xubuntu) does not work without libminiupnpc8-dev installed.

You mean with USE_UPNP=- (don't compile support)?

Its set to USE_UPNP=- in line 41 of makefile.unix .

No, it's set by default to USE_UPNP=0 (compile support, but disable by default) on line 5, and changed from (null) to - on line 41. So eg, USE_UPNP= will work also (but there is no way to support this syntax with -Qt)

The problem is that the README states that libminiupnpc is optional but make -f makefile.unix doesnt work without it, so maybe the default setting should be USE_UPNP=-. But probably its not that important.

And immediately under the dependency list:

miniupnpc may be used for UPnP port mapping.  It can be downloaded from
http://miniupnp.tuxfamily.org/files/.  UPnP support is compiled in and
turned off by default.  Set USE_UPNP to a different value to control this:
 USE_UPNP=-    No UPnP support - miniupnp not required
 USE_UPNP=0    (the default) UPnP support turned off by default at runtime
 USE_UPNP=1    UPnP support turned on by default at runtime

This isn't something new either, it's been this way since 0.4

[dust]

8min for 30% synchronization, was this always this fast?

I thought this was going to be synchronized in no time. Then at around 15k to go it almost slowed down to a halt.

There are very few transactions in the first 30% of blocks, so these blocks download and verify very quickly.  The most recent 15k transactions have a bunch of transactions (many of them satoshidice related), which makes them slower to process.

[Pieter Wuille]

Indexing advanced rapidly, 50 blocks per second, into the remaining 17000-16800 and its now indexing at pace one per second. Memory usage is at this point, before indexing has completed, normal at 150MB.

After the last checkpoint (block 193000 currently), signature verification is enabled, and in all likelyhood this is the bottleneck after that point.

[Pieter Wuille]

So the wallet.dat contains puplic/private keys, transactions, and the block count where it got all previous transactions ?

Yes, since 0.3.21.

If i didnt use a wallet for some time, it will rescan the blockchain i got on my disk without downloading it again? Is there any status shown on the client which tells me if the wallet is up to date with the blockchain dat files?

Yes, it will. It does this rescan automatically at startup, so there is no feedback in the GUI - when it is loaded, the wallet should always be up-to-date with the block chain.