Topic: libbitcoin - page 11. (Read 92487 times)

Maybe create another column of type text that is the text version of the bytea 'script' data.  Then you can use LIKE since each data type is of type  text.

You could use a stored procedure to do the conversion but I think it will take too long.

I assume firstbits would need to be calculated and injected into a table linking to its first block occurrence and full public key. The 33 char base58 address could be dropped entirely from the blockchain and calculated on the fly.

ok so I just commited an example app to get the balance of a bitcoin address:

Does anyone here know how I could do something like:


Where script is a bytea object in order for me to support firstbits?

That way I could add a fetch_balance_partial(...) method to support this.

Ha ha. Ok. It's difficult arguing against oneself. I really have no substantial objection to dropping the '1' prefix, I only tried to recall the arguments against. How about this from the neo-diablo advocating committee: Your suggestion would cause an unresolvable backward compatibility issue for many addresses beginning with '11'. For example, in block 134 is the address 13pS5Wui... (original firstbits 13p) and then in block 662 is address 113pDtuG... (original firstbits 113, though you would accept 13p). Under your regime, we could not support an OPTIONAL '1' prefix without extending the minimal length of numerous extant firstbits. Please think of the children.

EDIT: A possible work around exception reminds me of British telephone numbers. If the address begins with '11' then the minimal firstbits would be the firstbits for which dropping the '1' prefix would be unambiguous with all previous firstbits with and without the '1' prefix. All subsequent firstbits would still have to compare against all previous firstbits with and without the '1' prefix. While the '11*' are rare, those subsequent addresses which would newly conflict ('1*' ) could* be numerous.

I wonder how many addresses are actually effected. In order to preserve the beautiful simplicity of the original algorithm, I believe the '1' prefix can not be optional. Either always with or always without. And because of that (if true)*, I advocate always with a '1' prefix.

* Without a list of all addresses and their extant firstbits, I can't attempt to calculate the 'risk' of an optional prefix. Though I was surprised that the first instance I discovered of "13pdt..." in my very incomplete list was only recently (block 134795) and no instance of '113ps..." (again in my incomplete address list).

OT: Agree, I like firstbits idea a lot. I already implemented firstbits lookup on my pool.

a1zp1e

Also my vote goes to having it not fixed at any length. You can for instance say a1zp1e or a1zp1ep5q or a1 (as long as there's no conflicting matches- in which case it fails).

I suggested just as you, including a suffix or prefix checksum. Perhaps you could carry on the discussion this with FreeMoney and SgtSpike who were responsible for the original implementation and maybe Puik who implemented firstbits in the http://blockchain.info service.

I'm not sure where else it's implemented, but I hope it spreads. My primary concern is to get firstbits implemented as deeply into bitcoin as possible. It's far less cumbersome dealing with 5-7 case-insensitive characters than 30 char base58 strings. Since an address is only a hash of the public key, firstbits could become a first/second class citizen of the blockchain and perhaps reduce the size a wee bit. But most importantly, it would make bitcoin more accessible. The '1' prefix is a minor, though interesting, detail.

How would you represent the genesis address?

I'm not sure that's a good idea.

I never get confused between a fax number and a telephone number. You usually state what an identifier means- it's far easier to remember.

Bitcoin: 1kk5k

vs

Bitcoin: kk5kfb

The 1 is redundant and not needed. We don't need a checksum to make sure it's a bitcoin address as that is unlikely to happen.


There are some good single character checksums such as the Luhn algorithm.

Glad to hear it! Dropping the '1' prefix has been discussed since the summer with good arguments on either side, however, the '1' prefix distinguishes bitcoin from most altcoin addresses.

Oh! That is clever!

I must certainly will.

Tip: bitcoin addresses always begin with 1, so maybe use Kk5kFb instead.

Hi Genjix, are you considering implementing the firstbits algorithm in libbitcoin?

You should additionally provide hashes for the file, at least md5

Small update:

Thanks to phantomcircuit to DB is much faster and more efficient. I've put up database dumps of the blockchain.

+3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628

(registering to this thread)

(Well, the first publicly available one.)

Congratulations!

Thank you. It seems much more readable than the original.

Ok then. BTW, it's pretty hard to spot "@down" edits IMHO. I noticed this one by mistake.

Anyway, congratulations genjix, I believe this can really speed up Bitcoin clients/tools development!

Good work genjix. Congrats.

Yeah, that's why I said "pretty much".