As to the second batch - i've had no word from friedcat about them being restocked or anything. Anyone seen him posting anywhere? I did message him.
Just caught this; does this mean those that aren't marked as "Packed/Labeled" have to wait for friedcat to restock? Damn it. |
|
|
|
Shit! Difficulty approach 50 millions, and my AvalonB3 in way at while. Time to delivery estimated 1-2 weeks, and very possible growth difficulty to 70 millions for this time.
So, where I can buy voodoo dolls "Yifu" for Bitcoins? Now I have all another components for revenge: nitric acid, gas burner, shredder.
70 millions is optimistic. Next difficulty (estimate): 88,110,415 (source: http://bitcoindifficulty.com/) Estimates on next adjustment right after an adjustment are spurious at best. Give it a week before the actual hashrate starts to present itself and then a more accurate estimate can be had. |
|
|
|
60 still not paid for. Arklan, when do we cutoff for those who didn't pay for extras and do another round for the super-attentive?  still looking to buy 10, this price(reasonable) or more. only for previous participants. This is the third time you have asked and the third time you've been told to bugger off. Come on man. They're BTC.35 other places - go get em. |
|
|
|
Pardon quietness lately, my other work has been busy. I've fedex ed all those marked as such, though I missed sending taking emails, which I'll correct when i can, which is Wednesday. I'm unable to access my full pc right now, as it is not where I sleep...
This also explains why I haven't updated who has paid and such. I have the messages and emails. I'll fix it.
As to the second batch - i've had no word from friedcat about them being restocked or anything. Anyone seen him posting anywhere? I did message him.
If, after i catch up, any remain unpaid i will immediately divide them up among those who are paid up.
Just so you know Arklan, I wholeheartedly appreciate everything you've done here. Very smooth transactions, highly attentive, and just a really cool group buy to be a part of. Thanks! |
|
|
|
60 still not paid for. Arklan, when do we cutoff for those who didn't pay for extras and do another round for the super-attentive? |
|
|
|
Fine, you never hit "actually zero" if you always must assume the possibility of your code having bugs in it. But assuming you code properly, a collision from a random number generator having probability X becomes probability 0 if you iterate until you get a unique number for an address based on historical usage. No, because hardware is not perfect. Keeping the old values around increases the chance that a hardware failure will cause you to use one of them. Yea, ok, I can see that. You have a probability that is so absurdly small on one side that you can't ignore probabilities on the other side just on the grounds that they are very small.
True; for a working package. If you get to assume the code is proper, why don't I get to assume that a properly-code RNG won't produce collisions?
No, I'm not saying to assume your own code is proper. My point was that you limit trust in third parties. Your own code should be verified as well, but you can limit trust on code that you didn't write. Additionally, this approach places less trust in delivered libraries, which is obviously (according to the topic of this discussion) a good approach. That's a completely different issue. I agree that it might make sense to do this to protect against a broken RNG This was my primary point. Edit: I see that I switched them in my original post. This one should have come first. even while it makes no sense to do this to prevent the absurdly improbable collisions from a working RNG.
This was a secondary point that adds value (even if small). |
|
|
|
still waiting for a few people (no big deal. you got time.) to pay for their extras, and doosey and norman to pay for their 5 each.
I thought those unpaid had until midnight last night to pay, after which the devices would be re-allocated if still not paid? the unpaid 11 i'm giving a day. if i haven't heard by midnight saturday, they'll get give out to thos who asked for extra but didn't get a 4th.
pretty ruthless folks around here.. not like he was going to ship on sunday right? go get some air, its summertime Hey, snooze you lose right? Not about when it's shipped, it's about how many we can get. The less people make it, the more we OCD folks can get. |
|
|
|
If a wallet were to keep track of the k values per address, could that then mitigate these kinds of issues? If you have an actually working RNG, the chance of picking up the same 256 bit value for a second time is basically zero. Sure, but keeping track would make "basically zero" into "actually zero". And since the wallet has your private keys anyway, adding a small dictionary seems trivial and doesn't add any vulnerability. What's the downside? No, it wouldn't make it actually zero. You have to consider the possibility that the code that checks has a bug in it, fails due to a hardware problem, and so on. If you account correctly, you may find that the added complexity (especially since now you're keeping the old values around instead of getting rid of them) actually increases the chances of a value being reused. Fine, you never hit "actually zero" if you always must assume the possibility of your code having bugs in it. But assuming you code properly, a collision from a random number generator having probability X becomes probability 0 if you iterate until you get a unique number for an address based on historical usage. Additionally, this approach places less trust in delivered libraries, which is obviously (according to the topic of this discussion) a good approach. K must be unique per address per transaction and random. It is known that most math libraries use PSEUDO-RANDOM generators. So random is not always guaranteed. But you CAN guarantee through code that K is unique per address per transaction, even if you cannot guarantee randomness. |
|
|
|
I think the first step for everyone using the apps in question transfer their funds to a new address that hasn't been used before.
Bad idea, IMO. You can reveal your key at the very moment when transferring out your funds - if someone intercepts your priv-key-compromising tx while routing it, he can try to spend your cons before you. I'm pretty sure all the compromised keys have already been robbed, so I'd rather advise to wait for the fix, not moving any coins. Revealing a key for an address that you should already assume is compromised doesn't sound like a serious issue. More serious is letting coins sit in an address you should already assume is compromised. |
|
|
|
So -from a practical point of view- how can users use the Bitcoin Wallet/Blockchain.info apps before the (broken RNG?) can be fixed with an upgrade?
I think the first step for everyone using the apps in question transfer their funds to a new address that hasn't been used before. What apps are affected? |
|
|
|
If a wallet were to keep track of the k values per address, could that then mitigate these kinds of issues? If you have an actually working RNG, the chance of picking up the same 256 bit value for a second time is basically zero. Sure, but keeping track would make "basically zero" into "actually zero". And since the wallet has your private keys anyway, adding a small dictionary seems trivial and doesn't add any vulnerability. What's the downside? |
|
|
|
If a wallet were to keep track of the k values per address, could that then mitigate these kinds of issues? If you had a list of k values that had been previously used, then when you generated the next transaction you could add a line into the code: 1 Calculate e = HASH(m), where HASH is a cryptographic hash function, such as SHA-1.
2 Let z be the Ln leftmost bits of e, where Ln is the bit length of the group order n.
3 Select a random integer k from [1, n-1].
*4 If (k, privkey) pair is in kPrivKey dictionary, go to step 4
5 Calculate the curve point (x1, y1) = k * G.
6 Calculate r = x1 (mod n). If r = 0, go back to step 3.
7 Calculate s = k-1(z + r dA) (mod n). If s = 0, go back to step 3.
8 The signature is the pair (r, s).
*9 Insert (k, privkey) into kPrivKey dictionary
|
|
|
|
Still looking to buy 10.
Still only for previous group buyers. |
|
|
|
What I find puzzling is how Yifu delays chips for 6 weeks, and gets shit all over, but people are STILL buying from BFL who's shipping YEARS late. Baffles me.
Both situations suck, but you'd think BFL taught people a little patience.
BFL have publicly stated their entire order backlog would be resolved by end of September. We have no reason to distrust them. A little bit more patience is all that is asked. Lets be reasonable. No reason to distrust them? How many times were BFL customers told "Two More Weeks" TM? Are you fucking serious? Edit: Just saw your signature; maybe I missed the sarcasm in your post. |
|
|
|
|
What I find puzzling is how Yifu delays chips for 6 weeks, and gets shit all over, but people are STILL buying from BFL who's shipping YEARS late. Baffles me.
Both situations suck, but you'd think BFL taught people a little patience.
|
|
|
|
According to the spreadsheet, 401 miners are paid for. Breakdown: 355 original orders have been paid for. As I understand it, anyone who hasn't paid for their original order at this point is out. Is that correct? DebitMe is marked as not having paid for his original but eligible for 3 extra. Is this correct? 141 erupters were distributed to those requesting extras leaving 16 left over, is this correct? Of that number, 46 have been marked as paid. This leaves 95 in my calculations. Hard deadline for the extras? Also, what does the special note for Oaxaca imply? Sorry to seem pushy or overly exuberant Arklan, I'm just a bit overexcited. I also really like spreadsheets, so that probably plays in too. |
|
|
|
|
I have 20 chips in this group buy that I'm willing to sell. PM me with an offer.
|
|
|
|
What's going on with the extras?? due payment? when?
I can't keep up with the news, folks. Somebody do a rundown of things.
Pay now. You have the rest of today (I think) to pay for extras, and then they are being redistributed. You are marked as eligible on the sheet for 3 extra. Send Arklan .525 BTC to pay for your 3. |
|
|
|
the unpaid 11 i'm giving a day. if i haven't heard by midnight saturday, they'll get give out to thos who asked for extra but didn't get a 4th.
as to delivery: my information comes from the same public sources here on the forum you guys have, basically. as far as i am aware, AM hasn't gotten restocked yet, but expects them this weekend. i should then have the miners in hand sometime early next week, and get them out asap after that.
Damn Arklan, these extras just made my week. You are the man. |
|
|
|
I sent payment earlier this evening. Can you mark it down? Wish I had gotten a 4th. Oh well. Three extra is fucking awesome! Thanks Arklan! Edit: Also; what's the timeline for those who haven't paid yet. Do those that aren't paid end up as 4ths for those that lost out on the first round of had drawing? |
|
|
|
|
Show Posts
