libbitcoin

[d33tah]

I'm just providing immediate access to both to compare them more easily...

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!

[1714869744]

1714869744

[1714869744]

1714869744

[1714869744]

1714869744

[jtimon]

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

[log0s]

libbitcoin is the first alternative implementation of the bitcoin protocol to do full blockchain validation!

(Well, the first publicly available one.)

Congratulations!

[slush]

(registering to this thread)

[netrin]

+3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628

[genjix]

Small update:

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

[mizerydearia]

Small update:

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

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

[netrin]

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

[genjix]

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

Oh! That is clever!

I must certainly will.

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

[netrin]

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.

[genjix]

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.

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.

reduce the chance that a typo will lead to a mistaken payment.

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

[netrin]

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?

[genjix]

How would you represent the genesis address?

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).

[slush]

My primary concern is to get firstbits implemented as deeply into bitcoin as possible.

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

[netrin]

How would you represent the genesis address?

a1zp1e

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).

[genjix]

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

Code:

#include <iostream>

#include <bitcoin/types.hpp>
#include <bitcoin/kernel.hpp>
#include <bitcoin/storage/postgresql_storage.hpp>
#include <bitcoin/util/logger.hpp>

using namespace libbitcoin;

void display_balance(const std::error_code& ec, uint64_t value)
{
    if (ec)
    {
        log_fatal() << ec.message();
        return;
    }
    log_info() << "Balance: " << value;
}

int main()
{
    kernel_ptr app(new kernel());
    storage_ptr app_storage(new postgresql_storage(
        app, "bitcoin", "genjix", ""));
    app->register_storage(app_storage);

    data_chunk address = 
        bytes_from_pretty("12 ab 8d c5 88 ca 9d 57 87 dd "
                          "e7 eb 29 56 9d a6 3c 3a 23 8c");
    app_storage->fetch_balance(address, display_balance);

    std::cin.get();
    return 0;
}

Does anyone here know how I could do something like:

Code:

SELECT sum(value) 
FROM outputs 
WHERE script LIKE decode('76a91412ab8dc588ca9', 'hex') + '%';

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.

[netrin]

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.

[jimbobway]

Does anyone here know how I could do something like:

Code:

SELECT sum(value) 
FROM outputs 
WHERE script LIKE decode('76a91412ab8dc588ca9', 'hex') + '%';

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.

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.

[John Tobey]

Does anyone here know how I could do something like:

Code:

SELECT sum(value) 
FROM outputs 
WHERE script LIKE decode('76a91412ab8dc588ca9', 'hex') + '%';

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

I think bytea supports BETWEEN, so this could be (UNTESTED) "script BETWEEN decode('76a91412ab8dc588ca9', 'hex') AND decode('76a91412ab8dc588caa', 'hex')".  Abe does something like this:

Code:

                lo = abe.store.binin_hex(q + '0' * (40 - len(q)))
                hi = abe.store.binin_hex(q + 'f' * (40 - len(q)))

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

Keep in mind that firstbits is case-insensitive.  1a matches 1a* and 1A*.  You seem willing to implement a new, firstbits-like algorithm, and that's okay, but if it doesn't agree with firstbits.com, you shouldn't call it "firstbits".

[genjix]

Ahhh true, I forgot about the case insensitivity.

Thanks for the advice.