Re: [Bitcoin-development] [BIP 15] Aliases
On Sunday, December 18, 2011 8:14:20 PM Pieter Wuille wrote: Furthermore, the embedded bitcoin address could be hidden from the user: retrieved when first connecting, and stored together with the URI in an address book. Like ssh, it could warn the user if the key changes (which wil be ignored by most users anyway, but what do you do about that?) Like SSH, don't make it easy to ignore. eg, to ignore it, you need to manually go in and remove it from the URI. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
Pieter, it was more rhetorical question than asking for explanation, but thanks anyway. As an Internet application developer, I of course understand security issues while using HTTPS and CA. I have a gut feeling that there simply does not exist any single solution which is both easy to use and secure enough. At least nobody mentioned it yet. And if I need to choose between easy solution or secure solution for aliases, I'll pick that easy one. I mean - we need some solution which will be easy enough for daily use; it is something what we currently don't have. But if I want to be really really sure I'm using correct destination for paying $1mil for a house, I can every time ask for real bitcoin addresses, this is that secure way which we currently have. slush On Mon, Dec 19, 2011 at 2:14 AM, Pieter Wuille pieter.wui...@gmail.comwrote: On Mon, Dec 19, 2011 at 12:58:37AM +0100, slush wrote: Maybe I'm retarded, but where's the point in providing alliases containing yet another hash in URL? Any DNS-based alias system is vulnerable to spoofing. If I can make people's DNS server believe that mining.cz points to my IP, I'll receive payments to you... If no trusted CA is used to authenticate the communication, there is no way to be sure the one you are asking how to pay, is the person you want to pay. Therefore, one solution is to put a bitcoin address in the identification string itself, and requiring SSL communication authenticated using the respective key. This makes the identification strings obviously less useful as aliases, but pure aliases in the sense of human-typable strings have imho limited usefulness anyway - in most cases these identification strings will be communicated through other electronic means anyway. Furthermore, the embedded bitcoin address could be hidden from the user: retrieved when first connecting, and stored together with the URI in an address book. Like ssh, it could warn the user if the key changes (which wil be ignored by most users anyway, but what do you do about that?) -- Pieter -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
On 2011 December 16 Friday, Rick Wesson wrote: I believe that any URI scheme will still leverage DNS and inherit any base issues you would have with TXT records. I suggest looking at DANE HTTPS takes care of that. and reviewing their work on hardening certificate (x.509) infrastructure as your HTTPS scheme will inherit the issues we currently experience with CAs getting p0wned. This is the only real problem with HTTPS: we would be centralising part of our otherwise decentralised system. CAs are certainly a risk. However, trust is needed somewhere in the communication. There is no way to securely communicate between A and B without the use of some previously trusted secure channel -- in Joe Sixpack's case it's by assuming that the browser he downloaded came with an untainted CA list, and that the CAs are trustworthy. Neither of which is guaranteed. Until and unless we get PGP support in browsers, CAs are all that we have. Worrying about CAs misses the point anyway; if we're being that paranoid -- how did A tell B the appropriate alias to use for a lookup? Was that channel secure too? I could set up a MITM server that simply looks for the alias rickwes...@bitcoinaliases.org and rewrites it to andypark...@bitcoinaliases.org. When the answer to that problem is HTTPS (or some other system that requires a previously authorised secure channel for transfer of trust), then we're back where we started, and HTTPS is acceptable. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
On Fri, Dec 16, 2011 at 21:10, Amir Taaki zgen...@yahoo.com wrote: Especially when we already have bitcoin addresses with their own checksums- what value do IBANs add? Well, I'm not an expert like you, but one benefit would be to be compatible with existing software solutions that are based on using IBANs. H -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
On Fri, Dec 16, 2011 at 1:52 PM, Khalahan k...@dot-bit.org wrote: The number of proposals is not infinite, here are their problems : - FirstBits : centralized - DNS TXT Records : DNSSEC is required to have a minimum of security, limits usage to engineers, limits usage to some domain names (i won't be able to use a gmail address for example, because i don't control the gmail.com domain) The same goes for http(s) one would not be able to use http://google.com/user unless google offers the services. ALSO look at DANE for getting around the certificate requirement for https - Server Service (DNS + a daemon) : Same as DNS TXT records DNS TXT are not the only way forward, also registry/registrars can facilitate. - HTTPS Web service : relies on HTTPS and CA, bitcoin needs to be able to check the full certificate chain and access a list of up-to-date certificate authorities (installed on the OS or provided with bitcoin). And don't forget the CA model is not 100% reliable (several CA hacked this year + possible government control...). This most likely relies on a paid, valid certificate (that expires), no self signed certs. I admit that running a secured https server with a valid CA signed cet is as simple/hard as running a DNSSEC authority zone. using a x.509 certificate to secure a bitcoin transaction removes some of the anonymity of the transaction by allowing the lookup to identify the certification, ca, crl etc thus connecting a transaction/bitcoin address to the cert and to its issuing authority. No matter the frequency of the destination bitcoin address changing. IMNSHO, leveraging CAs to secure http to provide a lookup translation to a bitcoin address will only erode anonymity. While DNS is connected to whois there are provision for hiding behind a proxy where to the best of my knowledge there are no such provisions offered by CA's issuing x.509 certificates. Should self signed cers be allowed or encouraged only decreases security. Clearly DANE would be the only way to mitigate this situation but then you are back to relying on DNSSEC to bind the x.509 cert. wash, rinse, ... -rick - IP Transactions : This proposal seeks to enable DNS lookups for IP transactions = same as above I know that providing a namecoin daemon with bitcoin is not the lighter solution, but, if a better one existed i guess it would have already been integrated into bitcoin... (see in what state is my first attempt with the HTTPS proposal : Send payments to emails, urls and domains in GUI - khalahan opened this pull request April 20, 2011) So, what's next ? Le 16/12/2011 20:54, slush a écrit : Khalahan, honestly, using namecoin for aliases is (for me) clean example of over-engineering. I mean - it will definitely work if implemented properly. I played with a namecoin a bit (as my pool was the first 'big' pool supporting merged mining), but I think there's really long way to provide such alias system in namecoin and *cleanly integrate it with bitcoin*. Don't forget that people who want to do lookup need to maintain also namecoin blockchain with their bitcoin client. It goes against my instinct of keeping stuff easy. For example, yesterday I implemented HTTPS lookup for addresses into my fork of Electrum client. I did it in 15 minutes, it works as expected, it does the job and the implementation is really transparent, becuase implementation is 20 lines of code. There's no magic transformation, no forced ?handle= parameters or whatever. And I don't care if somebody provide URL https://some.strange.domain/name-of-my-dog?myhandle=5678iopanything_else=True And everybody can do the same in their clients, in their merchant solutions, websites or whatever. Everybody can do HTTPS lookup. But try to explain DNS, Namecoin, IIBAN, email aliases to other programmers... Those IIBAN - well, why not. At least I see the potential in PR. So far I understand it as some teoretic concept which is not supported by anything else right now. Give it few years until it matures and then add IIBAN alias to Bitcoin client too. Maybe I'm repeating myself already, but the way to go is to make aliases as easy as possible, so everybody can implement it in their own solution and thus practially remove the need of using standard bitcoin addresses for normal users. Using some superior technology, which is hard to implement or even understand won't solve the situation, because it will ends up with some reference implementation in standard client only and nobody else will use it. slush -- Best Regards, Khalahan http://dot-bit.org/ -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at
Re: [Bitcoin-development] [BIP 15] Aliases
This is maybe the best idea. I added it: https://en.bitcoin.it/wiki/BIP_0015#IP_Transactions Things I like about this: - IP transactions are useful, but have a security flaw. This mitigates their security problems. - The code for IP transactions is already in Satoshi client. If other clients want to add IP transactions, then it can be done with minimal fuss/bloat. I feel that for any protocol extension, less is more. The less code needed, the better the extension. Not always but generally we want to avoid bitcoin protocol bloat which *will* happen far in the future. The only way to mitigate how spaghettified the standard will be in the future, is by careful cautious planning now. - We can have a proxy node running 24/7 for us, serving our public keys in lieu of us. From: theymos they...@mm.st To: bitcoin-development@lists.sourceforge.net Sent: Thursday, December 15, 2011 7:59 PM Subject: Re: [Bitcoin-development] [BIP 15] Aliases Bitcoin already has code and a protocol for transactions to IP addresses. Why not reuse that for dynamic address lookup? Just a few changes are necessary to enable complete u...@server.com handling: - Extend the protocol so that reply messages can be signed by a fixed public key - Extend checkorder messages so they can specify an account to send BTC to. Or standardize on how to put the account into the message field. - Enable DNS lookups for IP transactions. The DNS-only proposals could also be used here to avoid having to use the IP transaction protocol sometimes. The public key for signing reply messages can be gotten from TXT records. This will be safe with DNSSEC and Namecoin. With plain DNS Bitcoin could take a SSH-like approach and ask the user to verify the public key the first time it is used, remembering it later. DoS attacks are already handled by the IP transactions code: the same IP address is always given the same bitcoin address until it pays to that bitcoin address. -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development-- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
This is the first proposal I've seen regarding mapping something like user@host that actually makes sense to me. Bitcoin itself is decentralised by design, in my opinion it seems obvious that it needs to continue to maintain this feature. On Fri, Dec 16, 2011 at 8:59 AM, theymos they...@mm.st wrote: Bitcoin already has code and a protocol for transactions to IP addresses. Why not reuse that for dynamic address lookup? Just a few changes are necessary to enable complete u...@server.com handling: - Extend the protocol so that reply messages can be signed by a fixed public key - Extend checkorder messages so they can specify an account to send BTC to. Or standardize on how to put the account into the message field. - Enable DNS lookups for IP transactions. The DNS-only proposals could also be used here to avoid having to use the IP transaction protocol sometimes. The public key for signing reply messages can be gotten from TXT records. This will be safe with DNSSEC and Namecoin. With plain DNS Bitcoin could take a SSH-like approach and ask the user to verify the public key the first time it is used, remembering it later. DoS attacks are already handled by the IP transactions code: the same IP address is always given the same bitcoin address until it pays to that bitcoin address. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
On Thu, 2011-12-15 at 13:59 -0600, theymos wrote: Bitcoin already has code and a protocol for transactions to IP addresses. Why not reuse that for dynamic address lookup? Just a few changes are necessary to enable complete u...@server.com handling: I'm not against this, but I think its way overcomplicated when compared to the DNS or HTTPS methods. - Extend the protocol so that reply messages can be signed by a fixed public key - Extend checkorder messages so they can specify an account to send BTC to. Or standardize on how to put the account into the message field. OK, not too debatable, but considering how terrible bitcoind's account handling is, the second might not be easy to get right... - Enable DNS lookups for IP transactions. The DNS-only proposals could also be used here to avoid having to use the IP transaction protocol sometimes. The public key for signing reply messages can be gotten from TXT records. This will be safe with DNSSEC and Namecoin. With plain DNS Bitcoin could take a SSH-like approach and ask the user to verify the public key the first time it is used, remembering it later. This is where I think this method becomes way overcomplicated. Not only do you have to update the IP-Transaction code, but now you have to implement the full DNS System that is the other option as well. Note that to make this secure, we have to have a full DNSSEC-capable resolver built-into bitcoind (there are libs, but it has to happen). Yes you can ask the user does this fingerprint look right to you? Y/N but that always opens you up to a ton of users getting screwed out of coins and I don't think it should be enabled, except in bitcoind, and since the main target of this whole alias system is bitcoin-qt users, well... Matt -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
Bitcoin itself is decentralised by design, in my opinion it seems obvious
that it needs to continue to maintain this feature.
What's the real issue?
- People want to use alternate representations ('aliases') of bitcoin
addresses, for various reasons.
- The blockchain is the only way to create distributed consensus
within the bitcoin network.
- Very few people - even those who wish to have a permanent alias -
want to have it map to a permanent bitcoin address, since this
discloses their financial history (eg: income for a business) to the
public
- Some people want throw-away (single use) aliases, others want
permanent ones. This means many addresses.
- Blockchain bloat is already acknowledged as an issue.
- The blockchain is not really a good option.
Leaving out the blockchain, there are still ways to implement aliasing.
What is the core problem for an extra-blockchain aliasing system?
At the core is usability - people basically want aliases to make it
easier to type in or remember addresses. So a solution that
sacrifices usability too far is a broken one.
Another requirement is absolute security. A user of the aliasing
system is going to trust it to translate a particular alias to a
bitcoin address - ie: 'where my money goes with absolutely zero chance
(by default) of getting it back if it's sent somewhere wrong by
accident'. Such an accident might be mistyping an alias. It might
also be a hijacking of the alias resolution system (eg: a DNS based
system without DNSSEC, etc.). As a case in point, we already see very
well organized attacks by domain squatters in order to steal traffic
or effect phishing under the DNS system.
So... to help see which qualities are meaningful for such an alias
system, let's look at what types of solutions to these problems exist
within conventional (ie: mature) financial systems.
First, arbitrary aliases are not in use. This means that memory-based
mnemonics are not subject to predictable squatting-style attacks. For
our purposes, this means that if you are payme...@business1.com, I
can't go and register payme...@busines1.com and take a portion of your
inbound cash whenever a client tries to pay you and typos on the send
address. Likewise, if you're 'someu...@hostedwalletservice.com' I
can't go and register as 'some...@hostedwalletservice.com' and pull
the same heist. IIBAN is the only aliasing proposal I have seen
mentioned within this thread that adopts this strategy, the others all
maintain this vulnerability through DNS. HTTP relies on DNS.
Second, checksum systems detect transposition errors. This is a very
powerful feature, which (I can't be bothered googling for stats, but
just think about it) cuts out the vast majority of such errors
instantly, at the time of input, before money changes hands or
anything touches the financial settlement networks. IIBAN adopts
exactly the same mature and proven MOD97-based two digit checksum
feature that is used within the IBAN standard, proposed by the
European Union with the benefit of decades of banking experience in
many member states and now growing rapidly in use around the world.
(For something as expensive and painful to implement as a
nationally-mandated banking standard affecting all member banks, a
growth rate of 'a few countries per year' is a pretty serious growth
curve!) With checksums, it's even possible to auto-suggest
corrections based upon common transposition errors and help the user
to check those parts of the alias for common errors more quickly.
Third, conventional financial systems typically require recipient name
(and sometimes address, or business tax numbers in some countries'
domestic schemes) as part of the transaction. This secondary data
facilitates error checking since an incorrectly supplied destination
address can be checked against these properties. Of course, Bitcoin
presently has no such secondary input with which to verify the
destination of a transfer, and since blockchain bloat is an
acknowledged issue and very few bitcoin users would like to see their
names appear against their transactions within the blockchain (visible
to all, for eternity!) it also seems that this feature is not going to
be added and for good reason. However, within an external (and not
necessarily bitcoin specific) higher-level 'transaction negotation'
protocol (alluded to in earlier posts as a logical extension of the
pre transaction alias resolution mechanism, and being a pre
transaction connection of some nature between a payer and payee, or
their proxying/representing institution, in the case of hosted
wallets/aliases), such external destination validation features could
be added. (Many types are possible... data-based as per name/address
validation, cryptographic validation schemes, etc.)
Finally, an increasing number of countries use an aliasing scheme
(IBAN) that is familiar to users. Doing so for digital currencies
such as Bitcoin increases usability (by eliminating novelty, and in
Re: [Bitcoin-development] [BIP 15] Aliases
FirstBits looks nice at glance, but is bound to create a gold-rush to grab every nice-looking FirstBits address. HTTPS is only as secure as the (centralized) CAs, thus not really any better than TXT records. I don't think an address of some form is avoidable. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
I don't think Amir wants to put it into the protocol, but I still don't like much the proposal if it has to rely on servers. As an aside, even if firstbits it's not useful enough for the human memory, it is still useful for QR-codes like in the case of green addresses's POS instant payments. Would it be too strange to use namecoin? Some devices may need to rely on block exploring servers, but it is the easiest decentralized solution that comes to mind. 2011/12/13, Zell Faze zellf...@yahoo.com: I agree with Luke-Jr. We need to try to find a decentralized solution if we are going to implement BIP 15. Bitcoin needs to remain decentralized in every aspect of the protocol or we lose its greatest strength. I feel like the HTTPS idea would be a great idea for a client feature, but not really something that should be added to the protocol. --- On Mon, 12/12/11, Luke-Jr l...@dashjr.org wrote: From: Luke-Jr l...@dashjr.org Subject: Re: [Bitcoin-development] [BIP 15] Aliases To: bitcoin-development@lists.sourceforge.net, Amir Taaki zgen...@yahoo.com Date: Monday, December 12, 2011, 5:32 PM FirstBits looks nice at glance, but is bound to create a gold-rush to grab every nice-looking FirstBits address. HTTPS is only as secure as the (centralized) CAs, thus not really any better than TXT records. I don't think an address of some form is avoidable. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jorge Timón -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
On Monday, December 12, 2011 6:37:56 PM Jorge Timón wrote: Would it be too strange to use namecoin? This has the same problem as FirstBits, except .bit domains are dirt cheap, whereas vanitygen at least slows down grabbing all the common words... -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
Are there any PGP key servers that support EC key pairs? OpenPGP Spec RFC2440 defines key types for EC, just not sure if they were ever implemented on the keyserver side. Could even have a similar 'web of trust' using private keys to sign people's identities similar to PGP. Will On 12 December 2011 23:16, Zell Faze zellf...@yahoo.com wrote: I agree with Luke-Jr. We need to try to find a decentralized solution if we are going to implement BIP 15. Bitcoin needs to remain decentralized in every aspect of the protocol or we lose its greatest strength. I feel like the HTTPS idea would be a great idea for a client feature, but not really something that should be added to the protocol. --- On Mon, 12/12/11, Luke-Jr l...@dashjr.org wrote: From: Luke-Jr l...@dashjr.org Subject: Re: [Bitcoin-development] [BIP 15] Aliases To: bitcoin-development@lists.sourceforge.net, Amir Taaki zgen...@yahoo.com Date: Monday, December 12, 2011, 5:32 PM FirstBits looks nice at glance, but is bound to create a gold-rush to grab every nice-looking FirstBits address. HTTPS is only as secure as the (centralized) CAs, thus not really any better than TXT records. I don't think an address of some form is avoidable. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
