I think I fixed it, it seems to load instantly for me now.
It's odd because I hadn't changed a thing in months.
Please tell me if it works for you now Bkk.
Topic: FirstBits.com - remember and share Bitcoin addresses - page 3. (Read 26262 times)
Just wanted to report that when I visit FirstBits.com now it gets stuck on the sealswithclubs.org advert and FF keeps trying to contact that web site. Even after 20 seconds or so I never get the entry address field.
Seems to hang the page indefinitely. Tried over and over, same result.
Seems to hang the page indefinitely. Tried over and over, same result.
And in the meantime if you don't know you can use blockchain.info to look up firstbits. Just put the address or firstbits in the search field there.
Just wanted to report that when I visit FirstBits.com now it gets stuck on the sealswithclubs.org advert and FF keeps trying to contact that web site. Even after 20 seconds or so I never get the entry address field.
Seems to hang the page indefinitely. Tried over and over, same result.
Seems to hang the page indefinitely. Tried over and over, same result.
Whoa, sorry. Let me look into this.
Anyone else getting that?
It paused for about one second or less for me before displaying the blank which it has never done before.
Just wanted to report that when I visit FirstBits.com now it gets stuck on the sealswithclubs.org advert and FF keeps trying to contact that web site. Even after 20 seconds or so I never get the entry address field.
Seems to hang the page indefinitely. Tried over and over, same result.
Seems to hang the page indefinitely. Tried over and over, same result.
I would be happy to try your patch for Abe. Is it online?
Are you able to show something like http://blockchain.info/fb/3g2 already? (it has a 2of3 signature).
It doesn't work on firstbits as well as on "vanilla" Abe.
Are you able to show something like http://blockchain.info/fb/3g2 already? (it has a 2of3 signature).
It doesn't work on firstbits as well as on "vanilla" Abe.
Sorry, I have not implemented this address type for Abe. Everything I've done is checked in.
The rules I proposed above got no reply, and I lost interest. Abe does not follow them exactly; for example, it ignores trailing OP_NOP when processing an output script. I have not taken the time to find test cases to determine how firstbits.com and blockchain.info handle nonstandard and newer script types. Here is the latest on Abe's implementation: https://bitcointalksearch.org/topic/m.965329
Hi, I recently implemented firstbits for Abe.
What do you propose to do if/when a previously unseen address appears in a multisig output or (horrors) a script-hash input?
Neither Abe nor BlockExplorer recognizes multisig scripts, but bitcointools decodes them into addresses, which blockchain.info displays: example. That site also displays firstbits of script-hash addresses: example.
The addresses I've looked at all appeared earlier in the chain in "normal" pubkey or single-address outputs, but nothing's to prevent someone from sending to a multiple-signature destination that includes a new address. Would that allocate a new firstbits?
I'm tempted to say "no" out of laziness and because Firstbits are for published addresses, whereas multiple-signature transactions are more for self-transfers.
What do you propose to do if/when a previously unseen address appears in a multisig output or (horrors) a script-hash input?
Neither Abe nor BlockExplorer recognizes multisig scripts, but bitcointools decodes them into addresses, which blockchain.info displays: example. That site also displays firstbits of script-hash addresses: example.
The addresses I've looked at all appeared earlier in the chain in "normal" pubkey or single-address outputs, but nothing's to prevent someone from sending to a multiple-signature destination that includes a new address. Would that allocate a new firstbits?
I'm tempted to say "no" out of laziness and because Firstbits are for published addresses, whereas multiple-signature transactions are more for self-transfers.
I would be happy to try your patch for Abe. Is it online?
Are you able to show something like http://blockchain.info/fb/3g2 already? (it has a 2of3 signature).
It doesn't work on firstbits as well as on "vanilla" Abe.
A couple of bug reports for firstbits.com:
1.
The email address listed on the site doesn't work:
2. (What I tried to email to you.)
When I enter the address from the genesis block (1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa), firstbits.com prints:
1.
The email address listed on the site doesn't work:
Quote
<[email protected]>: connect to firstbits.com[108.171.201.215]:25: Connection refused
2. (What I tried to email to you.)
When I enter the address from the genesis block (1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa), firstbits.com prints:
Quote
Your firstbits address: %s
I have excluded M-Of-N (Escrow) transactions from firstbits calculations.
P2SH addresses (http://blockchain.info/address/3N6RjoL4Z93c2VFpqpwJNCUsy5MFikzBWr) get a firstbits with the prefix 3 so as not to collide with old style addresses.
Anything you would like me to change?
P2SH addresses (http://blockchain.info/address/3N6RjoL4Z93c2VFpqpwJNCUsy5MFikzBWr) get a firstbits with the prefix 3 so as not to collide with old style addresses.
Anything you would like me to change?
I am happy with these rules. I suggest something like the following to define "appearance" in the chain:
Quote
A pubkey output is a transaction output with a script of the form: OP_CHECKSIG
An address is said to appear in a pubkey output when its version byte is 0 and its key hash equals the 160-bit hash of the output script's push operand (pubKey).
A pubkey hash output is a transaction output with a script of the form:
An address is said to appear in a pubkey hash output when its version byte is 0 and its 160-bit key hash equals the output script's push operand (pubKeyHash).
A script hash output is a transaction output with a script of the form:
An address is said to appear in a script hash output when its version byte is 5 and its 160-bit key hash equals the output script's push operand (scriptHash).
An address is said to appear in a block when it appears in one of the block's transactions' pubkey, pubkey hash, or script hash outputs.
In particular, output scripts not matching the above three cases can not affect whether an address appears in a block, nor can input scripts. For example, a script containing OP_DROP or OP_NOP can not match the cases, but the push operand in a pubkey output may have any length.
Code:
An address is said to appear in a pubkey output when its version byte is 0 and its key hash equals the 160-bit hash of the output script's push operand (pubKey).
A pubkey hash output is a transaction output with a script of the form:
Code:
OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
An address is said to appear in a pubkey hash output when its version byte is 0 and its 160-bit key hash equals the output script's push operand (pubKeyHash).
A script hash output is a transaction output with a script of the form:
Code:
OP_HASH160 OP_EQUAL
An address is said to appear in a script hash output when its version byte is 5 and its 160-bit key hash equals the output script's push operand (scriptHash).
An address is said to appear in a block when it appears in one of the block's transactions' pubkey, pubkey hash, or script hash outputs.
In particular, output scripts not matching the above three cases can not affect whether an address appears in a block, nor can input scripts. For example, a script containing OP_DROP or OP_NOP can not match the cases, but the push operand in a pubkey output may have any length.
Want to see what Piuk thinks and then lock it in 'officially'?
I have excluded M-Of-N (Escrow) transactions from firstbits calculations.
P2SH addresses (http://blockchain.info/address/3N6RjoL4Z93c2VFpqpwJNCUsy5MFikzBWr) get a firstbits with the prefix 3 so as not to collide with old style addresses.
Anything you would like me to change?
The "escrow" address (as labeled by blockchain.info) is not added as a firstbits address at this point in time. All other addresses involved in a multisig transaction would be added as firstbits addresses.
Would you consider defining "appears" on http://firstbits.com/about.php to exclude appearances in OP_CHECKMULTISIG outputs?I can't tell what is best, but we should all do it the same and be clear.
Want to see what Piuk thinks and then lock it in 'officially'?
The "escrow" address (as labeled by blockchain.info) is not added as a firstbits address at this point in time. All other addresses involved in a multisig transaction would be added as firstbits addresses.
Would you consider defining "appears" on http://firstbits.com/about.php to exclude appearances in OP_CHECKMULTISIG outputs?
The "escrow" address (as labeled by blockchain.info) is not added as a firstbits address at this point in time. All other addresses involved in a multisig transaction would be added as firstbits addresses.
Hi, I recently implemented firstbits for Abe.
What do you propose to do if/when a previously unseen address appears in a multisig output or (horrors) a script-hash input?
Neither Abe nor BlockExplorer recognizes multisig scripts, but bitcointools decodes them into addresses, which blockchain.info displays: example. That site also displays firstbits of script-hash addresses: example.
The addresses I've looked at all appeared earlier in the chain in "normal" pubkey or single-address outputs, but nothing's to prevent someone from sending to a multiple-signature destination that includes a new address. Would that allocate a new firstbits?
I'm tempted to say "no" out of laziness and because Firstbits are for published addresses, whereas multiple-signature transactions are more for self-transfers.
What do you propose to do if/when a previously unseen address appears in a multisig output or (horrors) a script-hash input?
Neither Abe nor BlockExplorer recognizes multisig scripts, but bitcointools decodes them into addresses, which blockchain.info displays: example. That site also displays firstbits of script-hash addresses: example.
The addresses I've looked at all appeared earlier in the chain in "normal" pubkey or single-address outputs, but nothing's to prevent someone from sending to a multiple-signature destination that includes a new address. Would that allocate a new firstbits?
I'm tempted to say "no" out of laziness and because Firstbits are for published addresses, whereas multiple-signature transactions are more for self-transfers.
Should be working now - thanks for the report!
http://firstbits.com/api/?a=19keo3
NO_MATCH
however looking it up on the front page returns an address.
why the difference?
NO_MATCH
however looking it up on the front page returns an address.
why the difference?
I think the API is not showing recent (not sure how far back) addresses. Investigating.
http://firstbits.com/api/?a=19keo3
NO_MATCH
however looking it up on the front page returns an address.
why the difference?
NO_MATCH
however looking it up on the front page returns an address.
why the difference?
Hey FreeMoney and SgtSpike, have you chatted with Genjix about implementing firstbits in libbitcoin?
https://gitorious.org/libbitcoin/libbitcoin
https://gitorious.org/libbitcoin/libbitcoin
I like this neat idea. Is there a chance that somebody write patch for official client?
+1 .. I think it's inevitable: multiple implementations, expanding user base, simple proven algorithm, it'll happen. I expect firstbits could help condense the local block chain. There need only be one instance of each (firstbits key, address) tuple and all other instances of the address can be reduced about 80%.
I like this neat idea. Is there a chance that somebody write patch for official client?
Jump to: