Show Posts
|
Pages: [1] 2 »
|
Whoever is generating the hash has access to the plaintext map of accounts can alter it at will before hashing it. You have to take the word of the person who is doing the hashing, and I don't see a way around that.
If your account map is { (A, 5), (B, 2) } you could add all the accounts, then take the total amount, 7, and append a nonce, so you have 7_snei238nbd, and then just sign that with the private key of whoever is doing the hashing. Third parties can verify the signature but they cannot forge messages.
You could go further and take the SHA-256 hash of the account data, and append it to the total and the nonce before signing. Then if the signer/hasher is challenged or "audited" they can't arbitrarily assign values to keys. They are locked into revealing how the values were assigned to keys at the time of signing.
No bounty? lol
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;<somehash> is not secure because <somehash> 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.
|
|
|
I don't think hashes will protect what you're wanting to protect. People with only the hash should be confident that the money is not being fabricated, but whoever is doing the hashing can fake it, and unless they are forced to prove that the full accounting generates the hash, there is no way to know. So you might as well just append the unencrypted total to the hash of the sorted list. 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. You could store the map in "unary", in other words { (A, 5), (B, 2) } would be stored as "AAAAABB" (lexicographically sorted before expanding) Then encrypt with a public key. The length serves as an indicator of total value. If you use a block cipher in counter mode then whoever has the private key could decrypt portions to prove that certain keys own certain coins, without having to divulge the entire ownership map. 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.
|
|
|
I don't understand your objection. This does cryptographically verify that the sums are the same, precisely the same way the BitCoin system ensures that a transaction doesn't import more money from a previous transaction than that transaction exported. All the inputs are cryptographically protected by hashes, so no special magic is needed to check the sanity, you just do it directly.
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.
|
|
|
You can prove the amount of currency has not changed because any change in the amount of currency will require changing one of the private key / balance pairs, which will change the hash in step 4.
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 1, balance 11), (private key 2, balance 21) ) and GETTHEBLOCK_x( (private key 1, balance 12), (private key 2, balance 22) ), and verify whether or not balance 11+balance 21 == balance 12+balance 22 . 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.
|
|
|
Your requirement that a balance of zero not be included in the hash violates the last two properties. The third property is violated because an input can be constructed from another input that has the same hash, simply by appending an account with a balance of zero. The final property is most trivially violated; any time a new (zero) balance is added, the hash is unchanged. I'll ignore these for the purpose of discussion, but I consider them alone a valid proof of the nonexistence of a cryptographic hash function, and claim the bounty.
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 1)×balance 1 + hash(private key 2)×balance 2 + ... + 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).
|
|
|
To close the gap, there needs to be a specific purpose for using BTC. A tentpole application. This app has to be FUN.
I say this, alot.. but I think there needs to be a game, in which the economy is based around BTC. The game would serve as stabilization tool for the BTC economy.
Imagine if there was a Second Life, Civilaztion type game where you can earn BTC based on skill. This would accomplish three things: 1) Remove the barrier for entry for using BTC- Reglar people will begin using it without thinking about the technical and political baggage. 2) Stabalize the economy- There will always be a place where BTC has a use, and a basis from which to determine value. 3) Encourage exchange instead of investing - People will see value in spending BTC, as opposed to hoarding it. Spending in game (investing) earns coins faster than waiting for the price to go up
Spending BTC outside of the game, on products like yours, will be an added bonus to using the currency.
tldr - There needs to be a specific use for BTC. This will help real world retailers
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.
|
|
|
I think you should ditch the whole community driven idea altogether. If your editorship is any good, it will show in your magazine. Plus you don't have to keep score/keep track. You review article and send feedback to the writer.
One month is too long for the magazine. It should be more like 1 week between issues. Also, I don't think this is going to dilute the quality of articles at all as long as you make your decision based on merits, rather than deadline. If the article didn't get through, the writer can resubmit in the next cycle. There should be no artificial number of articles per issue limit. This is not paper.
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.
|
|
|
A hash does not need to return a fixed-size bit string (although in software applications it usually does). Show me a definition that says it must be fixed-size. A hash function "number of vowels in the input" is an example of a hash function with no upper size limit. The Wikipedia article says "one can use the datum itself as the hashed value". You wanted assurance that the balance had not changed "from a reference". Since you can easily calculate the balance of the output of my hash function and compare it to the reference balance, it meets your challenge. :-) 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).
|
|
|
Unfortunately it won't make you happy, because the function simply maps its inputs to its output, resulting in a very large hash (but you said that's OK).
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"
|
|
|
See what nanotube said, earlier in this thread.
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).
|
|
|
IPv6 is hardly coming from the ground (you can do point to point encryption with that), good luck to get this implemented world wide scale. Also, your idea seems to generate a huge amount of overhead, which makes things slow. Nice idea, though.
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.
|
|
|
|