Hey! I think Firstbits is a really cool idea (especially since it only relies on the block chain)  and have been toying with the idea of integrating it into Instawallet. If I do, I will probably implement the algorithm myself, as to not be dependent on external services.

However, there is one thing I find a little worrying: It encourages reuse of Bitcoin addresses, since it can't work otherwise. I don't really want that catching on, especially among merchants, because I think the "proper" way of doing a sale with Bitcoin is to use a fresh address. So for that reason, I have put Firstbit support on the back burner for now. But I'll keep it in mind. Great project nevertheless!


It's not on the site yet, no. This thread is pretty much all the documentation there is. Hopefully I find some time in the next days to move it to the website. PS: I'll be looking forward to your project, I think you did a great job with Coinpal! :-)

Hey! Thx for the feedback. I was indeed a little bit torn between a GET and a POST for this call and this is my first attempt at a RESTful service so I welcome input. I guess my reasoning here is, that this doesn't actually change anything on the server. Since Instawallets are just random links, they are not really "created".

So in that light, if you had a call to /api/random_number would you make it a GET or a POST? (honest question).

And a question about "idempotency": I agree with the general concept, but wonder about situations like this: Let's say you have a /api/current_time call. I would model that as a HTTP GET, even though it doesn't seem idempotent to me - two calls will return different times. Or is it idempotent in the sense, that theoretically the calls could return the same data if you would execute them fast enough?

I'm happy to announce that there is now an API available for Instawallet. This API can be used to write mobile clients, desktop clients, browser plugins or any other cool stuff you can come up with. There already exists one Android client that uses Instawallet (BitPay), which currently screen-scrapes the Instawallet site, but plans to switch to this API soon.

I will put up the complete documentation on the Instawallet site soon. To see the API in action, I wrote a simple console client for Linux that can be found on GitHub: https://github.com/javgh/iw-console/blob/master/iw-console.py . Screenshot:



Here is a quick overview of the API. All calls return JSON-encoded data:

HTTP POST https://www.instawallet.org/api/v1/new_wallet
    Creates a new Instawallet.
    Example response: {"successful": true, "wallet_id": "1CKAK7zU5NGUlY1n3PK0aw"}
    Note: You can also use HTTP GET, but this is deprecated.

HTTP GET https://www.instawallet.org/api/v1/w/<wallet_id>/address
    Returns the Bitcoin address associated with this Instawallet.
    Example response: {"successful": true, "address": "1PmggT9YKj4HL2iaUs8ukUSvvk3Q1xMv5G"}

HTTP GET https://www.instawallet.org/api/v1/w/<wallet_id>/balance
    Returns the current balance in Bitcoin base units (Satoshis). This means 0.01 BTC will be returned as 1000000.
    Example response: {"successful": true, "balance": 1000000}

HTTP POST https://www.instawallet.org/api/v1/w/<wallet_id>/payment
    Your request needs to include the parameters "address" and "amount". Amount should be in Bitcoin base units (Satoshis). Example response: {"successful": true, "message": "Sent 0.01 BTC to 14Z1mazY4HfysZyMaKudFr63EwHqQT2njz", "message_code": 0}

If an error occurred or the API is not available for some reason, the parameter "succesful" will be false and a "message" as well as a "message_code" will be returned alongside. See the following table for possible messages and codes:
1   The API is currently unavailable.
2   Please provide a Bitcoin address.
3   Please specify the amount you would like to send.
4   Sorry, this does not look like a valid Bitcoin address.
5   Sorry, I was not able to parse the amount field.
6   Sorry, currently only amounts of 0.01 BTC and more are supported.
-4   Sorry, this does not seem to be a valid Bitcoin address
-6   Account has insufficient funds (or not enough confirmations) to complete this action
0   Sent <amount> BTC to <address>

The API also provides a way to get push-notifications on balance change. To use this feature, you first need to get a subscription ID:

HTTP POST https://www.instawallet.org/api/v1/w/<wallet_id>/subscription
    Returns a subscription ID to be used with the push-notification service.
    Example response: {"successful": true, "subscription_id": 1563757213}

The next step is to open a standard socket connection to www.instawallet.org:8202 and to send a JSON object encoding the subscription ID on a single line (terminated by either "\n" or "\r\n") like this: {"subscription_id": 1563757213} . Only the first such object will be accepted, further lines will be ignored. The server should respond with a "ping" (regardless of whether the subscription ID is valid or not). You now simply keep the connection open and the server will send another "ping" each time the balance on the server changes. Note: Because of the subscription mechanism the socket connection can be unencrypted.

Feedback and comments welcome!

Also relevant in this context: There already exists a project called PayBitBack ( http://forum.bitcoin.org/index.php?topic=14707.0 ) which allows to send Bitcoins to anyone with a twitter account.

Just put both files in the same directory (so authproxy.py and let's say sendmany.py which has the code that I listed) and then run:
python sendmany.py

Here is a solution in Python: I usually use the excellent Bitcoin Python Library "authproxy.py" by Jeff Garzik. Here is a version with a few improvements I added: http://pastebin.com/RZNMCGRe . Save this as authproxy.py .

Then you can use this code to use sendmany:


You can try out the above code on an empty wallet. You should get an "account has insufficient funds" error.

If this code is to your satisfaction, I humbly request the bounty to go to this address: 1fYHRKUXnFfj7ZhjwMMNqddjcnkGtq4wA . :-)

Absolutely. It's most likely less secure than "encrypting your own wallet". I never advertised this as a secure way to store lots of Bitcoins. In fact, I specifically mention in the FAQ and will repeat it here: Please _do not_ store significant amount of money at Instawallet. Instawallet is all about lowering the barrier of entry and getting people started with Bitcoin quickly. It's not meant as a vault to keep your Bitcoin wealth.


Just for the fun of it, here is what I mean by "doing the math": 16 bytes of random data is 128 bits, which means there are 2^128 = 340282366920938463463374607431768211456 possible Instawallet URLs. Let's say there are 10000 Instawallets in use (in reality the number is nowhere this large, but let's be optimistic and assume that Instawallet will grow). So you have a chance of 10000 to 2^128 to find a wallet with coins if you just guess once. To bring your chances to 50% of finding at least one wallet with coins, you need to guess about 2.359 * 10^34 times (some probability math applied here, I can elaborate if you like). Let's say you want to complete your search within one year. A year has about 3.154 * 10^16 nanoseconds. This means my server needs to serve roughly 7.48 * 10^17 requests per nanosecond to the attacker/botnet.

Do you think my server can handle this? I think we can safely wait until a few more upgrades in processing speed and bandwidth before I have to make the URLs any longer.


That's an interesting alternative, yes, I will keep it in mind. I am wondering whether this change will result in lost wallets. Are people really going to send money without making sure they can access it again? Maybe, I don't know... on the other hand, I can also construct cases where the cookie results in lost wallets: People start to rely on the site remembering them and then suddenly they get a new laptop or somehow clear their cookies and are caught by surprise that the site doesn't remember them anymore. But I will keep this issue in mind.


Everything besides the host name is encrypted when you use HTTPS, including the URL.

In another thread ( http://forum.bitcoin.org/index.php?topic=6526.msg147464#msg147464 ) about your other website bitcointoss.com you are quoted as saying:


Could you please elaborate on this? It sounds to me like the chances of winning are affected by the payout pool. If this is really the case, it's dishonest to claim a chance of 49% or whatever, if it really is "49% unless the payout pool can't pay the winnings". Does flipforbits.com work in the same way?

In other words: If I bet 100 BTC on flipforbits.com, do I have an actual 50/50 chance of winning? or is there some check in the code that says the chance of winning is zero if the prize can't actually be paid?

Another update: I deprecated the whole cookie thing. Instawallet will no longer make any attempts at trying to remember you. Please note: This means that it's now up to you to make sure you have a bookmark or similar to find your way back.

I thought it was a nice convenience function, but I have reconsidered this decision. Mostly I was worried about the possible confusion that can happen when people visit a specific Instawallet linked somewhere, then later return to the site and don't notice that they are redirected to an "old" Instwallet instead of a "fresh" one.

So starting from now on no new cookies will be set. But old cookies will continue to work until they expire (will take a while) or you clear them manually.

This might also be relevant in this context: https://github.com/bitcoin/bitcoin/pull/295 ("Allow generations to be assigned to accounts")

The reason that Instawallet does not work with generated coins is, that bitcoind does not credit generated coins to the account, that the address belongs to. Sipa wrote up a patch for that, but I haven't tested it yet.

This is not true - stuff like this is prevented by the same origin policy. (Think about it: if that was possible, you could also load Facebook.com in an iframe and then - provided the user is logged in - call all sorts of functions with javascript). You can only access the iframe from code, that comes from the same domain.

This might just get dangerous when combined with cross-site scripting: If you manage to feed the webserver some data that it will display back to you unescaped, you can then get your code to come from the same domain and can do these sort of things.

Bitcoind shut down again last night. :-/ Sorry about that! But I think I'm onto the cause now and should be able to make some improvements.

Looks promising, great to see someone tackle this! I like how it's all done over twitter. I was toying with a similar idea but was thinking of having some of the functions on a separate website. But doing it all through twitter messages provides probably a much nicer integration. Great stuff!

Out of curiosity: How are you dealing with fee issues? Let's say I tip someone 0.00000001 BTC, the person claims the address and you now need to forward it. But with the current fee structure, you would have to pay 0.01 BTC to get this relayed by other nodes. Do you run a modified version of bitcoind or what is your take on this?

Also: Thx for linking to Instawallet. =)

I just rolled out a small update to support balances of less than 0.01 BTC. I was hoping to also include the ability to send transaction smaller than 0.01 BTC, but with the current state of the RPC interface regarding fee handling and the rules surrounding "dust spam" this is still somewhat problematic. I have a more detailed post about the issues and a proposal for a more flexible solution over in the Development board: http://forum.bitcoin.org/index.php?topic=14571.0 .

I am currently trying to upgrade Instawallet to allow for transactions that a smaller than 0.01 BTC. I'm running into a couple of problems which I'm sure many other webmasters of Bitcoin-related sites will share. So I would like to try again to start a discussion on a more flexible transaction fee structure.

There are two problems:
1) The current RPC interface doesn't provide a very good way of dealing with fees. I want to be able to know in advance what fees I have to pay and be able to provide a maximum on a per-transaction basis. BlueMatt has worked on an improved interface (see this pull request: https://github.com/bitcoin/bitcoin/pull/289), which I think is very promising and I hope it can get the attention it deserves and this or a similar improvement can be merged into mainline soon.

2) The fee structure for getting a transaction relayed is too rigid. I'm not talking about what ends up in a block here. The miners are free to come up with good fee structure and I'm sure they will. I'm talking about the step before that, when transactions are getting relayed by the Bitcoin network. My users/customers will be using a standard Bitcoin client and will hook into the Bitcoin network at a random position. I want to receive from or send transactions to them and as such am bound by what the network in between will relay. The rules for this are not flexible enough.

What's the issue exactly? We have two shared resources:
a) network bandwidth of nodes
b) space in blocks

Again, I think that "b" will be taken care of by the miners. But access to "a" is governed by what the majority of Bitcoin nodes will do and the majority of Bitcoin nodes will run the standard Bitcoin client software. Currently this means that a transaction smaller than 0.01 BTC and which does not include a fee will not be forwarded by the network - and as such never has a chance to get to a low-fee miner unless you get out of the way to directly connect to the miner, which again your users/customers will probably not do.

I believe that free and as-cheap-as-possible transactions are a killer feature of Bitcoin at it's current stage. We need to make sure that free market effects can work not only on what miners will include in a block, but also on what nodes will forward in the network.

That's why I think we need some form of auto-adapting mechanism when it comes to forwarding transactions. We will never come up with a reliable set of fixed rules of what differentiates a spam transaction from a legit transaction. Instead, I think nodes should simply forward as much as they are able to, but focus on high-priority transactions when they are starting to get overwhelmed.

To describe the algorithm, lets assume a node can wait a while before it forwards a transaction: So it would collect transactions for some time, then sort all the transactions by priority and then forward as many as it is able to, starting from the top of the list. Obviously transactions should be forward as soon as possible, so this algorithm needs to be adapted to work in real-time: It would probably need to look at past transactions and dynamically determine the threshold it needs to apply to stay within the rate limits in needs to obey with regard to network bandwidth.

If such an adaptive algorithm were in place at the majority of nodes, the network bandwidth would be available at a price that corresponds to the current level of traffic. On "good days" you would probably get away without a transaction fee for the time being. On days where the network is spammed by some person, you still only need to pay a little more than the spammer to still get through.

Your thoughts?

Thx, much appreciated!


That's right, Instawallet is only available over SSL.

That's no problem. Instawallet uses SSL, so all the Tor exit node sees is an encrypted connection to Instawallet. The exact URL you are accessing is also only sent in encrypted form.

I heard that some Tor exit nodes use 'SSL strip' to perform a man-in-the-middle-attack on your traffic (is this common?). But your browser should warn you, if the SSL certificate of the site doesn't match.

Yeah, sorry for the outage guys. Nick is right, bitcoind crashed on me for some reason. I will probably set up some sort of restart script to improve uptime, although ultimately these crashes shouldn't happen in the first place. Hopefully these sneaky bugs in the Bitcoin source code can be tracked down over time.

Just became aware of this - pretty cool and related to what we are discussing here. A site that implements blind signing to launder Bitcoins: https://blindbitcoin.com/index.html .

This was meant as a bounty, right? Then I believe I claimed it. :-)

I first tried sipa's branch ( http://forum.bitcoin.org/index.php?topic=8091.0 ) to import the key, but couldn't make it work. Probably because I didn't arrange all the bits in the way sipa's format requires it. I should have looked at Hal's posting right away, because with the patch referenced there, it was fairly straightforward:

1) create file wallet.pem as listed in grondilu's post
2) run ./bitcoind importkey wallet.pem bountyaccount
3) restart bitcoind, passing the -rescan flag
4) check with ./bitcoin getbalance
5) move money somewhere to claim bounty