Topic: On the length of bitcoin addresses (Read 1265 times)

It really isn't that bad and hones your keyboard skills.  I can type a Bitcoin address without mistakes without looking at the keyboard well over 95% of the time, a skill that I believe has improved significantly the more I've had to do it.  I thought of publishing optimized code to auto-correct mistakes, since with 32 bits of "check" in each address, a computer can quite reliably fix even two or three typos in an address, and included trivial capabilities for that in Casascius Bitcoin Utility.  Typing in addresses is much less unfriendly if you can do it knowing that a little mistake or two will be ignored.  But of course it would be very nice if every input that accepted bitcoin addresses could also expand firstbits, or just the 8 characters, any time the expansion is available on the blockchain.

Ahh, I understand your point, and I agree that it is useful in that situation.  But eww.

I have no evidence but for some reason I thought the "addresses" called hashes have some error-correction built in. I hope they do?! to e.g. handle typos.
If they really lack this, I'd appreciate that to be fixed prior to shorten them.

Just keep in mind that Bitcoin needs to be compatible with ordinary people, not just Hero Members, and the task of entering something from a QR code for the average Joe often consists of downloading an app for his iPhone and retyping the code he sees into his computer, making the typo-proof redundancy necessary again.  It also needs to be possible to exchange Bitcoins in the absence of computers (I'm talking between trusted people of course).  I consider myself well-versed in Bitcoin and yet have gotten very accustomed to transferring addresses by hand, mainly because I use paper wallets and dedicated airgapped computers for Bitcoin just so I can depend on not getting mine stolen.  I transfer bitcoins to other people in person by handing them paper wallets, especially if I believe they will be asking me to redeem them later.

If a Bitcoin address were accepted without a check code and was scanned off a QR code and handkeyed with a typo as a sending address, it would result in a permanent loss of the funds the user was trying to transfer, which is clearly an unacceptable consequence.  It also requires the introduction of a new address format, which is a burden on users to learn, a burden on developers to implement, and saving 32 bits out of a QR code doesn't provide any practical offsetting benefit.

The communication necessary between a wallet and a node is really quite simple, if you strip it down to the bare minimum, and it is very possible to do it over JSON, or whatever.

At the bare minimum, only two calls are needed.  The first one is a way for the wallet to provide an identifier (public key, address, or whatever) and have the server return all transactions related to that account.  The second is a way for the wallet to push a transaction to the node so that the node can relay it to the network.

Note that this completely sidesteps the issue of interactive reception.  The reason for that is that I consider it a matter between the node and the ecommerce software, not between the wallet and the node.  The existence of blockexplorer.com should convince you that this problem is solvable.

On the original topic of addresses, I'm all in favor of having many means of transport.  But, we should always think carefully when adding a new format.

For example, standard addresses contain redundancy so that we can detect errors when someone types them in, or does a copy and paste.  The specification for QR codes also contains ECC, so it makes no sense to encode a standard address as a string in QR.  We would be better off encoding only the address part, and leaving the check code out.

I also think that firstbits is a bit silly, because I've never typed an address, and I don't think I ever will.  It also throws away the check information, which is funny because it was allegedly designed for typing addresses by hand.  But, I suppose in a way, it has a different means of verifying typing errors in that not every string is necessarily valid.  And as far as you know, no one has sent themselves a bunch of transactions that just happen to resolve to common misspellings of valid firstbits addresses. 

I agree with you - but I would propose that if you want instantaneous acknowledgement of incoming blocks, just implement a subset of the existing peer-to-peer protocol, connect as though you were a peer, send the bare minimum necessary to keep the connection alive, and then watch for events of interest.  The architecture pretty much already exists.

This isn't enough. The communication between wallet-handler and block-chain&network handler will require two-way communications. Obviously wallet-handler submits various queries to the block-chain handler. But the block-chain handler needs to be able to make callbacks to all interested wallet-handlers. The callbacks can be distilled to one: the blockchain was externded by a positive or negative number of blocks. Positive extension indicates normal operation. Negative extension indicates chain reorganization. The callback could pass an array of relevant Merkle roots or some such.

The main thing about the above requirement is that JSON-RPC is not a good tool for a two way communication. Neither is XML-RPC, SOAP or some other popular candidates. This is a serious question of software architecture.

And Gavin,

(perhaps this should be separated into a new thread called "on the separating of bitcoind from the wallet and UI")

I have mentioned a lot of things that would be cool to have in the UI, but I also recognize how this only makes your plate more and more full.  I think what you ought to consider doing is separating the fundamentals of "bitcoind" into the daemon you maintain, and let the community write the UI and the wallet management for all the various platforms.

In other words, have bitcoind do nothing but talk on the P2P network, validate transactions, keep the local block chain copy up-to-date, generate getworks for miners, and most importantly two new RPC functions for UI's: forward signed transactions to the network from the UI, and allow UI to query the daemon for unspent transactions given a list of addresses.

By separating the wallet, this frees you from having to worry about wallet encryption.  The only reason bitcoind would need a wallet would be to accept the proceeds of mining (and perhaps for limited purposes contemplated by developers, such as a "system wallet" when it's a web server etc.).  The average joe user would not use the system wallet.

With this separation of functions, the UI would manage the wallet and sign transactions, and different UI's could secure them in different ways.  Some UI apps would keep private keys on the hard drive, others might keep them offline and require the user to enter them or otherwise supply them to do a transaction (e.g. from a paper wallet, a smartcard, a flash drive, a web service, you name it).  While bitcoind would be platform neutral, you'd find UI's written to be platform specific and written by people more comfortable with their favorite OS, so they look and feel and operate natively like other apps for the same OS.

By decreasing the size of the bitcoind codebase, you have less to oversee when it comes to deciding what patches and changes to accept.  Someone makes a UI change, you don't need to be concerned if it introduces a new vulnerability into bitcoind.

These two RPC calls I suggested...they'd be huge! for the ability for someone to write their own UI without having to re-invent the bitcoind process from scratch in the environment of their choice.

There is pretty much already a way to do that in a de-facto sense.  Simply send the person a message with a throwaway PGP-encrypted Bitcoin private key encumbering the exact balance to be transferred, and allow them to import it.  Call it a "bitcoin cheque".  The transaction is complete when that balance is spent to a new address generated by the recipient.  (unorthodox: If the bitcoin UI had limited ability to issue PGP keys and directly decode PGP-encrypted cheques, it would be average joe friendly for the joe who doesn't normally use gpg, etc.).

Without a central authority to oversee that you are actually the owner of your address, and without reliance on your ability to receive or decrypt a message sent to you, there's simply no way to make sure I don't steal the alias "[email protected]" before you get to it.  Or "[email protected]" or whatever.  And if receiving such a payment depends on a registry somewhere (blockchain or otherwise), the payments you receive are now un-anonymous.  On the other hand, receiving a private key in e-mail preserves your anonymity.

The idea of "firstbits" is probably one of the cleanest address shortening ideas there is.  When expansion is based on the first occurrence in the block chain, it's completely decentralized and deterministic.  If the client could natively expand firstbits from the database, I'm "1bowser" and that's very user friendly.  And on the other hand, if you allow firstbits as handles to addresses already available in the blockchain, you really could have crazy long addresses anywhere they were useful, because the user would never actually have to type them.

My worry is that we'll schedule a blockchain split 6 months from now, and between now and then somebody implements a secure, way-cool, everybody-decides-to-use, way to use your email address as a bitcoin address.

So my receiving address is '[email protected]' and suddenly all the arguing over length of the bitcoin addresses used behind the scenes was just a huge waste of time.

I'm as guilty of doing stuff like that as the next geek-- I can get so focused on one little bit of a problem I don't even realize solving a larger problem makes the whole issue go away.  Slap me upside the head if you see me going down that path...

This is an unsafe assumption in userland.  I have personally typed out hundreds of key codes. QR codes grow larger and denser and require increasingly better reading conditions the more bytes you stuff in them and I don't even know how to go straight from QR to my computer's clipboard without typing.  If the potential of typing them is something "nobody" does, why were they made short to begin with?  Why ripemd160?  Why bother making sure to avoid 0/O/I/l?  Why not just have encoded the entire public key in PEM format and pass them around as blocks of base64-encoded text?  The public already thinks we're silly for having such long addresses as it is, but it's unavoidable because the entropy must be there for them to be secure.  Longer addresses will definitely inhibit the adoption of bitcoin by the public and should be high on the list of things to avoid.