Topic: FirstBits.com - remember and share Bitcoin addresses - page 5. (Read 26262 times)

We will post the code soon.

I don't plan to change the algorithm called firstbits at all even though there are no other implementations that I know of.

It's a neat idea (decentralized transferable aliases), but I like the purity and intuitiveness of firstbits. It would be strange to call something "firstbits" if 1mike7 returned 1jkaF92... I think you should work on your idea, but maybe find another way to encode aliases in the chain. It seems like it would be ideal to be able to pick any conforming alias and associate it with your address via some transaction. Then the rule would be the first to make a valid claiming tx gets the requested alias.

A (probably bad) example would be send 11 satoshis to an address then send any amount within 100 blocks and that amount is your alias. You could convert the number to whatever base is all lowercase or lowercase and numbers or whatever. If anyone ever tried to make the same claim it would just be ignored, only the first would count.

To be clear, I am in favor of other people making other systems, just not calling them firstbits. Anything calling itself firstbits should use our exact algorithm and opening the code will help people do that.

I think that is why he proposes it be added in to the "official" site early on, so it becomes part of the standard of rules that everyone uses.

But FreeMoney speaks the truth - it would take away from ALWAYS being able to identify the proper firstbits, no matter the site.  If transfers were allowed/implemented into the official site, but another clone site implemented only the basic firstbits technique, without adding in the algorithm for checking whether an address has been transferred, then the firstbits would be confused and owned by the wrong person on that clone site.  Sure, it would be the fault of the clone site for not implementing the full algorithm, but it would still return a valid-looking address, and it would devalue the purpose of having a firstbits address in the first place if no one can trust that they are getting the right address out of it.

I understand that everyone can implement a website (or client) with your rules. But another website can decide on their own rules on how to "transfer" an address. Since your rules won't be as simple as FirstBits, it will be hard for people to just accept it. As a user, I will just use payb.tc instead of paying someone for an address that only makes sense by your rules. Know what I mean?

Hi coblee.

I'm afraid you don't seem to have understood my proposal. The trade involves no third party and everything is still decentralised. The nice property that anyone can implement a website (or client) that provides the exact same service is retained. The only thing that changes is that it becomes possible, but not required, to sell or gift your alias or buy one from someone else. If you don't sell your alias, then it won't ever change.

H

hannesnaude, although your idea is interesting, I can't see it becoming popular. FirstBits has a nice property of never changing and that anyone can implement a website that provides the exact same service. The fact that a shortened address can change according to your rules makes it such that your are the sole controller of what's "right", of which shortened address points to which public address. In a sense, your service will be no different than a shortener that lets you pick a short vanity address. Why would anyone pay someone else for their shortened address via your service when they can just get their own vanity address here? http://payb.tc/

Cool. I thought it would still be early enough to make non-breaking changes to the algorithm (are there allready many other implementations out there?) and didn't think you would be in favour of other flavours of the firstbits idea due to the risk of confusion that you mention.

But if you are not opposed to the idea, I think I might have a go at coding a transferable decentralised address alias. Might I push my luck and ask if you would be willing to opensource the firstbits code? Would make a really nice starting point. 

Interesting ideas hannesnaude. I worry about some people implementing the change and some people using the 'pure' system. Calling it something else would help avoid confusion. It's also possible to make a system use something other than the beginning of an address. The end of address is obvious, but other things would work. A (probably bad) example would be to use the block number plus number of the transaction (listed by id, or alphabetically?) so Satoshi's addresses in the gen block that has a firstbits of "1" would have a BlockRankNumber of 1-1 and the second address in the most recent block would be 137009-2. This would probably lead to people packing blocks with even numbers 140000-1 might be a coveted spot, lol. Sorry, this is off your point, just wanted to say that there is room for a lot of different shortening methods. Flavors of firstbits are fine, but confusion would be really bad for the original and for spin offs.

I believe he is called Satoshi  . As pointed out before on this thread, that's the firstbits address of the wallet that received the coinbase payment from the genesis block. If you could transfer wallets, that would be a valuable one indeed for collectors, akin to the first dollar ever printed.

I've thought about my own proposal for signalling transfer of a firstbits alias a little more and realised a couple of things. It's not required to burn any money in order to generate a unique signaling transaction. Something as simple as inserting a NOP instruction into the pubkey script would make it distinguishable from an ordinary payment without making it impossible to spend the output. A better solution would be to use the OP_DROP instruction and include some data that indicates that this is a transfer.

Even though it is possible to do this without burning money, it may still be better to structure the tx in such a way that the output can't ever be spent, but not for the reason I thought before. The real reason is that if the output is spent, then future versions of the client may well prune this tx from the blockchain, eradicating all record of the transfer and causing the alias to revert to its original owner.

In addition, the proposed scheme effectively only verifies that the current owner of the alias is willing to transfer it, but not that the new owner is willing to receive it. You would be unhappy if 1pervert suddenly started resolving to your publicly known donation address.

So, my updated suggestion is as follows.

The buyer and seller of the alias agree on the price. The buyer then generates a normal payment tx for the agreed amount with some additional data inserted in the pubkey script using OP_DROP, marking it as an alias request. He does not yet transmit the tx on the network, but sends the hash of the tx to the seller (specifically to the key that currently has the alias he wants). The seller generates another payment tx using the hash that was sent to him as the input and sending 1 satoshi to the buyer's address using a crippled pubkey script so the output can never be claimed and the remainder to himself using a normal script. He then sends this tx to the buyer who verifies that everything is as expected and releases both txs onto the network. The firstbits algorithm recognizes this pattern on the blockchain and the alias(es) now resolve to the buyers address.

This sells the alias directly from seller to buyer without requiring trust or escrow.

Comments?

lol, that's probably Satoshi.

firstbits.com

The guy who has the address that start's with the number "1" is really lucky xD You just have to remember the first digit.

Oops, I don't know where I pulled that idea from .

Good suggestion. Two remarks.
 
Firstly, note that it gets progressively more risky every time the wallet is passed on, since any or all of the previous owners may try to grab your income. For an account with an fb alias like 1poker or 1bank that may be sold several times and is likely to ultimately handle large amounts of transactions this is completely unacceptable.

Secondly, this can easily get very expensive in terms of transaction fees, since you will always be shifting recently received cash and some of the received txs may well be small.

This is the same reason I wouldn't use one of these paper wallet or BitBills services. On the up side the new owner of the address can just use it as a transfer address where all funds get moved out to a safe address right away (such automation would be easy to code), thus limiting it's vulnerability somewhat (though not totally safe of course).

Yes, you could, but, as mentioned in my post there is no way for the recipient to know that you haven't kept a copy for yourself. Only a fool would accept it.

The typo on addressess is ironic in the context.

I simply mean a firstbits address where more than the minimum number of characters are supplied as has been repeatedly suggested in this thread in order to obtain some protection against typoz.


Indeed a single character provides pretty good protection. I would want to have the checksum as a postfix rather than a prefix, simply because it is optional and it is more intuitive to drop a postfix than a prefix. Any checksum scheme where there are 35 possibilities wil provide a 97% chance of detecting an error so the last character is by no means special. Where the schemes differ is in their ability to detect common errors. The scheme I suggested can detect 100% of single character substitutions. I realized since that it does not handle all single character additions and deletions and detects no transposition errors. This is pretty damn bad. A better suggestion would be something similar to the ISBN scheme that can detect all single character substitutions and transpositions. ISBN has the advantage that unlike firstbits it is dealing with a fixed length payload, so it doesn't need to worry about insertions or deletions.


Good for you. This is why it's optional. Use it, don't use it.


Implying that you consider the solution I proposed to be impractical. Care to elaborate?

As to "problem" and "nor is it eager to be solved". Again, if it doesn't affect you, good for you. Others feel different, grant them some space.

What do you mean 'extended firstbits addressess'?


A 5-bit checksum (~35 alphanumeric) is pretty good validation of the entire 5 character string. I could imagine replacing the prefix '1' with a firstbits checksum, such that 1kk5k could be x-kk5k. I suggest that the 'checksum' represent LAST character of the full 33+ character address. That would correctly detect 97% of potential errors or 99.9% with two characters.

But generally, I don't see the need for a checksum at all. I've rarely called a wrong number and if money was on the line, I'd triple check, checksum be damned.


I don't see a practical way around this 'problem' nor is it eager to be solved.

You can transfer a firstbit the same way you can transfers a regular bitcoin address, either send the whole wallet file or the keypair for the address

What makes firstbits great is the fact that there is no centralized database. The blockchain is the database and it is by definition impossible to delete something that has been confirmed by enough blocks from the blockchain. So to transfer ownership one has to enter a "redirect" tx into the blockchain.

I had thought about this, but didn't want to post twice in a row .

What I had in mind was that if I own 1linux123 and other person were more interested in "1linux", he/she could generate an address such as 1linux456 and pay me some money, then I would use half (?) of that money to pay firstbits for having 1linux123 deleted from the database. Then, I tell the other person that he/she can enter 1linux456 into the site and get the "1linux" firstbits.

First up, thanks to FreeMoney and SgtSpike.This is awesome.

Then I would like to make two suggestions. The first relates to the checksum discussion. It is important to note that simply extending the firstbits name beyond the minimum required characters is NOT the same as a traditional checksum. Where a standard 1 character checksum is sufficient to detect any single character typo, this does not hold for extended firstbits adressess. The 1 character extended 1kk5k address is 1kk5kf. If this is mistyped as 1kk5kg it may well point to another valid address. It doesn't today, but it could. In this case the typo was actually in the "checksum" meaning that you end up worse off than you would have been had you just quoted 1kk5k as your address.

A simple way to add a (still optional) checksum would be to use a separator followed by a traditional checksum i.e. 1kk5k-A or something similar. One simple implementation would be to ensure that the sum of the characters (when interpreted as digits in a base 36 system) adds to 0 modulo 36, But you could also have multi-character checksums that can detect more elaborate typos.

Once something like this is in place, I see no reason why this shouldn't be in the mainline client. It may initially refuse to accept firstbits adresses without checksums and later allow one to bypass this rule if you click through enough "are you SURE SURE SURE" dialogs.


I can hardly believe that this hasn't been discussed more. If the discussion is elsewhere please point me to it.

Vanity addresses and the firstbits algorithm make for a potent combination. If you think 1kk5k was easy to remember, try 1spike (or even 1spike-AX since you don't really have to "remember" spike the "additional" load of remembering the checksum suddenly seems even more trivial).

The only hassle today is that there is currently no way to transfer ownership of such an address. I don't own 1Linux, but if I did, I might be willing to sell said address to BkkCoins if the price was right . Today the only mechanism to do that is to send him the private key, but he would be a fool to accept such a deal since I may well have kept a copy of the key and be in a position to steal any funds he subsequently receives.

I am pretty sure that this can be added to the existing algorithm without any breaking changes (i.e. if 1linux or 1kk5k or whatever belonged to you before it is guaranteed to still belong to you unless you choose to dispose of it). One way of doing this would be to do the lookup as before, but once the address is found to check all subsequent transactions from that address for one that matches a to be determined arbitrary pattern. If such a match is found then the destination of that address becomes the new owner of the firstbits address in question. Rinse and repeat. This is slightly more computationally expensive than the existing algo, but no one is doing millons of firstbits lookups per second are they?

One example of a pattern that may signify a transfer of ownership is a payment from 1linuxdhfgf... to 1linuxtrsyudas.. of EXACTLY 123 satoshis. The amount should be very small and chosen in such a way that no such payments allready exists in the blockchain (so no-one has accidentally transferred ownership of their firstbits alias while trying to buy coffee  ).

This is just an example to clarify the concept and not suitable for actual use because it leaves open the possibility that someone may in future transfer a firstbits alias without intending to, either due to an incredible coincidence or because they were actively tricked. A better solution would be to use the pubsig script as an indicator. An otherwise nonsensical script can be used as an indicator that 1stbits ownership is being transferred. It has the downside that some BTC is being burnt (since it would be impossible to claim that output of the tx) but I don't think anyone is going to miss a few satoshis  . On the upside, one would need a special client to transfer alias ownership so no aliases would be transferred by accident.

If this was implemented we would suddenly have a market for firstbits aliases and hopefully I can sell 1Hannes to one of the many billionares out there with Hannes as a first name  . The only downsides that I can see is the slight increase in computational complexity of a lookup (as mentioned before) and the fact that if one does a firstbits lookup under the new standard one really needs to be online and up to date with the blockchain (allthough you would be able to get away with an offline lookup 99.9999% of the time).

In my original example I showed transfer of ownership of the 1linux alias from 1linuxdhfgf... to 1linuxtrsyudas.. but one could debate whether the second address needs to start with 1linux at all. If it didn't then we would have a marketplace even for firstbits aliases that have not yet been claimed. I would like 1HannesNaude but don't have access to the ridiculous amounts of hashpower I would need to generate it myself. But for anyone that is already running vanitygen the cost of adding it to their patterns list is close to zero. If it was in everyone's pattern lists because everyone knew that I would pay a million BTC for it , it would almost certainly be generated within a day.

Obviously anyone can introduce either of these suggestions, but I really believe it would be best if the firstbits originators did it. Then there would be no confusion or competing standards. Also this is much easier to do now while there is really only a single implementation to adapt than later when many clients and e-wallets have implemented firstbits and lots of code needs to be updated.

Working now. Thanks!