Bitminter is about 20TH. Network is 400TH. 400 / 20 = 20. Therefore Bitminter has a 1/20 chance of finding a block. Statistically, BM should find 5% of 124, or about 6.2 Blocks/Day (currently).
Isn't it 144 blocks/day (at 6 per hour)? I calculated it differently. 20 TH/s at the current difficulty calculates out to 268 BTC/day using this web calculator: http://www.alloscomp.com/bitcoin/calculatorTherefore, we should be finding, on average, 10-11 blocks per day. Yep. Correction is needed. It is 144 blocks per day. Thanks. That comes out to 7.2 blocks/day for BitMinter at 5% of network hash rate. I'm not going by difficulty, but network hash rate because network hash rate is calculated more often (I think). It is calculated more often, but it is not relevant until the next difficulty adjustment. When the math is done by miners trying to make blocks, they only look at the difficulty. It is the frequency of published blocks that people use to determine what the network hash rate is... it is not some accurate snapshot of the network's mining power, but rather an estimate (if everyone was having bad luck, the network hash rate would be calculated as being lower than it really was.) Currently, the network is finding over 9 blocks an hour, but that is not (yet) in any way hindering us from finding any blocks. Everyone continues to find them at the current difficulty. |
|
|
|
This has been discussed in at least one other thread. The plurality opinion seems to be: someone's experimenting with ways of simplifying the tracking of coins. Even if you normally only use each address in your wallet once, if someone drops 0.001 BTC into a change address you've never given out (but which appeared in the blockchain in a spend) it lets them tie that address to future addresses once you spend it.
Isn't that address already 'exposed' from the original transaction? If you mean exposed and vulnerable to the Android random-number sloppiness, then no. Quick explanation from my learnings: There are three parts to a bitcoin address/keypair/etc.: the private key, the public key, and the address. The private key is where it all starts. Elliptic-curve (ECDSA) encryption is used to get the public key from the private key. SHA-256 hashing and RIPEMD-160 hashing are used to get the address from the public key. The address is what you give out to folks. It's protected by ECDSA encryption and three actual hashes from two different methods. We currently know it to be safe from even quantum computing. Receiving bitcoins at a truly random address is essentially riskless. But to SPEND from that address, you need to reveal your public key. This is still considered safe (to non-quantum computers) since you can't (normally) get the private key from just the public key. The transaction is signed using ECDSA, and in theory should be solid. But ECDSA signing requires fresh random numbers each time you use it. If your computer happens to spit out the same "random" number twice whenever you ask for one to sign more than one transaction with the same private key, then you're in trouble, because the signature on the transactions will be similar, and it won't take any real effort to figure out the private key from the two transactions. IIRC, this sort of potential "loophole" was just one of several reasons why you really were never supposed to re-use bitcoin addresses. But, humans being what we are and all....  (Yes, I do it too, for the convenience of course....) |
|
|
|
also, one should answer the question, if imported vanity addresses are a problem. i would say no, only the possible other addresses where some change might have gone.
Yes, they are. This particular problem isn't about the private keys themselves (although I wouldn't trust private keys generated with a broken psuedo-random number generator anyway.) The problem is that securely signing a transaction requires using a unique random value each time. If you use the same private key in two different transactions/spends, and this includes vanity addresses, but the same random value is involved in the signing process both times, then your key is compromised. It doesn't matter what the private key is. If you can't get decent random values to use for the signing, you're going to be exposed. It's a pretty disturbing oversight on the part of those who wrote the Android PRNG library. |
|
|
|
done and done, thanks to you and this community for such watchfulness and timeliness with these kinds of issues.
You're joking, aren't you?  This post is over one month old, while this one over half a year... Watchfulness my ass As always, Bitcoin is mercilessly exposing every shady practice on everything it touches. I don't trust Google. Like MS they are also in bed with the US government. They try to promote Android as open source but keep the JVM for Android closed. This is why every Java based app for Android is not truly open sourced! Period. Paragraph. Hmph. I think if this were common knowledge it might raise a few eyebrows. I was under the impression it was open-source through and through. *re-investigates cyanogenmod* |
|
|
|
Question:
Private keys doesn´t start with 5?
It depends on whether the public key is compressed or not: For private keys associated with uncompressed public keys, they are 51 characters and always start with the number 5. Private keys associated with compressed public keys are 52 characters and start with a capital L or K. This is the same private key in wallet import format. Source: https://en.bitcoin.it/wiki/Private_key |
|
|
|
i randomly received .15 btc yesterday to one of my android generated addresses. Why would I randomly get free money? this never happened to me before, is this related to the flaw?
Potentially different (worrisome) issue. https://bitcointalk.org/index.php?topic=269231.0There is the chance that spending that "free money" could result in the private key of that address being exposed. |
|
|
|
Website paywalls: preventing new readership and killing your revenue deader than ever.  |
|
|
|
The whole "judge said it, therefore is true and significant" just reinforces the idea that state monopolies are the sole arbiters of what is true and what is significant. Kind of beginning to piss me off that people keep repeating this; who cares what one judge says or thinks? I knew it was money already without him/her to OK it for me.
+1 |
|
|
|
btcxyzzz, nice block! 44.8672 BTC with over 19 BTC in transaction fees.
 *checks out block* The bulk of that huge bonus came from one transaction: 7d396f48b59fc3dbf3d990abac7dd22d9c080c4ccd4301b1a9b64acc9d1a4c10I have to wonder if the fee was a mistake, since the transaction was only 1516 bytes. Then again, it's a somewhat unusual-looking transaction in general, and it moved over 900 BTC at once, so who knows? EDIT: Yeah, yeah, I know.... |
|
|
|
Wouldn't adding more decimal places be effectively be printing money? It would literally be creating more money availability out of thin air.
If Bernanke took a truckload of pennies, chopped them into 1/4 cents, kept the face value (0.25 cents each) and started paying all U.S. expenses with them instead of with dollar bills, checks or wire transfers, would anyone be any richer? Would that be "printing money?" |
|
|
|
+3 Met Charlie Shrem He was coming out as we were going in. He took one look at us and knew we were there for Bitcoin (lol) -- with a pretty girl on his arm, he still took the time to convo with us (#SuperNiceGuy) Promised a FREE round if we pay with BTC (I guess on a non-event night). Told me that BitInstant would be back this weekend??? Fingers crossed   |
|
|
|
This has been discussed in at least one other thread. The plurality opinion seems to be: someone's experimenting with ways of simplifying the tracking of coins. Even if you normally only use each address in your wallet once, if someone drops 0.001 BTC into a change address you've never given out (but which appeared in the blockchain in a spend) it lets them tie that address to future addresses once you spend it. Lucky? Maybe. Maybe not....  I just searched for "0.001 btc" and found one of the threads you mentioned. So this has been going on for a month or two then. Now I'm all paranoid about gubment conspiracies trying to de-anonymize BTC addresses. Is there a way of "sequestering" this 0.001 BTC and never spending it? If you have a wallet with coin control, yes. But the Qt client doesn't have that. If I were that concerned about it (not sure if I would be or not,) and didn't have a coin-controlling wallet, here's what I would try: - Extract the private key for the address from the wallet - Import the private key into a new Blockchain.info browser wallet - Create a custom transaction spending 0.001 BTC from that address to the address of your choice (a charity, a friend who doesn't care, a wallet of yours marked "tainted funds," the bitcoin black hole, etc.) - Choose "show advanced" to make sure that the offending transaction is the one the 0.001 BTC is tied to - Send it If necessary and I really wanted it done, I'd figure out how to craft the transaction by hand, quadruple-check it, and push it manually. Anyone wanting privacy who received this "free money" should probably do this, or something similar. For most, it might not matter; after all, this could just be an experiment by some college student. Then again, it could be the NSA attempting to deanonymize bitcoin addresses to track people who donated to Wikileaks. Or anything inbetween.  Also, I had an idea... The person doing this can't really hide his intentions by sending out so many bitcents to so many addresses. But for the rest of us, we can borrow this person's tactic and use it against him. How? Every so often, pick a random transaction in the blockchain and trace some of the coins for a bit, until you hit an address that there's no public record of (other than in the blockchain.) Send a random, small amount of bitcoins to it. If only done infrequently, it shouldn't cause alarm. If even a small % of people do this, it could be enough to thwart the same tactic used against us. Sure, some will worry about the blockchain bloat (I kinda do,) but if it's your privacy at stake, and possibly that of all bitcoin users, it seems legit enough to me. Just food for thought. |
|
|
|
Thanks. that's what I thought to look at before. Wasn't sure if it was the only way. It may not matter anyway for why I'm probing. Looking at the account I use: I'm perplexed about why Bitminter is showing the expected (btc) per block at 60% of the value it should be if based on the ratio of GH contributed to the entire pool GH. For example, if you contribute 14 GH, and the pool is at 14 TH, then the ratio is 1/1000. Therefore, you should expect 1/1000th of each new block found in the pool (specifically 1/1000 of 25 btc = .025 btc/block). In the account I use, the expected displayed is 60% of the ratio it seems that it should be. I've always liked Bitminter, and the operator seems like a nice guy each time I've communicated with him. But this seems wrong. So, I'm either missing something, or need to find another pool. My first guess is that it's a way to discourage pool hopping. However, I've been in the pool for a long time though. The only change has been to contribute more GH today. But should that really matter? Late entry: Though the expected is creeping up slowly to what it should be. It's now at ~65% of the expected expected. A quick look at my numbers shows I'm getting what I should be: it correctly calculates my hashrate of about 5.4 GH out of about 14.4 TH, translating to 0.0375% of the pool hashrate, and working out to roughly 0.0094 BTC expected per block. Stupid question: you haven't had any recent downtime have you? The expected is based on the last ten "shifts" worth of work. EDIT: Doh! You already answered my question for me. By adding new hashrate, it'll take ten shifts before the older shifts with lower values are removed from the average. |
|
|
|
This has been discussed in at least one other thread. The plurality opinion seems to be: someone's experimenting with ways of simplifying the tracking of coins. Even if you normally only use each address in your wallet once, if someone drops 0.001 BTC into a change address you've never given out (but which appeared in the blockchain in a spend) it lets them tie that address to future addresses once you spend it. Lucky? Maybe. Maybe not.... |
|
|
|
...thanks!  The money didn't go to a change address that you've never made public, did it? |
|
|
|
Download a copy of vanitygen and try it out. On a (pretty slow) laptop CPU ... # vanitygen.exe 1xxxxxxx Difficulty: 51529903411245 [82.48 Kkey/s][total 194304][Prob 0.0%][50% in 13.7y] That's slow. GPU will go a lot faster (oclvanitygen.exe), but not on my laptop, so try it yourself. With one less 'x' ... # vanitygen.exe 1xxxxxx Difficulty: 888446610538 [75.97 Kkey/s][total 243968][Prob 0.0%][50% in 93.8d] And if you don't care about the case ... # vanitygen.exe -i 1xxxxxx Difficulty: 14102327151 [78.83 Kkey/s][total 245760][Prob 0.0%][50% in 1.4d] Looking better 13.7 years.  I don't think i can wait that long. I'll look at DLing vanitygen now. Is there a way to get people with faster computers to do it for me for money or does that mean they will get my private key? You could check out SgtSpike's site, firstbitsrepo.com. Also, his thread regarding it: https://bitcointalk.org/index.php?topic=182063.0/ |
|
|
|
currently in the beta channel but will be available soon:
...
In case you didn't notice. Version 0.6.4 is generally available through Google Play and for direct download here. Major changes: - Aggregated/Segregated key view: In settings you can configure whether you want to view the combined balance/transaction-history of all your keys (Aggregated view) or the per key balance/transaction-history (Segregated View). Until now segregated view was the only choice. Now aggregated is the default.
- Cold storage spending: Scan a private key and spend from it. Awesome demo here.
- Optional autopay threshold: AKA, scan to pay, allows you to set a payment threshold value. If you scan a payment request (Bitcoin address + amount to pay), with a value below the specified threshold the transaction is sent with no further user interaction (If a PIN is configured you still have to enter it).
- Support for BGN currency
- Trimmed transaction history: Transaction history will only list the outputs for your keys. Other outputs are omitted (but available in transaction details). This is very useful if you are mining at Eligius, which does payouts with hundreds of outputs.
- Individual key balance: In Keys & Addresses you can now see the last known balance of the individual keys.
Enjoy & give feedback. If you haven't rated the app on Google Play please do so now. 5 stars appreciated Jan, so far the new app is amazing! I love that you've managed to keep most of the user-friendliness of it, while adding all of these new features (having the ability to print out private keys straight from the phone via the SD card really is impressive.) I also think the emphasis on cold storage was much needed, and really puts Mycelium just a step away from being usable as a hack-proof makeshift hardware wallet. With that in mind, a couple of questions: 1) How suitable is the code is to having something similar to Armory's noteworthy offline-transactions feature implemented? I will be downloading the Mycelium code this week and seeing if I can contribute to such a feature directly. 2) Is there a donation address visible anywhere in the app? (Or, if you're not going to be soliciting donations, is there any other way you plan on monetizing the app that we could contribute to?) |
|
|
|
|
Show Posts
