Version 0.3.12

[satoshi]

Version 0.3.12 is now available.

Features:
- json-rpc errors return a more standard error object. (thanks to Gavin Andresen)
- json-rpc command line returns exit codes.
- json-rpc "backupwallet" command.
- Recovers and continues if an exception is caused by a message you received.  Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.

If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard.  See this thread:
http://bitcointalk.org/index.php?topic=969.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/

[1714212021]

1714212021

[1714212021]

1714212021

[1714212021]

1714212021

[1714212021]

1714212021

[1714212021]

1714212021

[theymos]

What does the prohibition of "nonstandard" transactions do?

Code:

main.cpp:506
// Rather not work on nonstandard transactions
if (GetSigOpCount() > 2 || ::GetSerializeSize(*this, SER_NETWORK) < 100)
  return error("AcceptToMemoryPool() : nonstandard transaction"); 

What is included in "GetSigOpCount", and what does "GetSerializeSize" measure?

This is "lightly" enforced by the network:

Code:

main.cpp:1425
// Check that it's not full of nonstandard transactions
if (nHeight > 79400 && GetSigOpCount() > MAX_BLOCK_SIGOPS)
  return error("AcceptBlock() : too many nonstandard transactions"); 

[satoshi]

Bitcoin clients currently only create and recognize transactions that match two possible templates. 

Those are some quick tests that loosely check if transactions fit some general metrics that those standard transactions fit.  Nodes will only work on adding those transactions to their block.

In the future, if we add more templates to the existing 2 types of transactions, we can change the "rather not work on nonstandard transactions" test to accept them.

[jgarzik]

In the future, if we add more templates to the existing 2 types of transactions, we can change the "rather not work on nonstandard transactions" test to accept them.

Won't older clients will reject non-standard transactions, even if newer [future] clients are updated to generate them?

[theymos]

Won't older clients will reject non-standard transactions, even if newer [future] clients are updated to generate them?

They just won't include them in blocks they generate. So the transactions might be slowed down a bit, but not stopped entirely.

[nelisky]

satoshi et al: I have been thinking long and hard about security of the wallet, as I implement other web services that will (I hope) move larger sums of bitcoins. The backup wallet is great, I'm now doing automated backups every time I create a new address, including on sending transactions.

But will this scale on a site that sends many transactions? I always have to backup the whole wallet, and that takes addresses, key, transactions, and grows considerably with usage. For more intensive usage I believe either less backup points or better separation of data is needed.

The two simple solutions I can think of for this are:
1) separate addresses/keys from everything else, so it is easy to do incremental backups or at least limit the backup size to that really needed to recreate the funds in a hardware failure event.
2) implement what has been talked as a future feature, the ahead of time creation of address bundles to be used, so one backup of the wallet is good for 1000 future transactions, or something like that
2.1) to use this efficiently, one should have the possibility to query how many addresses are still left in the unused pool and request creation of a new batch if needed so backups can be timely created and we drop to 0 the possibility of loosing data between address creation and backup

Of course doing both 1) and 2) would be perfect, but can we expect any of the above for a future release? Should we start hacking our own patches?