Why don't you spread the release of the keys out over a few weeks instead?

The collections of identical keys are almost always due to hardware devices that generate a key on first boot, before they have any entropy. I doubt the JDK will ever be backdoored given the scrutiny it gets, but using Zulu or compiling OpenJDK yourself is not a bad mitigation if you're worried about it.

The app itself lets you "revoke" a pledge i.e. double spending it back to yourself. That's pretty fundamental to the whole model and is why money doesn't get stuck if a project never makes it to the finishing line. It also keeps it low risk for the pledgor - if they suddenly need the money for some reason it's always available to them.

Without SIGHASH_ANYONECANPAY Lighthouse would still be possible, just with a much worse UX. Basically you'd have to inform the project owner of which output you wanted to use, and then once enough value was pledged, the owner would have to construct a transaction with everyones pledges in it and then pass it around for everyone to sign. It'd be a two step process - very ugly. With the malleability features it's "fire and forget", much easier.

The source is here:

https://github.com/citp/TwoFactorBtcWallet/

They've eliminated the trusted setup requirement.

Do those clients actually support regtest mode? BitcoinJ supports it because I implemented regtest mode for my own use, but I'm not sure if others ever really picked it up.

ScripterRon, rather than use JNI you could look at JNA. It will let you eliminate all the C code from your project and just call into the library with a regular Java interface. It's much more convenient.

At the moment there isn't any way to fix this beyond telling the user to make sure their clock is correct. But you could just fetch the correct time from a trusted server, if this is really a frequent issue. E.g. just make an HTTPS request to google.com/gen_204 and then check the Date header.

There is no error in bitcoinj. That field is meant to be in seconds, as a quick inspection of the usage sites would have shown you.

As you have discovered, your system clock is wrong and that's why blocks were being rejected. Bitcoin requires a correct system clock and always has.

Yep, that sounds right. You can inherit from AbstractWalletListener to avoid having to implement empty methods.

Unless you use an external index of the block chain, there is no way to know about transactions to an address without actually scanning through it.

Cool! Tip sent

You might want to look at this project:

https://code.google.com/p/lanterna/

It could be used to create a pseudo-graphical updating list of transactions, like if you want to have your wallet running inside a screen rather than pure command line based.

If you made an installation procedure that didn't involve catting random shell scripts to a root shell, perhaps you could get it listed on bitcoin.org

You can look at the source of bitcoinj to see how it works, or read BIP 37.

Sigh. You know I have the deepest respect for you Gregory, but this is not the first time I get the feeling you're commenting on things I've written without having read them closely

I said:


I know how the code is currently written. I first read it a few months after it was released, remember But being concerned about an extremely common class of errors is hardly weird. Multiple people on this thread have brought it up.

My experience of working on several large C++ server codebases at Google is that it's quite possible to write robust code ... for a while. When you have a single thread, everything is written by one guy and all data is request scoped, the tools C++ provides can work very well.

But eventually one of the following happens:

1) Someone introduces multi-threading for better scalability, resource management, use of a blocking library etc, and accidentally writes code that races
2) Someone refactors code written by someone else and uninitialised data creeps in
3) Someone starts using a third party library that isn't written in the same way and requires manual heap management (like OpenSSL)
4) Someone profiles and decides to reduce the amount of copying that is going on

More generally: things change, teams change and software gets more complicated. Because nothing in C++ forbids manual memory management and some things require it, eventually it ends up being used. And some time after that, someone makes a mistake.

We can't magically convert Bitcoin Core to a safer language with a stricter type system. We can anticipate that mistakes will happen, and try to put in place systems to automatically catch and handle them.


This sounds somewhat like the Checker framework. It is a pluggable type system for Java. I'd like to see it adapted for Scala and Kotlin too. It has a number of very practical type systems that catch practical errors like mixing up seconds and milliseconds and other unit mismatches.

Does iOS not detect gated wifi networks already? Android pops up a notification when it spots one of these.

If you vend requests that use the payment protocol and Breadwallet supports it, then you should be able to receive transactions via HTTP(S) directly instead of via the p2p network.

You can just use the WalletTool program from the bitcoinj source code with a wallet file.

Andreas told me he wants to be careful about exposing the seed words because it can break in various edge cases e.g. if you have an old wallet that has pre-HD keys in it and then you think all you need are the post-HD seed words. So it will take some effort and testing to get it fully right.

I would say that we've got very lucky with respect to Bitcoin Core:  Satoshi was a very careful developer who knew C++ very well and maximised use of its features to increase safety. The developers who followed him are also very skilled, know C++ very well and know how to avoid the worst traps.

The main concern with Core is not that the code is insecure today, but what happens in the years to come. Will the people who follow Gavin, Pieter, Gregory etc be as good? What about alt coins? What if a refactoring or multi-threading of some performance bottleneck introduces a double free? Anyway, not much we can do about this except try and make the environment as safe as possible. I've made some suggestions on how to do this in the past (auto restart on crash, use Boehm GC) and normally Gregory likes to point out possible downsides but I'm not super comfortable relying on "don't make mistakes" as a policy over the long run.

WRT RNG issues in Java, I'm not aware of any beyond the Android bugs, which were very severe but didn't have anything to do with Java as a language or platform. If there have been issues in Java SE I don't recall hearing about them. Bypassing in-process RNGs is still a good idea though.


It's also true of C (e.g. AES keys can persist in XMM registers for a long time after use). Although hexafraction is right that on HotSpot you can do manual heap allocations, it doesn't matter much. If an attacker has complete access to your address space then this is so close to "game over" that it hardly makes any odds whether there are multiple copies in RAM. Even if the password isn't lying around, they can just wait until it is. I'm not a big fan of spending time trying to "clean" address spaces of passwords or keys.

Note that for core crypto, it's looking more and more like long term everything will have to be done in assembly anyway. Pain.

Yes it is since v4.0.

I think Andreas will expose the seed words at some point. Not sure what the delay is.

I wrote an article about some of the failures in wallet randomness we've seen in the past 12 months:

  https://medium.com/@octskyward/type-safety-and-rngs-40e3ec71ab3a

It's a 6 minute read, but the tl;dr summary is:

1) Find ways to make the type systems you are working with stronger, either through better tools or better languages

2) Try and get entropy as directly from the kernel as possible, bypassing userspace RNGs

I should practice what I preach - bitcoinj could be upgraded to use the Checker Framework for stricter type checking, and we currently only bypass the userspace RNG when Android is detected. I'll be looking at ways to make things stricter and more direct next year.

Yes by running a regular full node you are contributing resources that bitcoinj based wallets will use (along with other SPV wallets like BreadWallet)

Yes for now the wallet has to specify outputs explicitly. BIP70 doesn't have any kind of generation support in it at the moment. Besides, they are supposed to expire after a while to let wallets forget keys.

WRT NFC - you can also use Bluetooth to transfer the payment request. Andreas Schildbach's wallet and derivatives support this.

Yep. The new lower fee is accepted by most miners, it seems.