Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Why don't just...
bitcoin://url.without.explicitly.specifying.provider
bitcoin://alias@provider
bitcoin://IIBAN@authorizedBitcoinInstitution ??
Andy sounded very convincing when talking in favor of URLs. What's
wrong with his proposal?
A URI identifies a resource and is in effect an alias itself.
Identifying a resource is different from interacting with it. So,
while resource-type://resource-type-specific-alias will work
sufficiently for the identification, it does not explain the
interaction.
Interaction is a requirement, since there seems to be a widely felt
need to preserve anonymity through the use of temporary addresses.
Generating a temporary address requires some actual processing to
achieve, since the issuing of the new address cannot be done without
interacting with the entity hosting the wallet (unless I'm missing
something?).
By the way, I don't like the fact that a single authorized institution
needs to map the IIBANs to bitcoin addresses.
This is not the case. Please read my earlier response to Gavin and the
IIBAN specification itself to clarify. That would be a total breach
of privacy since the entity would have access to financial information
on all transactions using the IIBAN identifiers... prior to
transactions being executed.
It *is* true that under the current IIBAN proposal there would be one
entity (IANA) in charge of issuing namespace portions ('institution
codes' - probably best to rename these...), however:
- The policy is strict and something similar to 'give one out to
anyone except existing financial instutions with the pre-existing
capacity to issue IBAN'.
- IANA have a pretty reasonable track record
- This suggestion, like the entire proposal, is open for discussion
and modification. If you can think of a more efficient and fair way
of assigning namespace prefixes to random entities on the internet
that doesn't require someone *without* an established track record of
doing this for the internet community to take up IANA's place, then
I'd be happy to hear it. Whilst a bitcoin-like 'community consensus'
system is conceivably possible to deploy in its place, I don't think
it's necessary.
Regards,
Walter Stanish
Payward, Inc.
--
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] Fwd: [BIP 15] Aliases
On 2011 December 15 Thursday, Walter Stanish wrote: Andy sounded very convincing when talking in favor of URLs. What's wrong with his proposal? A URI identifies a resource and is in effect an alias itself. Identifying a resource is different from interacting with it. So, while resource-type://resource-type-specific-alias will work sufficiently for the identification, it does not explain the interaction. Quite so; the BIP15 standard shouldn't be setting the format of the URI; it should be setting what the format of the client-server conversation is. Effectively, what headers will a requesting client send? What headers should a server require? What will a server respond? Interaction is a requirement, since there seems to be a widely felt need to preserve anonymity through the use of temporary addresses. I think that's missing the point; any aliasing scheme is definitely reducing your anonymity, neccessarily so -- the alias has to be looked up somewhere, that somewhere reduces anonymity. If anonymity is what you want, stick with just a bitcoin address. The point of an aliasing server is surely to be able to give a single, unchanging, well known label to a transacting party, but still enable that party to generate a new address per transaction. I want my webshop to be able to say please pay 3.20 BTC to https://mywebshop.com/payments/orderid=27282; to enable the automatic connection from orderid to bitcoin address (which my payment system can then monitor for payment receipt). (This is just one example). Generating a temporary address requires some actual processing to achieve, since the issuing of the new address cannot be done without interacting with the entity hosting the wallet (unless I'm missing something?). Well yes; but then the client has no idea what address to send to unless it connects to that URI... interaction/address generation is done when that connection is made. In short: I don't really think that this aliasing system should be concerning itself with preserving anonymity of the receiving party. That is almost certainly already gone (I'm hardly likely to send money to someone I don't know unless I like gifting random cash). The sending party loses a little anonymity because their IP is revealed when they connect to the aliasing system. But there is very little anonymity in a supplier-client relationship anyway (you have to say what goods you want, and where you want them, and you had to interact with a website when you were ordering already). Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- 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] Fwd: [BIP 15] Aliases
2011/12/15, Walter Stanish wal...@stani.sh:
Interaction is a requirement, since there seems to be a widely felt
need to preserve anonymity through the use of temporary addresses.
Generating a temporary address requires some actual processing to
achieve, since the issuing of the new address cannot be done without
interacting with the entity hosting the wallet (unless I'm missing
something?).
I thought the interaction was just the server answering with an
address (maybe also amount and other details). But we don't have to
define how the server will get that address.
Some possibilities:
-A static address: less anonymity, but some people may not care. Say a
donation address.
-The servers stores the recipient private keys and generates a new one
for each payment.
-The server stores a set of addresses provided by the recipient and it
manages what address it gives in each request (like in the web service
I told you I can't find).
It *is* true that under the current IIBAN proposal there would be one
entity (IANA) in charge of issuing namespace portions ('institution
codes' - probably best to rename these...), however:
...
IANA reserves some namespace for bitcoin. All right.
The problem comes later.
* Systems such as [BITCOIN] have quirks that require slightly
delayed settlement due to the nature of their decentralized,
consensus-based approach to fiscal transfer. Users requiring
instant settlement MAY thus see benefit in the use of a
centralized proxy system or organization as an instantaneous
financial settlement provider (the 'institution').
As I understand it (probably I'm wrong, because I haven't read the
whole IIBAN draft) there would be a bitcoin institution that would
map bitcoin addresses to the bitcoin subspace of the IIBAN.
* IANA MAY delegate management of portions of the IIBAN name space
through such institutions.
If we can find a deterministic method to map the subspace the all
possible bitcoin addresses, everything's fine again. But if that's not
possible, we would need a central institution to manage the mapping
and that would be a step back in decentralization.
I can't find the answer of Gavin's question How is the mapping done?
in your post. I'll re-read it though.
--
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] Fwd: [BIP 15] Aliases
Why don't just... bitcoin://url.without.explicitly.specifying.provider bitcoin://alias@provider bitcoin://IIBAN@authorizedBitcoinInstitution ?? By the way, I don't like the fact that a single authorized institution needs to map the IIBANs to bitcoin addresses. The IANA is a good institution to rely on for mapping things, much history and wise execution there. -rick -- 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
[Bitcoin-development] CDataStream
OK, I admit that this is *really* of little importance... But could someone with commit rights please update the CDataStream test table in the code. The arguments for the custom stream are just way off (stringstream wins by factor 10-20!). On OS X (g++) I get: Further, if you get(got) bad stringstream numbers on e.g. windows (dikumware had some issues several years ago) you can improve just by changing the default allocation chunk size. So... speed is not a reason for reimplementing stringstream. (And perhaps this can motivate someone to revert bitcoin to stringstream ;-) Cheers, Michael PS: Could be fun to see the output on other OS'es ! serialize.h (with TESTCDATASTREAM defined, i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)): CDataStream: n=1000 0 seconds n=2000 0 seconds n=4000 0 seconds n=8000 0 seconds n=16000 0 seconds n=32000 0 seconds n=64000 1 seconds n=128000 1 seconds n=256000 2 seconds n=512000 4 seconds n=10240008 seconds n=204800017 seconds n=409600040 seconds stringstream: n=1000 0 seconds n=2000 0 seconds n=4000 0 seconds n=8000 0 seconds n=16000 0 seconds n=32000 0 seconds n=64000 0 seconds n=128000 0 seconds n=256000 0 seconds n=512000 0 seconds n=10240000 seconds n=20480001 seconds n=40960002 seconds -- 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 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] Fwd: [BIP 15] Aliases
I really like this proposal with standard URLs. All other proposals like DNS mapping or email aliases converted to URLs with some weird logic looks strange to me. Plain URLs (returning address in response body, redirecting to URI bitcoin:address or anything else) are very clear solution, easy to implement in clients and very easy to understand by people. It's also extremely flexible - almost everybody can somewhere setup static file containing his personal addresses or it's very easy to integrate such solution with eshops (providing custom address for given order) etc. I'm definitely for this solution. Best, slush On Tue, Dec 13, 2011 at 5:22 PM, Andy Parkins andypark...@gmail.com wrote: On 2011 December 13 Tuesday, Amir Taaki wrote: Maybe I wasn't clear enough in the document, but this is the intent with the HTTPS proposal. I don't like the idea of a hard-coded mapping at all. We shouldn't be making choices on behalf of server operators. It's up to them how they arrange their domain names and paths. I also agree that DNS is not the technology to use. DNS is a nightmare. gen...@foo.org Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system responds with a bitcoin address. Whether the system gives you a new address from a pool of addresses, or contacts the merchant behind the scenes is implementation defined. I'll clarify it later. This is the relevant line: string strRequestUrl = strDomain + /bitcoin-alias/?handle= + pszEncodedNick; Between HTTPS service and server service, I lean slightly towards HTTPS (automatic encrypted connection, CAs + all benefits of DNS). But still interested in arguments in favour of a server service (daemon answering queries). Why bother with an encoding scheme at all? If the address gen...@foo.org always maps to https://foo.org/bitcoin-alias/?handle=genjix Then forget the hardcoding of https the hardcoding of bitcoin-alias and ?handle= and the original email-looking gen...@foo.org. Just use the URL. Then the author of the service can use whatever they want. Can I pay you 10 BTC? Sure, send it to 'https://bitcoinalias.foo.org/genjix/' While I might implement my alias server like this: Sure, send it to 'https://google.com/bitcoin/?andyparkins' Sure, send it to 'https://parkins.co.uk/; ... or any other URL they want -- any of which suit might suit me and my webserver better than whatever mapping would otherwise be hard-coded. The world is already very familiar with URLs so this is no more scary than the email address. What's more, the email address form looks _too much_ like an email address, and will only lead to confusion ... send it to gen...@foo.org so I use outlook express for that, right? erm, no, you put it in your bitcoin client. The URL form could easily be made to detect a browser connecting rather than a bitcoin client (and this is an area that would benefit from a standards document -- define the headers and user agent triggers that an alias server expects) and give them better instructions. https can be specified as the default, so https://; can be optional when they're typing. If, in the future, bitcoin gets a distributed peer-to-peer alias system, then a new URL type can be added easily bcalias://andyparkins might automatically find my node in the network and query it for an address (or whatever). All of the above is exactly why OpenID chose to use URLs for ID. Andy -- Dr Andy Parkins andypark...@gmail.com -- 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 -- 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
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
