|
+1 barbarousrelic, though if the US government would ever need to actually pay Treasury bond holders with dollars, then it can simply issue more Treasury debt and tell the Federal Reserve to print dollars and buy this new debt, and use these devalued dollars to pay the bond holders. Without the ability to print new dollars it would be more meaningful to say that treasury debt is backed by full faith and credit, because this statement would mean that the debt holders get paid with money that has same value as the money they paid when they bought the debt bonds.
|
|
|
|
|
Actually, after asking Meni Rosenfeld about it, he started to convince me that the honest hash power dilution with faster blocks is less severe than what I estimated.
For simplicity, let's assume network propagation time of 1 second, i.e. it takes 1 second for each node to broadcast the longest chain that it knows of to all other nodes.
With 2mins blocks, on average once every 120 seconds some node sends the block it found, so during the 1 second of propagating the new block, the other miners are wasting their hash power while working on a shorter chain, so 1 out of 120 seconds is being wasted on average. If there's a fork where e.g. two groups of miners work on different chains of same length then that's ok, i.e. they don't dilute any of their hash power because of this fork. So in total 1/120 of the honest hash power is being wasted, which is only 0.83%, and with Litecoin 2.5mins blocks it's only 0.66%, and with 1min blocks it's only 1.66%
Simple huh?
|
|
|
|
there's a tradeoff between gambler's ruin initial deficit and honest hash power dilution due to detrimental effects on the orphan rate and network communication.
That's also a good point, although it is still a bit unclear how large this effect would be in reality. Maybe a good idea for setting up some simulations. The power dilution is approximately the network latency of the dishonest network minus the network latency of the global (honest) network, divided by the expected block interval. As a consequence, it has little difference if we're talking about dishonest pools. Given that the current network latency is about 2 seconds, it has very little effect at all. We can get well under a minute before it even starts being measurable. The global hash rate is relevant in relation to how much hash power the attacker should have so that the proportion between honest hash power and malicious hash power is small enough to allow carrying out the double-spending attack. Assuming that this proportion is some constant number, it's false to say that only the number of confirmations matters, because of hash power dilution of the honest miners with faster blocks. In other words, if the attacker has e.g. 30% of the total hash power, waiting for 6 blocks with average 2mins blocks is less secure than waiting for 6 blocks with average 10mins blocks. Which wiki is wrong on this point? Please cite the paragraph that's wrong?
No, it's not. The proof-of-work is a Poisson generator, meaning that the expectation value for the attacker follows an decaying exponential, which is itself a function of the number of Poisson events--i.e, the number of confirmations. So the probability of overtaking the honest chain after 6 blocks on the 2min intervals is exactly the same as 6 blocks on 10min intervals--hashes/block doesn't figure into the equations anywhere at all. The honest hash power dilution isn't just a result of network latency, but also because there's higher probability for the event of miners finding a block at about same time, at the lower difficulty that's implied by faster block average. You appear to claim that honest hash power dilution in negligible because in effect there are no more than couple hundreds of actual miners because everyone mines in pools, but would you make the same claims if everyone were solo-mining? Note that the current situation of having only few centralized pools might improve in the future, either by using p2pool or by using protection from malicious pool operators where miners prepare the block locally and use the pool's reward address (and then the event of finding different blocks at about same time will have similar probability compared to solo-mining). So overall it's false to say that only the number of confirms matters, because if honest miners have 70% power then it's being diluted by the faster block average time, and we're just arguing about the measure of this dilution? Feel free to provide more detailed analysis... Edit: what I wrote here is wrong, I was operating under the misconception that chain forks cause hash power dilution, which is false. Credit goes to MeniRosenfeld for correcting me, see the next post. |
|
|
|
I'm happy to see a discussion for possible ways to make it less risky to accept payments within under 10 minutes. Changing the blockrate is one of them and I'm not saying it's the best.
In the long term, option 3 of having centralized hubs as a layer on top of bitcoin is probably the best idea, also because of scalability issues discussed here: https://en.bitcoin.it/wiki/Talk:Scalability |
|
|
|
Faster time between blocks would also be burdensome on low trust light clients
That's a very good point I hadn't considered yet! Yeah, that's a good point that I didn't really appreciate until now, so I added it to the Litecoin wiki comparison. Still waiting for gmaxwell to explain his other point about DOS attacks with faster average blocks  |
|
|
|
This is a perennially bad proposal. The security of an N block bury comes largely from the amount of hash power used to bury it but also from the unlikelyhood of non-trivial internet splits lasting a given amount of time. If you half the hash power required to get N blocks, then you double the number of blocks you need for the same security. Obviously there is a non-linearity at the one block boundary, but you're not talking about a one confirmation transaction.
What definition of security are you using? For any of the double-spends mentioned in this thread it is the number of confirmations that matters, irregardless of global hash rate (yes, the wiki is wrong on this point). If you think otherwise, I'd love to see the math to back it up. The global hash rate is relevant in relation to how much hash power the attacker should have so that the proportion between honest hash power and malicious hash power is small enough to allow carrying out the double-spending attack. Assuming that this proportion is some constant number, it's false to say that only the number of confirmations matters, because of hash power dilution of the honest miners with faster blocks. In other words, if the attacker has e.g. 30% of the total hash power, waiting for 6 blocks with average 2mins blocks is less secure than waiting for 6 blocks with average 10mins blocks. Which wiki is wrong on this point? Please cite the paragraph that's wrong? |
|
|
|
Then you better not read the previous page where a few are saying that people should accept all but expensive txn's at 0 confirms ...
0 confirms for inexpensive txns, while scanning the network to detect double-spending attempts, is discussed here: https://en.bitcoin.it/wiki/Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmationThe point about machine guns is how many confirms should the GUI client wait for, before indicating to the user that the txn is secure. Suppose everyone agreed with your 2mins blocks idea, are you suggesting that the official client wait for 6 confirms or 30 confirms? If you're suggesting 6 confirms that's where the machine guns analogy could be valid. |
|
|
|
If you half the hash power required to get N blocks, then you double the number of blocks you need for the same security. I have already answered that by saying that if people want the same txn security they already have, then they simply wait for 5x the confirms - problem solved! That's inaccurate, there's a tradeoff between gambler's ruin initial deficit and honest hash power dilution due to detrimental effects on the orphan rate and network communication. See more details in "faster transaction time" section of https://github.com/coblee/litecoin/wiki/Comparison-between-Bitcoin-and-Litecoinkano: it's quite obvious that what's gonna happen in reality is that with 2mins blocks almost everyone will still wait for 6 confirms instead of 5x6 confirms, i.e. you propose something like giving away free machine guns to the entire population and saying don't worry about shooting incidents because people can choose not to use them. |
|
|
|
I can't search this thread so I guess I have to ask - linux binary miner?
(got trouble with ./configure: line 4759: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'), losing patient to be honest after fixing aclocal)
Here's how I fixed it: 1) download libcurl.m4, for example from https://raw.github.com/igetgames/pushpool/a9650e27e32926d6b0a6134a6104c97cdfcd0000/m4/libcurl.m42) put libcurl.m4 for example in ~/.share/aclocal 3) change cpuminer's autogen.sh aclocal line to: aclocal -I ~/.share/aclocal 4) ./autogen.sh ; ./configure ; make |
|
|
|
For example, imagine we're in a bitcoin-based economy. I want to buy a car that costs 5,000 bitcoins, but I don't have 5,000 bitcoins. I borrow 5,000 bitcoins and in exchange give an IOU worth about 5,000 bitcoins. The 5,000 bitcoins I borrowed are still in the economy, being spent by the guy I got the car from. But the IOU is also in the economy, and it effectively adds an additional 5,000 bitcoins because it is interchangeable in the marketplace with 5,000 bitcoins.
Yes, you can say that the 5,000 IOU adds additional 5,000 bitcoins into the economy, but this IOU should be considered less valuable than actual 5,000 bitcoins because there's counterparty risk attached to it, i.e. the borrower might default in case he fails to earn 5,000 actual bitcoins to repay the loan. Another issue that springs to mind: how could there be interest on loans if the money supply is fixed, i.e. where would the new money for the interest come from...? There's a simple example of how it would work at http://mises.org/daily/4569: Suppose there are two neighbors living in a community that uses actual gold coins as its money. Mr. Smith starts out with 1,000 gold coins, while his neighbor Mr. Brown starts out with none.
Brown asks Smith if he can borrow 100 gold coins for a month. Smith agrees, but insists on a 12.7 percent APR, which works out to 1 percent interest charged monthly. So on day one of this deal, Smith has 900 gold coins while Brown has 100.
At the end of the month, after whatever buying and selling he has done with the rest of the community, Brown has accumulated 100 gold coins in his possession. He pays that back to Smith. Ah, but Brown is still short 1 gold coin. So he offers to cut Smith's lawn and paint his fence (with materials provided by Smith). In return for this labor, Smith pays Brown 1 gold coin, which Brown then uses to pay off his interest.
|
|
|
|
i dont know, how to detect them, but maybe there are some coders who can do this.
the pool(s) who do so, must live with that big abuse of confidence - yet and in the future
OK, I asked in #bitcoin-dev on irc: http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/10/10/3Backdoor merged-mining can be detected after the block was generated, but not while generating it. See e.g. http://digbtc.com/ regarding which pools found which blocks. |
|
|
|
|
Is it impossible to detect? Because the way it works is that the pool pushes to the miners basically a hash of the block transactions that need to be signed, and the miners try to generate a valid hash on the hashed data that they received? But maybe you can detect that the nonce range is fishy, because the nonce has to contain the hash of the namecoin block? If it's impossible to detect then the only way for a miner to avoid being cheated is to use one of the merged-mining pools?
|
|
|
|
|
After you enter the password once, the bitcoin 0.4 client asks you to enter your password again in a new dialog box.
However, as a general note to people who fear losing their money, you should keep backups of your unencrypted wallet.dat before you encrypt it with bitcoin 0.4, and if you save a backup on the cloud (e.g. dropbox) then first encrypt it yourself using e.g. 7zip or gpg, that way you won't lose your money if something goes wrong. Just be sure not to send unencrypted wallet.dat to any 3rd-party host, and even if you store a backup of wallet.dat on your personal usb flashdrive or your laptop etc., it's much better that you store it only in encrypted form.
|
|
|
|
I'm talking about the one-to-one function y= SHA256(x') where x' is a 256-bit number.
It is extremely unlikely that this function is one-to-one, due to the birthday paradox. |
|
|
|
|
Right, and what about h(x) = f(x) xor g(x) ?
|
|
|
|
|
I'm saying that I fail to see why this 3AES should be more secure than 2AES(key,txt)=AES(key,AES(sha256(key),txt))
I think that if we assume that sha256 is (computationally) indistinguishable from a random function then both of these 3AES and 2AES wouldn't be less secure than AES itself, i.e. re-encrypting AES ciphertext with unrelated key is fine (the ciphertext is uniformly distributed because AES, or any other encryption algorithm, are permutations). So if sha256 doesn't have non-random quirks that can be exploited here (we cannot prove this), then it should be ok. But I don't have any idea how to estimate how much more secure this should be, under the assumption that sha256 is random. Like I mentioned there are diminishing returns when you use too many rounds with same key length. If you really care about increasing the security (I still have no idea why) then go for 3AES with independent keys.
|
|
|
|
Under the theory that should a practical attack on AES be published, it's a reasonable bet that the attack will not extend to a strengthened AES right away, as-is (or at least not be practical). That gives extra time to find a suitable alternative and transition everyone to it (which will take time for something like the bitcoin network).
The approach I'm considering would be the following:
K1 = K
K2 = SHA-256(K).truncate() // for AES-128 or AES-192
K3 = K
3AES_Encrypt(K, x) = AES_Encrypt(K3, AES_Decrypt(K2, AES_Encrypt(K1, x)))
3AES_Decrypt(K, x) = AES_Decrypt(K1, AES_Encrypt(K2, AES_Decrypt(K3, x)))
This approach is very bad, it's broken using only one known plaintext (ptxt,ctxt) and even more easily than 2DES, by meet-in-the-middle with same time complexity as brute forcing single AES, and even same space complexity (unlike 2DES). Simply iterate over all possible K and compare AES_Decrypt(K2, AES_Encrypt(K, ptxt)) with AES_Decrypt(K, ctxt) until they match, and you found the secret key. Edit: sorry, actually what I wrote is unnecessarily complicated, no need to mention MITM, simply iterate and compare 3AES_Encrypt(K, ptxt) with ctxt, i.e. brute forcing will work because you derive the keys from K, so I guess that there's no interesting reason to use 3AES instead of 2AES for example... |
|
|
|
|
Right, I forgot about CPUs with hardware AES, so e.g. 3AES does make sense if you use 2 or 3 independent keys (not sure if it'd make sense with single key), though I still wonder why regular AES128 isn't enough for you?
|
|
|
|
|
Show Posts
