[Bitcoin-development] 0.6 Release Candidate 1

2012-02-08 Thread Gavin Andresen
I'd like version 0.6 to get lots of review, soak time and testing, so
please download and run release candidate 1 from:
 http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/

You can review the code changes using github's compare feature:
 https://github.com/bitcoin/bitcoin/compare/v0.5.2...v0.6.0rc1

Please report bugs using the github issue tracker.


Release notes:

NEW FEATURES SINCE BITCOIN VERSION 0.5
--
Bitcoin-Qt can display and save QR codes for sending
and receiving addresses.

New context menu on addresses to copy/edit/delete them.

New Sign Message dialog that allows you to prove that you
own a bitcoin address by creating a digital
signature.

Wallets created with this version of bitcoin will
use 33-byte 'compressed' public keys instead of
65-byte public keys, resulting in smaller
transactions and less traffic on the bitcoin
network. The shorter keys are completely
compatible with older versions.

New command-line argument -blocknotify=command
that will spawn a shell process to run command
when a new block is accepted.

validateaddress JSON-RPC api command output includes
two new fields for addresses in the wallet:
 pubkey : hexadecimal public key
 iscompressed : true if pubkey is a short 33-byte key

New JSON-RPC api commands for dumping/importing
private keys from the wallet (dumprivkey, importprivkey).

New JSON-RPC api command for getting information about
blocks (getblock, getblockhash).

New JSON-RPC api command for getting extra information
related to mining (getmininginfo).


NOTABLE CHANGES
---

The -nolisten, -noupnp and -nodnsseed command-line
options were renamed to -listen, -upnp and -dnsseed,
with a default value of 1. The old names are still
supported for compatibility (so specifying -nolisten
is automatically interpreted as -listen=0; every
boolean argument can now be specified as either
-foo or -nofoo).

The -noirc command-line options was renamed to
-irc, with a default value of 0. Run -irc=1 to
get the old behavior.


PRELIMINARY SUPPORT FOR MULTISIGNATURE TRANSACTIONS
---

This release has preliminary support for multisignature
transactions-- transactions that require authorization
from more than one person or device before they
will be accepted by the bitcoin network.

Prior to this release, multisignature transactions
were considered 'non-standard' and were ignored;
with this release multisignature transactions are
considered standard and will start to be relayed
and accepted into blocks.

It is expected that future releases of Bitcoin-Qt
will support the creation of multisignature transactions,
once enough of the network has upgraded so relaying
and validating them is robust.

For this release, creation and testing of multisignature
transactions is limited to the bitcoin test network using
the addmultisigaddress JSON-RPC api call.

Short multisignature address support is included in this
release, as specified in BIP 16. Run with -bip16=0 to
turn off support for BIP 16.


-- 
--
Gavin Andresen

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Scaling at the end user level

2012-02-08 Thread grarpamp
 Have any groups published proposals for distributing
 a weekly precomputed bootstrap chain?
 rsync? db_dump  git  db_load?
 There is also 50% or more compression available in the index
 and chain.

 I have proposed packaging part of the block chain (doesn't even have to be
 weekly, just until the last checkpoint), but people fear it runs contrary to
 the distributed approach of Bitcoin.

Git repos are backed by strong hashes. Each commit could be a single
block dump, perhaps into a file hierarchy. Trusted entities, pools, etc
could sign at a checkpoint/height. Blockchain tools
would need made that can take the blk* and export single blocks and
process/export up to a certain block and quit. Everyone would do a
comparison and sign a commit hash. Everyone else git pulls. Having
the block toolset is a key prequisite to any sort of distribution. They don't
exist now :( Maybe the two bitcoin compatible library projects out there
will implement them :) Torrents are also strongly hashed and could be
signed as well.

Making the blockchain tools would be the most important thing to start.

 BTW: On such an old computer you should probably use one of the thin
 clients.

If that means not validating the chain, then it's as above. I'm not sure if it's
right to not care about the history if only making new transactions with a new
key post install time and then only validating new transactions as they come
in. Will have a look.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development