Surprised there's not a thread in Scam Accusations for this already. Apparently the owner of bitmarket.eu was gambling with user funds on Bitcoinica and lost them all when it shut down:

Hello all. I'm terrible sorry for not responding to this earlier. A mix of personal issues with searching for a solution prevented me from it.

Unfortunately, I have very bad news. I cannot currently proccess your withdrawals. The situation is very complicated and it's all my fault, that's why I feel terrible about it. I tried to make this up, to keep the site afloat and somehow recover the funds, but it's not possible anymore. Right now there are 1786 BTC pending withdrawal, which I can't honor...

Earlier this year, I had this "genius" idea which led me to making a fatal mistake. I thought I could provide a hedge fund service for Bitmarket users. There were other sites providing this service so I guesses that it could be successful. I had experience in trading before, all I needed is a platform. And there was one - Bitcoinica. I was so convinced with this idea (and sooo wrong in hindsight) that for a while I kept majority of "offline" Bitmarket funds there. What I didn't expect was that one day it could just dissapear - taking all the money with it. What's worse, the funds were shorted when it happened (converted to USD and sold) - and after Bitcoinica dissapeared BTC price rose by about 250% until now. So while there is still chance to recover the funds (there is an appointed liquidator assigned to this case and I've already sent in claims) it will be not enough to cover all people's funds. For the record - there are 20161 19980 BTC missing (edit: I subtracted my funds that also were deposited on Bitmarket), and Bitcoinica claims total for around 50K USD (the exact amount is uncertain because the liquidators haven't yet stated at what rate they will liquidate positions).

Sadly, I alone, I'm out of options. I don't have own money to pay for this loss (Bitmarket never made any real profit and I make up for a living by part-time web/mobile programming).

I kind of predicted this when Theymos originally offered to allow thread starters to set local rules which the moderators would enforce, but they've basically turned into a scammer's dream. Usagi in particular is making good use of them to ban anyone who points out the myriad ways in which he's screwing over investors and lying about the values of his underlying assets from his threads. In particular, he's banned everyone who's pointed out how badly his planned trade-in scheme would screw over investors from his latest thread trying to convince people to take him up on it, so that he can screw them over without the inconvenience of comments pointing out the holes in his claims.

Unless we want the forum moderation team to help scammers swindle suckers out of Bitcoins, it might be a good idea to rethink what kind of rules people can set in their threads.

Also, I notice Usagi claims to have spoken to theymos personally about setting these kinds of local rules and got his agreement on it:

EDIT: to avoid a seperate post please clarify this.  You repeatedly refer to "local rules" which allow a thread-starter to choose who may post and what content they may post.  Can you PLEASE point me to some official FAQ or guidelines post giving any validity to such "local rules"?  I honestly can't find one - but will happily stick to local rules if (and only if) such official guidance exists.  If no such guidance exists then please don't waste your virtual ink in the future referring to such meaningless "local rules" again.

I spoke with Theymos directly on this. I can only advise you that you probably don't want to break local rules too often. No I can't point you to a FAQ. I'm unaware of where local rules are described.

Never mind.

For the past few weeks I've been mining by hooking my DE0-Nano up to my PC directly via USB - no JTAG or microcontrollers or USB-to-serial, just full speed native USB. The code to do this has actually been publicly available in my git repository for about that long too, but I'm not entirely happy with it for various reasons. The licensing on the USB function core from OpenCores it uses is a bit odd, the code quality isn't that great, and I'm interfacing the FPGA pins directly to the USB port when I should really be using something like a TUSB1106 chip for better reliability and to protect the FPGA from being damaged by shorts to +5V.

Anyway, if anyone's got a use for this the Quartus project is in the projects/DE0_nano_USB directory of the de0-nano-usb branch, and the code to mine using this is in the usb-miner branch of afpgabm. You'll need to connect USB ground directly to pin 30 of JP1 on the DE0-nano, D+ to pin 25 and D- to pin 23 through say 10 to 47 ohm resistors (not sure what the exact resistor value should be), and connect a 1.5k pull-up resistor from D+ to a source of 3.3V that's only enabled when the 5V USB power is on. Better yet, rip out the fake USB transceiver logic from fpgaminer_top.v and use a TUSB1106 or similar. Users of expensive Spartan-6 boards should always use a real transceiver chip, partly to stop your hardware getting damaged and partly because some of them run on non-USB-compatible IO voltages that need to be converted.

Apparently SolidCoin 3.0 is going to introduce a daily fee for each address you own that has a non-zero balance in order to reduce the total number of addresses in use:

ne problem I saw with the SolidCoin v2 protocol is the fact that no one actually pays for any resources on the network besides transactions. Why is this a problem? Well every "address" or "account" actually consumes memory, disk space and processing power of all the running nodes. Then when someone does pay for a transaction, all the fees goes to the miner, when the truth is every node on the network has just as much burden when it comes to sending transactions and storing them. It is unfair.

Another problem was the fact that the system itself isn't self cleansing. That is to say, if someone sends 0.0001SC to a new account that account is there for life consuming resources with no purpose in a lot of cases (ie spam). So our solution to this is a decay and interest model. Here is how it works.

1) For every account (ie unique address) on the network, there is a small daily fee. (likely to be around 0.0025 SC or a quarter cent)
2) All the "decay fees" are added up and then given back to every account, depending upon their percentage of SolidCoin holdings. ie there are 2.8 million coins right now, if you have 28000 then you have 1% of all the SolidCoins and will get 1% of the daily account fees. So a certain amount of SC in your account will ensure you pay no daily fees.
3) Transaction fees won't go to the miners anymore but the same decay/interest model. This way everyone who is invested in SolidCoin benefits, including the miners, for including transactions
4) Once an account hits 0 it is removed from nodes memory, saving them CPU and MEMORY usage. It can of course come back if that user decides to later use it.

It's important to realize that you only need a single account now due to our improved transactions, so the only reason you'll want to use more accounts is for anonymity or other personal purposes.

RealSolid is also planning to introduce exponentially increasing fees for accounts that haven't been touched in over 6 months in order to quickly redistribute the funds to active users:

We will definitely be implementing a dead account acceleration , currently it's planned that if you don't use an account for 6 months, every month after that the fee doubles and interest stops. So by month 12 of inactivity, the fee is still only 4.8 per month, by month 21 of inactivity, the monthly fee is ~2400 . So even if you go away for 12 months on a large account, you're not going to lose any money, you'll have gained due to the first 6 months interest. Probably even by 18 months you'll still be in positive territory. But after that it quickly recycle any dead accounts and everyone benefits.

So if you stick some SolidCoin savings on a USB stick in a bank vault for a few years, they'll be gone by the time you come to collect them. If my math's right, you could have nearly all the SolidCoins in existence in your account and it'd still only take 36 months of account inactivity for it to be totally emptied through fees.

[This isn't true.]

One of the claims about BIP 16 - the "pay to script hash" change supported by most of the Bitcoin developers - is that it should be a reasonably non-disruptive change. In particular, it wasn't expected to affect pools and miners running unmodified Bitcoin clients too much even if they didn't upgrade. There was a small risk that they'd try and build on blocks containing an invalid attempt to spend a BIP 16 transaction, but the IsStandard check would supposedly stop them from trying to include any BIP 16 transactions they couldn't properly verify in blocks they created themselves.

This isn't true. As gmaxwell pointed out when he discovered p2pool was allowing miners to put non-standard transactions in their coinbases, IsStandard doesn't actually check that the scriptPubKey of the transaction being spent was standard at all - it only checks the scriptSigs and scriptPubKeys of the transaction being spent. This means that attempts to spend BIP16 transactions pass IsStandard in older clients and they'll include them in blocks they mine even though they can't do the extra BIP 16 verification required to do this safely. I've even tested this works using a couple of test nodes running on mainnet rules; unfortunately this can't be tested on testnet.

What does this mean? It means that once BIP 16 is switched on, anyone can send out a couple of simple transactions, the first paying money to a BIP 16 address and the second trying to spend it to a normal pubkey address in a way that pre-BIP 16 clients will accept and BIP 16 ones won't. Once they do, all the nodes that don't support BIP 16 will mine blocks that the BIP 16 nodes will treat as invalid and rewrite out of existence using their majority of hash power. Worse still, everyone running or mining on a pool that supports BIP 16 has an incentive to do this because it'll eventually push difficulty down and make them more money.

In retrospect, someone should've probably started asking questions once Gavin Andresen listed the fact that transactions spending from BIP 16 addresses would pass IsStandard and be forwarded by older nodes as an advantage over BIP 17. The rules for forwarding transactions are almost identical to the rules for including them in blocks. (BIP 17 probably has the same issue though.)

[Well, looks like this is pretty much dead courtesy of a >51% attack by Luke Jr. The more interesting features should in theory be available in Bitcoin eventually - including the removal of existing legacy Bitcoin addresses if Luke Jr gets his way (he was threatening to refuse to mine transactions using them). No idea when though and I certainly won't be developing the tools to make use of them.]

Well, looks like this is pretty much dead courtesy of a >51% attack by Luke Jr. The more interesting features should in theory be available in Bitcoin eventually - including the removal of existing legacy Bitcoin addresses if Luke Jr gets his way (he was threatening to refuse to mine transactions using them). No idea when though and I certainly won't be developing the tools to make use of them.

Since there aren't quite enough shamefully Bitcoin-cloning cryptocurrencies out there yet, I'm launching another one - Coiledcoin. It has all the features you might expect from a modern Bitcoin clone, plus a handful more:

• Merged mining and OP_EVAL support from the start
• No legacy addresses. Anyone and anywhere that can pay to a Coiledcoin address can pay to one that requires signatures from multiple parties to spend, such as an escrow account or a business account requiring approval from two managers. It makes no difference to the sender - all addresses use OP_EVAL and look the same. (The infrastructure to spend these is fairly poor right now though.)
• Block every 2 minutes on average, difficulty adjustment of up to 100% up/50% down every 720 blocks (nominally 24 hours), ArtForz timestamp exploit fixed.
• 10 CLC reward per block initially, halving every 525000 blocks (nominally 2 years) until it reaches 1 CLC where it will remain forever. This is an inflationary coin, at least until you take coin loss into account.
• Minimal 1337 50 CLC premine in the genesis block
• Note that internally Coiledcoin addresses and transactions are formatted differently to normal Bitcoin clones. Do not use Bitcoin tools like vanitygen or PoolServerJ's workmaker support to create new addresses or transactions, and do not import keys with pywallet either. In theory you can safely use PoolServerJ for merged mining with Coiledcoin as an aux chain, just don't turn on workmaker for the Coiledcoin aux chain - it'll look like it works but the payouts will be unspendable.
• More neat stuff (instant payments, light clients, possibly wallet protection services that require confirmation of large spends, etc) coming soon once I or someone else gets around to writing it.
• Not sure what the initial difficulty will be yet, most likely 16

Download it from here
Windows release
Windows installer
Linux release
Source code

Not sure if there'll be a pool available at the time of launch yet though. If not, once the difficulty rises and the block rate drops off you can use merged mining to solo mine it at the same time as mining Bitcoins on p2pool. In addition to those instructions, you need to set rpcuser, rpcpassword and server in coiledcoin.conf, run the Coiledcoin client, and when starting p2pool add "--merged-url http://127.0.0.1:8367/ --merged-userpass user:password" to the end of the p2pool command line. (Also, I'd recommend setting your RPC password to something stronger than "password" for security reasons!) Again, do not pooled mine on Coiledcoin with p2pool - it should stop you but payouts would be unspendable.

Edit: Apparently I'm not as 1337 as I thought; forgot to change the premine back from the rather smaller 50 CLC.

Something interesting happened in #mtgox last night. A user got their account locked down and MagicalTux said that the reason for it was that the coins could be traced back to a theft a long time ago. He unlocked the account in question, but it means that the widely-held assumption that Bitcoins are fungible - that it doesn't matter which you get paid with - isn't true and hasn't been for some time. Some Bitcoins are tainted and will cause you problems when you try to exchange them while others aren't, and there's no easy way to tell which is which just by looking at them. (Wonder if there's a way to require payment with recently-mined bitcoins...)

I have no idea whether or how this will affect Bitcoin though.

If any of you have ever wondered what the inside of your YubiKey looks like, Travis Goodspeed recently published tear-down photos and a die photo of the actual microcontroller it's based on. Probably not the most high-security device in the world, but I guess at least they're reasonably tamper-evident.

(Travis Goodspeed was also the other person involved in the Len "rabbi" Sassama tribute that was embedded in the block chain a while ago. He's apparently very neighbourly.)

A SolidCoin pool, squidnet, was reporting some truely bizarre problems a couple of days ago in which they were losing masses of money - their blocks appeared to be accepted, got into the blockchain and showed up on the block explorer but for some reason the payouts never showed up in their wallet. I don't remember hearing anything about what happened next or what the problem was, though. It was just bizarre and made no sense. Anyone know or can guess the answer?

16:29 <+TimothyA> RealSolid: in what scenario would we be sending more coins than we actually receive??
16:29 <+TimothyA> we're operating at a daily loss for some reason all of a sudden :|
16:30 < Bitcoinfornewegg> people withdrawing
16:30 <+TimothyA> Bitcoinfornewegg: no, this is before withdrawing
16:30 <+TimothyA> for some reason we're paying out too much
16:30 < Bitcoinfornewegg> thats indeed odd
16:30 < Bitcoinfornewegg> please dont fix it ok
16:30 <+TimothyA> -_-
16:30 <+TimothyA> if we don't fix it, pool = gone
...

16:31 < Bitcoinfornewegg> fees for tx?
16:31 <+TimothyA> Bitcoin: that wouldn't be a 50 SLC loss per hour
16:32 < brukmann> TimothyA: well, didn't one of the newer betas start marking more shares valid?
16:32 <+TimothyA> brukmann: that has nothing to do with this :|
...
16:42 <@RealSolid> TimothyA: are you recording block values correctly
16:42 <@mtrlt> mm thought squidnet uses pplns?
16:43 <+TimothyA> RealSolid: yes
16:43 <@RealSolid> TimothyA: ie youre not saying you won blocks you didnt
16:43 <@RealSolid> also
16:43 <+TimothyA> not as far as I know
16:43 < nickwright> guys what is teh issueh ??
16:43 <@RealSolid> firstly id go back over the last 100 blocks you won
16:44 <+TimothyA> I've upped the confirmations to 20
16:44 <@RealSolid> and make sure they are in the chain
16:44 <+TimothyA> they are
16:44 <@RealSolid> you checked the last 100?
16:44 <@mtrlt> could the payouts be done eligius-style? in the generation tx
16:44 <+TimothyA> sharky did
...
22:01 <+TimothyA> great, now I'm losing 50SLC every 10 minutes
22:01 <+TimothyA> fucking brilliant
22:01 <+TimothyA> for some reason I'm not getting actually paid for the blocks that made it into the chain
22:02 < mush> :S
22:02 <+TimothyA> ... and now suddendly 200SLC vanished
22:02 < forsetifox> Kill it.
22:04 <+TimothyA> ...and another 400SLC
22:05 <+TimothyA> I'm not running a goddamn faucet here
22:05 <@mtrlt> shut down everything
22:05 <+TimothyA> or do I have to put confirms on 1000 or something to get it to work reliably?
22:05 <@mtrlt> how many confirms do you use now?
22:05 <+TimothyA> mtrlt: 20
22:06 <@mtrlt> >_>
22:07 <@AhimothMobile> 20 should be plenty
22:07 <+TimothyA> AhimothMobile: then why is shit still vanishing?
...

22:10 <@mtrlt> TimothyA: are you using data from the blockexplorer to determine whether you got a block?
22:11 <+TimothyA> mtrlt: I shouldn't have to in the first place -_-
22:11 <@mtrlt> so yes
22:11 <+TimothyA> but that's the only place where I can get the goddamn blocknumber now
22:11 <+TimothyA> RELIABLY
22:11 <@mtrlt> AhimothMobile: have you fixed reorgs?
22:11 <@AhimothMobile> blockexplorer might have some bad data in it right now from the occasional re-orgs
22:12 < mush> TimothyA what are you having issues with, a website?
22:12 <+TimothyA> mush: squidnet
22:12 <@AhimothMobile> not yet... testing in dev
22:12 <+TimothyA> we're paying out more than what we're getting somehow
22:12 <+TimothyA> we're paying out more than what we're getting somehow
22:12 <@mtrlt> so that's the problem
22:12 < mush> Ah, you run it right?
22:12 <@mtrlt> problem identified but not solved.
22:12 <+TimothyA> and if it doesn't get fixed quick, we have to shut it down
...

22:22 <+TimothyA> here, wtf is this shit
22:22 <+TimothyA> there are blocks on the website that aren't even in the wallet
22:22 <@mtrlt> cuqa: make sure you're using 0.09
22:22 <+TimothyA> yet they show up on the blockexplorer
22:22 < cuqa> yea, im using 0.09
22:22 <+TimothyA> HOW THE FUCK DOES THAT SHIT WORK?!
22:23 <@mtrlt> TimothyA: does the BE show that squidnet found the blocks?
22:23 < cuqa> is there some dbug mode for reaper why shares are invalid or whatever
22:23 <+TimothyA> mtrlt: yes, but they aren't in the wallet
22:23 <+TimothyA> but yet they are on squidnet's block listy
22:24 <+TimothyA> http://blockexplorer.ahimoth.com/Home/BlockDetails?blockNum=49273 http://blockexplorer.ahimoth.com/Home/BlockDetails?blockNum=49271 http://blockexplorer.ahimoth.com/Home/BlockDetails?blockNum=49265
22:24 <+TimothyA> not in the wallets

Since it appears a lot of people here don't follow IRC, and I'm guessing many don't follow the SolidCoin forums either:

Sometime between block 45000 and 50000 (still to be decided) SolidCoin will be moving from a 32SC base coin value to 5SC .

The current inflation limiter decreased by 1 the base value every million blocks. So at block 1000000, base_value would be 31, and so on, until it reached a base_value of 4. The current code is below.

The new method will be exactly like below except for three changes, base_value will be 5, every million blocks it will drop by 0.1 , and the minimum value will be 1. So at block 1000000 it will be 4.9 for base_value.

The reason for this is because the current inflation is way too high for the amount of miners mining (somewhere between 1200 to 2000 people mining). At 5SC for the base each SolidCoin will cost somewhere between 10c to 30c to produce, thereby adding a "minimum" cost for each coin which is at a fairly nice base. Anyone selling below that price will be selling below cost and therefor running at a loss.

Another thing to remember is that with the difficulty modifier in place, it's not just "each block is worth 5SC" now. For each 100K of difficulty another 5SC is added. So at our current difficulty of 40000 an extra 40% of 5SC would be added, a block would be worth 7SC. With 5 blocks every 10 minutes, that means a total of 35SC would be generated in 10 minutes vs Bitcoins ideal of 50BTC. This is at current difficulty. As difficulty grows and we get more miners the amount of SolidCoins generated per hour will match that growth, whilst still maintaining a base cost of 10-30c of electricity to generate it.

The nice thing about SolidCoin is that in order to enforce a surprise change like this, he only has to get all the trusted nodes to upgrade and it then becomes impossible for anyone else to continue using the old rules.

[Edit:]

IIRC, one of the factors limiting pools has been how slow bitcoin is to answer getwork requests. It turns out that it's reasonably easy - with a few tweaks to the Bitcoin client - to move most of the work-generation out of bitcoind and into the pool server, with the pool server using one modified work item from Bitcoin to answer essentially as many getwork requests as it likes. So that's what I did:

https://github.com/makomk/bitcoin/tree/poolserv-work-gen https://github.com/makomk/pushpool/tree/local-work-gen

The changes are relatively straightforward: there's a new getworkex RPC call that provides a copy of the coinbase transaction and the merkle branch it's on, and when submitting solutions the pool server can send in a modified coinbase tx that's used instead of the original. pushpoold in turn now knows how to use getworkex, insert its own additional nonce into the coinbase, increment that nonce to generate work items,  and convert the submitted shares back into a form that bitcoind will accept. A very quick-and-dirty benchmark suggests it should be able to reach in the ballpark of around 3000 getworks/sec, which is much better than I was seeing before. (I'm planning to implement a way for bitcoin to push new work to the pool server at some point too.)

These changes are also incredibly experimental; I've basically only tested them with poclbm and cgminer on a testnet-in-a-box install so far. I hear that luke-jr has been working on something vaguely similar too, and shadders is developing another approach to poolserver work generation in PoolServerJ as well.

Edit: Exercise for the curious: the Bitcoin patch should in theory be enough to implement the parent blockchain side of merged mining, maybe even more effectively than the existing approach. You can use getworkex to add whatever you like to the coinbase transaction, and it gives you the merkle branch needed to submit the work to the auxiliary blockchains.

[Edit:]

Edit: Updated to create a new wallet.dat with the recovered keys.
Edit 2: New v0.2 release, new instructions. Note that this still can't recover encrypted wallets!
Edit 3: v0.3 release to support the compressed public keys created by recent Bitcoin versions. Still can't recover encrypted wallets.

For some reason, people keep reformatting their drive or deleting their wallet.dat without taking proper backups. As casascius helpfully points out - and this is something I'd already suspected - it may be possible to recover the crucial wallet.dat private keys and the bitcoins secured with them by scanning the disk for certain markers, so long as you're lucky and the data you need isn't too fragmented and hasn't already been overwritten.

To that end, I've written a little experimental utility that tries to search for and validate those keys. It's not even close to being able to recover all keys that are recoverable - though it should work in a decent proportion of cases - and importing those keys back into a new wallet is left as an exercise for the user to figure out for now, but it might be useful to some people.

Instructions:

• Stop using your computer until you've recovered your data, in case something overwrites it. Shut down the PC as soon as possible.
• Obtain a suitable 32-bit Linux LiveCD, like the System Rescue CD, and boot your computer from it. You'll need working internet access (or some other way to download http://makomk.com/~aidan/wallet-recover and transfer it over)
• Open a terminal.
• Run these commands to download the utility and unpack it (2MB download - it contains largish crypto and database libraries):

Code:

wget http://www.makomk.com/~aidan/wallet-recover-0.3-linux.tar.gz
tar xzf wallet-recover-0.3-linux.tar.gz

Run the program on your drive:

Code:

sudo ./wallet-recover-0.3-linux/bin/32/wallet-recover <insert device name here> recovered-wallet.dat

For 99% of users, this will be:

Code:

sudo ./wallet-recover-0.3-linux/bin/32/wallet-recover /dev/sda recovered-wallet.dat

Hopefully it should find and print out a bunch of public keys and corresponding private keys, at least 100 of them, together with a file recovered-wallet.dat. Copy the recovered-wallet.dat to a USB drive and load it up in the Bitcoin client as usual (not forgetting to start it with -rescan) - with a bit of luck you should have access to your money again. I suggest not doing anything with the computer you lost the bitcoins on until you're 100% sure the recovery was successful - load up recovered-wallet.data on a different PC if at all possible.

WARNING: The recovered wallet does not contain a pool of spare keys to send change to (the old ones should get recovered but aren't marked as such). It also doesn't include any names for addresses, so the address you can copy-and-paste in the client is a NEW address created when you first started bitcoin using your recovered wallet, and any change from transactions also goes to a NEW address - none of these addresses are in the original recovered wallet. After first running Bitcoin with the recovered wallet, you MUST exit it and take backup copies of the wallet.dat in your .bitcoin directory to several locations BEFORE making or receiving any transactions - then be sure to use this version and NOT THE ORIGINAL recovered-wallet.dat from this point on. If you're using bitcoind rather than the GUI, you must also call "bitcoind getnewaddress" before shutting down and copying the wallet.dat. Also, be extremely careful about backing up your wallet on a regular basis after using this tool - Bitcoin's handling of the keypool is quirky and this may trigger bugs in it. (Added 9th July, amended 19th Sept.)

Disclaimer: This code comes with no warranty, not even an implied warranty of fitness for its intended purpose. I don't guarantee that it won't make things worse, or that the recovered keys are correct, and obviously I can't guarantee that it'll manage to recover the keys you need. Oh, and it may not be able to recover older wallets at all.