I'm toying with the idea of using a Bitcoin miner to heat water (for domestic use) with excess electricity from a PV installation.  The goal is definitely to just use it when heat is needed and spare electricity is available, and not to run it always.  I'm not trying to maximise mining profit, but just do a fun project that has some useful purpose, too, but obviously I don't want to just burn a lot of money.

I can take care of all the control aspects easily, but I'm trying to determine whether or not there is suitable mining hardware available at all.  Basically I would need a miner with these properties:
- low power, 500-1000W intake
- can be watercooled easily (I'm not too much of a hardware tinkerer, so fitting some pre-made watercooler onto the board is the most I can do)
- cost in the $500-$2000 max range
- does not need to be the most efficient available, but obviously if it only makes $10 a year, there's no point

Does anything like this exist?  I've seen that there are watercooling solutions for S19's, but they draw a bit more power than I want to give it based on my estimates.

[old code will accept the new rules]

A soft fork means that old code will accept the new rules

nope, that's wrong

Yeah I agree with Carlton here. The segwit soft fork meant that legacy blocks are still accepted after the fork but this doesn't work the other way... From what I can tell the signed part of segwit transactions just get ignored by full nodes before v13 and they just take the 150 byte transactions (as an example from the standard size) because the longest chain is running with them (and there isn't a reasonable rival).

I sorry to say that, but this is still wrong.  See here for what a soft fork is: https://en.bitcoin.it/wiki/Softfork

I.e. it means that only additional restrictions are added (in the case of segwit, that the witness must be valid in addition to the old-style signature).  This means that old nodes accept all new blocks, but it also means that transactions that would be accepted by old nodes may be invalid according to the new rules.

Now it could be that in the particular case of segwit mining, you are fine running old code, as long as noone maliciously sends you transactions that are valid according to old rules but invalid according to new ones.  But that would then be just by chance and not a general property of soft forks.  Also, at least according to my understanding (I'm not a miner and haven't looked at the details recently), aren't segwit blocks supposed to have a new commitment in the coinbase, which old mining software wouldn't create?

Suppose that I have two Bitcoin transactions:  Tx A pays no transaction fees at all.  Tx B spends an output from Tx A and pays fees covering both transactions.  Now in general CPFP should allow me to get both transactions mined together.

But is it actually possible to submit them somehow to the network "as a package"?  If I try to submit them using "submitrawtransaction", I cannot do so because Tx A is rejected (not meeting min relay fee) and Tx B obviously can't be submitted before Tx A is.

(The reason why I'm interested in this is the following:  For a particular decentralised asset exchange I would like to allow makers to create Tx A corresponding to an order and publish them off-chain to some communication platform - they should not need to pay a fee for that.  Only if someone wants to actually take the offer then they would build Tx B on top of it, pay transaction fees, and submit both together.)

For certain potential blockchain applications (like online casinos or games), it is important to generate fair and unpredictable random numbers.  One way to do that is to base random numbers off the block hash; but in that situation, miners can manipulate the numbers by withholding blocks they don't like.  That costs them the block reward, but if they have sufficiently high stakes in a game, it may be worth it.  The incentive structure for this has even been analysed previously in detail, see http://www.ledgerjournal.org/ojs/index.php/ledger/article/view/29.

One way to overcome this issue for something like a two-player game (think a casino) is to use hash commitments.  For instance, in a roulette game, the player can submit H(nonce | bet) in a transaction that also pays the betting amount.  H is some secure hash function, nonce is a random number chosen by the player and bet is the bet (e.g. "red" or "black").  Then the actual result of the draw is computed from the block hash the transaction is confirmed in, but at this point, the miner does not know the actual bet and thus cannot withhold "bad" blocks.  Afterwards, the player has some time (e.g. 100 blocks) to submit the preimage nonce and bet to claim a win.  If they don't submit or submit a losing bet, then the casino gets the money instead.

This system is unfortunately not suited (at least not without major difficulties) to things like multiplayer game worlds, e.g. random numbers for a game like Huntercoin.  Here, I want to sketch an idea for preventing block withholding for such games in a different way.

The basic idea is to allow anyone (players and other users of the blockchain) to bet directly on block hashes, against the miners but giving the miners a slight "house edge".  This means that honest miners which produce unpredictable and truly random block hashes are (on average) rewarded, while miners that have a skewed distribution (e.g. because they manipulate random numbers) can be punished under the right circumstances.

For instance, let's consider a very simplified situation, that can be generalised for a real application:  Anyone can submit transactions to the blockchain that contain a hashed bet H(nonce | height | bit), predicting what the least-significant bit of the block hash at a (future) height will be.  They can bet an amount N of their choosing, perhaps within certain limits.  If they later reveal their bet and it is correct, they get N * (1 - eps) from the miner that mined that block and their bet back, where eps > 0 is some small parameter.  If they lost or do not reveal, then the miner of the block gets their bet of N.

This means that honest miners win on average, although the scheme of course increases risk and variance of miners.  Players that actually participate also in a casino game based on the least-significant bit of a block hash can hedge their bet, but if they do, they will just lose for sure.

However, if a player or other user monitoring the blockchain has reasons to believe that miners are manipulating the random numbers, they can make money
and punish miners if they are right.  This should serve to rectify miner incentives.

Of course, there are a lot of open questions and potential issues with this proposal.  A non-exhaustive list of issues that I can think of for now is this:

• As this increases risk for miners and their variance (even if honest miners win on average), it may lead to even more centralisation or just discourage miners in general.
• Miners may try to simply not confirm any bets to avoid any risk (or being caught if they manipulate hashes).  But if there are multiple miners on the blockchain and users can bet on arbitrary block heights (not just the "next" block), there may always be a chance to get a bet confirmed by some miner, in particular when combined with additional rewards for the confirming miner or high transaction fees.
• There needs to be an in-depth analysis of the game theory underpinning such a system to see how much the mining incentives are really "fixed" by that (depending also, of course, on the limits to bets and the constant eps).

Nevertheless, I think this idea might be interesting and promising, so I would like to get early feedback on it before working it out in more detail and with proper maths.  Is there any fundamental flaw that I overlooked, or can such a system be made to work?

I'm trying to fully understand how P2SH (BIP16) works, and I thought I did.  For fun and to check my understanding, I disabled BIP16 in Bitcoin Core (setting BIP16Height in chainparams to a high value) and tried to "sign" a transaction spending a P2SH output by just providing the redeem script.  According to my understanding, this should be enough pre-BIP16, since it will make the "OP_HASH160 <hash> OP_EQUAL" script of the P2SH output succeed, right?  But that seems to be not the case.

In regtest mode, I created the following P2SH address:

Code:

$ addmultisigaddress 1 '["03c278d06b977e67b8ea45ef24e3c96a9258c47bc4cce3d0b497b690d672497b6e", "0221ac9dc97fe12a98374344d08b458a9c2c1df9afb29dd6089b94a3b4dc9ad570"]'
2MwCrk6S9UEeFujacKe7m4uDCzu25F3VAeM

$ validateaddress 2MwCrk6S9UEeFujacKe7m4uDCzu25F3VAeM
{
  "isvalid": true,
  "address": "2MwCrk6S9UEeFujacKe7m4uDCzu25F3VAeM",
  "scriptPubKey": "a9142b6defe41aa3aa47795b702c893c73e716d485ab87",
  "ismine": false,
  "iswatchonly": false,
  "isscript": true,
  "script": "multisig",
  "hex": "512103c278d06b977e67b8ea45ef24e3c96a9258c47bc4cce3d0b497b690d672497b6e210221ac9dc97fe12a98374344d08b458a9c2c1df9afb29dd6089b94a3b4dc9ad57052ae",
  "addresses": [
    "mg41i3DBptiWbQ9PQ59ykdbc8T85gEqWdK",
    "muC6tdGQrYXSqghPZziyvZwu1KSwL49ioy"
  ],
  "sigsrequired": 1,
  "account": ""
}

And funded it:

Code:

$ sendtoaddress 2MwCrk6S9UEeFujacKe7m4uDCzu25F3VAeM 10
14e8f61534b9a0b6110655dc153d41cc90f64b8104b820e1f4534fd14a732df0

$ generate 1

$ gettxout 14e8f61534b9a0b6110655dc153d41cc90f64b8104b820e1f4534fd14a732df0 0
{
  "bestblock": "40d573ebb78bdab760d6659b8ad9d91c46633144d25084eaf3de1f7411040305",
  "confirmations": 1,
  "value": 10.00000000,
  "scriptPubKey": {
    "asm": "OP_HASH160 2b6defe41aa3aa47795b702c893c73e716d485ab OP_EQUAL",
    "hex": "a9142b6defe41aa3aa47795b702c893c73e716d485ab87",
    "reqSigs": 1,
    "type": "scripthash",
    "addresses": [
      "2MwCrk6S9UEeFujacKe7m4uDCzu25F3VAeM"
    ]
  },
  "coinbase": false
}

Then, I tried to spend it by providing just the serialised redeem script as scriptSig, but this fails:

Code:

$ decoderawtransaction 0100000001f02d734ad14f53f4e120b804814bf690cc413d15dc550611b6a0b93415f6e814000000004847512103c278d06b977e67b8ea45ef24e3c96a9258c47bc4cce3d0b497b690d672497b6e210221ac9dc97fe12a98374344d08b458a9c2c1df9afb29dd6089b94a3b4dc9ad57052aeffffffff0100e1f505000000001976a914cf112b41997697caa3eee9e308ad9b2b917b4e4c88ac00000000
{
  "txid": "1971750cd655c7f93627354c380595e3e3434b69c3b6e788eecfb9c685eba703",
  "hash": "1971750cd655c7f93627354c380595e3e3434b69c3b6e788eecfb9c685eba703",
  "version": 1,
  "size": 157,
  "vsize": 157,
  "locktime": 0,
  "vin": [
    {
      "txid": "14e8f61534b9a0b6110655dc153d41cc90f64b8104b820e1f4534fd14a732df0",
      "vout": 0,
      "scriptSig": {
        "asm": "512103c278d06b977e67b8ea45ef24e3c96a9258c47bc4cce3d0b497b690d672497b6e210221ac9dc97fe12a98374344d08b458a9c2c1df9afb29dd6089b94a3b4dc9ad57052ae",
        "hex": "47512103c278d06b977e67b8ea45ef24e3c96a9258c47bc4cce3d0b497b690d672497b6e210221ac9dc97fe12a98374344d08b458a9c2c1df9afb29dd6089b94a3b4dc9ad57052ae"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 1.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 cf112b41997697caa3eee9e308ad9b2b917b4e4c OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914cf112b41997697caa3eee9e308ad9b2b917b4e4c88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "mzPpjgciTo6DMGpE3Lkb4ZLBSn8A239aDZ"
        ]
      }
    }
  ]
}

$ sendrawtransaction 0100000001f02d734ad14f53f4e120b804814bf690cc413d15dc550611b6a0b93415f6e814000000004847512103c278d06b977e67b8ea45ef24e3c96a9258c47bc4cce3d0b497b690d672497b6e210221ac9dc97fe12a98374344d08b458a9c2c1df9afb29dd6089b94a3b4dc9ad57052aeffffffff0100e1f505000000001976a914cf112b41997697caa3eee9e308ad9b2b917b4e4c88ac00000000 true
error code: -26
error message:
16: mandatory-script-verify-flag-failed (Operation not valid with the current stack size)

As you can see, the scriptSig of the raw transaction I try to send matches the hex of the P2SH address.  (A very similar script is sent for a correctly signed spending of the P2SH output, except prepended by the actual signatures as mandated by BIP16.)  From my understanding of how P2SH works, this should be a valid script pre-fork.  Can someone please explain to me what I'm missing here?

In case someone is interested, I've written a paper about Bitcoin's difficulty retargeting.  It contains a model for Bitcoin mining, which explicitly focuses on the difficulty updates as well (they seem to be underrepresented in existing research).  The paper also proposes an alternative difficulty update strategy which gives more stable block times for longer periods of exponential growth.  The latter is quite interesting from an academic point of view, but not really relevant in practice.

The paper is published by Springer at http://link.springer.com/article/10.1007/s12083-015-0347-x, and the postprint is (without paywall) on my website at http://www.domob.eu/research/DifficultyControl.pdf.

EDIT: I should probably have added the abstract here:

Crypto-currencies like Bitcoin have recently attracted a lot of interest. A crucial ingredient into such systems is the “mining” of a Nakamoto blockchain. We model mining as a Poisson process with time-dependent intensity and use this model to derive predictions about block times for various hash-rate scenarios (exponentially rising hash rate being the most important). We also analyse Bitcoin’s method to update the “network difficulty” as a mechanism to keep block times stable. Since it yields systematically too fast blocks for exponential hash-rate growth, we propose a new method to update difficulty. Our proposed method performs much better at ensuring stable average block times over longer periods of time, which we verify both in simulations of artificial growth scenarios and with real-world data. Besides Bitcoin itself, this has practical benefits particularly for systems like Namecoin. It can be used to make name expiration times more predictable, preventing accidental loss of names.

(I hope this fits in this forum section since it is about "the Bitcoin network".  If not, feel free to move it somewhere else.)

Does Bitcoin Core's "verifychain" in level=3 accept the duplicate transaction ID's in the chain (those that fail strict BIP30 checks, as listed in main.cpp in ConnectBlock)?  I have the feeling that the strict check done in DisconnectBlock (that the tx outputs currently being undone match between what's in the block and what's in the coin view) could fail for those.  Unfortunately, I'm not able to check this "live" as it would require way too much memory.  I. e., while checking, the coins cache is filled and then level=3 checks are skipped for deeper blocks.

If my suspicion is right, is this simply not "fixed" because it does not matter, or is there some other reason?  (One could, for instance, move the list of BIP30-failing hashes to the chain parameters and use it both for fEnforceBIP30 as well as ignoring those DisconnectBlock failures.)  If, on the other hand, this is not a "problem" and DisconnectBlock works for those, why?

I'm working on a research paper about Bitcoin, and would like to give a quick historical introduction into how Bitcoin evolved.  I'm obviously aware of HashCash as a precursor to the PoW-aspect.  Is there also an earlier system that used digital signatures to transfer ownership of "coins"?  My impression so far was that Bitcoin "only" innovated in solving the double-spending problem.  But looking around, I can't really find any earlier system where such a signature scheme was proposed.

I can find Hal Finney's RPOW proposal (although information is not really dense about it), but from what I found, this is more like Chaumian cash in that some central instance is used to issue and redeem tokens.  I appreciate any pointers to earlier ideas that proposed already the signature scheme - if there are any.  Maybe my feeling is just wrong.

[how]

I wonder whether it may be a good idea to give users the option (not mandatory and not by default) to remove old blocks from disk (the undo and block files).  This could allow them to run "full nodes" with much less required disk space - but still the same trustlessness as a real full node.

From digging into the code, I found these places where the files are used/read:

Undo files:

• ConnectBlock (written) and DisconnectBlock (read):  The obvious places, but they only need "recent" files (at most until the last checkpoint).
• VerifyDB in a high level:  Removing old blocks will obviously prevent us from verifying their integrity, but that is no problem.

At least for the undo files, it should be straight-forward to allow removing old ones without sacrificing any functionality at all.  It would save quite some disk space.

Block files:

• ConnectTip/DisconnectTip:  They only need recent ones, so removing "old" blocks (before the last checkpoint) should be fine.
• -reindex and friends, -printblock, getblock RPC, PrintBlockTree:  Obviously, but these are "extra functionality" that is not necessary to run the node.  Users who want to use them should be sophisticated enough to know what they are doing when deciding to prune blocks from disk.
• VerifyDB in a high level:  Same as with the undo files.
• getrawtransaction (without tx index) and rescanning for wallet transactions:  This is also functionality that is not strictly necessary to run the node.  Again, users who prune blocks should know what they are doing and that this may compromise the ability to import private keys and the like.
• Processing network requests for blocks:  See below.

In my opinion, the only "critical" functionality that is removed when old blocks are deleted is the ability to send those blocks to other nodes while these are trying to bootstrap.  If not too many nodes prune blocks and/or not all blocks are pruned but instead only a random fraction, it should still be possible for other nodes to bootstrap.  In addition, more networking logic could be added (if asked for a block that has been removed, ask your peers for it and optionally store it again).

Another issue is the how of removing blocks from disk.  The simplest way is probably to remove whole block files, since otherwise we need to add a system that tracks empty places in the block files to reuse them for later blocks.  This seems like overcomplication.

What do you think of these ideas, are they worthwhile or not?  Are there already ideas about how to do networking (bootstrapping) when nodes may remove blocks from disk?  I'm willing to work on this if the idea is appreciated and if the consensus is that such incomplete nodes would not be too bad for the network.  (After all, it may lead to more people running "full" nodes if less disk is required!)

Look what my sister found hiking in the Raabklamm, Austria!   And it wasn't done by me:

Ich würde mir gerne bei Eventim.de Tickets kaufen, allerdings wird Bankeinzug aus "technischen Gründen" (vielleicht, weil ich aus Österreich bin?) nicht angeboten, Kreditkarte habe (und möchte) ich keine, und Vorkasse geht nicht, weil die Tickets anscheinend nicht so lange reserviert werden können.  Klassischer Fall von Bitcoin-Zahlung würde das Problem lösen halt.

Möchte hier jemand die Tickets für mich an einer Vorverkaufsstelle (oder vielleicht auch online mit Kreditkarte) kaufen?  Es sind so um die 280 Euro, glaub ich.  Ich biete 300 Euro in Bitcoin (zum aktuellen Kraken-Kurs) inklusive Versand nach Österreich (ist aber verhandelbar).  Ich bezahle gerne vorab bei vertrauenswürdigen Members, ansonsten Multisig mit vertrauenswürdigem Escrow.

Bitcoin Core has the start-up option "-printblocktree" to get information about the blockchain status, in particular, potential chain forks the client knows about.  I think it could be handy to have the possibility to access this same information also via an RPC call - this can be used from within a running daemon, and external services (web applications using the daemon internally, for instance) could use this to detect chain forks.

I've implemented something like this already for Namecoin and originally Huntercoin, see https://github.com/chronokings/huntercoin/pull/19.  This implements a simple new RPC command "getchains" (the name could be changed, obviously) with output like this:

Code:

[
    {
        "height" : 249522,
        "hash" : "458354cbd80c350045076193030d75dbcbb007d76f4960dbc6b00d560b77065d",
        "is_best" : true,
        "branch_len" : 0
    },
    {
        "height" : 249522,
        "hash" : "a18a3d1848e095297b41b9f921f5b86086c165ba9dff7e30d286c36373f334be",
        "is_best" : false,
        "branch_len" : 1,
        "branch" : [
            "7e78dc70d073a164ab66b066f2413578648b4d3ecc0d72ef9be2132faab36b82"
        ]
    },
    {
        "height" : 237894,
        "hash" : "b2274b69cf1e8ebd23c560b8b9811fe17c48720e0fb96e8f3ee5b5f5fffea27a",
        "is_best" : false,
        "branch_len" : 2,
        "branch" : [
            "28d1151f24990831e89bccfa1131a9387013ee3fdc946bf6fe8efa2d0c7a7a34",
            "c1ffb74675d2d23e087f026266d0f90096e4d1d6e7979b5638ed3be024f58543"
        ]
    },
    {
        "height" : 237865,
        "hash" : "0c0509b3d6e30663d7c96a0337d43223ce759b725a124a5892399efa37c9134b",
        "is_best" : false,
        "branch_len" : 3,
        "branch" : [
            "ddb0cb645af22155d652382ae03143401b733eb5b7981a9e9ba8b9f7632f4910",
            "ff6b5f794c08e8ca45682db3fe8ec715d31fb57159b2c90f2a0b7300b5e88b45",
            "6e60b1718f923c888f34d773eee6aa753c7f22e4405a128fc59740f98a8be61c"
        ]
    },
    {
        "height" : 87393,
        "hash" : "fef9f102dc000e0069e3042526032327bc618453b5bc0d8ca25ee5509028e628",
        "is_best" : false,
        "branch_len" : 12,
        "branch" : [
            "50926027c1fe34e43c59d8bf84a475e56bd63e62bf4a2e5756fea68ddbd00910",
            "648927b7b456d36a0a2baa68b57a51ad9878b10b1d708187acfeeb8f8b74ebe2",
            "e0872226a925cbf552557ba3f6a7d072fa6ee4f119da8719acfc5e3fb0477c1b",
            "841df107ac58c51d4ee4346b716e086368c987355cf6b854d8c423f31db4431b",
            "e28701a3bab940f3ec81cd0324ccb47cb34dfd8cc30211b23f3532cabb578d44",
            "9742dbcc4d447054a135255c720c286ff498002cda408f6c5e98d7c8fb4d3454",
            "92b463b45ec5afccfc7dc14a774b681966f9fa4740653bbf520eaa0b25d01049",
            "2c88dae0637e5977ebeb2367675c71e43c259b9ead16ed30fbb3135d989e9266",
            "8aa82978461c0dc812160ffcf4fc89a780f1d67e3a29123c318238eaa9b5facf",
            "f244148b7e02839787452481b9b76cb166718410f082b688b565644e18d3be1e",
            "91d4acdf2a641d7b545b4b73323db69eda60520ec21ba86e885e3a83f886c4e3",
            "497e0d08cef9c85e20fe7d758c3bf6010072105a6a2b33123b524e8413e45b69"
        ]
    }
]

What do you think about adding this or similar functionality also to Bitcoin Core?  Would a pull request be welcome?  I would be interested in working on a patch to implement this for Bitcoin Core.  Of course, the precise output format and other details can be discussed freely, and I will implement them as desired.

Looking at Bitcoin's serialize.h and in particular the WRITEDATA / READDATA macros, I wonder how this handles byte order / endian-ness issues correctly.  Seemingly, primitive data types (for instance, (unsigned) integers) are serialised just as they appear in memory.  The same seems to be true for the individual "words" (uint32_t each) of uint256.  I can not find anything that handles converting to a unified byte order.  Aren't these routines also used to compute the hashes and to transmit data over the network?  At least for these uses, shouldn't the byte order be "normalised" somehow?

I'm probably just missing something obvious, since I've only started looking at these pieces of the code.  What is it?

Are there (more or less "mainstream", so no prediction markets or things like that) financial instruments available that can be used to hedge against a rise in interest rates?  In other words, something which correlates positively with reference interest rates (of the ECB, for instance).  What can be used to achieve this?

I have absolutely no experience with these things yet ... but am sure someone here has.  A wild guess would be some leveraged bet on bonds.  But I'm not sure how strong they really correlate with the precise reference interest rate.

It seems that Apple is looking into (ab)using all the credit card information it has of its "beloved" customers for building up its own payment service: http://www.macrumors.com/2014/01/24/apple-mobile-payment-service/

Maybe this is why they used all they censorship powers against Bitcoin in the past?  But I guess they will fail in the end, and Bitcoin will win anyway.

I want to create a paperwallet, and think that TAILS (https://tails.boum.org/) could be a good choice for doing so securely.  Ideally, I'm thinking of the following workflow:

1) Disable WiFi on my laptop using the hardware switch and boot into TAILS.

2) Create a private key and address, encrypt the private key with a strong passphrase (using GPG), and save it to a flash drive.

3) Shutdown TAILS without ever enabling network access, boot into the main system, and print the encrypted private key.

This ensures that, even if my main system is compromised (I hope not), the passphrase used to encrypt the private key is never accessible to malware; assuming that the TAILS image itself is not already compromised, TAILS is written to not leak any data on persistent storage, and furthermore the system on which the private key is accessible in clear text will never be connected to the internet.

Does this sound like a reasonably good way to create a (long-term storage) address?  The problem I now have is the question, which tools to use to generate the address.  TAILS unfortunately does not include any Bitcoin tools and also doesn't come with gcc (although it can probably be installed using pre-downloaded apt-packages if I try hard enough).  I see the following options:

1) Use the bitcoind binary download.  I tried this, but it seems to not start up when not connected to the internet and no blockchain data is present.  Unfortunately, TAILS doesn't give me enough storage to keep a full blockchain.  Is it possible to start up bitcoind and use it to create a wallet and export a private key without ever connecting to the internet and ever downloading a single block?

2) Vanitygen:  Here I would also need a 32-bit binary, which I would have to try to find (not sure whether one is provided, usually I use the sources - but I would have to cross-compile them to 32-bit from my main system which uses amd64).  Is this a secure method to generate addresses, considering entropy?  I think it allows to seed the random-number generator with some arbitrary file, which could be generated from /dev/random earlier.

3) Using a downloaded version of bitaddress.org.  This works, but I'm hesitant to use that because I'm not sure about the security of the generated data.  Is the entropy good enough?  Of course, I could also generate a file from /dev/random, hash it, and use the resulting hash as passphrase to a brain wallet.  Do you think this is a secure enough method that I can trust?  Is the used crypto in JS code stable enough to trust it with generating a long-term storage key?

What would you suggest?

Heute Vormittag sind für einige Stunden die Bankomaten in Österreich auf Grund eines Serverfehlers ausgefallen: http://futurezone.at/digital-life/bankomaten-streikten-stundenlang/32.874.356  Dieses System ist wohl zu stark zentralisiert, da wär eine dezentrale Lösung viel besser.   Gemerkt hab ich's allerdings nicht, weil ich Bitcoins hab und solange, bis ich damit auch in meiner Umgebung zahlen kann, halt auch übergangsweise immer auch so ausreichend Bargeldreserven.  Bitcoin user not affected.

Let me announce libnmcrpc: https://gitorious.org/libnmcrpc  This is a C++ library that implements a JSON-RPC client to talk to the RPC interface of Namecoin or Bitcoin.  While I wrote it for Namecoin and will be using it that way, the general RPC calling mechanism (which is the part already implemented) can talk to Bitcoin (and other coins I presume) just as well.  I'm planning to add higher-level functions for Namecoin features in the future, but this will not impact its ability to be used also with Bitcoin if the correct RPC calls are formulated manually.

I'm posting this here in case someone finds it useful, it is free software (LAGPLv3).  Note that it is still very much work in progress, but in my tests the RPC calls worked already fine.

I've been thinking recently a little about the attack with compromised sites on Freedom Hosting (http://www.wired.com/threatlevel/2013/08/freedom-hosting/), and can't really make sense out of it.  Of course, the attack seemed to be successful in uncovering the identities of some of the people who tried to access sites on Freedom Hosting (and got a "Down for Maintainance" page instead according to the reports).

But what exactly does this use the FBI?  All they have is a proof someone tried to access a particular .onion site - but didn't succeed in accessing any illegal material because they took it down already.  Is this already a criminal offence for which they can hope to jail those people, even though there's no proof that they actually accessed such material (like child porn) in the past?  At least as far as I know the laws in my country, that would be difficult to argue in court (apart from the fact that I'm not sure how evidence gained by such an attack would be valued).  If they on the other hand just wanted to identify "suspects" in order to investigate further and search their computers, I think that everyone of those people should have heard about the attack already and just wiped their computers.

What am I missing here?

Anscheinend fände das nicht nur ich eine gute Idee:

http://futurezone.at/netzpolitik/17101-snowden-fuer-friedensnobelpreis-vorgeschlagen.php?rss=fuzo

Bei der Gelegenheit könnte man den Preis gleich auch an Assange verleihen (wobei ich nicht weiß, ob geteilte Preise wie in den Naturwissenschaften auch beim Friedensnobelpreis üblich sind).  Wäre interessant zu sehen, wie die USA im Vergleich zu China darauf reagieren.  (Oder ganz gleich.)