You agreed a contract with someone to do some work in exchange for a bitcoin, didn't pay once they did the work for you, and then publicly stated you weren't going to pay. In fact, that seems to be one of the usual ways of getting a scammer tag around here...

Edit: Oh, and you've since changed your name in order to disassociate yourself from that.

All of the changes can't be released as a modified client for the Bitcoin blockchain; doing so would cause a fork in the blockchain which would be a lot more disruptive than simply starting a new one. In particular, the problem with forking the blockchain is that transactions can be carried from one side to the other and this can be used to double-spend bitcoins - once on each side of the fork - and obtain bitcoins that are valid on both sides, guaranteeing that exchanges and e-wallets will be screwed over.

Sounds like a good reason to implement it on a new, smaller network rather than Bitcoin then.

Not relevant to Bitcoin now; it's an open question as to whether it will be in the future. Also, the limited difficulty increases aren't just a subsidy to miners, they're also necessary to stop the difficulty from overshooting wildly. (For some reason they're not just implemented as a simple change to one constant either; the way difficulty increases are calculated is substantially modified.)

It was an arbitrary choice when Satoshi made it for Bitcoin and it's still an arbitrary choice now.

(Also, am I the only person that's more worried about the security implications of their changes to difficulty targetting than anything else?)

Just spotted this conversation in #bitcoin yesterday afternoon:


Sigh.

Because it's what the existing code that fpgaminer wrote was using and it saves trying to hook up an extra cable of some kind for communication, basically. There are already methods of running miners without using the FPGA software if you don't want to use JTAG.

Some government trying to spoof the blockchain into oblivion using masses of GPUs shouldn't cause your old bitcoins to become invalid unless it wipes out all bitcoins in existence. There are already periodic blockchain lock-ins that fix the block chain prior to that point in stone; if we need to change over to a new protocol whoever designs it could just lock-in the entire classic Bitcoin blockchain up to that point and build from there. Alternatively they could choose to start over from scratch, in which case all Bitcoins will be affected.

The only things that could cause a Bitcoin wallet that's been successfully stored for a long time to be invalid without invalidating all Bitcoins are a serious break in either elliptic curve crypto or SHA-256, or a deliberate consensus to invalidate them on the part of other Bitcoin users and mining pools. For example, if transaction volume gets too high mining pools and other full nodes might decide that storing the full blockchain is too expensive and throw away the older parts, either destroying older Bitcoins that have been sitting idle or making them increasingly hard to spend.

By the way, I eventually managed to get the site to send me a password reset e-mail and reset my password... but I had to edit the URL in the e-mail because it sent me to the main BTCGuild site rather than SCGuild.

Edit: Also, glad to hear the reset stats button will be making an appearance. I'm testing pointing my slow FPGA miner (now with long polling!) at SC Guild and it would've come in handy, though I guess I could've created a new worker...

Via somewhat dubious methods that I'm really hoping won't get me in trouble with Altera legal - you might want to hold off on that. It's actually an incredibly straightforward bit of functionality on top of the rather hairier - but documented - virtual JTAG layer. Thankfully someone else had already written code for talking to UrJTAG and enumerating virtual JTAG nodes, even if they did foolishly believe the documentation (which someone else had fortunately already discovered was wrong.)

I don't think they do. According to the virtual JTAG documentation, their approach is really complicated and involves duplicating the entire JTAG state machine in LUTs using code that we don't have access to at a low enough level.

Edit: The closest equivalent is their virtual JTAG layer; you should be able to do pretty much all of the same things with that as you can with BSCAN_SPARTAN6, but talking to it involves most of the same complications as talking to altsource_probes. At least virtual JTAG is documented I guess.

I didn't notice that issue...

OK, I'm now mining on an Altera FPGA with poclbm. (Well, some heavily hacked-together Python code based on poclbm to be exact.) You can find the code in question on Git here but it's a bit of a pain to use right now; you have to create a new BSDL directory, obtain the BSDL file for the FPGA you're using and copy it to the directory, edit the source to use the correct directory, and then run it and hope it finds the correct USB Blaster and works. Oh, and it needs UrJTAG installed.

In theory this means that you can now mine using fpgaminer's code for Altera FPGAs that communicates over JTAG without having any Altera software installed. (It also has long polling support obviously.)

Edit: Now has a bsdl/ directory in the source tree to place the bsdl files in.

Anyone that had been reading the SomethingAwful thread or that had even watched his show live - but I repeat myself - would already have had appropriate expectations. I'm not really convinced anyone from there could've stopped laughing long enough to finish writing half of these posts; they're skilled but not that skilled. Seriously, the SA thread is worth reading...

I have to admit that the dual FPGA board is looking rather better price-wise.

Presumably it has less flexibility too, though I'm not sure precisely what you're planning...

(Edit: On an unrelated note, #*!$ing Altera and their undocumented altsource_probe JTAG protocol...

Edit 2, hours later: Here, have a incredibly ugly Python hack to speak to FPGAs running fpgaminer's virtual_wire-based code over USB Blaster. It won't bite much.)

Errrm, I've kind of lost my password for SCGuild and can't seem to get the password reset feature to work. (Same username as my forums account). Don't suppose you could look into this?

You don't actually have to broadcast the transaction at all - the block is still valid even if the transaction was never broadcast. In fact you don't want to broadcast it because that significantly increases the risk of something going wrong and you losing your bitcoins. Doesn't stop malicious attacks though.

Also: this scheme will stand out like a sore thumb to everyone watching Block Explorer and probably get mentioned on IRC.

Yeah, they're not actually that much cheaper than the equivalent full dev boards and your ability to develop other stuff for them is vey constrained.

I'd suggest buying a DE0-nano if it wasn't for the fact that they've cheaped out on the power circuitry to the point it's very difficult to get reliable mining at any speed, let alone max the chip out. If they'd used more efficient power regulation circuitry it ought to top out at about 25 MHash/sec, probably even with just USB power, which isn't bad for the price.

That's interesting. Someone who replied to one of my /. comments reckoned FPGAs were about half the retail price if bought in bulk from the manufacturer... of course he could be talking BS or the required volume could be higher than you're going to reach, and the lead times are probably horrid.

Have you actually read the post you linked to? He spends quite a lot of it ranting about how Bitcoin users are trying to discredit him by linking him to MyBitcoin. Also, insinuations are not facts. The facts are that he's arranging a meet-up of Bitcoin users at a hotel that caters to gays, and that some Bitcoin users are under 18. When you put it like that it's rather different from nanoaimogold's insinuation that he's luring underage boys back to his hotel room for dubious purposes.

Hah. Nice idea, but no - buttcoin.org is on a completely different host that I haven't encountered in relation to MyBitcoin, Privacy Shark, any of the Privacy Shark-registered domains I've looked at, or any site even remotely related to any of the above.

Attempt by nanaimogold to distract from the links between him and MyBitcoin, at a guess - nanaimogold.com isn't just on any random Canadian hosting provider. There's a whole bunch of interlinked sites that appear to be run by either the same people or people that know each other due to lots of similarities in hosting setups (many use FreeBSD, one particular obscure and uncommon webserver, are on the same hosting provider in the same range of IP addresses, have PrivacyShark-registered domains, that kind of thing). One of these sites is link2voip.com: they use FreeBSD, that webserver, and that host provider and IP address range. (They also linked to e-gold with the same referral code as PrivacyShark back when both accepted it for payment.) Oddly if you look at their facilities information the listed IPs for their Candian VOIP servers 66.51.127.173 and 66.51.110.210 aren't on that IP address range. In fact...

Same hosting provider for nanaimogold.com as for those VOIP servers. Funny that. (This happens a lot when you dig into the people and companies surrounding MyBitcoin and PrivacyShark... they're all so incredibly intertwined.)

There's definitely something magical about the first confirmation though; accepting coins after one confirmation is a lot riskier than accepting them after two no matter what the interval between blocks is, at least for reasonable intervals. Remember that malicious miners aren't the only threat; it's also possible to exploit natural block chain forks, and single-block orphan blocks are a lot more probable than double ones. (Also: if a big miner or pool redirects their mining power to attempt a double-spend, I think it should be easier to detect statistically with 5-minute blocks and 12 confirmations required.)

That would be an example of an unreasonable interval. Anything less than a minute is likely to cause breakage.

You're talking about the developers intentionally revoking previously-valid transactions by central fiat - and they can't just revoke the ones involved in the double-spend, they have to revoke all of them. If any exchange or e-wallet site remains running after the double-spend attack - and not all of them can afford to watch the news 24/7 - they risk having their wallets drained by double-spends assisted by the Bitcoin developers themselves! This could well end up doing more damage than the original attack. From the point of view of those affected byt this second attack the developers' version of the chain is in fact the malicious one and they'd be entirely justified in hard-coding their clients to reject it instead; imagine if Mt Gox did this.

Edit: Oh, and it's kind of hard to tell for sure when the botnet has "given up", because they don't have to tell the rest of the Bitcoin network about their malicious chain until it's time to replace the existing one with it.

Hmmmm. Looking at the source code... genesis block has a New York Times headline from 20th of August 2011 (and there's left-over code both for generating a new genesis block and for exiting after the required number of pre-mined blocks), the pchMessageStart and list of hardcoded seed nodes have been changed correctly, the difficulty calculation doesn't look to do quite what's suggested here but is close, and I can't spot anything suspicious.

The sha256 of the source archive I downloaded was c54f404b15d229cf2a922fcb4d78ce19aa26a3d97a2df507376ad45c9fb06ebd.

server=1. Same as for the bitcoin client.