It appears that the problem with bigendian magic money is specific to the "mint" function. Minting one coin works OK, but minting more than one causes every coin after the first to be rejected by the client. Creating a coins.dat file with the -p function of the client works OK, even with more than one coin. Sending the output.asc to the server works OK too, as does handling the ascii file that comes back from the server. Only minting fails. Here are hex dumps of two coins.dat files. The first one is OK. It was created by "c -p" and has two coins. Key size is 512. 0000000 c0c4 f7c6 cbe5 af34 0893 a6dc ab39 4292 0000020 8200 1101 000d 01fd 1098 23f4 a67e 1f58 0000040 8fbe 3199 67cb dc70 6cd1 6921 df53 aa8a 0000060 8b5b 2a63 5e67 94da 9b18 7f03 ece9 34b2 0000100 0535 75f3 4e6a 3a45 b25e 565e 3fbb 14db 0000120 f3fb c6a7 6def cf77 c05a 9043 0ba7 e490 0000140 0ff5 fa15 83ae cbb3 1a00 1101 000d 01fe 0000160 2c61 ff65 299d 987f 4d88 0a3c 4b13 9f8f 0000200 612a dba6 ad6f 250d f665 ce0c 868f 3b62 0000220 5d1f 725f 449e 15bc da50 c270 5fba 2386 0000240 49ad 2c45 e26e b3af b94e deed b1e6 5f15 Here is a similar coins.dat file created by "s m" and also holding two coins of the same value (but different bit patterns, of course): 0000000 c086 9b22 8601 2974 3e71 d344 f7f1 ab13 0000020 6400 1101 000d 01fd 10ea 1ecb 711a 5114 0000040 5361 a558 9e67 a0ce 9eda 49af 58e1 9203 0000060 8f6b 9056 673c 88fb 79da 4a21 0e98 0e95 0000100 08a6 40f9 81f6 9e76 21e7 ea8d accf 0ef1 0000120 6e41 3657 aacf 34fb c0cc 8cc5 f400 0130 0000140 1400 0000 0000 0000 5900 1101 000d 01ff 0000160 5568 2e3d 9c7e ded9 6489 ba47 687e dc1a 0000200 f4e6 743e 2f12 f095 1363 7b03 6394 83ef 0000220 dbab 598b 60db ecf0 d09a d5ce 5ea8 d2e6 0000240 8277 1061 076b fd00 8aa8 edd9 17d0 3eeb It is immediately obvious that the 2nd, bad, file has a block of 7 zeros where the other one has random data (on the line labeled 000140). If I am interpreting this file right, this block of 0's is towards the end of what should be a 16 byte block of random numbers. So it looks like something overwrote 7 bytes of this 16 byte block before it could be stored. Hope this helps. BTW, for the curious, the format of the coins.dat file is as follows. For each coin, there is first a c0. Then there are 16 random bytes, the "coin ID". Then there is a PGP-style multi-precision integer which is the exponent corresponding to the coin. In this case it is 0011 01000d. The first two bytes are the number of bits in the MPI, (11 hex equals 17 decimal) and then there are as many bytes as are implied by that many bits; these hold the value. This exponent MPI is followed by another MPI which holds the bank's signature. This can be expressed as (C.ID)^(1/e), where e is the exponent, and C.ID is a byte of 0, a byte of 1, padding bytes of ff, the magic 18-byte "ASN" string, then 16 bytes of the coin ID. In the examples above, the first coin ends exactly in the middle of the row labelled 000120. Try to see if you can pick out the sub-fields of each coin in the files.