I have no clue what is wrong with the biddingpond folks, but I have been bugging them for a simple, working payment method for well over six months...

MyBitcoin people usually respond to my support emails within 2-3 days.

I'm not so sure.

The consensus on IRC was that pool performance is measured by submitted solutions, and I've never seen slush contradict this.

Do you have some evidence / numbers / URLs?

Well, there is CoinPal: Buy bitcoins with Paypal.

For a more complete list of currency exchanges see https://en.bitcoin.it/wiki/Trade#Currency_exchange

Version 0.7.2 is released.  Changes:

- Add port of ufasoft's sse2 assembly implementation (Linux only)
  This is a substantial speed improvement on Intel CPUs.

  Big thanks to mmarker/chromicant for this work.

- Move all JSON-RPC I/O to separate thread.  This reduces the
  number of HTTP connections from one-per-thread to one, reducing resource
  usage on upstream bitcoind / pool server.

  This is prepartion for adding long-polling support.

See top of thread for URLs and info.

SHA1: 2673c5f5c2cd85acc332a9c8a1f48415b8dd0fc9  cpuminer-installer-0.7.2.zip
MD5: 24211f26b1d6b0c68fe696662b3082e7  cpuminer-installer-0.7.2.zip

Yes.  It will permit miners (CPU miners, in particular) to get cut their number of HTTP connections and ask rate quite dramatically.

Very nice.  If you have this JSON, you shouldn't need anything else IMO.



According to my research, the sad fact is comments are outside JSON scope  You may add faux-entries like


Ugly hack, I know.

Seems like it would be better for the entire community, if you simply worked with other pool servers to accomplish the same goal.

If you support long polling, then the default upstream poclbm (m0mchil's) -- and soon, every other miner -- will only ask for work once every ~60 seconds.

Community standards like this benefit everyone.

Also, I would rather like to see a feature that permits bitcoin to sign and verify simple messages.  That verifies you control a private key, without needing to send any in-band data.

I think providing the first [working, sustainable] decentralized digital currency is enough.

And what that means is, people should remember that supporting currencies have multiple layers.  The US dollar itself does not provide any hooks for payment APIs, nor chargebacks, nor fraud protection.  These are all layers on top of the currency itself, and occur out-of-band with respect to information transiting with the currency itself.

If we keep the base currency simple, and not used for other exotic goals such as distributed data publishing, that makes it most likely that bitcoin-the-currency will succeed.

So, adding a 512-byte opaque data area to each TX, for this merchant, seems excessive because

1) It could be done elsewhere.  Merchants are best served by a merchant friendly solution that provides gadgetry like order id's.  Bitcoin is a money transfer network, and traditionally merchants do not hook directly into a money transfer network.  They connect to a provider (FirstACH, PayPal, ...) who then connects them to the transfer network.  The great freedom that bitcoin provides is universal public access to the money transfer network -- but that comes with a high maintenance cost of living directly on a beta-quality P2P network.  Your small business coffee shop or flower shop should not be encouraged to connect directly to the bitcoin P2P network unless their staff has the time and skill to understand and handle P2P security issues.

2) Privacy-eroding poor programming practices become easier, such as storing unencoded order data in that area.  Programmers should never store anything except cryptographic hashes or encrypted data in such a data area, but they will be tempted to do otherwise because it's easy.

3) It would seem to open the door to other data storage applications.  Is data storage possible now?  Yes.  But that doesn't mean we should encourage non-currency uses.

That said, as a programmer I certainly recognize the value of being able to attach a piece of my data to a transaction whose contents is entirely outside the control of the creator, save for $BitcoinAddress and $Amount.  Thus, my fallback position on this issue has always been, if overruled by the community, argue for no more than a 32-byte data area.  Enough to store a cryptographic hash of your own, but small enough still to (hopefully) discourage people from storing Lady Gaga music in the block chain.

Also, I think it is a bad idea for most merchants to run a local bitcoind node.  That implies they will need to know a good deal about P2P networking, in order to defend their installation against attacks.  You have to track bitcoin software closely for security updates, that sort of thing.

That's just not realistic for most merchants, IMO.

We should be directing most merchants to APIs such as mybitcoin.com's SCI or mtgox.com's merchant API.

And they can provide an order id (I think MBC does already?) through those Web APIs.

Latest gnutella release adds support for UPNP and NAT-PMP... 

If this data is stored in the block chain, it reawakens the entire BitDNS/BitX debate.

512 bytes of blank data space in the chain just makes it trivial for non-currency users to use bitcoin for its generic data broadcasting services...

Keys have a standard PEM format...

I strongly recommend a merchant solution such as mybitcoin.com's SCI or mtgox.com's merchant API.  Running a bitcoin node yourself is maintenance intensive, and requires additional knowledge on the part of the site owner.

The pool test has been closed for a few weeks.  I'll update the top post.

Yep.  I was on proper.com (and that site) from inception until they banned lending North Carolina due to regulatory issues.

Very educational.

There is IMO absolutely nothing wrong with lending bitcoins.  I think any healthy economy must involve lending -- which is essentially human beings investing in other human beings, moving progress and civilization forward.

When used wisely, debt may better direct capital to useful enterprises (== entrepreneur borrowing to invest in new business you would have never thought of, or have time to run).  The lender understands there is a risk that money may simply never be recovered, in certain cases (bankruptcy or theft).

Well done.

In particular, kudos for working on a license.  This is the best way to legitimize bitcoin, and take it mainstream.

See the history of Prosper.com for peer-to-peer lending...

Unfortunately, you are duplicated work.  This CPU miner supports VIA padlock: https://github.com/jgarzik/cpuminer

The main client does not need any CPU mining tweaks.  In fact, we discuss from time-to-time how to hide / disable / remove CPU mining from the main bitcoin client.