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

cool site! bookmarked.

2 requests though for http://blockchain.info/unconfirmed-transactions
* on the map you show flags but not in the list. wouldn't it make sense the other way round? in the map the symbol could rather represent the order of magnitude of the transaction than the country which is clear by the location.
* please make the sound opt-in instead of opt-out. Took me 5 minutes to find the tab that was beeping.

The point in doing the demos is not really to minimize the total amount in fees... it's to minimize the perception that you're being ripped off just like ordinary banks do.
Also - I'd hoped to actually *give* the entire demo amount to the friend/family member in question - and I don't have enough BTC available at the moment to give multiple BTC to each person. 

I could have given 0.2 or so to a few people - but then the 0.01 fee becomes really obvious and lessens the impact of the demo.
I guess this is old problem of Bitcoin not really being suited to Microtransactions..   but at least with the default client there is only the network fee which is much smaller.

If it's 1% of 0.01 BTC, 1 BTC is the equilibrium.  Send more than that and you pay MORE in fees.  Yes, it's less by percentage, but you're still spending more BTC on fees.  If you are minimizing fees on demo transactions it doesn't matter the amount as long as it is 1 BTC or less, you will pay the 0.01 BTC minimum.

I don't know if it can be worked around - but I wish it were only 1%. 
It's 1% or 0.01 BTC ...   so for sub 1BTC amounts it's quite a high cut.

I'd hoped to use it as part of a demo to people about how easy it is to shuffle around money using Bitcoin.
Looks like I'll have to use amounts in the order of a few BTC rather than 0.x BTC so that it's not eaten up so quickly by fees.

Not that I want to give anybody any ideas, but can't people easily remove the 1% fee from the output of a transaction, given the way the transaction is constructed and signed on the client side? Like use a greasemonkey script or something that does it automatically? Are you just hoping that people won't do that, or is actually not possible somehow?

The firstbits are an ideal (theoretically) unambiguous shortener... provided the address has been seen by the network. For public addresses not yet publicly seen by the network, perhaps Puik could add a temporary otherwise invalid code. The first 8 characters of an address are typically unambiguous (sans vanity codes), something like 1eDj5Efw000 (zero zero zero) might produce a collision list page?

Great to see the new QR code support.
It worked fine on an iPhone and windows pc.. but QR code popup didn't display the image on a friend's android device.

minor point on the popup..  it might be nice if the popup could be 'pinned'.. at the moment it only works as a mouse hover-over, so you can't copy/drag the QR code or get the path to the image.

It would also be nice to have an address shortener such as btc.to available next to each address.
(at least for the 'receive money' page - but would be even better if the 'send money' page would accept btc.to addresses too)

usecase e.g standing near someone's pc with a mobile phone - want to tell them the address to send BTC, but they don't have a camera and you don't want to have to send an email or get them to attempt to type the whole address string.
(also for payment instruction via voice call)
It's easy enough to just go to your favourite shortening service when you're on a desktop machine - but a bit of a hassle when on a mobile device.

Nice!

I use BitcoinJ to decode scripts and it doesn't support many op codes. http://code.google.com/p/bitcoinj/source/browse/src/com/google/bitcoin/core/Script.java. Shouldn't be too hard to add more.


My Wallet now works on the mobile devices, including iPhone, iPad and android.

More info here https://blockchain.info/wallet/devices

Wallet.dat import & export soon.

Looks like your script decoder can handle only some opcodes, but not all...
http://blockchain.info/tx-index/12417196/9969603dca74d14d29d1d5f56b94c7872551607f8c2d6837ab9715c60721b50e?show_adv=yes

Should be fixed. Still having trouble connecting to your server Slush.


There's the possibility your email could be compromised, but your yubikey still safe. Can't hurt anyway.

P.S. Can anyone get http://www.webqr.com/ working? I would like to add it but it doesn't work with my webcam.

You have two separate stats for "BTCGuild" and "BTC Guild" :)

I don't see why there would be a problem using email address recovery, unless someone is silly enough to have used the same password for their email system.
The standard way of verifying an email address is not forged is surely to send a code to it, and ask for it back if the action is approved.

The site now supports two factor authentication via email (Yubikey is still recommended if you have one).

Also the server side wallet code is now available at https://github.com/zootreeves/blockchain.info/blob/master/WalletServlet.java please review it if you are able and have the time.


To combat this you can now add a "Secret Phrase" to your account, this can be a phrase or word of your choosing and can be provided to help prove your identity. This service is not automated and so lost yubikeys//emails will be reviewed on a case by case basis. The sentence doesn't have to be exact, as long as can recall it partially. I've put up a page explaining a bit more about security etc.

Nothing stopping you doing this. However currently if you try and import an encrypted JSON backup the password must be the same as on the old account or instead decrypt it using other software and import the plaintext JSON.


Yes the default format has no checksum. I didn't really see the need for a checksum as if you miss type the private key it's immediately obvious as the address is different.


Maybe it might be possible for the wallet to keep a pre signed transaction moving all coins to a backup address. Then if an 'authorised' transaction is made it could attempt to quickly push out this transaction and prevent the other ones from going through. Just an idea, don't know how well it would work in practice.

I did have success trying base64 but MtGox wouldn't accept that. Converting it on bitaddress.org to base58 and then redeeming on MtGox worked for me.

I think these other sites use SIPA and not simple base58 - I gather there is some chksum added but don't know the details of that. I just recall one time reading a post on the bitaddress thread that there was something like that involved.

---
Answering question just posted above - it's impossible for the wallet software here to somehow prevent a private key from being used elsewhere. So you (or anyone) can always take the private key and import it and gain access to the funds.

I just tested that by importing my key into MtGox and I'm waiting on the confirmations on my balance being added to my MtGox BTC balance. The wallet here shows the transactions (because it gets them from the blockchain) but it has no control over the transaction content. In this example MtGox created the transaction and set the values.

Is there anything in the software preventing someone who has lost account access, from lost login info or lost yubikey, from importing their private keys into another account?  Assuming they have backed up their private keys in another place.

The private keys are in base58 format, which bitaddress.org or Mt.gox don't seem to support. I've added an option to the export panel so you can choose the private key format:



I was able to then import my keys into Mt.gox and bitaddress using Hex format, both sometimes has trouble with base64 (possibly issues with their auto detection code?)

Hope that helps.

Edit: Wallet Import Format always starts with a 5, base58 encoding on it's own does not.

There seems to be a bug in the wallet export functions. I tried both the unencrypted and PDF options (which output the same value). The private key that is exported is invalid.

I checked it on bitaddress.org (which states it not a valid private key) and importing on Mt.Gox which gets confused and reports a different address that has no value, or if repeated, that it has already been used.

I'm not pasting the private key here as it has a few coins on it. But the public address that checks out in block explorer as having 5 BTC on it is: 13PsqCwzX3zuTQaLeNwEKB7FWHE2NLyM6r

I also generated a new address and checked it's private key value on bitaddress.org and get a similar invalid key message. In this case the key has no value and is

FnPRAHpS5asqHEEQRMAcUhNVzVm4Zxqx2KozVH3jgNrw

Something fishy going on there. This obviously isn't SIPA format, or Hex.
Possibly base64 but doesn't get accepted as that format.

Currently, if your site went down there would be no way to recover the monies in our wallet.

Edit: I see now on the export page you can choose format. But the default base58 is not outputing valid base58 values. eg. the one above should start with 5 but does not. I just tested the base64 option and that seems to be giving values acceptable to bitaddress.org and once converted to base58 on bitaddress.org the value works in MtGox to recover the coins.

Good enough. I'm not sure why you chose that instead of something far more standard like GnuPG ( cmd: gpg wallet.json.gpg to decrypt) but since it's only in the event that your site is gone it's not critical. Maybe an option to save a backup in gpg format would be nice. Then a user doesn't have to d/l and compile code to decrypt as gpg is usually installed on linux desktops by default. (Ah, I suspect the reason was availability of suitable client JS code.)
I understand. But it's a shame as soon Bitcoin will cost as much as using Paypal when you add in multiple fees at different steps.