|
I'm definitely open to new ideas like this.
bitcoin really needs a transaction processor that works to detect double-spends, sampling all over the network.
|
|
|
|
|
Note that "bitcoins sent" includes change transactions. I would love to exclude those, but there is no feasible way to do so.
|
|
|
|
Because if you must communicate between your PC and your FPGA, this might slow it down quite a lot.
As long as the FPGA performs millions of hashes for each "call" (host sents work to FPGA), host<->FPGA communication cost is small. |
|
|
|
New version 0.3 released (see top post for URLs). Changes: - Add crypto++ 32bit assembly implementation
- show version upon 'minerd --help'
- work around gcc 4.5.x bug that killed 4way performance
SHA1: e748faf3272a766f6de3e99ad1b6e434a0f3d023 cpuminer-installer-0.3.zip MD5: c1fc335c2548afa726ac49871ff73d08 cpuminer-installer-0.3.zip |
|
|
|
And it has always been true that the more CPU power you have, the more BTC you will receive.
You say that as if everyone's CPU power is pre-ordained. No, I say that as if nothing. It is a simple functional statement of fact. It is a basic assumption of the bitcoin system. If you contribute more CPU power, you are highly likely to receive greater rewards. That is the way bitcoin is supposed to work. That is the incentive for mining (and for scaling up your mining operation). |
|
|
|
My issues with BitCoin come from the unfairness of money creation, which is essentially a technocratic central bank issuing currency. If you have enough CPU-power and energy, you can originate most significant amount of new BTC into the market.
Technocratic central bank issuing currency? WTF? acrylicist is being hyperbolic, but he's right. bitcoin is a software-fiat currency, where the "central bank" is a collective agreement on software rules. USD is a human-fiat currency, with a traditional central bank. And it has always been true that the more CPU power you have, the more BTC you will receive. |
|
|
|
Out of curiosity, is Satoshi even Japanese? Or is it just a pseudonym? His english is absolutely perfect, so I'm leaning towards the latter.
I know plenty of Japanese, Chinese and Koreans who are able to write proper and colloquial English. Particularly in the dev community, where English is often the de facto language of programmers for a variety of historical reasons. Let's not make biased assumptions here. |
|
|
|
|
This patch is officially considered deprecated, as of mainline SVN r204.
|
|
|
|
What I like about slush's approach is that it works with unmodified CPU/GPU miners. It seems reasonable that we could work on a patch for mainline bitcoin that supports pooled remote mining. AFAICS, the modifications required of mainline bitcoin would be - add user database, and support multiple RPC user/password combinations
- create a variable fPoolTarget, specifying a reduced hash target for miners in the pool
- create a variable bool fMinerPool, indicating pooled miner mode
- in getwork RPC, reduce hash target value to fPoolTarget, if fMinerPool is true
- in getwork RPC, if CheckWork() succeeds, credit user for solved hash, if fMinerPool is true and hash found is >= fPoolTarget
Everything else can be implemented outside bitcoind, in a script. |
|
|
|
In many ways, I hope that another block chain or two are started at least to compare different ways to be using cryptocurrencies. If it is of any value at all, I'm sure that somebody will start to use it in exchanges. Trading between Bitcoins and other similar currencies ought to be simple and straight forward.
I expect several bitcoin clones to arise eventually. Both with the bitcoin codebase or with a totally new codebase and protocol. Proof-of-work timestamp server is now "out there" on the Internet. Derivatives are inevitable. And probably 98% of these clones will either fail, or be worth nothing, compared to mainline bitcoin chain. |
|
|
|
|
Updated first post with a release tarball for Linux/BSD, so that people don't have to bother with autotools and the git repo.
Recommend avoiding gcc 4.5.x at the moment.
|
|
|
|
Provide a front end to buy amazon mp3 music for bitcoins and you would have instant content.
I'd pledge a 1000 BTC bounty for that. Automated front-end (ie. no manual human purchases behind the scenes) that supports >50% of current Amazon mp3 content. |
|
|
|
Interesting. This seems to imply that mass hashing has never before been needed or else this would already be in production. Was the "hash over and over until you get below the target" idea really a new creation and not borrowed form somewhere?
Hashing mostly-the-same data twice, over and over again, is not remotely a common activity  |
|
|
|
when I run this I get a json_rpc_call failed, does anyone know why?
The miner is unable to connect to the URL you gave it, for some reason. Hi jgarzik, as I promised somewhere on this forum, I'm sending you my first reward from cooperative mining, because your code helped me a lot to understand, how mining works inside. So 38 BTC is yours, enjoy :-).
Thanks! |
|
|
|
I like DokuWiki. Just rename the "documentation" link on bitcoin.org to "wiki".
Or call the link "documentation wiki" to cover all bases. |
|
|
|
See http://yyz.us/bitcoin/patch.bitcoin-datanet-fork for an incomplete example fork. At a minimum you need - your own 4-byte message header (or "magic number"; ensures separation of network clients)
- your own genesis block
- your own default port numbers for RPC and P2P network interfaces
- your own IRC seeding method / channel
|
|
|
|
My guess is that SHA256 is so simple to implement in silicon that it's within the grasp of undergraduate-level engineers. It is orders of magnitude less complex than MPEG.
Well not "so simple" but basically correct. There's even a LGPL'd core you can download already: http://opencores.org/project,sha_coreSuch a chip would blow GPU's away on two fronts - one on the hash count, second on the cost, because all the wasted resources and engineering that normally goes into a supercomputer useful for solving really complex scientific problems (or a GPU to solve problems necessary for 3d graphic rendering) could be entirely skipped.
Up to a point, buying a bunch of mass-market GPU's with ALUs is quite comparable to the up-front costs of even a small run of ASICs. FPGAs won't get you nearly the speed needed to keep up with modern GPUs. |
|
|
|
|
Show Posts
