I'll be there!

Here is a short version of a text-to-key algorithm, resulting from a discussion with gmaxwell and etotheipi. I'm currently working on other things, but I hope it can already provide some inspiration.

The idea is to have both a variable number of iterations, and a checksum (by not allowing every possible input text).

To go from text T to key:

• Calculate SHA512(SHA512(...(SHA512(T))), with 256 iterations
• If the 256th iteration results in a hash that starts with 8 zero bits, output the 255th iteration result as key
• If not, do more iterations, until the 512th
• If the 512th iteration results in a hash that starts with 9 zero bits, output the 511th iteration result as key
• If not, do more iterations, until the 1024th
• If the 1024th iteration results in a hash that starts with 10 zero bits, output the 1023th iteration result as key
• and do on ...

So you sacrifice some bits in checksums, but compensate those exactly by more iterations. This way, the seed text itself  encodes the number of iterations, and an attacker cannot know the right number in advance, preventing a short way out.

A more complex version, with some mathematical guarantees is derived here, but there is little explanation.

In my opinion, Bitcoin is a digital currency, and not a payment processor. Since it is digital, one can much more easily build payment processors on top of it.

Currencies do not provide the ability to revert transactions. You cannot ask a paper dollar to return to your hand when the other party does not provide a requested service. The only difference is that in the Bitcoin world, the other party is rarely physically close while doing the transaction. If that means you require a money-back guarantee, I suppose it shows the need for payment processors (that you can trust...).

I don't think this is an issue. Over time, solutions will develop that work similarly to what you're used to, if they are needed.

Orphan blocks (blocks whose parent is not known) are never stored on disk. They are kept in memory while their parents are requested.

Stale blocks (those connected to genesis, but not in the current best chain) are stored on disk, as blk000?.dat + blkindex.dat represents the whole (known part of the) block tree, not just the best chain. You need the side chains in case of reorganisations.

That said, yes optimizations are possible, and you could theoretically remove old stale blocks once the best chain has progressed enough. But as the blk000?.dat files are monolithical, you can't just remove parts of without rewriting the entire file.

I think this is a minor issue only, as the percentage of stale blocks in a typical blk000?.dat file is quite low. I also don't intend to change this in my experimental ultraprune branch. What it will do is use smaller blk000?.dat files (smaller number of blocks per file), and support removing old block files entirely (even when they still contain unspent outputs).

Right, addrman is not primarily intended to optimize quick connections. Its first priority is preventing sybil attacks, and limited disk/memory usage.

I'm not sure you're looking at the same dictionary that "professional" password crackers use.

From the many password database leaks that have already happened in the past, there are known passwords of over 10 random-looking characters that have been cracked, presumably just from the leaked SHA hash. I don't have an example myself, but please don't just assume that because you can't crack something yourself, nobody can. Everyone is smart enough to devise a system he can't crack himself. Realize that the bitcoin network itself has done almost 2^70 SHA256 operations already, enough to traverse the entire space of up-to-11 characters alphanumeric passwords.

If you're really creating a wallet based on a passphrase, do the math. A word chosen randomly from a 5000-word dictionary provides 12 bits of entropy. Say you include randomly some words from one other language, given that there are 500 other languages and dialects, gives you 13*n+9 bits of entropy. I wouldn't advise using less than 128 bits to create a wallet, so that'd mean 9 words if you include foreign ones, or 10 if you don't. Please note that this calculation is assuming random words, and not existing text.

The comments Gregory is referring to are here: https://github.com/bitcoin/bitcoin/blob/master/src/addrman.h#L91.

The "new" buckets are for addresses to which no succesful connections has been made yet, the "tried" ones for addresses that are.

The idea is that you want both, so that there is always a chance for connecting to an old and known functional node, but still always keep trying new ones as well. For "new" buckets, the bucket is derived from the origin of the node's knowledge (where you heard it from), so that an attacker needs many distincts IP ranges to poison your entire table. For the "tried" bcukets, the bucket number is based on the address itself, for the same reason.

Over-complex? Maybe...

In practice, this would indeed help a bit. But I hope that someday in the future, when addresses are used exactly once only (ideal for both security and privacy), this becomes irrelevant.

This kind of filtering is already being discussed. It would be a protocol extension that allows a light node to request that it is only interested in certain transactions; the peer would then only forward filtered blocks and transactions, but still cryptographically committed to the block header chain, via merkle paths. This means that you'd get the SPV security guarantee, with low storage and low bandwidth, and without relying on any particular trusted peer (though you could set up one, and trust it of course). Since the filtering would be done using a Bloom filter, which (intentionally) allows false positives, some privacy can be maintained still.

Creating one block requires (on average) 2^48/65535*difficulty hashes, or 4295032833*difficulty, since difficulty 1 corresponds to a target of 0x00000000FFFF0000...

This means that with n MH/s, you need 4295.032833*difficulty/n seconds per block. Otherwise said, 50 BTC per (4295.032833*difficulty/n seconds), or n/(difficulty*85.90065666) BTC/s.

This equals:

• 0.6984812728*n/difficulty BTC/minute
• 41.90887637*n/difficulty BTC/hour
• 1005.813033*n/difficulty BTC/day
• 30000*n/difficulty BTC/month (approximate)
• 367000*n/difficulty BTC/year (approximate)

Which?


How?


I need to trust the super-node if I use it, no? If I don't need any trust, we have the same situation as the current client provides. If I do need to trust it, this means a decrease in security. It may be a marginal one, and it may be worth it for some people, given the benefits it provides (see Electrum, for example), but it is a risk.


Depending on what the super nodes and how it functions, it may be able to derive what your addresses (or even who you) are.

Hello all,

I spent the past 12 days travelling through Iceland (executive summary: waw!). The next 4 days I'm staying in Reykjavik, so if there are any people around that would like a meetup, let me know something!

Do you have a donation address?

No, the Qt interface requires much more intimate access to bitcoin's datastructures than what is exposed through RPC.

There are some long-term plans to separate node and UI further, though.

You should be able to spend coins sent to a multisig address, if your client knows the multisig address, and has all involved keys.

To draw an analogy in real life: not everything that is legal to do, is considered well-mannered.

blk0001.dat will be at most 2130706432 bytes, or 2080768 KiB, or 2032 MiB.

No, that won't help. If there was a corruption, 0.6.3 would complain whether it was an old or a new wallet.

See http://msdn.microsoft.com/en-us/library/windows/desktop/ms683183(v=vs.85).aspx

Thread IDs are DWORDs on Windows, meaning 32 bits.

The reference client only lets you spend coins sent to a multisig addresses if you have all involved keys. That doesn't mean that the protocol requires this.

The current functionality is really just proof of concept, as the question of who "owns" coins in a multisig setting is not very well defined. In practice, you want to use it in a situation where not all required keys are available to a single system at all, and a different mechanism is needed to create, gather and combine the required signatures.

The 0.7.0 release will come with a 'raw transaction' API that allows signing unsigned or partially signed transactions, passing them around out of band, and when fully signed, broadcasted to the network.