Yeah, and why is that? Why must a person's Facebook profile be "professional"?
Someone might very well conduct themselves professionally during every single working hour, and get a bit crazy on weekends. I see nothing wrong with that, and no reason they shouldn't share that. It seems considerably better to focus on that candidate than the one who has an impeccable image because they can present the appearance of conducting themselves professionally, yet are unable to actually handle some responsibility.
Sparkleshare seems to use Git as a backend, which seems like a Really Bad Idea if you're trying to clone Dropbox. For one, purging old versions should be efficient and automatic.
Clearly you don't. And apparently, the guy who was robbed had the same problem.
The additional "safety" is in other areas -- there's no central, controlling authority, so no one can arbitrarily increase or decrease the supply of Bitcoins, whereas with fiat currency, people absolutely can do that. This is a good thing and a bad thing -- it's a bad thing in that there's no central authority which can attempt to fix the market when things go south, but it's a good thing in that said central authority can't mismanage things, or deliberately manipulate the market for their own game.
It's also anonymous, which is "safe" for other reasons.
But none of this implies your wallet is automagically safe, if you don't take steps to protect yourself. You can make your money safer than with other currencies, but this takes some effort -- the obvious solution would be to create a second "savings" wallet, generate a few thousand addresses for it, then store the actual wallet.dat (with all the private keys) encrypted and in a few thumb drives (or CDs, etc) in a safety deposit box, say. You can send money to savings without retrieving it, but you can only send money from savings by going and retrieving those drives.
Of course, you can go a step further -- you could do all that and also maintain an airgap, so you create the transaction to "withdraw" and sign it on a machine with the "savings" account, then transfer it by sneakernet to your Internet-connected machine.
And you can also take real money and leave it in big stacks on your kitchen table, with your front door unlocked, and then wonder why you were robbed, since you assume dollars are supposed to be "safer" than Bitcoins.
Technically, if I understand the way that bitcoin confidence works, half the damn bitcoin network should know about the details of the transfer.
Which is also probably why the thief knew where to go. It's a security hole.
Ok, parent was already wrong, and you are more wrong.
First, yes, they knew which account it went to, but without sniffing the traffic of the entire Bitcoin network, it's much harder to know which machine it went to. It seems unlikely that the Bitcoin network itself is vulnerable that someone could send an attack to a Bitcoin address without at least getting an IP address out of it first.
Maybe if you were a neighboring peer, you could notice a lot of transactions coming from one particular peer, but you still don't know if those transactions originated from that peer, and it also doesn't help you, since transactions originate from the sending peer (for obvious reasons), and are broadcast to pretty much the entire network. So even if you could track where a transaction originated from by sniffing traffic, that doesn't tell you where it went -- it could, in fact, be anywhere in the entire network, or in an account which is physically disconnected, or even in an account which doesn't exist (user mis-pasted the destination address).
To get anywhere close, you'd have to be able to sniff pretty much all of the originating peer's traffic, including other channels like web and IRC where the transaction was probably negotiated. Even that doesn't help you much, since you now have the problem of tracking a website, forum user, or IRC user back to the actual IP address where the coins are kept.
Now, all of this stuff is possible, certainly, but none of it really has much to do with Bitcoin being anonymous or not. At least, it provides no new problems over traditional banking, and is actually somewhat safer. If I could somehow sniff your communication with your bank (though admittedly, Bitcoin IRC and forums aren't always encrypted, and are more often TORed), I could drain your account whether you're the sender or receiver, and I wouldn't need to break your machine if I could somehow intercept your credentials (MITM). Banks can use SSL, but you could also refuse to trade Bitcoins over any forum which doesn't.
So, TL;DR: There's no way that the entire Bitcoin network knowing about a transaction (or about every transaction) is going to lead to knowing which physical machine to attack.
Not that the user should have known this, but dontcha think if there was $500k involved that a little curiosity on how it works and how to encrypt it better (put the.dat file in TrueCrypt container and make copies)?
Um. Yes. And yes, the user absolutely should've known that. WTF were they doing putting $500k in Bitcoin if they didn't? It's certainly enough to afford some extra hardware so you can do air-gaps.
I mean, I don't know what sort of precautions I should take before carrying $500k around in my pocket (or in a briefcase), but I'd bloody well find out before I did so.
In the case of Anonymous, if they actually are anonymous, there's no particular reason you couldn't have any member deny responsibility while (falsely) claiming to speak for the entire collective.
And no, it's really not, BItcoin actually is reasonably anonymous. Everyone can see transactions, but that doesn't give them terribly useful information if you're doing it right and generating a new address per-transaction, which is trivial to do.
Or, better, if you care about anonymity, pre-generate a few hundred (or thousand) addresses for your "savings" wallet, so that each time you send money to it, you send it to a different address.
The victim should know exactly what the recipient address of those ill gotten gains are.
Assuming there's a single address.
Technically, if I understand the way that bitcoin confidence works, half the damn bitcoin network should know about the details of the transfer.
Sure.
But there's two problems here: First, addresses are trivial to create, and generally you create a new one per transaction. So it could've gone to dozens of accounts.
Second, you can't prove the person who claims to be robbed didn't transfer the money to another account they own (like the "savings" account I describe below), and even if you could track the account they went to, it's much harder to figure out who actually owns that account. And maybe they've already spent them -- in which case, you have similar problems again; did they actually buy this, or simply transfer the money to another account they own?
I know that bitcoin technology provides for cloud-based "banks" of a sort. If they have been implemented yet, I do not know.
I think the main idea of those is for people who don't want to install the software and manage it themselves. I don't think they give you any additional security. If anything, they reduce your security, since an attacker can either steal your username and password (with or without breaking into your machine) or attack the online bank in pretty much any way (including being the online bank).
By contrast, if you run your own security, you have options. If I had a significant amount of Bitcoins, I'd create a second wallet and keep it encrypted and probably offline, and use it as a "savings" account. I could trivially generate a few hundred accounts, then put the wallet on a flash drive or two, and then not need to plug it in until I need to withdraw, since I can send coins to it without it being on my or any machine.
Of course, you have to be equally careful to actually make backups, since if your wallet.dat is on a drive which fails, or even if there's just a bad sector in the middle of it, your money is just as gone as if someone stole it. I'd like to think that this sort of thing would be incentive for people to finally start giving a fuck about security. Unfortunately, it looks like it's instead going to be a disincentive for people to adopt Bitcoin.
It makes for a better demo, I guess, but that'd be my first question too.
My second question would be whether it's the application which decides where it runs, or the OS -- it seems like now we'll not only need multicore schedulers, but GPU-aware schedulers also, but it's still something I'd like the OS to have a say in. For instance, "We need the GPU for graphics now, so you get routed to the CPU instead."
I suspect my second question is more naive than my first.
For digital there is far less reason to have the high end stuff but quality matters.
Only for longevity/durability.
It's digital. Either it works or it doesn't. Either you get a signal or you don't. On or off.
I suppose if it's HDMI, it might matter that there are supposedly certain features present in one but not the other, but still, I laugh out loud when I see HDMI cables starting at $25 or so and often approaching $100, when they're under $10 on Newegg. It just has to show me a picture!
I don't think we actually disagree, but the point is, a higher-end, gold-plated, audiophile-approved, blessed-by-the-tears-of-Baby-Jesus cable is still not going to get you any better audio/video quality if it's really just sending you bits. (I swear I've seen an audiophile Ethernet cable before!) The only reason you'd care about one over another is whether it's going to physically fall out or fall apart, and even with the cheap stuff, I rarely have that happen.
That comes up to something like $60 USD, so it's not really far off from the $100 I was assuming. Far from "expensive" for headphones. Ludicrously expensive for a cable which doesn't really affect the sound, which was the point.
Yeah, you would hope there'd be a hardware provision to clear memory blocks. You'd also hope that there's some amount of buffer between malloc/free/new/delete and actually returning that memory to the OS or allocating more.
It does, however, mean that you're effectively running some sort of garbage collection all the time. Java can just pass a pointer around; you have to pass a pointer and increment/decrement something. Java might interrupt your program to do some GC; you might call free/delete whenever any given reference falls out of scope.
It might matter less now, but this did occasionally have advantages -- aside from the efficiency gains of having at least some amount of buffer so as to not always be allocating/freeing directly to/from the OS (and I bet someone can optimize C++'s new/delete to do the same thing), there's also the fact that having all your GC code in one place, such that your normal code isn't even calling it, makes your normal code faster, and more importantly, smaller, so it all fits into cache. Then, when a GC cycle hits, the GC itself is all in one place, so it all fits into cache.
On the other hand, the less often a given GC cycle runs, the more likely it is to involve a fair number of cache misses (even just to find out what memory is in use), whereas sufficiently small/light branches of C++ code might allocate, use, and free all of their memory over and over again without any cache misses.
I should really shut up until more profiling is done, which means I should probably RTFA.
Others have pointed some of these out, but I also don't agree with everything on that list, so here we go:
Thou shalt not shun thine player's mouse
By the same token, don't rely exclusively on the mouse. Yes, the mouse is going to be quick for configuring stuff and for navigating an unfamiliar menu. However, any game I end up playing a lot, I find myself wishing I could use the keyboard for navigation more -- I think that comes down to:
Remember thine user-interface conventions and keep them holy
I'm not sure there's a good technical way to do this yet, but it'd be really nice if every game didn't reinvent the GUI. Steam even seems to have its own windowing system and GUI library in order to be able to show you a chat window either outside in the OS or on top of a running game. But it does mean that they have to re-solve a lot of problems that GUIs have solved for decades. When I have a GUI up with a bunch of options, every input field in that form gets some sort of accelerator, or at least the tab key will move between them. Steam at least looks and feels kind of like normal windows, but I'm not sure they get that, and I know most games end up rolling their own UI directly on top of whatever 3D framework they're using, which is probably where we're getting the Huge Text of Doom.
One thing that's actually kind of refreshing is the ability to set visual options in a separate window before the game engine actually starts, but that has its own caveats -- I shouldn't have to restart the game to tweak resolution. Especially on older video cards, and with games with a lot of options, it's going to take me a few tries to find the right balance of performance vs visuals. Make that loop as tight as possible.
Anyway, moving on:
Thou shalt not accelerate mouse input
Can't really agree. Maybe don't make it the default, and maybe make it a checkbox somewhere. It's even possible that it's a useless feature. But remember, this is a PC game -- don't arbitrarily change the control from one behavior to another in a new version, make it an option.
Thou shalt not mix thine bindings
This one is also a bit mixed. Context-sensitive bindings can be a very good thing, though they do have all the problems mentioned here. What we want is some balance, perhaps a configurable balance, between the console idea of "press B to do anything" (Conker's Bad Fur Day had a lot of fun with this) and the old-school PC idea of "Bind a keystroke to everything." Duke Nukem 3D had an extensive keymap, including hotkeys for a number of inventory items like the jetpack. Old-school shooters in general would bind each weapon to a number. These are good things for more advanced players, and once you either master the everything-has-its-own-key keymap or figure out which items you care enough about to assign a key to, it's a good thing. Still, having a smaller set of controls I have to pick up to be adequate is very useful to get me playing until I reach that level -- so, for example, keys to navigate through my inventory and use an inventory item, or using the mousewheel to navigate through weapons, is much more critical than being able to press 'j' to instantly activate my jetpack, or 'h' to instantly activate my Holoduke, etc.
Lugaru has a ton of context-sensitivity, and there's no way it'd be playable if it wasn't context-sensitive. It's even part of the skill of learning to play this game well -- for example, to successfully perform a silent takedown, I need to somehow end up behind an enemy who hasn't noticed me yet, and press attack without pressing forward. Easy enough if I sneak up on them, much harder if I'm jumping from across the map and landing right behind them -- but immensely satisfying to be able to one-hit a wolf. The downside is that I often find myself blocking an attack (and being counter-blocked and then gang-beaten by all
That, and I actually don't mind games which have been ported to the PC, if they've been done decently well. Beyond Good and Evil smelled very much like a console port, but it worked very well and had what it needed to have to be playable -- it's nowhere near as bad as most of the things mentioned in this article.
There are practical reasons for lossless, however. Where lossy media hurt is a generational loss -- maybe on my desktop or on devices which support it, I'd prefer Ogg Vorbis. Maybe if I had an iPod, AAC would be better. My feature phone likes MP3, and that's also useful if I want to share it with people. And maybe someone wants me to burn a CD, and maybe they will then rip that CD into their own lossy format.
AAC 256k sounds fine. But generational losses do eventually add up, and disk space is cheap, so there's no good reason to put up with them.
And no, I don't have $100 speaker cables. I'd much rather have $100 headphones.
Anonymity is because you can generate a unique number for each transaction you receive. Individual coins, or fractions of coins, are trackable, but they're not necessarily associated with anything else you've done with that account. Basically, a bitcoin "wallet" is an abstraction over an arbitrary number of accounts. Anyone can send money to any of these accounts, but any attempt to transfer money from these accounts must be signed with that account's private key, which you keep.
There's also the fact that if you're paranoid, and doing everything via TOR and such, there's even less opportunity for any online persona you create to be tied back to the actual person.
The entire network has a record of every single transaction. Technically, there is room for nodes which don't keep the entire history, as long as some do. So, transfer of ownership is guaranteed by this consensus. Every time someone mines new bitcoins, they also record your transaction in the same block as the transaction which gives them 50 bitcoins out of thin air -- and each new block that's mined is added to a chain which everyone has (the longest chain wins), so as long as no one entity owns the majority of the computing power on the network, it's unlikely that once you see any transaction confirmed a few times that it will ever be reversed.
In other words, transfer of ownership is guaranteed because everyone acknowledges (and a few lucky miners sign and timestap) that account x sent y bitcoins to account z, and only the person with the key to account x could've generated such a transaction. Anonymity is more or less guaranteed because the person who owns account z also owns n other accounts, with no way for an observer other than z to see that relationship. (You'd think you could track it by spending habits, but each transaction sent is to a different address, and likely from a different address!)
In any case, a bitcoin isn't a file. It's much more a number in the sense that a dollar in the bank is a number -- there is no single entity either in software or in the real world that corresponds to that dollar. What matters is that the bank agrees that you have a certain number of them (including fractions of dollars), and is willing to give you pieces of paper which represent them -- or, that banks are willing to decrement the numerical value of your balance and increment the numerical value of someone else's balance at your request (writing someone a check).
It's all about logic and structure, That also tends to help you understand math, but it's not math that makes you able to program.
Sure it is.
I mean, aside from the fact that all programs are, in fact, mathematical expressions, there's the fact that mathematical thinking is exactly what programming is. I'm not talking about O(n), I'm talking about logic, recursion, sets... Maybe basic calculus seemed really unrelated, but it seems like the more math I learn, the more closely related it is to the coding I've done.
Like for example I've rewritten some really horrid SQL, I'm sure both Microsoft and Oracle has put tons of work in optimizing microseconds off the execution time...
Even stuff like software engineering, though. Math, particularly trying to prove interesting things in abstract spaces, trying to get this idea you have clear enough and concrete enough that you can write it in symbols, flexes all the same mental muscles as trying to write a program from scratch, or refactor it to make way for a new feature (or just because it was ugly)...
Of course, learning math won't teach you to program, but it will make you a better programmer.
Yes, there are constraints, but there are also plenty of problems I run into on a daily basis which I can solve, much more easily and cleanly, because I am at least Unix-savvy and also a programmer.
For example: I'm not sure I want to write my own browser -- actually, I kind of do, but who has the time? -- but userscripts and extensions mean I can hack up websites quite easily. Right now, most webcomics I've ever read, I've added keyboard shortcuts to. (Except XKCD, which already had them!)
Or, take personal data -- suppose that, for whatever reason, someone has the email addresses of a few dozen (or hundred) people they want to send an email to, all in an Excel spreadsheet, and now they want to send a message to all of them via GMail. Will copy and paste work? It will if you save to CSV first, and if that fails (maybe someone has a comma in their name), a script to parse out the actual email addresses from that CSV is trivial.
Here's a weird one: My parents are financial advisers, and every quarter, they get quarterly reports for all their clients in a single giant PDF. The old approach was to print, then physically mail them. Apparently, they are allowed to email these, but you don't want to email everyone's reports to everyone else. But how do you split a PDF? I found a commandline tool to do that within a few minutes of learning about this problem, and I wrote a GUI to do something similar to a mail-merge, but with different regions of the PDF sent to each person.
And that's just the office-drone stuff.
A little knowledge can be dangerous -- I actually kind of wish there were less programmers in the world, and not just because I want job security -- but even so, programming comes in handy quite often, and without spending inordinate amounts of time. Quite often, I think, "I wish it did that," and I can make it happen.
I don't see how a break in ECDSA is better than a break in SHA-256.
everyone can just transfer all their bitcoins back to themselves under a better signature scheme.
Problem is, the "transfer bitcoins to myself under a better encryption scheme" and "rob this person blind, storing the resulting coins under a better encryption scheme" operations look identical, at the network level. So there's a window of opportunity during which a quantum computer could rob anyone and everyone, and while they couldn't double-spend those coins later, they could certainly steal a lot of them ahead of time -- and there'd be no way to tell who had their coins stolen and who simply moved them or spent them.
I'm not sure a break in SHA-256 is much better, but at the very least, there's the entire transaction history to fall back on, and even a new, compromised transaction history could be examined, data-mined, etc. It'd be a massive job to recover, but it seems like recovery is at least possible. By contrast, if my account is emptied, I have no recourse -- again, "I got robbed" looks identical to "I just transferred money to myself under a better encryption scheme" to the network, and to pretty much all the logs in the network.
I'm also not sure I buy the idea of brute-forcing ancient bitcoins. First, how do you know they were actually lost? Maybe someone didn't get the memo about moving to the new cryptosystem, but that doesn't mean it's OK for you to rob them just because someone inevitably will. Second, how does it actually benefit the network? Worst case, enough coins are lost that we have to add another few decimal places to existing bitcoins, but there don't seem to be real barriers to that.
I think the bank wins, for this reason: Banks have fallbacks. If I'm balancing my checkbook, and someone cracks whatever crypto is in place and transfers money out of my account, I can probably have that transaction reversed -- I can prove who I am, and it's probably clear that it's fraud.
I remember getting a call from my parents' credit card company, asking if I'd know my father's voice. I wasn't sure, but we went ahead and tried anyway. They let me listen in (with my line muted, of course) while they talked to someone claiming to be my father. And I don't know how good I am at identifying voices, but my father does not have a thick Indian accent.
So, for better and worse, Bitcoin doesn't have mechanisms like that built in. If someone robs my digital wallet with a quantum computer, that's a bit like stealing my cash, there's not much I can do about it. Banks may occasionally have terrible online security, but they also have social and procedural measures to minimize how much any one attack vector is going to hurt me.
So, if I'm in the bitcoin economy, and I sell something valuable for bitcoins while somebody else is deploying a new gee-whiz type of computer or algorithm that will crack hashes and such, I'm screwed?
Probably. Things might be done more delicately than just rolling the last 24 hours or so back, but it seems like the major problems would be fraudulent transactions and counterfeit currency, and whether keeping either is acceptable. Consider -- if you find yourself with a counterfeit bill, it's no more worthless now than it was when you got it, it's just a lot worse here since you have no reasonable way to tell ahead of time that it's counterfeit.
We start with somebody coming up with a way of messing with the crypto to steal bitcoins. So far, not many people know about it, but some people are crying foul when their bitcoins don't transfer properly.
I'm not sure quite what form it would take, but I don't think this would work. I think it's much more likely that people notice transactions they thought they accepted, and thought were confirmed, suddenly disappear.
Overall, I don't see this as desirable in a system of currency.
Very much not so. Much more desirable would be catching the vulnerability early on enough that there's been minimal damage (if any) so that the worst that happens is an extremely important patch -- or, better yet, catching the potential for a vulnerability before anyone figures out how to exploit it, so that there can be a gradual rollout -- someone mentioned the idea of at first accepting hashes in either form, and then only accepting them in the new, secure form.
Slashdot Mirror
Yeah, and why is that? Why must a person's Facebook profile be "professional"?
Someone might very well conduct themselves professionally during every single working hour, and get a bit crazy on weekends. I see nothing wrong with that, and no reason they shouldn't share that. It seems considerably better to focus on that candidate than the one who has an impeccable image because they can present the appearance of conducting themselves professionally, yet are unable to actually handle some responsibility.
Sparkleshare seems to use Git as a backend, which seems like a Really Bad Idea if you're trying to clone Dropbox. For one, purging old versions should be efficient and automatic.
It's supposed to be super safer, I don't get it?
Clearly you don't. And apparently, the guy who was robbed had the same problem.
The additional "safety" is in other areas -- there's no central, controlling authority, so no one can arbitrarily increase or decrease the supply of Bitcoins, whereas with fiat currency, people absolutely can do that. This is a good thing and a bad thing -- it's a bad thing in that there's no central authority which can attempt to fix the market when things go south, but it's a good thing in that said central authority can't mismanage things, or deliberately manipulate the market for their own game.
It's also anonymous, which is "safe" for other reasons.
But none of this implies your wallet is automagically safe, if you don't take steps to protect yourself. You can make your money safer than with other currencies, but this takes some effort -- the obvious solution would be to create a second "savings" wallet, generate a few thousand addresses for it, then store the actual wallet.dat (with all the private keys) encrypted and in a few thumb drives (or CDs, etc) in a safety deposit box, say. You can send money to savings without retrieving it, but you can only send money from savings by going and retrieving those drives.
Of course, you can go a step further -- you could do all that and also maintain an airgap, so you create the transaction to "withdraw" and sign it on a machine with the "savings" account, then transfer it by sneakernet to your Internet-connected machine.
And you can also take real money and leave it in big stacks on your kitchen table, with your front door unlocked, and then wonder why you were robbed, since you assume dollars are supposed to be "safer" than Bitcoins.
Technically, if I understand the way that bitcoin confidence works, half the damn bitcoin network should know about the details of the transfer.
Which is also probably why the thief knew where to go. It's a security hole.
Ok, parent was already wrong, and you are more wrong.
First, yes, they knew which account it went to, but without sniffing the traffic of the entire Bitcoin network, it's much harder to know which machine it went to. It seems unlikely that the Bitcoin network itself is vulnerable that someone could send an attack to a Bitcoin address without at least getting an IP address out of it first.
Maybe if you were a neighboring peer, you could notice a lot of transactions coming from one particular peer, but you still don't know if those transactions originated from that peer, and it also doesn't help you, since transactions originate from the sending peer (for obvious reasons), and are broadcast to pretty much the entire network. So even if you could track where a transaction originated from by sniffing traffic, that doesn't tell you where it went -- it could, in fact, be anywhere in the entire network, or in an account which is physically disconnected, or even in an account which doesn't exist (user mis-pasted the destination address).
To get anywhere close, you'd have to be able to sniff pretty much all of the originating peer's traffic, including other channels like web and IRC where the transaction was probably negotiated. Even that doesn't help you much, since you now have the problem of tracking a website, forum user, or IRC user back to the actual IP address where the coins are kept.
Now, all of this stuff is possible, certainly, but none of it really has much to do with Bitcoin being anonymous or not. At least, it provides no new problems over traditional banking, and is actually somewhat safer. If I could somehow sniff your communication with your bank (though admittedly, Bitcoin IRC and forums aren't always encrypted, and are more often TORed), I could drain your account whether you're the sender or receiver, and I wouldn't need to break your machine if I could somehow intercept your credentials (MITM). Banks can use SSL, but you could also refuse to trade Bitcoins over any forum which doesn't.
So, TL;DR: There's no way that the entire Bitcoin network knowing about a transaction (or about every transaction) is going to lead to knowing which physical machine to attack.
Not that the user should have known this, but dontcha think if there was $500k involved that a little curiosity on how it works and how to encrypt it better (put the .dat file in TrueCrypt container and make copies)?
Um. Yes. And yes, the user absolutely should've known that. WTF were they doing putting $500k in Bitcoin if they didn't? It's certainly enough to afford some extra hardware so you can do air-gaps.
I mean, I don't know what sort of precautions I should take before carrying $500k around in my pocket (or in a briefcase), but I'd bloody well find out before I did so.
In the case of Anonymous, if they actually are anonymous, there's no particular reason you couldn't have any member deny responsibility while (falsely) claiming to speak for the entire collective.
And no, it's really not, BItcoin actually is reasonably anonymous. Everyone can see transactions, but that doesn't give them terribly useful information if you're doing it right and generating a new address per-transaction, which is trivial to do.
Or, better, if you care about anonymity, pre-generate a few hundred (or thousand) addresses for your "savings" wallet, so that each time you send money to it, you send it to a different address.
The victim should know exactly what the recipient address of those ill gotten gains are.
Assuming there's a single address.
Technically, if I understand the way that bitcoin confidence works, half the damn bitcoin network should know about the details of the transfer.
Sure.
But there's two problems here: First, addresses are trivial to create, and generally you create a new one per transaction. So it could've gone to dozens of accounts.
Second, you can't prove the person who claims to be robbed didn't transfer the money to another account they own (like the "savings" account I describe below), and even if you could track the account they went to, it's much harder to figure out who actually owns that account. And maybe they've already spent them -- in which case, you have similar problems again; did they actually buy this, or simply transfer the money to another account they own?
I know that bitcoin technology provides for cloud-based "banks" of a sort. If they have been implemented yet, I do not know.
I think the main idea of those is for people who don't want to install the software and manage it themselves. I don't think they give you any additional security. If anything, they reduce your security, since an attacker can either steal your username and password (with or without breaking into your machine) or attack the online bank in pretty much any way (including being the online bank).
By contrast, if you run your own security, you have options. If I had a significant amount of Bitcoins, I'd create a second wallet and keep it encrypted and probably offline, and use it as a "savings" account. I could trivially generate a few hundred accounts, then put the wallet on a flash drive or two, and then not need to plug it in until I need to withdraw, since I can send coins to it without it being on my or any machine.
Of course, you have to be equally careful to actually make backups, since if your wallet.dat is on a drive which fails, or even if there's just a bad sector in the middle of it, your money is just as gone as if someone stole it. I'd like to think that this sort of thing would be incentive for people to finally start giving a fuck about security. Unfortunately, it looks like it's instead going to be a disincentive for people to adopt Bitcoin.
It makes for a better demo, I guess, but that'd be my first question too.
My second question would be whether it's the application which decides where it runs, or the OS -- it seems like now we'll not only need multicore schedulers, but GPU-aware schedulers also, but it's still something I'd like the OS to have a say in. For instance, "We need the GPU for graphics now, so you get routed to the CPU instead."
I suspect my second question is more naive than my first.
Well, assuming your code has embarrassingly parallel components. Otherwise, it's pretty useless.
I have to imagine that was also behind XP.
It just keeps getting more relevant.
And why would you do that? What does someone's personal life have to do with their ability to conduct themselves professionally?
I mean, I can understand if they included that picture on their resume, but really?
For digital there is far less reason to have the high end stuff but quality matters.
Only for longevity/durability.
It's digital. Either it works or it doesn't. Either you get a signal or you don't. On or off.
I suppose if it's HDMI, it might matter that there are supposedly certain features present in one but not the other, but still, I laugh out loud when I see HDMI cables starting at $25 or so and often approaching $100, when they're under $10 on Newegg. It just has to show me a picture!
I don't think we actually disagree, but the point is, a higher-end, gold-plated, audiophile-approved, blessed-by-the-tears-of-Baby-Jesus cable is still not going to get you any better audio/video quality if it's really just sending you bits. (I swear I've seen an audiophile Ethernet cable before!) The only reason you'd care about one over another is whether it's going to physically fall out or fall apart, and even with the cheap stuff, I rarely have that happen.
That comes up to something like $60 USD, so it's not really far off from the $100 I was assuming. Far from "expensive" for headphones. Ludicrously expensive for a cable which doesn't really affect the sound, which was the point.
Yeah, you would hope there'd be a hardware provision to clear memory blocks. You'd also hope that there's some amount of buffer between malloc/free/new/delete and actually returning that memory to the OS or allocating more.
It does, however, mean that you're effectively running some sort of garbage collection all the time. Java can just pass a pointer around; you have to pass a pointer and increment/decrement something. Java might interrupt your program to do some GC; you might call free/delete whenever any given reference falls out of scope.
It might matter less now, but this did occasionally have advantages -- aside from the efficiency gains of having at least some amount of buffer so as to not always be allocating/freeing directly to/from the OS (and I bet someone can optimize C++'s new/delete to do the same thing), there's also the fact that having all your GC code in one place, such that your normal code isn't even calling it, makes your normal code faster, and more importantly, smaller, so it all fits into cache. Then, when a GC cycle hits, the GC itself is all in one place, so it all fits into cache.
On the other hand, the less often a given GC cycle runs, the more likely it is to involve a fair number of cache misses (even just to find out what memory is in use), whereas sufficiently small/light branches of C++ code might allocate, use, and free all of their memory over and over again without any cache misses.
I should really shut up until more profiling is done, which means I should probably RTFA.
Others have pointed some of these out, but I also don't agree with everything on that list, so here we go:
Thou shalt not shun thine player's mouse
By the same token, don't rely exclusively on the mouse. Yes, the mouse is going to be quick for configuring stuff and for navigating an unfamiliar menu. However, any game I end up playing a lot, I find myself wishing I could use the keyboard for navigation more -- I think that comes down to:
Remember thine user-interface conventions and keep them holy
I'm not sure there's a good technical way to do this yet, but it'd be really nice if every game didn't reinvent the GUI. Steam even seems to have its own windowing system and GUI library in order to be able to show you a chat window either outside in the OS or on top of a running game. But it does mean that they have to re-solve a lot of problems that GUIs have solved for decades. When I have a GUI up with a bunch of options, every input field in that form gets some sort of accelerator, or at least the tab key will move between them. Steam at least looks and feels kind of like normal windows, but I'm not sure they get that, and I know most games end up rolling their own UI directly on top of whatever 3D framework they're using, which is probably where we're getting the Huge Text of Doom.
One thing that's actually kind of refreshing is the ability to set visual options in a separate window before the game engine actually starts, but that has its own caveats -- I shouldn't have to restart the game to tweak resolution. Especially on older video cards, and with games with a lot of options, it's going to take me a few tries to find the right balance of performance vs visuals. Make that loop as tight as possible.
Anyway, moving on:
Thou shalt not accelerate mouse input
Can't really agree. Maybe don't make it the default, and maybe make it a checkbox somewhere. It's even possible that it's a useless feature. But remember, this is a PC game -- don't arbitrarily change the control from one behavior to another in a new version, make it an option.
Thou shalt not mix thine bindings
This one is also a bit mixed. Context-sensitive bindings can be a very good thing, though they do have all the problems mentioned here. What we want is some balance, perhaps a configurable balance, between the console idea of "press B to do anything" (Conker's Bad Fur Day had a lot of fun with this) and the old-school PC idea of "Bind a keystroke to everything." Duke Nukem 3D had an extensive keymap, including hotkeys for a number of inventory items like the jetpack. Old-school shooters in general would bind each weapon to a number. These are good things for more advanced players, and once you either master the everything-has-its-own-key keymap or figure out which items you care enough about to assign a key to, it's a good thing. Still, having a smaller set of controls I have to pick up to be adequate is very useful to get me playing until I reach that level -- so, for example, keys to navigate through my inventory and use an inventory item, or using the mousewheel to navigate through weapons, is much more critical than being able to press 'j' to instantly activate my jetpack, or 'h' to instantly activate my Holoduke, etc.
Lugaru has a ton of context-sensitivity, and there's no way it'd be playable if it wasn't context-sensitive. It's even part of the skill of learning to play this game well -- for example, to successfully perform a silent takedown, I need to somehow end up behind an enemy who hasn't noticed me yet, and press attack without pressing forward. Easy enough if I sneak up on them, much harder if I'm jumping from across the map and landing right behind them -- but immensely satisfying to be able to one-hit a wolf. The downside is that I often find myself blocking an attack (and being counter-blocked and then gang-beaten by all
That, and I actually don't mind games which have been ported to the PC, if they've been done decently well. Beyond Good and Evil smelled very much like a console port, but it worked very well and had what it needed to have to be playable -- it's nowhere near as bad as most of the things mentioned in this article.
There are practical reasons for lossless, however. Where lossy media hurt is a generational loss -- maybe on my desktop or on devices which support it, I'd prefer Ogg Vorbis. Maybe if I had an iPod, AAC would be better. My feature phone likes MP3, and that's also useful if I want to share it with people. And maybe someone wants me to burn a CD, and maybe they will then rip that CD into their own lossy format.
AAC 256k sounds fine. But generational losses do eventually add up, and disk space is cheap, so there's no good reason to put up with them.
And no, I don't have $100 speaker cables. I'd much rather have $100 headphones.
Anonymity is because you can generate a unique number for each transaction you receive. Individual coins, or fractions of coins, are trackable, but they're not necessarily associated with anything else you've done with that account. Basically, a bitcoin "wallet" is an abstraction over an arbitrary number of accounts. Anyone can send money to any of these accounts, but any attempt to transfer money from these accounts must be signed with that account's private key, which you keep.
There's also the fact that if you're paranoid, and doing everything via TOR and such, there's even less opportunity for any online persona you create to be tied back to the actual person.
The entire network has a record of every single transaction. Technically, there is room for nodes which don't keep the entire history, as long as some do. So, transfer of ownership is guaranteed by this consensus. Every time someone mines new bitcoins, they also record your transaction in the same block as the transaction which gives them 50 bitcoins out of thin air -- and each new block that's mined is added to a chain which everyone has (the longest chain wins), so as long as no one entity owns the majority of the computing power on the network, it's unlikely that once you see any transaction confirmed a few times that it will ever be reversed.
In other words, transfer of ownership is guaranteed because everyone acknowledges (and a few lucky miners sign and timestap) that account x sent y bitcoins to account z, and only the person with the key to account x could've generated such a transaction. Anonymity is more or less guaranteed because the person who owns account z also owns n other accounts, with no way for an observer other than z to see that relationship. (You'd think you could track it by spending habits, but each transaction sent is to a different address, and likely from a different address!)
In any case, a bitcoin isn't a file. It's much more a number in the sense that a dollar in the bank is a number -- there is no single entity either in software or in the real world that corresponds to that dollar. What matters is that the bank agrees that you have a certain number of them (including fractions of dollars), and is willing to give you pieces of paper which represent them -- or, that banks are willing to decrement the numerical value of your balance and increment the numerical value of someone else's balance at your request (writing someone a check).
It's all about logic and structure, That also tends to help you understand math, but it's not math that makes you able to program.
Sure it is.
I mean, aside from the fact that all programs are, in fact, mathematical expressions, there's the fact that mathematical thinking is exactly what programming is. I'm not talking about O(n), I'm talking about logic, recursion, sets... Maybe basic calculus seemed really unrelated, but it seems like the more math I learn, the more closely related it is to the coding I've done.
Like for example I've rewritten some really horrid SQL, I'm sure both Microsoft and Oracle has put tons of work in optimizing microseconds off the execution time...
Even stuff like software engineering, though. Math, particularly trying to prove interesting things in abstract spaces, trying to get this idea you have clear enough and concrete enough that you can write it in symbols, flexes all the same mental muscles as trying to write a program from scratch, or refactor it to make way for a new feature (or just because it was ugly)...
Of course, learning math won't teach you to program, but it will make you a better programmer.
Yes, there are constraints, but there are also plenty of problems I run into on a daily basis which I can solve, much more easily and cleanly, because I am at least Unix-savvy and also a programmer.
For example: I'm not sure I want to write my own browser -- actually, I kind of do, but who has the time? -- but userscripts and extensions mean I can hack up websites quite easily. Right now, most webcomics I've ever read, I've added keyboard shortcuts to. (Except XKCD, which already had them!)
Or, take personal data -- suppose that, for whatever reason, someone has the email addresses of a few dozen (or hundred) people they want to send an email to, all in an Excel spreadsheet, and now they want to send a message to all of them via GMail. Will copy and paste work? It will if you save to CSV first, and if that fails (maybe someone has a comma in their name), a script to parse out the actual email addresses from that CSV is trivial.
Here's a weird one: My parents are financial advisers, and every quarter, they get quarterly reports for all their clients in a single giant PDF. The old approach was to print, then physically mail them. Apparently, they are allowed to email these, but you don't want to email everyone's reports to everyone else. But how do you split a PDF? I found a commandline tool to do that within a few minutes of learning about this problem, and I wrote a GUI to do something similar to a mail-merge, but with different regions of the PDF sent to each person.
And that's just the office-drone stuff.
A little knowledge can be dangerous -- I actually kind of wish there were less programmers in the world, and not just because I want job security -- but even so, programming comes in handy quite often, and without spending inordinate amounts of time. Quite often, I think, "I wish it did that," and I can make it happen.
I don't see how a break in ECDSA is better than a break in SHA-256.
everyone can just transfer all their bitcoins back to themselves under a better signature scheme.
Problem is, the "transfer bitcoins to myself under a better encryption scheme" and "rob this person blind, storing the resulting coins under a better encryption scheme" operations look identical, at the network level. So there's a window of opportunity during which a quantum computer could rob anyone and everyone, and while they couldn't double-spend those coins later, they could certainly steal a lot of them ahead of time -- and there'd be no way to tell who had their coins stolen and who simply moved them or spent them.
I'm not sure a break in SHA-256 is much better, but at the very least, there's the entire transaction history to fall back on, and even a new, compromised transaction history could be examined, data-mined, etc. It'd be a massive job to recover, but it seems like recovery is at least possible. By contrast, if my account is emptied, I have no recourse -- again, "I got robbed" looks identical to "I just transferred money to myself under a better encryption scheme" to the network, and to pretty much all the logs in the network.
I'm also not sure I buy the idea of brute-forcing ancient bitcoins. First, how do you know they were actually lost? Maybe someone didn't get the memo about moving to the new cryptosystem, but that doesn't mean it's OK for you to rob them just because someone inevitably will. Second, how does it actually benefit the network? Worst case, enough coins are lost that we have to add another few decimal places to existing bitcoins, but there don't seem to be real barriers to that.
I think the bank wins, for this reason: Banks have fallbacks. If I'm balancing my checkbook, and someone cracks whatever crypto is in place and transfers money out of my account, I can probably have that transaction reversed -- I can prove who I am, and it's probably clear that it's fraud.
I remember getting a call from my parents' credit card company, asking if I'd know my father's voice. I wasn't sure, but we went ahead and tried anyway. They let me listen in (with my line muted, of course) while they talked to someone claiming to be my father. And I don't know how good I am at identifying voices, but my father does not have a thick Indian accent.
So, for better and worse, Bitcoin doesn't have mechanisms like that built in. If someone robs my digital wallet with a quantum computer, that's a bit like stealing my cash, there's not much I can do about it. Banks may occasionally have terrible online security, but they also have social and procedural measures to minimize how much any one attack vector is going to hurt me.
So, if I'm in the bitcoin economy, and I sell something valuable for bitcoins while somebody else is deploying a new gee-whiz type of computer or algorithm that will crack hashes and such, I'm screwed?
Probably. Things might be done more delicately than just rolling the last 24 hours or so back, but it seems like the major problems would be fraudulent transactions and counterfeit currency, and whether keeping either is acceptable. Consider -- if you find yourself with a counterfeit bill, it's no more worthless now than it was when you got it, it's just a lot worse here since you have no reasonable way to tell ahead of time that it's counterfeit.
We start with somebody coming up with a way of messing with the crypto to steal bitcoins. So far, not many people know about it, but some people are crying foul when their bitcoins don't transfer properly.
I'm not sure quite what form it would take, but I don't think this would work. I think it's much more likely that people notice transactions they thought they accepted, and thought were confirmed, suddenly disappear.
Overall, I don't see this as desirable in a system of currency.
Very much not so. Much more desirable would be catching the vulnerability early on enough that there's been minimal damage (if any) so that the worst that happens is an extremely important patch -- or, better yet, catching the potential for a vulnerability before anyone figures out how to exploit it, so that there can be a gradual rollout -- someone mentioned the idea of at first accepting hashes in either form, and then only accepting them in the new, secure form.