Hi m0mchil, firstly thank you for your work. Is there any way to include getwork patch into official client? I’m using bitcoin on old centos server and compiling is pain here! A revised version of getwork is now in the official client, but the miners need to be updated a […]
Read moreMonth: November 2010
Re: New getwork
Quote from: jgarzik on November 24, 2010, 04:47:42 I suspect something weird going on with ByteReverse (or lack thereof). It’s quite unclear whether or not ‘data’ and ‘nonce’ must be byte-reversed, and in what way. getwork does the byte-reversing. midstate, data and hash1 are already big-endian, and you pass data […]
Read moreRe: New getwork
I understand the use case for external miners, but I rather like the all-in-one approach. Will I still be able to compile in my own mining code? I really enjoyed the revamped interface you introduced some time ago, and would very much like to keep on using it. It’s not […]
Read moreNew getwork
I uploaded a redesign of m0mchil’s getwork to SVN rev 189 (version 31601) m0mchil’s external bitcoin miner idea has solved a lot of problems. GPU programming is immature and hard to compile, and I didn’t want to add additional dependencies to the build. getwork allows these problems to be solved […]
Read moreRe: OpenCL miner for the masses
Quote from: m0mchil on November 20, 2010, 10:16:19 updated to SVN 186 Thanks m0mchil for keeping up on the updates! GPU miners, please upgrade as soon as possible to shut down the free transaction abuse! This version has the new priority-based limit on free transaction spam. Quote from: m0mchil on […]
Read moreRe: Transaction / spam flood attack currently under way
Quote from: creighto on November 19, 2010, 20:29:12 Perhaps in addition to the age priority rule recently implimented, there should be a minimum age rule without a transaction fee. Said another way, perhaps a generation rule that says that a free transaction must be 3 blocks deep before it can […]
Read moreRe: Need OP_BLOCKNUMBER to allow “time” limited transactions
At the moment, if you make a payment to someone but they’ve wiped their wallet then the coins are irretrievably lost. Similarly, if the network is flooded with 0.01 fee transactions and you make an urgent payment but forget to include a higher fee then you can’t reissue that payment […]
Read moreRe: Some testing that I did on the testnetwork, my findings.
Quote from: ByteCoin on November 13, 2010, 23:55:11 Of course, if the network is not being flooded and you’re not overly concerned about the current transaction getting held up then it’s probably worth preferring to use your 0 conf transactions so that you can “save” the higher priority coins for […]
Read moreVersion 0.3.15
Version 0.3.15 is now available. Changes: – paytxfee switch is now per KB, so it adds the correct fee for large transactions – sending avoids using coins with less than 6 confirmations if it can – BitcoinMiner processes transactions in priority order based on age of dependencies – make sure […]
Read moreRe: Some testing that I did on the testnetwork, my findings.
Spent transactions can be forgotten (though they currently aren’t). That would prevent your sending coins back and forth from having a big impact on block size. The transaction inclusion issue is fixed by increasing fees and making non-generators aware of the current blocksize. The fees after 250KB should increase faster. […]
Read more