[Bitcoin-development] BIP21 bitcoin URIs and HTML5

2013-04-24 Thread Mike Hearn
HTML5 allows web apps to register themselves for handling URI schemes, such
as the bitcoin: URI that is already in use and being extended as part of
the payment protocol.

The bad news is that for security reasons there is a whitelist of
acceptable schemes in the spec:

http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-navigator-registerprotocolhandler

The good news is that yesterday I talked to Hixie about it and he added
bitcoin to the whitelist:

http://html5.org/tools/web-apps-tracker?from=7849to=7850

I'm currently finding out what the process is for browser makers to notice
the change (perhaps they watch the spec commit history and nothing needs to
be done), but within a few months most users should have browsers that can
accept bitcoin as a web-app handleable protocol scheme. I suppose IE10
users may be the laggards, but I guess we can live with that for now.

Ian pointed out some errors in the BIP21 spec. What's the process for
amending the BIP? Do we need to create a new one and mark the old one as
replaced, or can we just fix it in place given the relatively exotic nature
of most of the issues? Here's his feedback:


- BNF doesn't say what it's character set is (presumably it's Unicode)

 - bitcoinparams production doesn't define the separator, so in theory
the syntax is ...?label=foomessage=fooother=foo (rather than
...?label=foomessage=foo etc)

- the syntax allows ?amount=FOOamount=1.1 as far as I can tell, since
otherparam matches any name followed by any value, including amount
followed by a bogus value.

- pchar is referenced without definition.

- the simpler syntax is just wrong (it would result in
bitcoin:address?amount=1?label=FOO rather
than bitcoin:address?amount=1label=FOO)

BTW the IETF URL specs are being obsoleted by http://url.spec.whatwg.org/,
at least for Web purposes. In that case matters.
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP21 bitcoin URIs and HTML5

2013-04-24 Thread Andreas Schildbach
I had another amendment, which roughly (can't remember the details) has
to do with case-sensitivity of the scheme part and parameter names. If I
remember right, BITCOIN:1d4...?AMOUNT=0.1 would be a correct URI but not
valid in the sense of BIP21 currently.


On 04/24/2013 09:42 AM, Mike Hearn wrote:
 HTML5 allows web apps to register themselves for handling URI schemes,
 such as the bitcoin: URI that is already in use and being extended as
 part of the payment protocol.
 
 The bad news is that for security reasons there is a whitelist of
 acceptable schemes in the spec:
 
 http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-navigator-registerprotocolhandler
 
 The good news is that yesterday I talked to Hixie about it and he added
 bitcoin to the whitelist:
 
 http://html5.org/tools/web-apps-tracker?from=7849to=7850
 
 I'm currently finding out what the process is for browser makers to
 notice the change (perhaps they watch the spec commit history and
 nothing needs to be done), but within a few months most users should
 have browsers that can accept bitcoin as a web-app handleable protocol
 scheme. I suppose IE10 users may be the laggards, but I guess we can
 live with that for now.
 
 Ian pointed out some errors in the BIP21 spec. What's the process for
 amending the BIP? Do we need to create a new one and mark the old one as
 replaced, or can we just fix it in place given the relatively exotic
 nature of most of the issues? Here's his feedback:
 
 
 - BNF doesn't say what it's character set is (presumably it's Unicode)
 
  - bitcoinparams production doesn't define the separator, so in theory
 the syntax is ...?label=foomessage=fooother=foo (rather than
 ...?label=foomessage=foo etc)
 
 - the syntax allows ?amount=FOOamount=1.1 as far as I can tell, since
 otherparam matches any name followed by any value, including amount
 followed by a bogus value.
 
 - pchar is referenced without definition.
 
 - the simpler syntax is just wrong (it would result in
 bitcoin:address?amount=1?label=FOO rather
 than bitcoin:address?amount=1label=FOO)
 
 BTW the IETF URL specs are being obsoleted
 by http://url.spec.whatwg.org/, at least for Web purposes. In that case
 matters.
 
 
 
 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service 
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
 
 
 
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 



--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Sending Bitcoins using RSA keys

2013-04-24 Thread Melvin Carvalho
So there's a slight world divide in digital payments with bitcoin using
ECDSA and GPG, payswarm / webid etc using largely RSA

Here's how to bring the two worlds together and enable bitcoins be sent
over webid or payswarm


Problem: Alice and Bob have RSA key pairs, but no public bitcoin
addresses.  Alice wants to send 1 BTC to Bob.

1. Alice takes Bob's WebID and encrpyts it with her private key (to create
entropy) ...

2. Alice uses that message as the seed to produce btc address (as per
http://brainwallet.org ) with ECDSA key pair

3. Alice sends coins to this address

4. Alice and then encrypts the seed again with Bob's public key

5. Bob decrypts the seed using his private key

6. Bob can now use the seed to recreate the wallet and spend the coins

Unless I've made an error, I believe this unites the web paradigm and
crypto currency paradigm into one potentially giant eco system ...
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP21 bitcoin URIs and HTML5

2013-04-24 Thread Gavin Andresen
 Ian pointed out some errors in the BIP21 spec. What's the process for
amending the BIP? Do we need to create a new one and mark the old one as
replaced, or can we just fix it in place given the relatively exotic nature
of most of the issues?

Those all sound like bugs in the BIP; I think they should just be fixed, I
don't think we need a new BIP.

I vote for a new meta-data item in the BIP header:

  Corrected: date

-- 
--
Gavin Andresen
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Sending Bitcoins using RSA keys

2013-04-24 Thread Craig B Agricola
Maybe I'm missing something crucial, but what benefit does this dance give over
the slightly more obvious mechanism of simply:
1) Alice generates a new address with her bitcoin client and sends the BTC to
   this new address
2) Alice exports the private key for that address (there is a well supported
   format for that)
3) Alice writes a nice email to Bob, including that exported private key
4) Alice encrypts the email with Bob's public key using GPG and sends it to him
   by email
5) Bob decrypts the email
6) Bob imports the private key into his wallet

There's no need for sending a whole wallet; just the one key is needed.  Every
bit of infrastructure needed above already exists.  And of course, the above
has the same issue as your proposal; this is a way for two trusting parties to
send BTC without using the Bitcoin network, but it's not a payment mechanism.
They now share control of an address; whoever spends that BTC first wins, so
until Bob uses the Bitcoin network to spend that BTC to another address that
only he controls, it's still in joint custody.  And if ensuring that he has
control of the BTC is the last (implicit) step in the procedure above, as well
as yours, then they might as well have simply used the Bitcoin network to do
the transfer in the first place.

Did I miss the point entirely?

 -Craig

PS. Re-reading, I realize that the above might come off sounding snarky or
dismissive; it's not intended that way.  I'm wondering if I'm missing the
big picture.

On Wed, Apr 24, 2013 at 04:18:38PM +0200, Melvin Carvalho wrote:
 So there's a slight world divide in digital payments with bitcoin using
 ECDSA and GPG, payswarm / webid etc using largely RSA
 
 Here's how to bring the two worlds together and enable bitcoins be sent
 over webid or payswarm
 
 
 Problem: Alice and Bob have RSA key pairs, but no public bitcoin
 addresses.  Alice wants to send 1 BTC to Bob.
 
 1. Alice takes Bob's WebID and encrpyts it with her private key (to create
 entropy) ...
 
 2. Alice uses that message as the seed to produce btc address (as per
 http://brainwallet.org ) with ECDSA key pair
 
 3. Alice sends coins to this address
 
 4. Alice and then encrypts the seed again with Bob's public key
 
 5. Bob decrypts the seed using his private key
 
 6. Bob can now use the seed to recreate the wallet and spend the coins
 
 Unless I've made an error, I believe this unites the web paradigm and
 crypto currency paradigm into one potentially giant eco system ...

 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service 
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Time for a 0.8.2 release

2013-04-24 Thread Gavin Andresen
Consensus in #bitcoin-dev chat is that it is time to do a 0.8.2 release. A
few important bugs have been fixed, and the goal will be to get a 0.8.2
final release before the May 15'th hard fork deadline.

Pieter has already started going through the issues list; help with
testing, debugging, and fixing high-priority issues is very welcome. I'll
also be going through the issues list and marking any issues I think need
to be fixed with the '0.8.2' milestone.

If translation work needs to be done, now is a great time to do it.

We still don't have a basic QA checklist for testing of release candidates;
I'll commit to spending a little of the remaining Bitcoin Testing Project
bitcoins to whoever contributes to creating one.

-- 
--
Gavin Andresen
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP21 bitcoin URIs and HTML5

2013-04-24 Thread Melvin Carvalho
On 24 April 2013 09:42, Mike Hearn m...@plan99.net wrote:

 HTML5 allows web apps to register themselves for handling URI schemes,
 such as the bitcoin: URI that is already in use and being extended as part
 of the payment protocol.

 The bad news is that for security reasons there is a whitelist of
 acceptable schemes in the spec:


 http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-navigator-registerprotocolhandler

 The good news is that yesterday I talked to Hixie about it and he added
 bitcoin to the whitelist:

 http://html5.org/tools/web-apps-tracker?from=7849to=7850

 I'm currently finding out what the process is for browser makers to notice
 the change (perhaps they watch the spec commit history and nothing needs to
 be done), but within a few months most users should have browsers that can
 accept bitcoin as a web-app handleable protocol scheme. I suppose IE10
 users may be the laggards, but I guess we can live with that for now.


This is great news for bitcon, and the IANA application will be improved if
there is evidence of it being used



 Ian pointed out some errors in the BIP21 spec. What's the process for
 amending the BIP? Do we need to create a new one and mark the old one as
 replaced, or can we just fix it in place given the relatively exotic nature
 of most of the issues? Here's his feedback:


 - BNF doesn't say what it's character set is (presumably it's Unicode)

  - bitcoinparams production doesn't define the separator, so in theory
 the syntax is ...?label=foomessage=fooother=foo (rather than
 ...?label=foomessage=foo etc)

 - the syntax allows ?amount=FOOamount=1.1 as far as I can tell, since
 otherparam matches any name followed by any value, including amount
 followed by a bogus value.

 - pchar is referenced without definition.

 - the simpler syntax is just wrong (it would result in
 bitcoin:address?amount=1?label=FOO rather
 than bitcoin:address?amount=1label=FOO)

 BTW the IETF URL specs are being obsoleted by http://url.spec.whatwg.org/,
 at least for Web purposes. In that case matters.


Not 100% sure how accurate this is, tho it may be the world view of some
folks in WHATWG.  WHATWG is not a major standards body tho.  Work on
improving the URL spec is always welcome, as it is the value proposition of
the Web.





 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] [RFC] Fees/Minimum Priorities based on Mempool and Memory-Limited Mempool

2013-04-24 Thread Matt Corallo
I hacked together a new min fee/prio calculator and memory-limited
mempool a while back and figured Id post the code here to get some
comments.  Its more of a discussion-starter than a strict proposal and
has a few obvious holes (hence posting here instead of pull-requesting).

It works as such (note that all constants are really place-holders, so
please recommend reasonable constants):

1) Watches when transactions enter mempool and calculates minimum
fee/priority based on a fairly dumb algorithm... It finds the highest
FEE_POLICY_TOP_N_TX (10) fee/prio transactions in mempool that have been
in mempool at least FEE_POLICY_DETERMINATION_BLOCKS (6) blocks and
averages together their fee/prio then multiplies by FEE_POLICY_FACTOR
(1.1).

2) It limits mempool size to a default of 10*MAX_BLOCK_SIZE (bringing it
down to 9*MAX_BLOCK_SIZE each time it has to throw out transaction).
When transactions are throw out, it keeps 2/9 of the mempool size in
highest-prio transactions and 7/9 of the mempool in highest-fee
transactions.  

3) Any transactions which have a fee lower than the lowest-fee
transaction thrown out of the mempool and a priority lower than the
lowest-priority transaction thrown out of the mempool will not be
accepted into the mempool at all.  

Obvious bugs:
1) It doesnt yet do anything for minimum fee/prio when it hasnt seen at
least FEE_POLICY_TOP_N_TX (10) transactions sitting in mempool for at
least FEE_POLICY_DETERMINATION_BLOCKS (6) blocks (ie hasnt been running
for 6 blocks or blocks are being filled completely).  The likely way to
address this is to look at previous blocks and find the lowest fee/prio
transactions included in them.

2) It will relay all transactions until the mempool has filled up (or if
the mempool never fills).  Something should be done initially to limit
DoS potential.

Code is at
https://github.com/TheBlueMatt/bitcoin/commits/fees

Matt


--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Cold Signing Payment Requests

2013-04-24 Thread Jeremy Spilman
Payment Protocol uses x509 certs to sign a Payment Request. This
allows wallets to display meta-data from the cert to the payer instead
of the address, which should make it easier to verify where money is
being sent, and make it harder for an attacker to change the address
displayed to a user so that coins are not sent to the wrong place.

The difficulty is that Payment Requests must be generated live, and
therefore the key used to sign those requests must also be live,
exposing the key to theft similar to a hot wallet. Steal the key,
forge payment requests, and the payer sees a 'green box' but the coins
go to the attacker. The question... is there a way to sign something
once, with a key kept offline, which verifies the address in the
Payment Request belongs to the payee?

1) Given a 'parent' cert which is kept offline, and a child
certificate of 'parent' which is kept hot on the payment server.

2) Given a public key and chain code { pubKey, code } under BIP32 we
generate child keys as I = HMAC(code, Kpar || i), Ki = I[0:32] * Kpar.

3) If we sign Kpar with the parent cert's key offline, we can sign the
remaining less critical data (address, I[0:32], amount, description,
etc.) with the child cert's key.

4) The payer verifies Kpar, and verifies the address by calculating
Hash160(Kpar * I[0:32])

In fact, there's no requirement to use BIP32 to calculate I[0:32], it
could also just be randomly generated.

Any I[0:32] included in the Payment Request, even if it is tampered
with, will correspond to an address for which the payee can calculate
the corresponding private key.

So the idea is your 'most trusted' cert would be used offline only to
sign a Kpar once, and a 'less trusted' cert would be used to sign the
other stuff, like 'amount', 'description', 'merchant-data', and the
'I[0:32]' as well.

I'm not an expert on x509, but I imagine the trouble is, how does the
payer know which cert is which? I was originally thinking the parent
cert would be an intermediate CA cert used to sign the child cert, but
I guess good look getting one of those, even with a name constraint,
from a Root CA. I'm not sure if you can do better than just a
'convention' such as one is an EV cert and one is not. Perhaps the
less trusted cert is actually self-signed using the EV cert, but that
requires special validation, since its no longer a standard
certificate chain. I would love to hear a better idea.

Any comments if this is something worth pursuing? I think there are
definitely benefits if merchants can keep the key signing the address
offline.

Thanks,--Jeremy
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-24 Thread Alan Reiner
There's some good discussion about that here:

https://bitcointalk.org/index.php?topic=130749.msg1398972#msg1398972

thanke came up with this first, and then I reinvented it, and now you
have.  But the thread has some good discussion about how to move
forward.  I'm a big fan of putting the lower-case root hash160 in your
subdomain and getting and SSL cert for that.  Feel free to contribute to
that thread if you find it compelling.

-Alan


On 04/24/2013 07:01 PM, Jeremy Spilman wrote:
 Payment Protocol uses x509 certs to sign a Payment Request. This allows 
 wallets to display meta-data from the cert to the payer instead of the 
 address, which should make it easier to verify where money is being sent, and 
 make it harder for an attacker to change the address displayed to a user so 
 that coins are not sent to the wrong place.

 The difficulty is that Payment Requests must be generated live, and therefore 
 the key used to sign those requests must also be live, exposing the key to 
 theft similar to a hot wallet. Steal the key, forge payment requests, and the 
 payer sees a 'green box' but the coins go to the attacker. The question... is 
 there a way to sign something once, with a key kept offline, which verifies 
 the address in the Payment Request belongs to the payee?

 1) Given a 'parent' cert which is kept offline, and a child certificate of 
 'parent' which is kept hot on the payment server.

 2) Given a public key and chain code { pubKey, code } under BIP32 we generate 
 child keys as I = HMAC(code, Kpar || i), Ki = I[0:32] * Kpar.

 3) If we sign Kpar with the parent cert's key offline, we can sign the 
 remaining less critical data (address, I[0:32], amount, description, etc.) 
 with the child cert's key.

 4) The payer verifies Kpar, and verifies the address by calculating 
 Hash160(Kpar * I[0:32])

 In fact, there's no requirement to use BIP32 to calculate I[0:32], it could 
 also just be randomly generated.

 Any I[0:32] included in the Payment Request, even if it is tampered with, 
 will correspond to an address for which the payee can calculate the 
 corresponding private key.
 So the idea is your 'most trusted' cert would be used offline only to sign a 
 Kpar once, and a 'less trusted' cert would be used to sign the other stuff, 
 like 'amount', 'description', 'merchant-data', and the 'I[0:32]' as well.
 I'm not an expert on x509, but I imagine the trouble is, how does the payer 
 know which cert is which? I was originally thinking the parent cert would be 
 an intermediate CA cert used to sign the child cert, but I guess good look 
 getting one of those, even with a name constraint, from a Root CA. I'm not 
 sure if you can do better than just a 'convention' such as one is an EV cert 
 and one is not. Perhaps the less trusted cert is actually self-signed using 
 the EV cert, but that requires special validation, since its no longer a 
 standard certificate chain. I would love to hear a better idea.

 Any comments if this is something worth pursuing? I think there are 
 definitely benefits if merchants can keep the key signing the address offline.
 Thanks,
 --Jeremy


 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service 
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development