Bitcoin Forum
June 24, 2024, 09:28:43 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 [15] 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 ... 243 »
281  Bitcoin / Pools / Re: [90 TH] EMC: No Fee DGM. Anonymous PPS. on: November 11, 2013, 01:17:56 AM
Yes, it is still true.  Payout is 8 decimal places... that line is in reference to the fact that early bitcoin clients would make anything less than 2 decimal places go poof at one point, or something like that, I don't quite recall.  It's not really been an issue for a long time, though.
282  Economy / Auctions / Re: Advertise on this forum - Round 102 on: November 09, 2013, 03:54:25 AM
7 @ 1
283  Bitcoin / Hardware / Re: Did Butterfly Labs (BFL) release all their customer's vitals into the wild? on: November 09, 2013, 03:48:31 AM
I've been privately speaking to Bruno about his constant posting of false information.  We've come to an agreement/bet, here are the terms:

Quote
Bet between Inaba and Phinnaeus Gage.

Bet terms:  Bruno will refrain from posting false information until January 1st, 2014. False information is defined as posting any information that is false, incorrect or unverified, including overt, non-overt, implied, speculated or otherwise not backed by hard, verifiable facts and/or proof.  Posting any false or incorrect information, making any implications or posting any "speculation" or unverified information will result in an immediate loss of the bet. Posting anything other than verified and verifiable facts will result in a loss of the bet. Posting with any sockpuppet accounts, alternate accounts or trying to circumvent the bet through third party posting, whether paid or unpaid will result in an immediate loss of the bet.

The bet is considered satisfied and won on January 1st, 2014 UTC if and only if Bruno Kucinskas or his agents have posted no false, incorrect, or unverified information as stipulated above. Any other outcome is considered a loss on the part of Phinnaeus Gage as per the terms of the bet.

The bet is for 10 BTC.  If Phinnaeus wins, Inaba will pay 10 BTC to the BTC address of Phinnaeus choice.  If Inaba wins, Phinnaeus will pay 10 BTC to the BTC address of Inabas choice and request and accept a permanent ban from Bitcointalk staff willingly and without recourse or appeal.  If the Bitcointalk staff refuse to ban his accounts, for whatever reason, Phinnaeus will refrain from ever posting on Bitcointalk again, either as himself or any alternate accounts.

Bruno said privately he would agree to those terms and I agree to those terms.  I suspect I will have this bet won inside of a week unless he issues a self-appointed ban on posting anything... Bruno has already agreed with the terms of the bet privately, I assume he will do so publicly.  It will be an interesting couple of months to say the least.
284  Bitcoin / Meetups / Re: Kansas City meet up - Sunday, Oct. 13th, Meet "Life On BTC" stars. on: November 08, 2013, 05:06:17 AM
Cool man I look forward to it!
285  Economy / Auctions / Re: Advertise on this forum - Round 101 on: November 07, 2013, 03:49:22 PM
4 @ 3.75
286  Economy / Auctions / Re: Advertise on this forum - Round 101 on: November 06, 2013, 05:58:03 PM
7 @ 2.75
287  Bitcoin / Meetups / Re: Kansas City meet up - Sunday, Oct. 13th, Meet "Life On BTC" stars. on: November 06, 2013, 04:09:47 PM
Yes I will be
288  Bitcoin / Meetups / Re: Kansas City meet up - Sunday, Oct. 13th, Meet "Life On BTC" stars. on: November 06, 2013, 05:04:51 AM
I'll try to be there, but I'll just be getting back from Singapore, so hopefully I can make it. Smiley
289  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: 400GH/s on: November 05, 2013, 08:40:48 PM
That probably is the least of your worries.  BFL hasn't even shipped all minirigs from last year.

One more lie, added to the books!  I will never understand why, with lots of legitimate complaints people have against BFL, some people feel the need to lie about it and make up information.  It's absolutely mind boggling.

290  Economy / Auctions / Re: Advertise on this forum - Round 101 on: November 05, 2013, 03:22:40 PM
4 @ 2.25
291  Economy / Auctions / Re: Advertise on this forum - Round 101 on: November 04, 2013, 04:14:09 AM
7 @ 1.5
292  Bitcoin / Mining support / Re: BFL Jally Not Mining on: November 03, 2013, 03:10:41 AM
Is it overheating?
293  Bitcoin / Mining support / Re: BFL Jally Not Mining on: November 02, 2013, 08:49:35 PM
That's a very strange error.  Have you tried powering off and letting the Jalapeno cool for a bit before repowering it?  I've also seen bad power do weird things to it, maybe a bad PSU source?  The Jalapeno power bricks are pretty reliable though for the most part.
294  Bitcoin / Armory / Re: Is Armory vulnerable to USB-Stick viruses like BadBios? on: November 02, 2013, 08:47:16 PM
What about a raw/custom formatted USB stick?

I think a real danger after disabling autoplay is the filesystem itself. There have been exploits within several kernel modules for the different filesystems (e.g. http://www.cvedetails.com/cve/CVE-2013-1773, http://www.cvedetails.com/cve/CVE-2011-4330, http://www.cvedetails.com/cve/CVE-2009-4020). I don't know how severe these bugs are and if they could have been used for malicious code execution, but I think it is reasonable to expect an existing, unfixed bug, which can be used for code execution.

A custom format, which only defines the most necessary fields to transfer the raw transaction data should be much safer. The code to read the custom format should be much simpler and thus less error prone than conventional kernel filesystem modules. Additionally, any exploit of this custom format parser will be executed in the user space and not within the kernel, because only the signing application (e.g. Armory) must read and parse the data.


My thoughts about the USB stick infection of "badBIOS":
I don't think, that it is possible for a simple mass storage device to infect a pc just by plugging in (and not reading and interpreting any data on it). The circuit to read and write data on the drive is hardwired and can't be manipulated by software (correct me if I'm wrong). This should be true for the USB host interface in the mainboard, too. So as long as there is no data transfer it is impossible to infect anything. Things might change if data is transfered. However, even then, the hard wired host interface or the kernel code which handles the usb frames must be compromised by a malformed usb frame. This however should be prevented by the hard wired circuit on the drive itself.
Don't get me wrong, I think it is perfectly believable, that a system can be compromised by its USB subsystem. This has been demonstrated with the PS3. However, a special USB frame had to be crafted for this to happen. A simple mass storage device could not do this.

I think part of the problem is that windows kind of does its down thing when a USB device is inserted.  Admittedly I am not that well versed in Windows USB enumeration, but it's always been my feeling (which may be entirely baseless) that windows does a lot of data reading and other useless stuff (in the name of convenience) when a USB device, particularly a storage device, is inserted into the system.  That can be exploited as an attack vector and would be no guarantee of safety, even with a custom formatted stick, since Windows will still try to read it and ask if you want to format it (at which time a specially crafted payload could be delivered) ... this might be far fetched and unlikely, but I'm just throwing it out there as an avenue I would look into if I were looking to exploit an offline bitcoin computer that might be using Armory   or something similar.

295  Bitcoin / Armory / Re: Is Armory vulnerable to USB-Stick viruses like BadBios? on: November 02, 2013, 05:37:53 PM
Thanks Alan.

I'm actually a lot more worried about the "assume-the-ONLINE-system-is-already-compromised-by-the-most-advanced-malware assumption". That has basically been my assumption all along, which is why I find the concept of infections spread by USB keys really scary. Is that what you meant?

In many ways, I have designed the system assuming the online system is compromised, but without the ability to spread USB viruses (easily).   As long as you check very carefully on the offline system that the amounts and addresses are what you expect, then it's an exceptionally safe setup (because we've assumed no USB viruses like this).  The data that is transferred over USB is public, non-sensitive, and contains everything the offline computer needs to fully verify all the details of the transaction.  I had even considered an operational mode where people could run just the wallet, and then send their watching-only wallets to a server, and the server would prepare the transactions for them to sign (for the people without the resources to run Armory online).  I could provide such a service confidently, because it would actually be a very safe system -- the downside would be how easy it is for the server to feed bogus UTXO information and effectively DoS the wallet (every signature produced would be invalid, thus making the system unusable -- but better than losing coins!).

So, under the offline-system-is-secure scenario, the worst that happens is having your transactions become invalid (though, you can lose coins because you didn't verify the addresses and amounts on the offline system before pressing "sign" -- the virus could exploit someone simply being non-attentive).  If the offline system is compromised, then it would be a pretty advanced virus (jumped through hidden data on USB), and thus should be sufficiently advanced to shuttle private key data back over USB.  Or hide data in transaction malleability.  Or if both systems are compromised, it just flat out jams the private key into the signature space, and tells you it's valid, and the online system recognizes and sweeps the funds to the attacker before you've even realized your broadcast transaction is invalid.

Because of this, it's worth visiting how to minimize damage of an offline computer compromise, but it's a very difficult problem and one I can't claim to solve.  Use anti-virus on your online computer, dedicate a small USB key to be used for only offline transaction shuttling, and really check all the addresses and amounts of the transactions before signing.  Also, if the transaction is sufficiently large, I recommend making a phone call to the recipient to manually verify the addresses.    This will keep you from being "low-hanging fruit" to the next piece of Bitcoin malware Smiley




How does this address the issue of malware on the watching only system (online system) infecting the USB key with a bitcoin tailored bit of malware that will then infect the offline system when you insert the USB stick, steal the private keys from the offline system and then take the private keys back with it when the USB stick is back in the online system (to send the transaction after it's signed)?  Then the malware sends out the private keys through another channel of the infected system.  

There needs to be a way to isolate the offline system without putting a device into both systems.  I've got nothing off the top of my head, but that's what ultimately needs to happen.  

296  Bitcoin / Mining support / Re: BFL Jally Not Mining on: November 02, 2013, 04:52:32 PM
Try a different pool and see if you get the same response.  That looks like a potential pool error.
297  Other / Beginners & Help / Re: is there any way for US person to cashout from mtgox on: November 01, 2013, 05:41:09 PM
There is no way to get USD from MtGox.  Convert them back into BTC, transfer to Coinbase or CampBX and cashout from there.
298  Bitcoin / Pools / Re: [90 TH] EMC: No Fee DGM. Anonymous PPS. on: November 01, 2013, 02:47:30 AM
It is eu.eclipsemc.com port 3333

There's a news section that I will be populating as well, to keep up with server news.  I'm going to be moving the web server to a new machine, which should be much faster in the next week or so, but I'll keep everyone posted about that.
299  Other / Off-topic / Re: sick of "crumbs" on: October 31, 2013, 04:17:45 AM
Quote
So come in, barf on my nice rug, cry on my shoulder and smear your snot on my bespoke lapel.
Let it all out, vent, rage in my nice clean thread, i deserve it.
Drag your rancid carcass over to deface my abode with your insolent, shameless, leering poverty.

Holy shit, this might be my new signature.
300  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: 400GH/s on: October 30, 2013, 05:14:26 PM

Although it was a bad call in retrospect, I considered buying BTC instead of making a Batch 1 order, back at then end of August.  I would have made quite a bit of money by now.


Do any of you trade in stocks?   It is completely different if you bought BTC instead in August since you probably would of sold them in Sept on a small increase, then sat on the sidelines saying ...'I should not of sold my bitcoins so early, I would have made quite a bit of money by now'

It's a lot easier when someone else holds your money hostage and then comment on what you 'would have done' which of course would be to perfectly play the market




Some one needs to sticky this quote so everyone can link back to it each time someone whines about "what I would have done."

To those that keep whining about it, everyone knows that what you "would have done" is exactly what you did, but you keep whining about how you would have done things differently if only you had known.

Guess what? We would all be multi-billionaires if we had the perfect insight you think you had. The fact that you are whining about what you would have done vs being rich proves it to be untrue. If only I had known bitcoin would be $200!
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 [15] 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 ... 243 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!