|
Regarding Germany: There was an article about Bitcoin on "Spiegel Online" just a couple of days ago, which is one of the biggest online news sites in Germany. That's some pretty "mainstream" press coverage, even if it's 'only' online at the moment.
|
|
|
|
I've got a protocol worked out for this, as well as a Bitcoin version for BTC-backed accounts on OT that I've been working on with one of you. (Meaning: if the server is hacked, they still can't steal your bitcoin. If the server is malicious, they still can't steal your bitcoin. Etc)
Can you elaborate on how this will work? If I send my Bitcoins somewhere, to back an account, I presumably have lost control over them, haven't I? Also: Could you describe how the communication flow would look like, when a merchant accepts an OT currency for payment? I assume there is communication with a OT server involved during the payment process? |
|
|
|
Why not just a website that runs like Paypal to do instant payments between its users - exactly like Mt Gox.
Sure, that's an option too. But PayPal knows if Bob pays at a sex toy store with PayPal. So what I'm saying is: If you do go for a centralized component, then you might as well push it as far as possible and use the existing technology in this field - like blind signatures to protect privacy. |
|
|
|
Bitcoin is, as far as I know, unique among digital currencies because of its decentralized nature, where you don't need to trust anyone in particular, but just need to trust that 51% of the hashing power is honest. It does have however serious scaling challenges and the ever-present problem of delays before transactions are confirmed. Many other solutions instead require a trusted mint to issue coins, which then allows to do very fast transactions. Lots of thinking and cryptography has gone into these systems to give them additional nice properties. Especially "Chaumian blinding" is a key technique here, as far as I can tell, which prevents the central mint from knowing too much about the people that it issues coins to: If Bob gets some coins from the mint, then buys something at a sex toy shop and the shop then redeems the coins with the central mint, then Chaumian blinding prevents the mint from concluding that Bob was shopping at the sex toy shop. The Ripple project is yet another approach to the trust problem: Here a trust chain between people needs to exist. (I trust a friend who trusts the person I want to pay.) I think Bitcoin will pretty quickly face serious scaling issues and it seems to me, that some of these technologies could be a great complementary solution. Imagine having a (more-or-less) trusted central mint, where you could exchange Bitcoins for Fast-Transaction-Coins. With those coins you can now do fast mobile payments and extrem micropayments and whatnot, and at the end of the day (quite literally) exchange them back to Bitcoins. If you only keep a small amount of Fast-Transaction-Coins at any given time (like petty cash), you don't even need to have that much trust in the central mint, because you would have limited losses should the mint disappear or abuse its position. So my question is: Which project would you consider the best fit to interface with Bitcoin in such a way? I guess it would make sense to leverage existing open source code in building something like that. Here is a nice overview of various digital currency projects: http://disattention.com/78/digital-currencies-crypto-finance-and-open-source/My personal thoughts on this: I think Ripple is very interesting, but I am not convinced that the "trust chain" works well enough for arbitrary situations. I just want to buy something from some random online shop without needing to figure out a trust path to them. Open Transactions seems like a very interesting project, but suffers a little bit from too much complexity. Because of that, I haven't fully understood it and have the feeling, it tries to do too many things at the same time. But maybe a simple subset of Open Transaction would be a good start. And I believe the author has started on some "Bitcoin to Open Transaction" solutions already: see https://github.com/FellowTraveler/Moneychanger/wikiLinks to the options mentioned in the poll: Open Transactions: https://github.com/FellowTraveler/Open-Transactions/wikiRipple: http://ripple-project.org/Lucre: http://anoncvs.aldigital.co.uk/lucre/OpenCoin: http://opencoin.org/Loom: http://loom.cc/What are your thoughts on this? Do you think making Bitcoin the backbone system too a low-latency, high-volume counterpart is a worthwhile goal, even if it introduces one or several centralized exchange points? |
|
|
|
Instawallet is reporting a human error
6.04 BTC was somehow accidentally added to the dish.
Thx for getting back to me, I wasn't aware that this was the penny dish Instawallet. The "human error" was basically me screwing up during some testing of the site (these are my personal funds, no Instawallet funds are affected). I was hoping for the lucky founder to be honest and return it to me. Seeing as this is such a public wallet, I guess the chances are slim. In any case, here is an address to return it to: 1JU1RGvKiMXRTwPXseuDQY7JkPa7oU4X4Z . I will also gladly pay a finder's reward and am happy if 5 BTC are returned. In the meantime, I'll remove the message shortly and consider it an expensive mistake. Thanks for using Instawallet! |
|
|
|
Thank you for this very useful site. I have used it for a long time and I have always found it very helpful. One of those "does one thing and does it well" websites.
Thx for the kind words! I thought it would be useful when hovering over the yellow "block" data points if it could give you the block number of that new block.
That's a good idea! Unfortunately with the current state of my backend I don't actually have easy access to this information. I'm thinking of restructuring the backend at some point in the future and will keep this idea in mind, thanks! |
|
|
|
I'm happy to report that I found some time to give http://www.bitcoinmonitor.com a new look! I also updated a few other things. The website now uses the trade data from bitcoincharts.com (great service, thx tcatm!). Some of you also requested the feature of being able to zoom into the data, and I implemented a simple variation of that, hope you like it. Donations always appreciated! :-) |
|
|
|
|
I'm in favor of this proposal. It's both future proof and backwards compatible.
The problem with replacing an existing term is, that you create confusion during the transition where people need to figure out, whether you use the old or the new meaning of the term. For an open-source project like Bitcoin it can be pretty difficult to make an organized and well-communicated switch from one meaning to the other. So I think it's better to make up something new, like the proposed UBC. This is what I mean with backwards compatible.
And the fact that 0.01 UBC would be the smallest possible value seems very future proof.
As to the suggestion of XBC: I think I would prefer UBC over XBC, but wouldn't mind either one.
|
|
|
|
Would you consider creating a namecoin version of instawallet?
I think Namecoin is a very interesting project, but would prefer to focus my resources just on the Bitcoin side of things for now. Is it possible for someone to generate addresses locally and inputting them to your site, sort of like a brute force way to find random wallets? I noticed the url is different from the wallet address, which is good, but I would still be concerned about an attack like that.
Knowing the Bitcoin address of a wallet doesn't improve your chances of guessing an Instawallet, if that's what you mean. As to randomly trying Instawallet URLs: the search space is big enough, that this won't get you anywhere. @JAV, You may also have to worry about Toolbar programs (like Alexa toolbar, Ask toolbar, Bing tool bar, Yahoo Tool Bar, Google Toolbar, lots of Firefox plugins). I believe that some of these send URLs back to the "mother ship" to help with page rankings and site analytics.
Thx for the heads up, but how do you propose I should deal with them? It seems to me, that if people want to send their private data to a cloud service, it's up to them whether they trust that provider. I'm not the only service that uses secret URLs. You can, for example, create YouTube videos that can only be accessed through a private link. As far as I know, these services also don't deal specifically with toolbars. But I will mention it in the upcoming FAQ. Could you implement some kind of thing like Mt. Gox's API where I could send BTC by just opening a URL, and then as long as enough BTC were in my wallet, it would send them.
I have been toying with the idea of providing an API. It will probably happen at some point, but I can't promise anything right now, there are still lots of other things in the queue. |
|
|
|
|
Quick update: All traces of Google Analytics have been removed. I also tackled the biggest source of user confusion: changing Bitcoin addresses. The address you see on your Instawallet will from now on not change anymore.
So far everything seems to run fine. More updates (including a FAQ) will follow.
|
|
|
|
That can definitely account for a lot of traffic, but unless I'm mistaken, it didn't hit the frontpage of Reddit. As far as I know, r/technology is not part of the standard Reddit frontpage. So you won't see it, unless you subscribe to that subreddit specifically. I'm not 100% sure about this, but it seems to be confirmed by http://redditsnapshot.sweyla.com/ which archives snapshots of the Reddit frontpage and a search for Bitcoin reveals nothing. |
|
|
|
@jav: How much access do you have to money in an instawallet? It wouldn't surprise me if it's possible to arrange things so you have no access at all. One way would be to randomly generate the URL for each new wallet, but derive keypairs deterministically from that URL, and not keep a record of the URL on your end. (Of course you'd have web server logs, but you could purge them of sensitive data on a regular basis.)
That's an interesting idea and it should be possibly in theory. I don't think it's very practical at the moment, though. It would probably require large changes to bitcoind, to support frequent imports and removals of private keys for the temporary time that the user is logged on. And it would still be kind of a kludge, as the user is still vulnerable during the time he is accessing the Instawallet. I agree though, that it would have many benefits. I think the WebCoin project does some interesting work in this regard, going so far as completely preventing the server from seeing the private keys at all. It should be interesting to see what they can come up with and their software might eventually be a better backend for the Instawallet site. |
|
|
|
I can't see any reason why they wouldn't want to use the phone's data service instead. It is already established and plenty fast enough for the small amount of data required for a POS transaction.
That's what I had in mind when I wrote "connected to the Internet" - using the phone's data service, not necessarily using WiFi. I'm just not clear on how the app knows in which merchant store the phone currently is. The presentation claims that the phone is not on WiFi, so how else can it tell at what store it is?
I believe Dwolla is using the phone's GPS for knowing the list of merchants nearby: http://www.dwolla.org/help/what-is-dwolla-spots/That's why I suspect the USB device for the merchant's POS is a wi-fi stick that simply operates as an SSID beacon that the mobile sees so that payment to the correct merchant is ensured. The mobile need not ever connect to to the wi-fi, it just grabs the list of SSIDs from after doing a scan. Maybe you are right about using an SSID scan. I would find it a little misleading then though, that they claim the phone isn't using WiFi... sure, it's not connected to an access point, but doing a scan is kind of "using WiFi" as well. All interesting ideas to consider for Bitcoin mobile clients. Does an SSID contain enough data to encode a Bitcoin address? That trick could be used then as well to identify a merchant without even requiring a lookup on some server. |
|
|
|
I don't know if this might just give people a false sense of security, but you might want a robots.txt excluding your wallet URLs. Google has several wallets indexed now, although there were no bitcoins in any of the ones I saw. Aw, nice... yeah, whenever their robot comes back it gets a fresh wallet. =) Thx for pointing that out, I will set up a robots.txt. The problem with people clicking through to a specific Instawallet is a valid concern (I had one person using the /w/free_bitcoins link posted by Insti in this thread, transfer 0.01 BTC there and then wondered when it disappeared) and there is no point in spamming the search index anyway. google-analytics? ....... afaik that gives google access to every page that it runs on  Yes, that's correct. And while I consider my Analytics data to be pretty secure, it's an unnecessary risk, I agree. I will move to a local-only log analysis tool soon and then delete the Google Analytics data set. |
|
|
|
|
Always interesting to see different POS concepts. I just wish they would explain the technical details a bit more on their website. What I gather: Some Fig Card central server mediates between the merchant and the smartphone, which - as far as I can tell - needs to be connected to the Internet at the time of the sale. I'm just not clear on how the app knows in which merchant store the phone currently is. The presentation claims that the phone is not on WiFi, so how else can it tell at what store it is?
|
|
|
|
Another concern: If someone uses an anonymizer agent like Tor, how will your "recognition" system work? It could be that it will identify the user based on the exit point, which would be a serious problem as it's likely that eventually two users will have the same exit point.
The recognition system works with cookies. Cookies are stored locally by your browser, so as long as your are using the same browser to come back to the website, it doesn't matter whether you use Tor or not. I'm a bit worried that I might put money into a wallet and then lose the address. Hypothetically, if I were able to tell you the exact balance of a wallet (and that balance were something unique like 142.41305), would you be able to send me a link?
I'm sorry, but I would probably not want to that, no. Remember, Bitcoin transactions are public. Somebody else might - maybe with some additional clues - figure out that some Bitcoin address belongs to Instawallet and can just look up the balance on blockexplorer.com. I guess it would be ok if you would tell me the correct balance plus the last couple of characters from your secret link. Just write that down somewhere, to be safe. well, i'm having problems with it. easy to get 2 send tx's into instawallet of .01 btc each but now can't get them out. instawallet shows balance of zero, my btc wallet shows 2 deposits of +.01 however they are greyed out and have 0 confirms. have contacted JAV but have yet to get this fixed.
Please give this at least 24h to sort itself out. If you quickly send coins back in forth, then these transactions look very "spammy" to the Bitcoin network and can potentially take a long time to be confirmed. How does the address allocation work for this?
I sent 0.02 btc to the generated address at instawallet, works okay.
Then I sent those 0.02 btc back to another bitcoin client. When I return to instawallet page a new receiving address has been generated, why does it do that?
What happens if I now receive a payment at the old address that I was allocated first, who has control of that?
Every Bitcoin address you ever saw on your Instawallet page will always be yours and you can still receive payments there. asdf explained it right: You have one specific Instawallet URL, which is tied to an account in the Bitcoin wallet. The Bitcoin daemon automatically assigns a fresh Bitcoin address to an account once it receives or sends out a transaction. The old ones continue to be associated with that account though, so they will still work. It's kind of an un-intended side effect of using the account feature right now. I can understand how it can be confusing that the addresses change from time to time and I will probably soon put code in that will just keep the address static. But for now: Don't worry about changing Bitcoin addresses, they are still all tied to your Instawallet URL. |
|
|
|
It is definitely an issue-- the account code doesn't keep track of where the coins it is sending out came from, so if you accept 0-confirmation coins you're vulnerable to double-spending attacks (see, for example, the discussion of the "Finney attack" in these forums).
I see, thx for clearing that up. I would really like to keep the speedy transactions, so I have decided to still allow 0-confirmation transactions. But I implemented a server-wide rate-limit for those transactions, which should make the Finney attack not worth the effort. Great idea, that's probably how I'm going to do it! |
|
|
|
Great to see the site being positively received. :-) This instant deposit feature is great, but you might want to wait until the funds clear before letting people withdraw it back out again.
I thought this wouldn't be an issue, but I'm not so sure anymore. I use the "account" feature of bitcoind and every wallet has its own account. My understanding was, that this will mean that the coins being sent are limited to the account as well. In that case it doesn't matter if the funds end up not confirming, because it will also invalidate the withdraw transaction. But maybe bitcoind uses coins from other accounts as well sometimes? Has someone here more insight into this? Interesting question, I'm not sure. The balance is whatever the method "getbalance <account associated with your wallet> 0" (so minconf=0) will return. I have no idea if this is the case for these pool transactions. Where are the wallet files kept?
who has access to the physical equipment that the wallets are stored on?
What kind of encryption does instawallet use?
can we see the source code?
Sorry if any/all of these are answered somewhere on the site, but I can't find it yet.
One of the next things I will add is some sort of FAQ list that will address these things. For now: the wallet is on a VPS, running Debian Squeeze on an un-encrypted file system. So my VPS host prgmr.com technically has access and of course I do. Besides SSL there is no encryption used, but the regular backups I will make will be encrypted. I haven't decided about the source code, so for now it remains closed. In any case: This isn't really the place to store your Bitcoin wealth! I will try my best in keeping the service stable and secure, but ultimately I want to see mostly Bitcents on these wallets. A lot needs to happen before I would trust a cloud service with a larger amount of Bitcoin to store over longer time and Instawallet is definitely not the place to do that. Yeah, this seems rather nifty, but I'd want a lot more details about how the unique URL is generated, what protections there are against people trying to brute-force URLs to stumble upon money, and how the server/wallets are secured before using it for anything serious.
The URL contains 16 bytes of random data. I hope an attacker will do the math before wasting his and my bandwidth. Right now there isn't any sophisticated throttling implemented. Let's see how long until I have to deal with some trouble maker. My only suggestion would be a "copy to clipboard" icon/link next to the funding address
Thx for the idea, I will consider implementing that! It's not specifically supported, but yes, it works at the moment and you are free to make up your own wallet URL. 1. Did you address the possibility of cross-site request forgery?
Maybe not to its full extend. You need to provide the wallet identifier when making a payment, but maybe this could be scripted with JavaScript after being redirect to the wallet URL? I will tighten up security in this area, thx for the pointer. Again, I don't recommend people to store large amounts of money there, so that CSRF would be worthwhile, but of course I appreciate the trust in the service if someone ends up doing it anyway. 2. Though the standard is somewhat vague, the traditional interpretation of RFC 2616 is that Referrer: headers are permitted from HTTPS content as long as the target uses SSL as well. I don't know offhand how each different modern browser reacts by default, but I disagree with Theymos that it's not a concern in general.
2a. To address this issue partly, it would be fairly easy to continue to permit pages to be accessed using an address in the URL but to redirect the user immediately to a page that doesn't include it there, either storing it in the session or including it as a hidden form parameter.
It seems you are correct, that referrer is transferred when linking to another SSL site. I will have to think about this, but as I don't have outgoing SSL links, it should be fine at the moment. Redirecting in the way you describe would be an option, but I'm not sure I like it much. I consider seeing your actual wallet link in the address bar a usability feature. 4. Are the addresses generated using a secure PRNG? If it's an ordinary PRNG, it wouldn't be hard to guess addresses.
What is an "ordinary PRNG" for you? I use Python's os.urandom() which I would consider pretty "ordinary", but I have checked the documentation which claims that it returns "random bytes suitable for cryptographic use". |
|
|
|
|
Thx for your feedback!
@khal: Thx for spotting that http logo link, I will fix it in the next update.
@Garrett: That's correct, for now those wallets are permanent and don't expire (and I will announce it earlier enough if that should ever change).
I do plan to keep it fairly simple. But I'm toying with the idea of having a sort of "Instawallet Premium" option, where you can upgrade your secret link to a proper wallet with username and password and then have features like an address book and things like that. But I definitely want to keep the quickstart experience as uncluttered as possible.
|
|
|
|
I'm happy to announce that https://www.instawallet.org is now live. It is an online wallet service which requires no signup. When you browse to the website, a secret link is created for you, which is the only way to access your wallet. This service is mostly targeted towards people who are curious about Bitcoin and want to give it a try. These people often don't want to download software (the Bitcoin client) or even sign up for some random website (e.g. MyBitcoin). Here they can try out Bitcoin without having to jump through any of these hoops. To that end I have tried to keep everything very speedy. The balance auto-updates as soon as you receive a transaction. You can get your 0.05 BTC from the faucet and donate it to the EFF in a matter of seconds. Feedback is much appreciated! :-) |
|
|
|
|
Show Posts
Do you know if your service can be used with this pool? 
