Hmm, not sure, but I'm not qualified to say that what I'm doing matches the design assumptions behind BIP32, and I'd need (multiple) qualified people to be very confident of this to talk me out of doing the least cryptographically-interesting thing here, which is a bunch of independent random numbers.

If these were being used in regular payments then I would, but it's a special case that I think breaks the assumptions behind BIP32 HD keys, because we actually end up releasing these _private_ keys for the entire world to see. See discussion of what we do here:
https://bitcointalk.org/index.php?topic=423638

Thanks, I'm mainly thinking about those, plus the Rumsfeldian unknown unknowns that I haven't thought of. I guess your comment about only Bitcoin Core doing test key signing and verification makes me think it's going to be a safer choice for the latter, if there's any genuine concern there beyond my primitive superstitions.


Marginally. Would there be any difference between implementations to worry about here?


As far as possible I'm trying to design a process where the relevant points can be witnessed by a second (or third etc) party, so ideally the process would be: Sign the box that will generate keys out of secure storage, run the steps listed on the check-sheet (for example, boot the box, run script X, burn CDs Y and Z, shut down box), sign the box back into storage etc. This is quite easy to do in one session if it's under an hour or so, but if it becomes a multi-hour process it becomes a bit more complex. (Bathroom breaks?...)

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?

It's worth adding that since miners' costs basically track USD, the conditions described by the OP don't just hold on the reward halving, they also hold when the value of bitcoin takes a dive, as it does every now and then.

If there's really some kind of network-weakening incentive-breakage under these conditions then a price dive seems like a more likely trigger than the block reward halving, because the risk of incentive-breakage could reduce the usefulness of bitcoins, and feed back into an ever-lower bitcoin price.

That's a great summary of the thinking behind VAT and why it makes no sense to put it on bitcoin sales (as opposed to on fees exchanges charge when they sell you bitcoins). The hitch is that not everybody's tax legislation is necessarily well enough written to translate the purpose you describe into law.

I don't know anything about Estonian law but here in Japan it looks like we could end up with a situation where businesses have to collect VAT (1) on bitcoin sales but they can then reclaim it against VAT they already owe, resulting in a lot of paper-shuffling busywork and a net tax take of zero or less. I'm sure the tax authorities would rather avoid doing this, but they may not be able to find an adequate loophole...

(1) Japanese VAT is branded as "consumption tax", apparently because the post-war US occupation authorities levied a VAT and it was unpopular so the current government likes to pretend its tax is different to their tax, but it walks and talks like a VAT.

PS IANAL and I'm just pulling this out of my arse but I wonder if guys like Maidsafe and Ethereum who got around securities laws by claiming to be selling tokens for a service (storage or computing or whatever) will find themselves in a different bucket. If I'm buying storage via Maidsafe it feels like there must be some value added _somewhere_...  If it's not collected when I buy the tokens, when is it collected?

What's the "us" that's getting barred here? They're talking about a law about metal coins.

IANAL and I hate to nitpick but reading the judgement nobody seems to be saying that that government has a constitutional monopoly on money creation. What the court ruled was that the government has the constitutional power to grant itself a _statutory_ monopoly on money creation - in this case specifically metal coins intended for general circulation. (That last bit is presumably the difference with the collectible replica cases.)

Applying it to our situation, I suppose it also means that Congress could pass a law banning bitcoins if they wanted to. This law would be dumb and probably ineffective, but it would be constitutional. But did anyone ever doubt that in the first place?

Read the court filing:
http://www.gata.org/files/VonNotHausOrder-Nov-10-2014.pdf

Apparently the prosecution persuaded the court that they'd had trained people to do things like mixing Liberty Dollars into change and dropping it into their hands so they didn't notice, and telling them things like "This is the new $10 silver". The court also decided that making coins while intending them to be used like that counted as counterfeiting as the law defined it.

I can't say whether they really did that or whether the court's reading of the law is right, but if they did it doesn't actually sound like a victimless crime: If I thought I was getting normal US Dollars in change I'd be narked off if I was really getting 10 US Dollars worth of silver which I then have to work out what to do with, and even more so if I was getting what they seem to have been pushing here, which is a coin with less than 10 US Dollars worth of silver in it.

Obviously none of this stuff applies to bitcoin because nobody's pretending bitcoins are dollars, and neither does the other thing they nailed this guy for which was minting metallic coins, which Congress has apparently passed a daft-but-constitutional law against.

A quick update on our Freebase data source: Yesterday Google announced that they'll be closing Freebase to new edits at the end of March, 2015:
https://groups.google.com/forum/#!topic/freebase-discuss/s_BPoL92edc

We liked having Freebase there as a big, general data source allowing you to formulate pretty much any factual proposition in the known universe. We'll take a look at other options and see if we can replace it with something that performs the same role, although at this point we can't guarantee we'll be able to find something suitable, and if we do we're not sure whether we'll be able to seamlessly migrate the outstanding facts currently in our database over to it.

As of today we've stopped accepting new Freebase facts beyond March, 2015, since we're not yet sure that we'll be able to do automated resolution on them. We don't have a huge number of Freebase facts currently registered beyond that date, so in this case if we're unable to find a suitable replacement data source we plan to have a human settle them free of charge when their settlement dates come up in 2015 and 2016.

UI stuff is often unintuitive. You just have to test it and see what happens.

But while they're A-B testing this stuff, I wish they'd test "Just put a sodding bitcoin address up there" and see if that does better than of all this bollocks with Coinbase and email addresses and things.

The piece is weirdly worded. I think it's saying that Estonia wants to put VAT on sales of bitcoins (eg if you sell someone 100 Euros of bitcoins you have to collect 20 Euros in VAT), but Germany only wants to put VAT on exchange fees incurred when buying bitcoins, eg if the exchange takes a 1 Euro commission on the 100 Euros they have to collect 20 euro-cents VAT. The former is a bit mad, but the latter would work fine in practice.

Yup, that would be good when we get OP_CHECKLOCKTIMEVERIFY. In the meantime Alice and Bob might want to use the Alice+Bob branch when they set up the original funding tx to sign transactions to each other using a traditional nTimeLock to protect against both Reality Keys and their counterparty disappearing.

PS while we wait for BIP-65 you can fake it for other purposes with a tautological Reality Key like "1 Bitcoin to be worth at least 1 Bitcoin on [date]". If people want this I might add a less kludgey "release on date" or "release on block number" key type.

For people who are wondering, the goal here is:

Alice and Bob make a transction based on some real-world event. Alice gets paid if it happens, Bob gets paid if it doesn't. An oracle (my service, Reality Keys) will judge whether the event happened or not. The oracle will not be party to, or sign, the actual transaction between Alice and Bob. Although they haven't done so here, Alice and Bob would be able to conceal their transaction so that neither the oracle nor anyone else would know about it. However the oracle's verdicts about the outcome of the event should be public so that anyone can check up on it. Alice and Bob should also be able to withdraw their funds by mutual agreement, without the help of the oracle.

To achieve this, Reality Keys  issues two public keys, one representing "Yes, it happened" and one representing "No, it didn't happen". At the agreed date it will release a private key for the appropriate public key corresponding to its verdict, and throw the other one away.

The aim of the script redeemed in this transaction is to make the funds spendable by any combination of:
Alice + Yes
Bob +  No
Alice + Bob

We use the if flags to indicate which of those combinations you're trying to use to claim the funds with the signatures you're supplying. Another approach would be to duplicate the signatures and test each combination in turn. I don't have a strong opinion about which is better, although I find this one easy to understand and it avoids making nodes waste time checking signatures that are definitely going to fail.

Any comments and suggestions welcome, especially if somebody can think of a reason my tx doesn't do what I think it does...

PS There's also an approach using ECC maths to combine keys and make a standard 1/3 tx, but it has at least one nasty trap for the unwary, and maybe more that I'm not aware of... More on my resources page linked in my original post.

OK, so Eligius mined this one:
https://blockchain.info/tx/fbd6be67bb26e107e553377d3f217c29386d19b8a15b85c2602b0648d6ac3fa0

I guess my transactions were too small and piddling and smelled of dust, or my transaction fee was too mean.

Edit to add:

Yup, they took this one, too - 0.4 mBTC with a 0.1 mBTC fee.
https://blockchain.info/tx/0c82fa329f510b205bf982c95695d3bf0ca8008cc46e3a2c9698261ca07db208

I guess a 0.2 mBTC tx (0.1 mBTC + 0.1 mBTC fee) just looks too much like dust to them.

Ah, thanks, Amaclin.

These guys seem to be averaging about 1 block per day, which is quite a useful thing to have around.
https://mining.bitcoinaffiliatenetwork.com/index.php?page=statistics&action=blocks

I wonder why I'm not getting any love from Eligius... guess I'll try some more high-rolling transactions and some bigger fees and see if that helps...

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?

This mostly covers things already discussed on this thread, but we've written up some information about transaction patterns etc for creating contracts, with links to a couple of working examples:

https://www.realitykeys.com/developers/resources

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.)

Here are some example implementations for encrypting with bitcoin public keys. (Not addresses, you'll need the public key.) No idea how much you can rely on these, I'd be interested to hear opinions.

ECIES:
node.js: https://bitcointalk.org/index.php?topic=627927.0
Python: https://github.com/planetbeing/bitcoin-encrypt

Not sure what this is:
https://github.com/jackjack-jj/jeeq (Python)
From the description of it here it seems to be original, which is cool but sounds like a good reason to prefer one of the other ones...
https://bitcointalk.org/index.php?topic=196378.5