This doesn't begin to solve the problem I identified, read my original post again and see what I'm trying to accomplish, then read the requirements for what the hash needs to do. It needs to be cryptographically secure against recovering individual inputs. I'm looking for a formal written research here. Prepending the total sum to the hash of the pairs is not cryptographically secure in the context of this problem. Examining the output to determine the sum of the inputs (but no other information may be recoverable, like private keys) must guarantee that it's the same sum of the inputs that used to produce the hash. An output of 7; is not secure because could be anything, something whose inputs do not sum to 7, or even nonsense that's not a hash at all. Using a nonce in a function disqualifies it from being a hash because the input produces an unpredictable output.

And also, I would need your Bitcoin address.

The sum of the values must be cryptographically secure, else you could tamper with the hash and say the total is different than the actual totals of the input to the hash. And it isn't enough to merely be confident that the sum isn't rapidly growing, you have to have certainty that it hasn't changed. This means if you're going to use length of the encrypted data, you must not pad it.

This possibly meets the requirements for GETTHEBLOCK_2, though you can extract way more information than just the amount of currency from this which is sort of pushing what I asked for by a cryptographically secure hash... How do you guarantee all the keys are the same length, for instance? The keys, too, may be of arbitrary size.

Because it's still the case that a different distribution of private keys creating a different hash could carry the same total amount of currency. The sum would be the same, but the hash would be different, and when you run the balance through SHA1, it will very nearly destroy the information about the currency in circulation. There's no way to compare the sum of values of the (key, value) pairs when the hashes are not the same, there's not even a probabilistic way of comparing them (which could suffice for GETTHEBLOCK_1).

Suppose I have the following sample pairs of keys/values with a sum of 7: { (A, 5), (B, 2) }

I need to be able to verify from the hash of that set that it contains the same balance as another distribution of the values, maybe { (B, 2), (C, 1), (D, 4) }, and likewise, I need to be able to verify from the hash of { (D, 5) } that the listed hashes do not embody the same sum of the values as the others (as 5 != 7). The hashes will be different when different private keys are associated with different values, but a comparison of the sum of all the values to the private keys, and only that comparison, must be possible.

This does not cryptographically verify that the sum of the values of all the keys is the same as another hash, of a different distribution of values/currency/funds, sorry for the confusion. The idea is I should be able to compare GETTHEBLOCK_x( (private key₁, balance₁₁), (private key₂, balance₂₁) ) and GETTHEBLOCK_x( (private key₁, balance₁₂), (private key₂, balance₂₂) ), and verify whether or not balance₁₁+balance₂₁ == balance₁₂+balance₂₂ .

The "reference" I'm talking about is the initial input that contains a publicly known private key, and the initial currency. You compare future hashes to this block to verify the sum amount of currency in circulation has not changed.

This does happen to be a bit of a departure from a traditional hash, in that it's supposed to preserve exactly one piece of information information somehow: the sum of the values, even if you can't tell exactly how much, you should be able to compare it to another block.

I specified that the hash must be cryptographically secure, so yes, a cryptographic hash function of fixed length, except for GETTHEBLOCK_2 which may be of arbitrary length.

Appending an account with a balance of zero does not change the distribution of funds, and thus does not change the input, so there is no violation. If this is impossible to do and remain cryptographically secure, that merely needs to be proven. This requirement alone (cryptographically secure or not) can be done as follows: hash(private key₁)×balance₁ + hash(private key₂)×balance₂ + ... + hash(private key_n)×balance_n (where "+" denotes addition and/or XOR). But again, this may not be cryptographically secure.

Even if it were cryptographically secure (such that the private keys are unrecoverable), it does not meet the requirement that a change in funds from one person to another must cause a predictable change in the hash (specifically, the algorithm must offer a way to prove the total amount of funds in all the accounts is the same before and after the transfer).

Me, Kiba, and some others looked into this: http://bitcoin-gamedev.sourceforge.net/
It's stalled for now but any new ideas would be awesome.

The only thing you would be able to do is know the private key used to formerly redeem coin, and I can't think of any reason that would be useful. As other people now know the private key, it's useless for anything functional. So no, there isn't a market, there won't be... If anyone does, it's going to be a special arrangement for some bizarre reason.

This makes as much sense as a "market for trade secrets."

Let's say a person (the house, let's call them) took a number of Bitcoin and converted it into two rival currency: Pro-event and anti-event. They then sell them at some initial probability such that pro + anti = 1. Each of these currency would be traded on the market. If overall people thought there was an 80% chance of X event happening, pro-X coin would sell at 0.80 Bitcoin and anti-X coin would sell at 0.20 Bitcoin. If pro+anti is more than or less than 1, that's a signal to the house to sell more or buy back coin. When the event happens (or doesn't happen), the house merely needs to release the information that allows people to cash one or the other in for Bitcoin, at 1:1. Perhaps both could be redeemed if both keys were released, but people wouldn't be able to redeem for more than the account holding the actual Bitcoin contains, someone would unfairly lose.

There's no way around having a "central" account and house to referee the event, but the market values of the pro- and anti- coin would reflect the trust in them. But it is certainly decentralized because there is no server to take down.

Absolutely, the editor/publisher model works just fine. Find good authors, review what they write, include as necessary, pay the authors for their articles. Profit. Rinse and repeat. Public domain content with paid ads and maybe a physical delivered copy is the way to go.

1 week is way too short I would prefer quarterly maybe. But if people can find the time, and find it profitable, to work on a monthly schedule, by all means.

Also, someone who can do layout. Good formatting and font would go a long ways.

In some cases it might not be fixed size but a hashing function won't ever produce output proportional to the input, that's just a regular function, otherwise, what differentiates a hash from a general function? I was looking at http://en.wikipedia.org/wiki/Cryptographic_hash_function which specifies fixed size but that has other things that aren't strictly necessary like "it is infeasible to find a message that has a given hash" (though that will certainly be true if you can't determine the very large private key used as the input).

"from a reference" meaning, I can verify that the sum of the inputs is the same sum of the inputs of a previous hash (B0 most likely), and such that you can't (easily) create a hash that passes the test even though the sum of the inputs was not the same as the reference (or wasn't derived from a hashed set of inputs at all).

Not quite because (1) a hash (by definition) returns a fixed-size bit string, as in, the number it returns must never exceed a certain value/size, (2) the balance wouldn't be cryptographically tied to the the private key, I could modify the balance of the "hashed" output and it would be undetected, and (3) pairs with a balance of zero would affect the output.

I have a feeling that what I overall described would be impossible, you cannot accurately verify the existence of an item in a large enough set, it will have to grow more and more inaccurate (false positives or such) as a constant size hash needs to store more information, the only thing you would be able to retrieve with complete accuracy is the total balance (if it exists, by definition). This problem by itself is not asking to query information, however, except for the total balance. It is likely a transaction chain would still be necessary...

How about this, 10 BTC bounty (another one) for a function called GETTHEBLOCK_2 that is like GETTHEBLOCK_1 but it returns an arbitrarily large number, and it must be cryptographically secure and must not leak the private keys used (that is, it must be mathematically hard).

You use hostnames? There's nothing wrong with the idea, if it just needs encryption. As-is it's not safe to use.

The biggest thing it needs is mandatory encryption... Providing the public key hash of the server, this way, you can't preform a MitM attack, and there is no need for a third party (even if mutually trusted) to verify and sign the certificate. Instead of using a host, you would use hash@host like "f013d66c7f6817d08b7eb2a93e6d0440c1f3e7f8@example.com"

What about it?

Alright, I'm putting up a 10 BTC bounty for anyone who can find such a function OR prove that it doesn't exist, with a reasonable description of what combination of features makes is making it impossible.

All it has to do is this: Define a hashing function GETTHEBLOCK_1( inputs ) which takes a map of (private key, balance) pairs, and produces a very large number based on it, in such a way that any pairs with a balance of zero passed to the input does not affect the output, and additionally such that an examination of the hash can securely prove that the amount of currency embodied within it has not changed from a reference.

#bitcoin currently isn't registered, why not simply register it? If the Bitcoin project is registered as a project with Freenode (As it should be) it would get control over the entire #bitcoin namespace (#bitcoin-*).

Becides being discussed before, bitcoin: addresses musn't be using // in them because it's not a network location, the syntax is described in RFC 2396

(I voted "depends") It depends on the method Bitcoin is using to transfer and propagate information across the network and into storage. If the method used merely verifies information as true -- "X owns 66 BTC" "W transferred 200 BTC into your account" "example.com resolves to a.b.c.d and is owned by Y" it doesn't matter the data, why wouldn't you want it in the network? I describe such a strategy in http://bitcointalk.org/index.php?topic=2035.0.

Bitcoin will depend on being able to verify transactions quickly, this will mean not relying on a large local database to verify a transaction. I will say Bitcoin needs to be able to carry metadata across transactions, as long as it is not stored in the network and it's still cryptographically verifiable. Maybe it needs a small protocol change so people can prove their identities using the network, or doing interactive transactions instead of just broadcasting transactions, such a small change would be acceptable. Storing arbritary data inside the block chain, however, would not be a good idea, there's no reason you couldn't develop a parallel network that stores the data (and again, maybe uses minimal hooks into Bitcoin to do so).

I can do end to end encryption with IPv6? How do I verify the person at the other end?

The overhead isn't as great as I thought it was, IPv6 addresses are 128 bits, an MD5 hash is the same size, and a SHA1 hash is 160 bits. Routers do not need to know anything about the encryption, they are only looking at the packet header, the same things that they look at in the IPv4 and 6 packet.

Idea: Would it be possible to IP over Tor, and implement Tor over plain Ethernet (instead of IP)?
So then we just use public keys (.onion addresses) as IP addresses?

The idea is this: Something that can deliver a packet to the holder of the private key that packet is encrypted with (with the same reliability and all of IP).

Also keep in mind, whatever URI is designed, it really NEEDS to contain a public key hash in it or some other way of verifying the recipient. Sending to a random IP address, even if secured with SSL, can result in sending to the wrong person. Even if it's something like bitcoin://keyhash:IPaddress/?message=... you need to know that the correct person is at the other end of that encrypted communications like. This assumes that the Bitcoin send-to-IP will be encrypted.