I find it is inexplicable and inconvenient to an extreme that the client running testnet accepts mainnet addresses. Could we please fix this. It is just a one line fix.

in base58.h: change line:
     return (nVersion <= ADDRESSVERSION);
to:
     return (nVersion == ADDRESSVERSION);

I don't see any practical reason for it to be the way it is. It is only an historical accident that it was named a version byte. It is not a version byte and has never been a version byte. If some day we do need/want to use it as a version byte we will need to rewrite the code in question anyway as I see it.

Meanwhile it is used as a net id byte for addresses and I think it is a mistake to use addresses from another net and the net id byte can be used to detect when you are trying to use an address with the wrong net and prevent your mistake.

Thank you.

Diki was having trouble figuring out what target hex string to use to set up a giving difficulty for shares on his pool so I wrote this little difficulty calculator for him:


  bitcoin difficulty calculator

  accepts floating poind difficulty or
  hexadecimal target in either the long 256 bit form or
  the short compressed nBits form and

  displays the result in all three formats


 download portable C source and linux executable from :

  http://www3.telus.net/millerlf/diffcalc.tgz

have fun

Attached file is a diff -c patch for the loss of accuracy in the difficulty calculation. For instance any nBits compressed value from 0x1a44b800 thru 0x1a44b9ff will show as difficulty 244139.4816. This patch will more accurately convert the nBits compressed values to the double difficulty.

This will display any of the recent difficulty levels slightly differently though. Early difficulties and testnet difficulties are not large enough to trigger this bug.

None of the actual targets or compressed targets are changed, only the conversion to the floating point difficulty is changed and afaik it is only ever displayed, never converted back so the patch does not effect the target calculations, binary files, databases nor the binary protocol. only programs which use the floating point displayed value of the difficulty might be effected. (pools? I don't think so, but they may need a heads up about the change)

Code:

*** bitcoin-0.3.21/src/rpc.cpp  2011-04-20 16:08:01.000000000 -0600
--- bitcoin-0.3.21-test/src/rpc.cpp     2011-05-25 18:20:48.000000000 -0600
***************
*** 199,208 ****
      // minimum difficulty = 1.0.
      if (pindexBest == NULL)
          return 1.0;
!     int nShift = 256 - 32 - 31; // to fit in a uint
!     double dMinimum = (CBigNum().SetCompact(bnProofOfWorkLimit.GetCompact()) >> nShift).getuint();
!     double dCurrently = (CBigNum().SetCompact(pindexBest->nBits) >> nShift).getuint();
!     return dMinimum / dCurrently;
  }
 
  Value getdifficulty(const Array& params, bool fHelp)
--- 199,220 ----
      // minimum difficulty = 1.0.
      if (pindexBest == NULL)
          return 1.0;
!     int shift = (pindexBest->nBits >> 24) & 0xff;
!     double diff =
!         (double)0x0000ffff / (double)(pindexBest->nBits & 0x00ffffff);
!
!     if (shift < 29)
!         while (shift < 29) {
!           diff *= 256.0;
!           shift++;
!         }
!     else
!         while (shift > 29) {
!           diff /= 256.0;
!           shift--;
!         }
!
!     return diff;
  }
 
  Value getdifficulty(const Array& params, bool fHelp)

I just made this today as an exercise. It is primarily a single bash script with a few small C utilities. It is primarily intended as a reference implementation to teach how getwork mining is done. It can do 50 hash/sec/core!

check it out at:

http://www3.telus.net/millerlf/bashhashminer.tar.gz

Have fun.

In block #72785 with timestamp 2010-08-07 04:53:03:
If the block genenerated 50 BTC is transaction #0 of block #72785 then transaction #3 is kinda odd. It takes an input of 5.00 BTC and splits it to two outputs of value 1.8585 BTC and 3.1415 BTC. I think it is the only transaction that is not an even number of bitcents. There is no fee associated.

Is there any serious consequences to this transaction?

Was it necessary to use a customized client to produce this transaction?

So far as I can figure it is harmless but I thought I might bring it up here anyway.

seems a block at height 74638 has expoited a bug in the net. It uses an integer overflow to make a negative total transaction. The two transaction outputs are:

 out Value:92233720368.54(7ffffffffff85ee0) out Value:92233720368.54(7ff
ffffffff85ee0)

We need a fix asap

Edit:
(satoshi)
0.3.10 patch download links here:
http://bitcointalk.org/index.php?topic=827.0

The VIA C7 is a little x86 type CPU sorta intended to compete with the Intel Nano I think except it has some special builtin crypto features including SHA256 instructions.

So I hacked up Satoshi's code and got it to do the mining using the buil;tin instructions. It went from 293 Khash/s to 1590 Khash/s.

This on a motherboard with the cpu included costing $65 (you can prolly find it for less too). It should be real good on power consumption too.

I was starting to wonder when my systems seemed to quit generating coins if there was something going on. They went from about 1 block / day to none in a week.

ArtForz in irc suggested I run a test isolated net with two nodes only connected to each other with empty wallet dir. I took a couple of quad core systems and set them up. they have produced no blocks in about 90 minutes now while hashing at a combined rate of over 8000 khash/sec. Is this evidence of a problem yet or is it more bad luck?

The systems are Linux 64 bit one Intel quad q6600 and one AMD quad phenom II 940.

I cant figure out how to send a transaction to an ip address from bitcoind command line interface. Has the function been implemented yet? (linux 64 if it matters)

I have seen some speculation about scalability and denial of service by spam transactions in the IRC channel so I thought it would be a good idea to try a test.

I set up a stupid little bitcoind script on a couple of my linux machines to send 1000 tiny transaction to a third machine as quickly as they would run.

I asked on IRC for any obvious reasons why I shouldn't do it and got one supporting response thinking it was a good idea to try and one reserved response saying I should ask here first. I brashly decided to go ahead with it.

The scripts just printed a countdown of the number of remaining steps in the loop and the output of the bitcoind sendtoaddress command, normally just "sent".

They both started out quickly till there was something like 600 transactions submitted then both senders started to slow down perceptibly. One was quite a bit faster than the other, 3 or 4 times faster, due I think to a faster CPU. I thought at first it was the clients throtteling me to save the net from overload or something but that was just speculation. We later figured maybe it was the databases getting a bit slow on my old disks.

Then one of my machines suddenly seemed to speed up. But it wasn't really. It was an error, the bitcoind daemon had died. A little bit of investigation found the .bitcoin drive was full so you can't fault the program for giving up there! grin

The other machine was grinding pretty slow by then down to maybe 5 sec per transaction or so just judging by eye. It eventually finished after about 50 minutes. no errors at all.

The machine that crashed after I gave it some more disk space started right back up and showed it had only sent 424 transactions so there is an initial benchmark then - 1424 transactions in 50 minutes. It should be easy to get more.

I think the main thing slowing them down was the .bitcoin/database directory. They seemed to get a lot of data written to them some 184MB on the one that ran outa disk space and 1341 MB on the one that did the full 1000 transactions.

It seems another test with more people more distributed around the net might be in order to try to shake down any potential problems.

The net seemed to shrug it off as if nothing special happened anyway so that is a positive result. The clients mostly did just what they were told and expected except for a possible performance problem with the database.

Thats all I can think of for now.