Okay. I see.
We have already seen these fastflux bonnet detecting. Check https://www.reddit.com/r/Bitcoin/comments/3g8htv/certsi_filed_an_abuse_complaint_with_my_isp_for/.

Just replay to Hetzner that everything is okay and the report was a false positiv.

We are working on a solution (TTL DNS)

Can you post the Abuse-Mail content?
Do you run a dnsseed or just a standard node?
Thanks.

Thanks for precision.
Right, every address (including change addresses) generated "after" the encryption happened, was never exposed in a unencrypted wallet.

Some additional thoughts/informations:

1) recovery phrase like the electrum does as greg mentioned (~bip39) in case you have lost your wallet (encrypted or unencrypted) requires a bip32 hd wallet: at the moment not supported by bitcoin core.

2) Current bitcoin-core always creates a unencrypted wallet at first start. If one decides to encrypt the wallet, all used private keys (`getnewaddress`, change addresses) where exposed plaintext over the wallet.dat file during the time between creation and encryption.

3) An encrypted wallet is basically not an encrypted wallet. Only private keys are encrypted. Public keys, wallet transactions, labels & comments are plaintext stored in wallet.dat.

Would it make sense to store the mempool on-disk?


LevelDB (kv store) seems pretty much the thing we need for bitcoin-core (there is no need for extensiv querying if you don't want to run a block explorer). What alternatives would you propose today? Would it be worth implementing (balance between (implementation-time+risks <==> benefits-of-a-new-database)? How would you handle migration, testing on serval filesystems?

We see here multiple problems:


a) DNS Seeder (only affects the handful of operators who runs a dns seed)
This solution should not bother normal bitcoind nodes.

b) Nodes which cannot connect to sipas dns seeder because some system has detected his IP as malware severing IP because it does netscanning (that is what a seeder needs to do). Maybe IPSs share informations about malware serving IPs.
This is not a problem for a bitcoind node, because it can fetch IPs over different seeds or over the internal static list. As soon as one feasible IP/connection could established, more IPs come in over getaddr

c) ISP detect portscanning behavior on a bitcoind node:
Nodes can send you unroutable IPs addresses though getaddr. Example: 242.0.0.1. If your bitcoind then try to connect to this ip, no route can be found and your ISP might detect this as a port scan.
You could solve this theoretical problem by using tor or limit max connections.

However I'm not running the above bitcoin-seeder app, so I'm not sure how that PR would do anything for me. (I'm only running bitcoin core and P2Pool)
[/quote]

Sure.
If i'm right, for bitcoind you could use -proxy= for connect to nodes through tor. Your ISP could then no longer detect a port scan pattern.
But your communication speed between your node and connected nodes might drop.

Once approche would be to reduce the amount of connection with the `--maxconnections` argument.
Or your a tor SOCK5 proxy for outgoing connections.
Similar like the patch i wrote for the seeder: https://github.com/sipa/bitcoin-seeder/pull/29

Yes. I'm talking about sipas public dns seeder (https://github.com/sipa/bitcoin-seeder).

I had to pragmatically change the function CNetAddr::IsReserved() to:


Hetzner (the datacenter provider) was informing me about some detected unallowed netscans:


Because the crawler/seeder uses getaddr it might retrieve IPs from a non-routable range.
So it very likely that a host running sipas seeder might be seen as botnet or server/IP that acts like a botnet controller.

 
I also had to patch (didn't open a PR) the dns seeder to avoid blocking through Hetzner (datacenter).
The dns seeder does a very aggressive scanning.
I got serval abuse mails because Hetzner detected non valid routing to non public and not routable IPv4 ranges.

Just wanted you to know that I'm working on this problem by rewriting most of the bitcoin-cores wallet: https://github.com/jonasschnelli/bitcoin/tree/2015/05/corewallet

So help is on the way, but not for today and tomorrow.

You can call
(mind the true = verbose).

If you have to do multiple rpc calls, check out the JSON RPC 2.0 batching options (since bitcoind 0.7 aggregate multiple rpc calls in one). If you need more details check the bitcoin-core source and search after
There is a pull request for mempool REST call (https://github.com/bitcoin/bitcoin/pull/6013).

0000000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f010000

First 4 bytes (00000000) is the chain height (int32)
Next 32 bytes (6226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f) is the chain tip hash (little endian notation, so it's "reversed")
Next 2 bytes (0100) is the bitmap where you can see if your queried outpoints are in the UTXO set. 01 = size, 00 = not in set (first queried outpoint is not in set,...).
Next 1 bytes (00) is a serialized vector of a Coin (uint32_t nTxVer, uint32_t nHeight, CTxOut out). In this case it's empty.

Also mind that you can have JSON output for getutxos:

/rest/getchaininfos is not available in the 0.10 branch [1].
You should test the rc2 of 0.11 (https://bitcoin.org/bin/bitcoin-core-0.11.0/test/).

[1] https://github.com/bitcoin/bitcoin/blob/0.10/src/rest.cpp#L223

Have a look here:
https://github.com/bitcoin/bitcoin/pull/5228
https://github.com/bitcoin/bitcoin/pull/5219

Bitcoin-Qt should be retina capable soon.

It's not as hacky as it sounds like.
It doesn't require a jailbreak.
The iOS wallet app could also been made open source so people can check what's going on.

Sorry to say that, but in future, nobody will use web-wallets (or similar) where the user doesn't own the private key.
What have we learned from Mt.Gox?

The one who don't own the private key they don't own the bitcoins signed with them!

In my eye, only a nativ iOS wallet will have success.

Would you trust your money to a startup company?
I wouldn't.

You didn't read my plan. did you?

Where are the private keys stored?
On your webserver?


We are looking for a real native solution!

It would be easy to sneak into the iOS world (without jailbreak requirement!).
Look here, let's get inspired:
http://gba4iosapp.com/download/

The steps are:
-> found a small company (cost around 2-3 BTC depend on origin country)
-> apply for Apple iOS Enterprise Programm (299$ = 0.5BTC)
-> create iOS wallet app (this might be difficult)
-> sign the app with your enterprise provisioning file
-> provide a custom download page: http://gba4iosapp.com/download/
-> apple then probably then revoke your certificate
-> tell users to set back the date during the download/install of the app

Guys

Look once at http://gba4iosapp.com/.
They got a enterprise deployment program from Apple (299USD per Year) and built and signed a by-apple-not-allowed iOS app.
Now, of course, Apple pulled-back the certificate, but everyone can install the app via web when setting back the iOS system date to date before when apple pulled-out the certificate.

Why should we not do that with a nativ iOS wallet?

1) Found a small company
2) Register for a enterprise program
3) sign app and make it public downloadable
4) wait till apple pulls back the certificate
5) inform user to set back the date (and blame Apple) while installing the app
6) set the date back to "now"