A lot of people out there are starting to do more interesting stuff with multi-sig, often involving multiple parties combining their keys in transactions to create a P2SH address.

When one of the parties comes to actually spend whatever's been sent to that P2SH address, they're going to need the original public keys to recreate the P2SH address, even if they don't actually need the corresponding private keys that would allow them to sign. So this information needs to be stored somewhere. We want this to be around even if whatever site may have helped set up the transaction has gone away, and it probably doesn't need to be secret, since it's ultimately going to show up on the blockchain anyway. I guess that implies we want it to be mirrored in several or more places, ideally run by a mix of different people in a mix of jurisdictions.

I know there are a bunch of clever data alt-coins and things in development, but has anyone got any suggestions for something practical we can use for a web app right now? We all love P2P but if there isn't a good fully P2P solution I think the "reasonably trustworthy vendor" model is OK here, as long as you have the data synced to reasonably diverse reasonably trustworthy vendors.

Basically I guess we're looking at an append-only public data storage for shortish bits of data. (I guess the fiddly bit is how you do anti-spam, since it's hard to squeeze "pay the data storage guy" in some of these workflows until you actually do the redeem.)

I know I'm not the first person to be feeling pain here - any suggestions for something that would be good to use, or if not any thoughts about what would be a useful thing to build?

So I have a workflow which involves me pre-generating literally millions of random keypairs offline, which I then need to store securely until future dates. Last time I did this I used bitcoind and just ran getnewaddress to get a bitcoin address out, then ran dumpprivkey and validateaddress against it to get the private and public keys (which is what I actually want - I don't actually care about the address). That worked OK, except that:
1) It's a bit of a sledgehammer to crack a nut, and I think it may be doing some pointless indexing work and things.
2) It was a bit slow to generate millions of keys like this, particularly on the rather under-powered machine I was using for it at the time. (In particular it seemed to bog down once its wallet.dat file got big, although I could speed it up again by stopping bitcoind and deleting the file, then starting it again.) In this case there are some practical security-related benefits if I can do the whole thing in an hour or so on modern-but-low-end hardware.

Obviously the advantage of bitcoind is that it's had a lot of eyes on it - any other thoughts for tools that have been well enough scrutinized to trust that they'll do this simple job without somehow bollocksing it up? Vanitygen?

So I'm tinkering around with some transactions that are currently non-standard, but should become standard in the next bitcoind release.

The transactions I'm using follow the pattern here:
https://www.realitykeys.com/developers/resources#nonstandard

I'd been expecting these to get mined by Eligius, and basically nobody else. But it seems like Eligius will accept them via its web form but never actually mines them, and there are a bunch of random IP addresses out there that _do_ mine them for me.

Here are a bunch of transactions:
https://blockchain.info/address/391ByYRP3ZGtizQt3XKc96T8xxLvzWj5Ec?filter=1

Can anyone shed any light on what's going on here? Am I tripping over some other Eligius check? (Key reuse? Some malleability thing?) Or are those random IPs really Eligius? If not who are my mysterious non-standard-tx-mining benefactors?

After we released Reality Keys someone suggested that it could be used to help people make smart contracts for personal goals.

For a while we've wanted to put out an application for people to look at to help them build things on top of Reality Keys, so we've put together a little static HTML/JavaScript web app along these lines. The suggestion made to us was to support Withings health tracking gadgets, which we certainly want to do, but we've built this app to use RunKeeper, which provides an API allowing us to confirm that you completed a walk or a run, based on your GPS.

For now we're defaulting to testnet coins, but you can use real bitcoins if you're brave and prepared to lose them if something goes wrong. We'll switch it over to default to bitcoins once we think it's had enough scrutiny.

https://bymycoins.github.io/

Source code here:
https://github.com/bymycoins/bymycoins.github.io/

The steps to use it should be fairly obvious, but it works like this:

1) Set a goal, eg. I will walk 5000 meters by Saturday.

2) Choose a charity or beneficiary who will be paid if you don't make it. By default it will fund my wife's flight to the 2014 World Savate Assaut Championship in Rome. We'd happy to list any other good cause - the app will give you a public key, which you can send to us to add to the list. Alternatively you can pair up with a friend - just select the "other" option and stick their public key in the box. (The app will give you a public key on the "Secret" screen.)

3) The app will send you to RunKeeper, where you need to give Reality Keys permission to look at your data.

4) You get a 12-word mnemonic which you'll need to keep safe. You can use this to restore to a different browser later.

5) You get an address to pay, which you can fund with as much money as you want to lock up.

6) The app will give you a prompt to tweet your contract to @bymycoins. Anyone will be able to click on that and see the contract. If they want to they'll also be able to pay the address to encourage you. You don't have to tweet, but the charity won't be able to claim the funds unless you somehow let it know about the contract.

7) A day or so after the deadline you set, you'll be able to claim the coins if you make it. If you don't, the charity will be able to claim your coins.

Feel free to fork this app - it could be made to do all kinds of different things with some fairly minor changes. The obvious one is to flip it around to do the equivalent of sponsored walks (funder funds, charity gets the funds if you make it, funder gets them back if you don't) but similar code could power a lot of different kinds of applications, especially with different data sources. Don't hesitate to let us know if there's a data source we can add to Reality Keys to allow you to make something interesting.

All comments, questions and suggestions welcome, as of course are reports of security issues.

Technical stuff:
* It's a browser app, which is convenient but hard to secure. If anybody wants a little python script to do the same job let us know and we'll put one together.
* The app is built on bitcore.js.
* We use a custom transaction to send the money to the right place depending on which Reality Key gets sent. This means that the part where you claim winning funds is currently non-standard. The app sends it directly to Eligius, which mines it, but that means you may need to wait a few hours for Eligius to find a block. The transaction we're using should become standard in Bitcoin 0.10.
* As far as possible the app is purely client-side. But we use the following APIs:
 1) Reality Keys for the information about whether you reached your goal and keys allowing funds to be unlocked depending whether you did or not.
 2) Blockr.io for payment information and pushing transactions to the network.
 3) A little proxy service we run ourselves for pushing transactions to Eligius over HTTPS, as their submission form is HTTP-only which upsets some browsers when serving a page over HTTPS. (We hope to replace this soon.)
 4) A little server-side script to gather up information about contracts from Twitter and make it easier for the charity to receive them. (It would work without that, but somebody at the charity end would have to click on each contract to load it into their browser.)

I'll do a proper announcement later but I'm working on a little JavaScript app for setting up smart contracts with your future self.

The idea is that you set a goal for yourself, eg. Run a total of 100 km by the end of the month, and lock up some money in the bitcoin network that you'll forfeit (to charity) unless you reach your goal. You track your exercise activity on RunKeeper, which is in turn monitored by Reality Keys or similar, who provide keys that will let you unlock the money if you succeed or let the designated charity unlock the money if you fail.

The app is pure static HTML / JavaScript, built on top of bitcore.js. (It's hosted on GitHub, but in theory you could run it locally.) Since it needs to some things that a conventional wallet couldn't do, like talking to Reality Keys and signing fancy branching multisig transactions, it implements its own little wallet, with keys generated from a seed that's stored in local storage in the browser.

Security-wise things like "browser" and "local storage" are obviously sub-optimal, but we're generally not talking about huge amounts of money. Nevertheless, I'd like to avoid helping users lose their money to unforced errors. How would people suggest handling the creation of a seed? Should we let the user type something in, or are we better letting JavaScript do its best at making something random? Any suggestions for things I should / shouldn't be doing here, and any good examples out there I should be learning from?

Here's the app in its current state:
https://bitpact.github.io/
https://github.com/bitpact/bitpact.github.io

So I've been hacking on bitcore.io trying to do some (hopefully not for much longer, Inshallah) non-standard transactions with it, and I'm finding they're getting rejected by my testnet node for being invalid. I can generate the same transactions with a python script I made earlier and get them accepted and mined OK, and the hash that's getting passed to the sign code seems to be the same in both cases, so I reckon I'm somehow screwing up the actual signature creation rather than elsewhere in the script, but I'd like to test the signatures in isolation to be sure and confirm that the ones getting created by my JavaScript are definitely wonky where the ones created by my Python code are good.

Any suggestions for an easy, hard-to-screw-up-when-sleep-deprived way to verify a signature in isolation? I'm wondering if I can do something like (made-up options follow):

Code:

openssl --i-would-like-to-verify-a-signature-please --ecdsa-something-or-other <pubkey> <hash_that_gets_passed_in_for_signing> <signature>

I'm pleased to announce the release of Reality Keys. We provide information about things happening in the world - everything from exchange rates to election results, drawn from services with public APIs - in a form that can be understood by miners and used to confirm Bitcoin transactions. Our service is a little bit different from the  "external state oracle" Mike Hearn discusses here:
https://en.bitcoin.it/wiki/Contracts
...but we hope people will find it useful for some of the use-cases he describes.

Specifically, you can register an event - "1 USD will be worth more than 1 Euro on Feb 24th", or "Edward Snowden will win the Nobel Peace Prize by the end of 2015" - and we give you a pair of public keys, one representing the event happening and another representing it not happening. When that date comes around, we'll query the relevant API to find out whether the thing happened or not and release the private key for the public key that corresponds to the outcome. You can then use those keys in multi-sig crypto-currency transactions in the same way you might use a normal signature.

Currently our data comes from Coindesk (Bitcoin exchange rates vs USD), the ECB (exchange rates of legacy currencies), blockchain.info (Bitcoin address balances) and Freebase (everything in the known universe). Let us know if anyone has anything else they'd like us to monitor; In principle we can handle any API you can point us to as long as it has reasonably permissive Terms of Service and some other feasible way to double-check the information we get from the it in the event that it misbehaves. Please be patient with us if we run into performance issues over the next week or two, or if you manage to turn up some patterns of information in Freebase that we hadn't bargained for.

Our service can be used free of charge, to the extent that you are happy to abide by the automated results we pull from our data sources. However, we also allow you to pay a fee, currently 10 mBTC, to have a human check what happened, in the event that you think the API-generated result was wrong. For exchange rates etc we expect that this facility will hardly ever be used, but it may be useful for if you've made - say - a high-rolling bet on an election result, and the loser tries to rip you off by tinkering with one of the community-curated databases that feed into Freebase.

Note that although we think this will be useful for people making all kinds of Bitcoin contracts, including some of the scenarios described in this CoinDesk piece, we aren't going to do anything to help you find someone to make a contract with or actually create the transaction. Obviously our service isn't much use without being able to do these things one way or another, but software for brokering advanced transactions and (potentially p2p) order books are big projects in themselves, which we hope to leave to the people already working on them, who are generally much smarter than us. We've provided a simple, authentication-free API that you can use to register facts, grab the resulting keys and check on their status. Please don't hesitate to get in touch if there's anything we can do to make our service more useful to you.

Also note that, since we only issue keys to say what happened in the world rather than actually taking part in contracts, we're not in a position to confirm the legality of using our keys to create any particular contract in your particular jurisdiction. Please make sure you check these things yourself and abide by your local laws and regulations.

Finally, special thanks to a couple of people on these forums: Mike Hearn, who has long been blowing everybody's minds on all things contract-related, and Peter Todd, who seems to come out with at least one important bitcoin-related insight every weekend, and two on bank holidays.

I've created Address Machine, a free public database to help people who need to pay each other in Bitcoins, but don't know each other's Bitcoin addresses.
https://www.addressmachine.com/

It uses a simple, login-free process where you can look up addresses on the website, by email, by Twitter or through a web API. It confirms email address registrations before adding them to the database by sending a confirmation email.

Or you can use it from Twitter, for example:
 Look up my address: @addressmachine @edmundedgar
 Add your address (replace this with your own address, obviously...): @addressmachine 1Q4uC95NvGSw3JrmFAcc4ZDRDNGZ2u3bFT
 Delete your address: @addressmachine DELETE 1Q4uC95NvGSw3JrmFAcc4ZDRDNGZ2u3bFT

I'll also add the ability to have the system create a temporary address for someone from the API and send them a key to access their wallet, so that you'll be able to pay people who haven't registered Bitcoin addresses yet. For now that will create an Electrum wallet, grab an address for it and send the owner the seed.

The code is open source (AGPL) and is designed with sharing in mind - for example, email addresses are stored hashed (I don't keep the plain text) so we can let a few independent people keep mirrors of the database, while reducing the risk that if they leak the data all the users get spammed.

More information on the website, detail in the README on GitHub.
https://github.com/addressmachine/addressmachine

Comments welcome, and if anyone's interested in mirroring the database, or has some confirmed identitifier<->Bitcoin address data they could share (eg maybe you run an e-wallet service), please get in touch.

I'm working on a Bitcoin module for the OpenSim virtual world server, which I'm doing by re-purposing a module originally designed for PayPal. One thing you can do with the PayPal version is to send money to an email address even if the user doesn't have a PayPal account yet. PayPal will then hang onto the money and send the user an email inviting them to come and claim it. I need this feature because OpenSim does user-to-user micro-transactions, where everyone is a potential vendor, so realistically I can't expect everyone to have a bunch of Bitcoin addresses on file.

I found a service called Coinapult ( http://coinapult.com/ ) that seems to do the same thing (API to create a Bitcoin address, pay money to that address and the user gets an email to collect.) It has a really nice web UI, but it needs an API key, and I can't get a response from them to my email asking for one. My module is designed to be run by virtual world hosts with minimal faffing, so I can't really make them contact some rather odd-looking site then wait around for an API key.

Ideally I'd set this thing up with a few different services in case one falls over.

Features I need are:
1) API call to create a Bitcoin address for an email address.
2) When paid, the owner of the email address gets an email telling them where they can get their money.

Features I'd like but don't absolutely need are:
1) Public API, without needing a key. (I don't really see why Coinapult make you sign up for one, as even if you could come up with a working business model that used them for spam you could just make a script to hit their regular web UI...)
2) Customizable email.
3) Ability to specify an address to send the money to if it isn't claimed after x days. (Coinapult return to sender after 1 month, but it would be better if I could choose this myself.)

This seems like the kind of thing e-wallet providers would want to provide - do any of them do it? If not it seems a bit embarrassing to be out-featured by PayPal...

There was some talk a while back about whether BitCoin could serve as a currency for the Open Metaverse - that's the non-centralized version of Second Life, built on a piece of software called OpenSim.
https://bitcointalk.org/index.php?topic=49310.0

I've been doing some hacking on this, and I thought I'd post the details of what I'm trying to do in case anyone has any suggestions. I didn't get a wildly enthusiastic response when I raised this on the OpenSim list, so I don't know if any grid operators will actually use what I build, but we won't know until we try. This will be a bit technical...

Currently money in the Open Metaverse works by either:

a) A money server running on each grid which stores balances for the users of that grid. Effectively each grid has its own currency, which may or may not be convertible to other currencies. There is some money server software here:
http://www.nsl.tuis.ac.jp/xoops/modules/xpwiki/?OpenSim%2FMoneyServer
b) A money server running on each grid that talks to an external central money company, usually VirWox.
These money servers kick off transactions when a user tries to buy an object, and deliver the object when the transaction is complete.

My ultimate goal is for metaverse money to be 100% P2P, so neither any central company, nor the grid operator, needs to handle anybody else's money.

I'm working on a customized version of the money server so that:
1) Each grid holds a list of BitCoin addresses for each avatar who may want to receive payment.
2) When one avatar does something requiring a payment to another avatar, the grid looks up a BitCoin address for them and tells them to pay it.
3) Once payment to an address has got a (configurable) number of confirmations (this may be zero), the transaction is completed (eg the object is delivered).

Optionally, I also want preserve the option of having a balance of money stored on each grid, as in the existing option (a) above. This will allow you to pay money into a grid in advance to make things faster and easier, especially if the grid is configured to require enough confirmations to ensure there's no risk of a double-spend. (You don't want to have to wait an hour to upload a texture.)

From a UI perspective, the really annoying part of this turns out to be getting BitCoin addresses into the grid so that sellers can get paid. It's also quite annoying to have to go out to the BitCoin client every time you want to make a payment. To solve this my thought is:
1) Alongside the BitCoin daemon that stores your money and the OpenSim viewer that you use to access the grid, you have another program, which I'll call the BitCoin-Viewer Bridge. This could be running on your own PC, or it could be a web application hosted by somebody you trust.
2) When you log into a grid, it gives you a URL to open, containing a session ID and the URL of the grid, that allows the BitCoin-Viewer Bridge and the Money Server on the grid to talk to each other for as long as you're logged into that grid.
3) Once logged in, your BitCoin-Viewer Bridge will automatically generate addresses for you and pass them to the Money Server in case somebody wants to pay you later.
4) When it prompts you to make a payment, the BitCoin-Viewer Bridge will give you the option of trusting the grid you're connected to to make future payments without asking you, up to a maximum amount. So from then on you'll click "Buy" in the client, and everything else will happen behind the scenes.

I would hope that in future some kind person will build the BitCoin-Viewer Bridge into the existing OpenSim viewer, which will make the whole process seamless.

Any thoughts on this? In particular, if one of the existing online BitCoin wallet sites is interested in hosting a web-application version of the BitCoin-Viewer Bridge, that would make things much easier for people to get started, and in turn make it easier to persuade grid operators to use the thing.

So I'd really, really like to be able to do escrow transactions with BitCoin, without relying on a third-party I've never heard of. (There are a bunch of these, I know.)

I know the core developers are working on this, but they seem to have been derailed by politics and some very earnest arguments.
https://bitcointalk.org/index.php?topic=61125.0
(To think people worry about the developers putting something evil in BitCoin - it turns out they can't even get something beneficial out into the world, because even after 6 months of discussions some guy pops up and says maybe they need to paint the shed a different colour...)

Presumably it's going to take some time from getting the thing into the blockchain to actually getting useful features into the client. So realistically, how long are we talking?

The reason I ask is that if it's going to be a while I'm thinking about setting up a site to help people do their own escrow transactions (without me sitting on their money) by making a wallet, encrypting it and splitting it among the participants. Thoughts on how I'd like to do this transparently (with as little need to trust me as possible) here.
http://edmundintokyo.wordpress.com/2012/02/02/can-anyone-sell-me-a-transparent-cloud/
But I don't want to bother doing this if it won't be long until BitCoin supports doing it properly, with no need to trust me or verify my stuff.

PS. I'm not sure who reads this "Newbie" forum, but I'd appreciate it if someone could promote the thread to the regular one, which is probably where the people who can answer my question are.