[Bitcoin-development] Network version increase

2012-04-02 Thread Pieter Wuille
Hello all,

Mike Hearn has submitted a pull request to add a pong message in reply to a 
ping.

This warrants an upgrade of the network protocol version number, which is since 
BIP14
independent from the version numbers of the reference client.

Any opinions about a numbering scheme? Currently the value 6 is used. We 
could
simply start increasing the number one by one now for every change, or we could
do a cleanup to 10 first, and start incrementing from there.

-- 
Pieter

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Release plan: 0.6.1

2012-04-02 Thread Gavin Andresen
Summarizing a discussion from #bitcoin-dev this morning:

The merge window for pull requests for a 0.6.1 release is now open.

This will be a bug-fix and code-cleanup only release, with the goal to
have Release Candidate 1 binaries available for testing in three
weeks: April 23'rd.  We want this to be a quick release cycle so we
can start pulling new features for a 0.7 release in a month or so.

The major issues I would like to get resolved:
 # 1024 Correct passphrase crashed the client
 # 1012 bitcoin-qt slow to shut down after recent commits

There are currently 189 open issues in our bug tracker; lets try to
get that down to under 100.

I know this will frustrate some of you who think development is
happening at a snail's pace; feel free to pull and test new features
(IPv6 support and coin control) that are important to you. Adequate
testing is still our biggest issue, if you want your favorite feature
to get into bitcoin core faster please spend some time helping test
other people's favorite features.

-- 
--
Gavin Andresen

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Network version increase

2012-04-02 Thread Jeff Garzik
On Mon, Apr 2, 2012 at 11:23 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
 Any opinions about a numbering scheme? Currently the value 6 is used. We 
 could
 simply start increasing the number one by one now for every change, or we 
 could
 do a cleanup to 10 first, and start incrementing from there.


It would be nice to have 10 as the baseline, frozen protocol.
-- 
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Network version increase

2012-04-02 Thread Wladimir
On Mon, Apr 2, 2012 at 6:32 PM, Jeff Garzik jgar...@exmulti.com wrote:

 On Mon, Apr 2, 2012 at 11:23 AM, Pieter Wuille pieter.wui...@gmail.com
 wrote:
  Any opinions about a numbering scheme? Currently the value 6 is
 used. We could
  simply start increasing the number one by one now for every change, or
 we could
  do a cleanup to 10 first, and start incrementing from there.


 It would be nice to have 10 as the baseline, frozen protocol.


Yes, I think increasing with one is enough for now. Let's not get ahead of
ourselves :)

Wladimir
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Signature Blocks and URI Sign Requests

2012-04-02 Thread Alan Reiner
I would like to propose two things that are closely related.  I will 
start making BIPS if there's positive feedback.  Sorry it's so long, but 
I felt both should be in the same email...



_*(1) Signature Blocks*  -- A more-robust, versatile, message-signing 
exchange_


Satoshi client 0.6.0 introduced message signing, but I've been fairly 
unimpressed with the implementation.  Strictly speaking, it works, but 
it's really not intended for regular users.  There is no indication of 
what message was signed or what address signed it.  Key recovery works 
for the computers processing it, but the user has no idea what this 
chunk of random data is.  They don't even know if the message they 
thought they signed is what's in the signature (along the lines of the 
copypaste virus, the message could be switched out without the user 
noticing).


I have implemented Signature Blocks 
https://bitcointalk.org/index.php?topic=56424.msg776163#msg776163 in 
Armory (as of v0.55), which is a fully-functional expansion on the 
idea.  Along the lines of BIP 10, a signature block is a human-readable 
chunk of data that immediately identifies the address and the message 
that are being signed.  It is easily copypasted via email or text 
files, and is fairly compact for visual identification.   Click the link 
above to see an example signature block and an Armory screenshot of the 
UI (which needs improvement, but still usable).  The verification 
process will include:


-- Check that the public key (included or recovered) matches the address 
field.
-- Verify that the signature matches the included message for this 
public key
-- The message is properly formatted with a standardized character set 
and escape/replacement scheme for things like newlines or double-quotes.


gmaxwell already pointed out that key recovery makes the Public Key 
field pointless.  Okay fine -- I just don't have key recovery 
implemented yet in Armory, and when I do I can ditch that field (or 
simply make it optional).  The point is to create a versatile, 
human-readable standardized form, much like the BIP 0010 
signature-collection scheme https://en.bitcoin.it/wiki/BIP_0010.



_*(2) Sign-Message URI scheme***-- Request signed messages from users 
using URIs_


I had the idea that for certain services, the first funding address 
could be used to identify the owner of an account, and all account 
maintenance (such as cashouts) be done through signed messages with this 
address.  For instance, the user would need both a login password *and* 
a signed message in order to make a withdrawal or purchase:


(Please withdraw 12.3 BTC from acct 1828349132 to address 
1Hfr3jk2093f)_signed_by_A


This gives the service the ability to use two separate factors to 
authenticate the request (usernamepassword *and* access to unencrypted 
wallet).  This /could/ work with manual signature blocks alone... but 
it's too many steps for regular users.  However, I think it's workable 
if we expand bitcoin URIs to include Signature Requests.


The URI scheme would add a few parameters to the scheme, and would have 
to have further replacement rules to make sure that messages are handled 
properly.   The general CONOPs would be (*Con*cept of *Op*eration*s*):


-- User navigates to Withdraw funds on webpage
-- Webpage has you fill in the details:  from-account, to-address, 
withdrawal amount
-- Webpage produces a clickable URI link that loads all the 
information into your client, including addr-reqd-for-sig
-- Client asks for confirmation and passphrase (if necessary) then 
produces a signature (and sig block if necessary)
-- URI may include reply-to field that tells it where to send the 
siganture when it's ready


So the extra tags that would be needed would probably be:

*requestSig*=True:
Flag to identify that this is a signing request URI
*sigNeeded*=1Qjf3392k31h
The address that needs to sign the message

*message*=Please%20withdraw%2012.3%20BTC%20to%20addr%201Hfr3jk2093f
Some encoding of the message that can be parsed the 
same way on all systems

*replyurl*=http://requestor.com/sig_replies.asp?;
(Optional) After signing, application will submit the 
signature to the replyurl


The reply url could be simply an http URL which will use bitcoin URI 
syntax, with the fields above copied.  Therefore, to complete the above 
request, the application handling the request will simply send an HTTP 
request to:



http://requestor.com/sig_replies.asp?*sigNeeded*=1Qjf3392k31h*message*=...*signature*=1fb1893ac193...*replySig*=True


Any thoughts?  (I have no doubts that there are :) )

-Alan





--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.

Re: [Bitcoin-development] Signature Blocks and URI Sign Requests

2012-04-02 Thread Luke-Jr
On Monday, April 02, 2012 4:55:03 PM Alan Reiner wrote:
 Any thoughts?  (I have no doubts that there are :) )

IMO, the sign-request URI should be an extension on the existing bitcoin: URI 
scheme; this way, sigNeeded can be omitted to imply sign with a sending 
address.

--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development