Topic: Blockchain.info - Bitcoin Block explorer & Currency Statistics - page 54. (Read 482537 times)

Only a question about the messages that sometimes are above a transaction. public note. When such transaction shows the username of a user here in the forum then thats a proof when this forum user claims the btc are coming from him. I mean that can only be edited or set by the real owner of the sending address right? Its an equivalent of verifying an address with a signature?

I've now tried it, myself:
I picked a compressed and an uncompressed key from my wallet (yes, my wallet
has a couple of each kind) and created a multisig-address from these two.
I then re-did the addmultisigaddress, replacing the compressed address by
its compressed key, and it gave me the same multisig address back as before.
Then I re-did it again, this time with the "04..."-format pub key instead, and
without much surprise I got a different address, now.

tl;dr?

It definitely matters, whether the address has been created as a compressed or
uncompressed key, and the current feature is very bad at the moment when
used on compressed addresses!

If some key is a "compressed" one, and you pass that "04..." string to someone else,
who then creates a multisig-address based on the "04..." key you gave him, then you
will NOT be able to sign it later!

For compressed keys, the blockchain.info wallet should definitely show some "02..."
or "03..." string!

EDIT:  has been fixed, since.  Thanks!

Would be useful to have my address and QR code displayed without having to login.. so on the nickname pages like https://blockchain.info/wallet/nickname

Actually my request for this may have been based on the false assumption that "addmultisigaddress" rpc call of bitcoind requires a list of public keys.

I just checked again and it seems one can also use addresses:


well, all the better. Sorry @piuk for making you introduce a feature I probably wont need after all. I still thinkgs it's a good feature, though.

EDIT: correction. Using address seems to only work when address has been used in blockchain and pubkey can therefore be retreived from blockchain:

For a particular private key, there exists only one public key. The representation
of this public key, however, can be compressed or uncompressed, and it depends
on this choice, what bitcoin-address you end up with.   Therefore, the encoding
of the private key (the number) to some base58-string was made such, that it
contains an extra "flag" which specifies whether compressed or uncompressed
representation of the public key is used for obtaining the btc-address.

As this "compressedness" is relevant for the verifyication that the pub key is actually
the one for a given btc-address, it appears likely to me, that using the public key for
generating an escrow address will likely also need the information about compression,
or the funds on the escrow address might just end up unspendable!

I know pretty well about compressed and uncompressed keys, but I know not
much about generating escrow addresses. (I don't even know, why one would
even need the public keys for creating an escrow address, but someone seems
to have requested the "show public keys" feature with that motivation.)

Anyway, it is a pattern that I noticed in btc-world, that whenever you need a
public key for a btc-address, you also need to know, if it is intended to be used
compressed or uncompressed, and without that flag, the information is just
incomplete (or at least requires try&error lateron).

I do not know if this is what you are after but the public key and the compressed public key are basically the same thing in that given the public key you can calculate the compressed form of the public key or given the compressed form you can calculate the uncompressed form.  So the public key can be displayed, emailed, transmitted, etc. in either form and from one you can always calculate the other.  Does that help?

Sounds like he is simply converting to and displaying the full form.

Would really love an updated iOS app!  I know it's a lot of work, just saying I'm looking forward to it eventually. 

I tried this on two addresses, a compressed one, and an uncompressed one.
both gave me the "uncompressed" hex-string "04......"

I think, that if the public key is used somewhere, then it is likely, that one will
also want to check that it really corresponds to the address, and for that, one
would need to know the type of the address along with the actual pub key.

In the case of a compressed key it might be worth a consideration, to
have it printed as "02..." (or "03..." for odd y).
Another option would be to append some flag-string e.g. "04...... (compr)"
to indicate "compressed"-ness without actually hiding the y-coordinate.

PS: If anyone who knows compr address-types AND how they interact with
   escrow-keys (I fail at the latter) could speak up about what format is really
   needed, now that would be great

Thanks! You are the best.

How do I get rid of the green popup? There's no close button.

Great stuff piuk! Thanks a lot for these new features!!!

Are you going to add the P2P Fallback mode also on the Chrome app?

P2P Fallback mode in the android app

The android app now includes to ability to switch between using blockchain.info's servers to retrieve information about transactions and the bitcoin p2p network itself. When P2P mode is enabled the app will switch to using bitcoinj as an SPV client and once it has synced the block headers you can send and receive transactions even if blockchain.info is offline. It can also be used to verify your wallet balance independently of blockchain.

- In P2P mode you cannot generate new addresses (since the wallet can't be saved on the remote server)
- Watch only addresses will not work
- If the app cannot connect to the PIN server the password will need to be re-entered every time the app launches.




I'll get that fixed tommorrow.

It's a watch only address - the private key has never been uploaded to blockchain.info.  EDIT: yes, definitely a bug, because the public key it presents me is different each time.

Will

It doesn't need to be used on the network because the public key can be derived directly from the private key (which the JS interface has access to). How did you convert the pub key to an address?

If it is for a watch only address then it may be a bug.

I have an address in my wallet whose public key has never been seen on the network (it has only received bitcoins), and blockchain.info is somehow able to display what it thinks is the public key for this address, even though it cannot possibly have it...

I manually converted the public key presented by blockchain.info to a bitcoin address, and it doesn't match the bitcoin address - so I"m not sure where blockchain.info is getting this public key from...  Perhaps it should instead present an error if it cannot obtain the public key?

Will

On the addresses tab using the Actions button there should now be and option to Show the public key.

Good objection...

I'm assuming the output of signmessage contains the pubkey (there's a "/" in there, so I guess one part is the sig and the other part the pubkey). Couldn't find concrete info on this, though. Anyone?

btw: blockchain.info has an api call "verifymessage", which anologous to the equally named call in bitcoind takes a bitcoin address as argument and returns (among other things) the pubkey of the address. This kind-of solves my problem. However it's not very nice to have to tell blockchain.info wallet users to use an api call manually and the parse the resulting json for the pubkey... seems this could easily be integrated into the web gui.

piuk?

EDIT: just found this:


page linked as author of quote talks about the possibility to construct an escrow transaction by using the "escrow" tab after having selected "send coins". I can't find this.

Neither can I find any "QR code icon" in the recieve coins tab that would reveal a pubkey.

what up?

Okay, I'm seriously confused then....

verifymessage

It looks like the official client uses the address. And the only keys it talks about is the private key.

signmessage

Which you can get the addresses just fine from blockchain....

[/quote]
Maybe this helps?:

https://en.bitcoin.it/wiki/Transactions

Quote

A Bitcoin address is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key.

Okay, I'm seriously confused then....

verifymessage

It looks like the official client uses the address. And the only keys it talks about is the private key.

signmessage

Which you can get the addresses just fine from blockchain....

No. A bitcoin address is a hash of a public key.  It cannot be used to verify a signature.  This is why bitcoin wallets supply a public key along with a signature when creating a transaction, and not just a signature alone. Peers are then able to use the public key to verify that the signature was made with the corresponding private key, and then hash the public key to verify that it results in the bitcoin address that is associated with the transaction output that is being spent.