I just thought of a neat solution to block withholding attacks. It does require a hard fork to add support because there's a small tweak to legal coinbase transactions and to how block hashes are checked against the target. The basic mechanism involves a hash blinding factor that is included in the coinbase transaction and must be XORed with the block hash before it is tested against the difficulty target.

The scheme works as follows:

1) When the pool creates work for a miner, it generates a random hash blinding factor. It then masks off all the bits in the blinding factor that contribute to whether the miner has found a share or not. The masked blinding factor is included in the coinbase transaction. With difficulty 1 shares, the blinding factor might be 00000000987E872A234...

2) The pool gives the work to the miner.

3) The miner finds a share normally, and the pool gives the miner credit.

4) The pool, knowing the hash blinding factor (because, of course, it must have saved the coinbase transaction because it needs it to submit the block) checks if the miner found a block. If so, it submits it to the network.

5) The miner does not know the blinding factor and so has no idea whether he found a share or a block. So he can't withhold blocks without withholding shares.

[CAUTION:]

I have a KNCMiner Titan scrypt miner. It's supposed to get 300MH/s, but I've only gotten about 275MH/s. I'm kind of annoyed at it, so I'd like to sell it. I don't have the original packaging, but I'll pack it safely for shipment. It's an early Titan, ordered March 19, shipped September 24.

Is anyone interested?

CAUTION: Someone seems to be impersonating me and possibly trying to get someone to pay them for this miner.

[Update]

I ordered an SP30 as part of a group buy before moving. My old house had plenty of power; my new house, not so much. The order was placed April 30, 2014. With the various discounts I was able to get, I paid $4,495.50 for the miner. Here's a product link:

http://www.spondoolies-tech.com/products/sp30-yukon-second-batch

And here's a picture of the order status:



I'm willing to be flexible on both the price and the terms. I'm happy to accept payment in Bitcoins and happy to accept some percentage now and the balance as soon as the SP30 ships to me. I'm also willing to discuss escrow.

Update: Best offer so far is $4,000, half now, half when the SP30 is in transit to me. I will almost definitely accept the best offer I get.

I've been working on putting together a set of tools to securely generate and access crypto-currencies placed in cold storage. I've found almost all of the pieces I need except one. Something to allow people to store things like accounts and passwords for exchanges, private keys for crypto-currency accounts, and the like. Ideally, with a way for them to maintain them and permit another person to have access to them in the event of emergency or disaster.

I'll describe the ideal tool:

1) It would provide a secure editor that allows lists of private keys and/or passwords to be edited.

2) Encrypted data could be stored locally. Preferably automatically keeping past versions.

3) Unencrypted data would never be stored anywhere except in RAM while the program is running.

4) It would integrate with Dropbox, Google Drive, or something similar to permit synchronization of files.

5) The tool would be able to run on a PC as an application to access the local copy and not require Internet access. (Though, of course, it couldn't synch changes without Internet access.)

Ideally, a single easy-to-use tool would be best. This is intended to be easy to set up and use securely by non-technical people.

Any ideas?

There's a new US Trademark application for "BITCOIN WALLET" based on use starting last month. The term "Bitcoin wallet" has been used generically to describe wallet programs designed to hold and transfer Bitcoins.

Word Mark:  BITCOIN WALLET

Serial Number: 86185037

Filing Date: February 5, 2014

Goods and Services: IC 036. US 100 101 102. G & S: Cash management namely facilitating and tracking transfers of electronic cash equivalents; virtual currency exchange transaction services for transferable electronic cash equivalent units having specified cash value.

FIRST USE: 20140205.

FIRST USE IN COMMERCE: 20140205

APPLICANT: Bitcoin Wallet, LLC LIMITED LIABILITY COMPANY KENTUCKY P.O. Box 176247 Fort Mitchell KENTUCKY 41017

I am selling my ASICMiner block erupter blade on BitMit. This post is locked and mainly exists to confirm that the BitMit auction was actually made by me.

Original listing:
https://www.bitmit.net/en/item/68254-asicminer-block-erupter-blade-12gh-s-bitcoin-miner

Relisted because the buyer didn't make payment as agreed:
https://www.bitmit.net/en/item/81192-asicminer-block-erupter-blade-13gh-s-bitcoin-miner-bonuses

[k]

It looks like we have another scam site pretending to be Mt Gox. This one is even purchasing ads on Google. The site is MtGok.net. I'll file a complaint with Google shortly.

The btctock.com website offers unusually low prices for Bitcoin mining hardware. The same person has traded on BitMit as 'btctock' and possibly trades elsewhere as well.

On at least two BitMit auctions, the seller attempted to convince buyers to cancel escrow and deliver the Bitcoins directly. Because the website promises low prices, claims immediate availability, only takes payment by Bitcoins, spells its own name wrong in its site graphics, and its owner has no real identity that I could find, I strongly suspect that it's an outright fraud.

Mostly for fun, I put together a 13 GH/s mining setup two weeks ago.

I started mining with Ozcoin and mined block 242128. Sadly, being in a pool, I just got a normal share.
https://ozcoin.net/content/block-history-bitcoin

Then I switched to Eclipse and a few hours ago, I mined block 243360. Again, being in a pool, I just got a normal share.
https://eclipsemc.com/block_stats.php

Now, I have some philosophical questions: If I had been solo mining, would I have still mined these two blocks? Did choosing to mine in a pool cost me $5K? Am I clearly a lucky miner and should begin solo mining immediately? Should I buy a lottery ticket? Or did I use up my luck and need to stay in pools forever? Should I look both ways twice before crossing streets?

Could someone who understands the nature of luck please help me with these confounding questions?

https://www.youtube.com/watch?v=fjYrursFkJQ

This video was made by the IRS, starring IRS employees, using $60,000 of taxpayer money. I was able to get through about 1 minute of it before I just had to turn it off. It is just awful on so many levels.

Please take this caution seriously. I don't know for a fact that this is happening, but there's a very serious risk associated with buying Pirate debt that is not obvious. The debt you are buying may not actually exist even if you confirmed it.

1) John Smith comes to you and says, "Pirate owes me 10,000 BTC. Would you like to buy this obligation for 5,400 BTC?"

2) You confirm that this obligation exists with Pirate.

3) You think Pirate might pay back, and it seems like a reasonably good risk, so you buy it.

4) But John Smith may actually *be* Pirate and the 10,000 BTC may never have been deposited at all.

5) Pirate just got 5,400 BTC for an obligation that never actually existed and that he never intends to pay back.

I would strongly urge people *not* to buy any Pirate obligations. It's not just that Pirate might default, it's that selling the obligations may be an engineered part of a default. As I've argued elsewhere, this is one of the best explanations for why Pirate would have bought himself a week or so to make payouts. This is all time he can sell non-existing obligations for real money.

I know a lot of people have informally offered bounties to get various things bitcoin-related done. What I'd like to do is start a project
specifically to organize bounties. The primary aim would be to make badly needed usability improvements and fix bugs in the bitcoin client.  

I can commit at least some of my time and will put my reputation behind the project. I can provide hosting for the project web pages.

What I'm asking for at this time is primarily a response on whether people are interested, whether my basic plan makes sense, and whether there are any other people who are willing to take on larger roles in the project. Also, if this is duplicative of other efforts, I'd prefer to combine forces than have two projects.

Here's the basic idea:

1) All project records would be completely open. All project funds would be held in accounts with well-known bitcoin addresses. All payouts would be documented: amount, recipient (possibly by psuedonym), and reason.

2) The project would take suggestions for most wanted bounties. The primary goal would be improving the bitcoin client to make the client more useful for ordinary people, especially those unfamiliar with bitcoin internals. But improvements to other bitcoin-related open source projects would be acceptable too. Bounties could be awarded in stages: First to offer patch, first to submit pull request, changes accepted into mainstream client, and so on.)

3) Donations would be primarily through a small number of fixed addresses and separated by purpose for project transparency. Plans for project
termination would be pre-arranged (perhaps donation of funds to a charity chosen from a list, perhaps refunds where possible). Each address would have a focus, for example one address just for client usability bounties, one just for client bugfixes, and so on, so donors could focus their donations on their areas of interest. (Probably no more than 5, for sanity reasons.)

The project would be strictly limited to improving bitcoin-related open source projects with an initial primary focus on improving the usability and
security of the bitcoin client and a secondary focus on other improvements (such as bugfixes) to the bitcoin client.

Hopefully, I could transfer most of the day-to-day control and decision making power over the project to a group of voting members. Sadly, I would have to make myself ineligible for claiming bounties.

The biggest issue for me is the security of holding other people's money. If anyone knows a better way than transferring coins to offline encrypted
wallets with emergency key backups printed on hidden sheets of paper, I'd love to hear it. Perhaps I can find three trusted people and give them each 2/3 of the key as an emergency backup in case I get hit by a bus.

There are two things TradeHill doesn't do that I would really appreciate. I'm curious if other people would appreciate these features as well and also if there's some unusual reason they're not easy to do.

1) Orders to sell bitcoins I don't yet hold or buy bitcoins with funds I don't yet have:

Say I want to sell all my bitcoins if the exchange rate hits $13. But I also have a lot of triggered buy orders. So I don't know how many bitcoins I'll have. Right now, I can't place a sell order for more bitcoins than I currently hold. I'd like to be able to place a sell or buy order with an "up to" amount, and it will buy or sell as much as possible up to that amount. This way, if bitcoins are at $10, I can place a buy order at $9.50 and a buy order at $9 and a sell order at $13 to sell any bitcoins I might buy if those buy orders trigger and the price comes back to $10.

Similarly, say bitcoins are currently trading at $10 and I currently hold no bitcoins. I might want to place a buy order at $9 and a sell order at $9.50 to sell any bitcoins I might buy should the price drop to $9 and come back to $9.50.

In reverse, this means I can place sell orders as the market rises and use those funds to fund a buy order that I place now. If the buy order triggers, it will buy with funds I have now plus funds acquired after the order was placed should any sell orders trigger. This would also mean I could place an order to sell bitcoins before I transfer them into my account or buy bitcoins before I transfer dollars into my account and the order would fill as it was funded.

2) Stop loss / take profit orders:

Say I hold 50 bitcoins and bitcoins are currently trading at $7. I can certainly sell them now for $6-$7, but I don't want to sell them. But I don't want to keep holding them to $5. What I'd like to be able to do is place a stop loss / take profit order that will sell my bitcoins if they start trading below $6.

In reverse, if I have $100 and bitcoins are trading at $10, I can certainly buy them for $10-$12 now. But suppose I'd prefer to wait for the market to drop, but if it goes above $12, then I want to buy before it gets too much higher. I'd like to place a triggered order to buy at market rate before the market gets much above $12.

So, are these features doable? Am I the only one that would use them?

Granted, bitcoin does provide more anonymity and privacy than other payment method known. However, a lot of identity information can be scraped by forensic analysis of the hash chain. If anyone ever asks for donations in public, whether in a forum, a web page, a flyer, or whatever, anyone can tell exactly how many donations they got and the timing and amount of each one.

By scraping the Internet, an interested organization could map thousands of bitcoin addresses to identities. By mapping the hash chain intelligently, they could obtain a lot of information about cash flows. You can create new address for each payment, but this doesn't work for cases where an address has to be persistent such as in print media, press releases, source code, and so on.

Also, bitcoin provides no way to confirm receipt. If you see my donation address and want to send me 10 bitcoins, you have to assume that I am actually still monitoring that address and haven't lost the key. For months, years, or more the transaction can sit in limbo with you having no idea whether I got the coins or not.

In addition, bitcoin requires you to either compromise some anonymity or create a new address for each transaction's change. This makes it more difficult to keep your addresses safe. You are constantly creating addresses with non-zero balances and you can't really control it.

Well, I have a solution to all of these problems. It works like this:

1) Instead of using a hash as a bitcoin address, you use the public key itself. You create one address for each public identity. (For example, if you want to receive money anonymously, you can't tell others the same address you post in your forum signature. And you may want separate addresses to know why you got money. But otherwise, one address does it. New addresses are only needed when the user needs one.)

2) To send money, you generate a public/private key pair. You then encrypt this new private key with the recipient's public key (this is the primary key) and with your own public key (this is the secondary key). To perform the transaction, the output includes the public key, the primary key, and the secondary key.

3) The client checks every transaction's unclaimed outputs to see if any of its keys decrypt the primary key or the secondary key to a private key whose corresponding public key is the one in the output. If the client can decrypt the primary key, it marks the transaction as unclaimed incoming funds. If the client can decrypt the secondary key, it marks the transaction as unclaimed outgoing funds.

4) For the recipient to claim the funds, he simply transfers them to himself, following the method in step 2, except the secondary key is the encrypted transaction ID. The recipient will know these transactions are to himself because the secondary key will decrypt to the transaction ID. But otherwise, these 'claims' will look just like all other transactions.

5) If the recipient has not claimed the funds, the sender can reclaim them using the secondary key. Again, these claims will look like all other transactions. Nobody else will be able to tell how the person claiming the transaction got the private key needed to sign a transaction claiming it.

One downside to this is that some people may prefer irrevocable transactions. One way to solve this is to overload the public key a bit. The last four bits can indicate the transaction preference. For example, '00' can mean the recipient has no preference. '11' can indicate the recipient only wants transactions they do not have to claim. There is no requirement a secondary key be included. You can zero it to make it public that this is irrevocable. You can make it random to secretly make it irrevocable.

The beauty of this is that an organization can include a donation address in their contact information and it is not possible to tell how much money was donated to them. You can still give them a donation and find out when they claimed it but not where it went, since the recipient of the very first transaction is opaque to you (you can't even compare it to other transactions where they are the sender or recipient!) this doesn't get you much.

This can easily be added to bitcoin without disruption, though it cannot be done quickly. It will have to be done in stages adding support for introduced transactions first, then waiting for the vast majority of miners to support the new code before adding the ability to introduce transactions. Then miners who don't support the new code won't get their blocks in the public chain (or alternatively, will just reject transactions of the new type).

So, what do you think?

I have an idea for a feature that could easily be added to the client. It would provide a simple way to backup private keys to paper. The basic idea is to add two RPC commands to the client -- an export command, and an import command. They would work as follows:

The 'export' command would take a BitCoin address whose private key was known to the client and export it in RFC1751 form. This includes a checksum, is case-insensitive, and is very easy for a human being to write down or read out loud. It will typically look like this:
BOGY CURE TIDE HIS DUNK GOOD FEUD GIBE FOUL FROM JOE NEST ADA SMUG FLAT MAKE MALI FAKE WINO ARK LAIN WERE TAN OVA

The 'import' command would take a private key in RFC1751 form and import it into the wallet, returning the BitCoin address and balance as well.

In the non-GUI case, you could use the existing 'listreceivedbyaddress' command to get keys to export. In the GUI case, we could include a way to get the exported keys for all addresses with non-zero balances in a form that could easily be printed. And, of course, a command to enter in a key and add it to the wallet.

This way, people can write their BitCoin private keys on a piece of paper (or print it), lock it in vault, or whatever. The idea is not to serve as a normal wallet backup for an active account. The idea is to serve as a long-term backup for balances that people do not expect to be using for an extended period of time. The biggest argument against it that I see is that it's too much effort for too narrow a use case.