Hi all, I am a bit confused here:
According to the spec and main.cpp the version message should be first me and then you:
(line 2364)
        int64 nTime;
        CAddress addrMe;
        CAddress addrFrom;
        uint64 nNonce = 1;

but from what I see over the network it is more the otherway around, as net.h would suggest too:
line 743
    void PushVersion()
    {
        /// when NTP implemented, change to just nTime = GetAdjustedTime()
        int64 nTime = (fInbound ? GetAdjustedTime() : GetTime());
        CAddress addrYou = (fUseProxy ? CAddress("0.0.0.0") : addr);
        CAddress addrMe = (fUseProxy ? CAddress("0.0.0.0") : addrLocalHost);
        RAND_bytes((unsigned char*)&nLocalHostNonce, sizeof(nLocalHostNonce));
        PushMessage("version", VERSION, nLocalServices, nTime, addrYou, addrMe,
                    nLocalHostNonce, std::string(pszSubVer), nBestHeight);
    }

As I am not proficient in cpp, I don't really know now what is going on.
Could someone shed a bit more light on this please?

Thanks,

Martin

While I am quietly in my limited spare time building a python implementation of the bitcoin protocol I am increasingly charmed about the ingenuity of the protocol itself.
Sure in the beginning I had of a lot of things* that I found strange but what is even stranger is that I am continuously discovering that the choices made might not be pretty, or particular easy but they share one common trait so far; the alternatives have far worse implications**.

So I would like to take my hat off and say three cheers to everybody that is working, designing and building the protocol, the software and community!

Thank you, it is truly appreciated!

<sub>* )
1 The constant byteswapping. Well once (:-)) you have it subclassed  you hardly notice it anymore.
2 Only ~21 million BTC available? Yeah but it is easy enough to increase the divisibility
3 What about lost coins, can we not have a system in place where forgotten coins are available for reminig? Neat, but this ultimately leads for regular users to a dependency on an external service provider, which opens a whole other can of worms.
4 The use of secp256k1, Well ones you look into it, it is kinda neat and there is not a clear and obvious advantage to other curves or public key algorithm, so this falls in the category why not.
5 The lack of a python implementation. Well, I am working on it, so that one is my fault for not moving my behind faster :-)

** )
My opinion, thus the validity of the made statements are not universal.</sub>

Hi all,

As I am rebuilding the protocol in python and testing it out with some tcpdumps gathered with the official client, I noticed that my client (version 3210)  on a getdata message sends out the wrong count.

The offending hex is: FD9A01
After investigating I found that for this particular example my count is 663 while the actual entries are 410

According to the spec, varint should do:
<= 0xffff    3    0xfd + uint16_t

So what it seems to do is only setting the total value in the next two bytes without subtracting 253 of it.

Is this a known error in this older build and is it solved in a newer version (I am on FreeBSD btw)?
On a side note, is this forum the appropriate media to report such unconfirmed things or should I shout somewhere else, perhaps a more stable medium?

Cheers and Thanks,

Martin

Hi all,

I was wondering how the hash was calculated of a transaction, so I can replicate it in my python code.
I have read up on:
https://en.bitcoin.it/wiki/Protocol_specification#tx
and
https://en.bitcoin.it/wiki/Dump_format

But I think I am missing something.

For example the block http://blockexplorer.com/b/130264
hash a transaction with hash "230cf0853ffdd82e99fbf1eef37cc3e97de310812d9e2a3ba79fe1ffa9518109"

How is this hash calculated with the given context?
---cut---

Code:

    {
      "hash":"230cf0853ffdd82e99fbf1eef37cc3e97de310812d9e2a3ba79fe1ffa9518109",
      "ver":1,
      "vin_sz":1,
      "vout_sz":2,
      "lock_time":0,
      "size":257,
      "in":[
        {
          "prev_out":{
            "hash":"e65af16c23e007da9b15ddad8b9ea8e27fd6181ac71c197b1e96a8aa53e32e70",
            "n":0
          },
          "scriptSig":"304402204076ee83b670eed45880d63de03b1c0416516c78d6ae3cd89896c5ab14e2f8700220170c0558f5f55f6c278017a493ba26e0ca6d7611130da747184bce7ac8e5381601 042563b05ef6870d0aaaec0365d0cf2b9d8264b7ed1b86e38c8a57166e2d04a3e6176f434ec93ac7c6dceafcdb4c8b633859580b50555e6020594298ac7be14d93"
        }
      ],
      "out":[
        {
          "value":"3.47000000",
          "scriptPubKey":"OP_DUP OP_HASH160 ef7af3db798daeb7f8206e2ecfbfc2465524d9e1 OP_EQUALVERIFY OP_CHECKSIG"
        },
        {
          "value":"129.50000000",
          "scriptPubKey":"OP_DUP OP_HASH160 2008f9f46db9ccd1fc8eda2fdcae57e258be0865 OP_EQUALVERIFY OP_CHECKSIG"
        }
      ]
    },

---cut---

Thanks for any suggestions,

Martin

Hi all,

I am trying to recalculate the hash but I think I am making somewhere a giant snafu.
I attached my code, would anyone be willing to hint me in the right direction?

Thanks

<code>
import hashlib

def i2w(integer):
    """Convert integer to 4 byte word in a string.
    Will raise exception if overflows."""
    work = bin(integer)[2::].zfill(32)
    if len(work) > 32:
        raise(OverflowError(integer))
   
    tmp = list()
    while len(work) > 7:
        part = work[:8]
        work = work[8:]
        char = chr(int(part, 2))
        tmp.append(char)
       
    return(''.join(tmp))


if __name__ == '__main__':
    # Contents of genesis block: http://blockexplorer.com/b/0
    #"hash":"000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
    #"ver":1,
    #"prev_block":"0000000000000000000000000000000000000000000000000000000000000000",
    #"mrkl_root":"4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
    #"time":1231006505,
    #"bits":486604799,
    #"nonce":2083236893,
    #
    hash = "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f"
    # Try to reproduce the above hash with below data
    v = 1
    p = "0000000000000000000000000000000000000000000000000000000000000000"
    m = "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b"
    t = 1231006505
    b = 486604799
    n = 2083236893
   
    tmp = i2w(v) + p.decode('hex') + m.decode('hex') + i2w(t) + i2w(b) + i2w(n)
   
    one = hashlib.sha256()
    one.update(tmp)
    hash_one = one.digest()
   
    two = hashlib.sha256()
    two.update(hash_one)
    hash_two = two.digest()
   
    print(hash)
    print(hash_two.encode('hex'))

<output>
>>> 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>>> f40519089bfd56ee63f6207f11e69707ac85e5ca20ab0e4aeaa468dbc72e7ae0
       

Hi all,

I am making a parser in python for the 'data' part of the getwork json-rpc call.
All well so far but I am getting a bit confused why merkle root changes.

According to https://en.bitcoin.it/wiki/Block_hashing_algorithm it should change every time a transaction is accepted. But as far as I can tell no transaction change has been incoming (checking with tcpdump) and even when I do two repeated calls so that the timestamp is the same it still changes.

What else contributes to merkle root being different on subsequent getwork calls?