Quote
Thanks to Bitclockers, Bitlc.net, Bitcoin.cz, BitMinter, pool.itzod.ru, BTC Guild and ozco.in for supporting BIP 16
What about slush?
Topic: Version 0.6 release candidate 1 - page 4. (Read 13477 times)
What about slush?
While I have only the vaguest of understanding of EC cryptography, the "compressed public keys" bullet point there looks… interesting. I tried searching the boards and didn't see anything other than this post, so I guess I'm asking here:
• Is there discussion of this elsewhere that you could point me to?
• Is there discussion of this elsewhere that you could point me to?
I mailed about it to the -dev mailing list, without much response though.
Quote
• Does this form a new type of address/public/private-key pairing in the wallet.dat?
Yes and no. The same private key now corresponds to two different pubkey/address pairs. Which one is used is determined at generation time. Since the wallet stores both pubkey and private key, the length of the pubkey is used to determined which pair is intended.
Quote
• How far is this "complete compatibility" with older versions? Can I move a wallet.dat from this new release that's created these new keys to an older release and have it still work?
Good point. It will probably work, but the compressed pubkeys will be considered non-compressed ones by older versions, so they will probably miss transactions. Over time, the ledger seen by older clients and newer clients may diverge. I'll try to fix this before 0.6.0 final is released.
Quote
• Has testing so far included sending transactions between old and new versions, and between old wallets that have been upgraded to the new version, and probably more permutations on things like that?
Sending from and to old and new addresses has been tested, and between old and new clients. As mentioned, I didn't test downgrading.
Quote
Or are these the kinds of things that are being asked to test thoroughly? Is there a test plan of some sort, or should we just be doing whatever we can think of on testnet to see what happens?
All testing is welcome, of course...
New Sign Message dialog that allows you to prove that you
own a bitcoin address by creating a digital
signature.
Oh that's nice own a bitcoin address by creating a digital
signature.
Or are these the kinds of things that are being asked to test thoroughly? Is there a test plan of some sort, or should we just be doing whatever we can think of on testnet to see what happens?
You are the Quality Assurance department. A test plan is an excellent idea, could you write one up and post it on the wiki and ask for volunteers to help test?
Gavin, will Btcoin-QT support plain M-Of-N transactions and P2SH transactions or will it be etiher-or?
I don't know, the GUI for multisignature transactions hasn't been designed yet. But I imagine it will be simpler to always produce P2SH transactions, just as the client always produces OP_HASH160 transactions and has no option to produce plain OP_CHECKSIG transactions.
I assume that both forms will be supported for multisig payments into your wallet (but detailed discussion on how to support multisig in the GUI should happen somewhere other than this thread).
so far all seems good.
signing a message with a key is nice, now we need an easy way to verify a message with an address aswell... signing only works if the signature can be interpreted by somebody i think
signing a message with a key is nice, now we need an easy way to verify a message with an address aswell... signing only works if the signature can be interpreted by somebody i think
Nice list of improvements
It is expected that future releases of Bitcoin-Qt
will support the creation of multi signature transactions.
will support the creation of multi signature transactions.
Gavin, will Btcoin-QT support plain M-Of-N transactions and P2SH transactions or will it be etiher-or?
• Is there discussion of this elsewhere that you could point me to?
https://github.com/bitcoin/bitcoin/pull/649https://github.com/sipa/bitcoin/commit/11529c6e4f7288d8a64c488a726ee3821c7adefe (no discussion)
While I have only the vaguest of understanding of EC cryptography, the "compressed public keys" bullet point there looks… interesting. I tried searching the boards and didn't see anything other than this post, so I guess I'm asking here:
• Is there discussion of this elsewhere that you could point me to?
• Does this form a new type of address/public/private-key pairing in the wallet.dat?
• How far is this "complete compatibility" with older versions? Can I move a wallet.dat from this new release that's created these new keys to an older release and have it still work?
• Has testing so far included sending transactions between old and new versions, and between old wallets that have been upgraded to the new version, and probably more permutations on things like that?
Or are these the kinds of things that are being asked to test thoroughly? Is there a test plan of some sort, or should we just be doing whatever we can think of on testnet to see what happens?
• Is there discussion of this elsewhere that you could point me to?
• Does this form a new type of address/public/private-key pairing in the wallet.dat?
• How far is this "complete compatibility" with older versions? Can I move a wallet.dat from this new release that's created these new keys to an older release and have it still work?
• Has testing so far included sending transactions between old and new versions, and between old wallets that have been upgraded to the new version, and probably more permutations on things like that?
Or are these the kinds of things that are being asked to test thoroughly? Is there a test plan of some sort, or should we just be doing whatever we can think of on testnet to see what happens?
Do these builds use a gitian-like build process?
Yes, thanks for reminding me: I just uploaded gitian signatures for the win32 and linux 0.6rc1 builds to:https://github.com/bitcoin/gitian.sigs
The win32 build was not deterministic, though. There's a pull request to fix that.
The OSX binary is not gitian-built.
Do these builds use a gitian-like build process?
I'm not using the proxy option, but the new GUI is showing some strange IPv6 looking address in the proxy field.
e.g. a9b1:0:f2:v532:200:0:0:0
Once I change it, its all good.
Unchecking UPnP ports doesnt seem to save me selection.
Great job on all the new features!
e.g. a9b1:0:f2:v532:200:0:0:0
Once I change it, its all good.
Unchecking UPnP ports doesnt seem to save me selection.
Great job on all the new features!
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/
please download and run release candidate 1 from:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/
testing started
Quote
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.
--------------------------------------
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.
sounds good!
Looking good. Finalized Chinese Translation (Simplified)， hope get in rc2.
Re-posted from the bitcoin-development mailing list:
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=
that will spawn a shell process to run
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.
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=
that will spawn a shell process to run
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.
Jump to: