Since you make the 'reference' transaction, you can make one that has a low number of txo. Let's say your txo index has to be < 4. 2 bits are enough to encode that offset. You want 20 bits of checksum so txo index and checksum fit in 22 bits or 2 words.

The block height is encoded with a continuation bit and either 20 or 31 bits for a total of either 21 bits if height < 2^20 (~1 million) or 32 bits if above but lower than (2^31). Add the version bit and it comes exactly to either 2 or 3 words.

TxIndex is simply encoded as words.

Recap:
# first part
- version bit: always 0
- length indicator
    - if 0: use 2 words
    - if 1: use 3 words
- block height

# 2nd part - always 2 words
- txo index: 2 bits
- checksum: 20 bits

# remaining words
- tx index

For any reference tx below index 2048 before height 2^20, it is guaranteed to be 5 words. The format is pretty constant and doesn't rely on txcount or the number of txo in the reference tx. Moreover, generation and parsing is straight forward.

I keep forgetting that it goes back to the beginning. Then there is no problem.

That makes sense. The 2nd case implies that outputindex is small enough - so we are not talking about a large range actually. With 3 different paths, you need to prove that there is no overlap. Basically, proving the unicity of the encoded value.

Edit: What I mean is this: http://en.wikipedia.org/wiki/Variable-length_code - Uniquely decodable codes

Yeah, you end up using y1 and z1. The only time it's not the case is when txindex is small enough and utxo index = 0. If that's the intent, it's better to call it out explicitly and formulate a direct method (without loops). It'd be easier to prove that it's uniquely decodable. I think it's not worth the trouble and I'd discard that special case.

Well, I have a hard time seeing what you are implementing. I thought you meant to go to step 4 because if I have to go to step 3 the case isn't that useful.

If in step 3, y = y2 because you have enough bits left then you use them all. Next in step 4, there won't be any left. So unless utxo index = 0, you will have to increase w and go back to the beginning. What's the idea behind this case then?

This is different than what I think you meant in English.

Right, I changed that to match your value but there is no need for it. Use tx output = 1 then. The point is that w gets incremented after y was chosen based on w=1.

(It looks better in markdown)

Using the same values for `x=3`, `c=4` and the blockchain:
I want to encode a tx at index 3, output index = 0
My tx index is 11b. `y3=2` and `z3=1`
Now I go through the encoding steps.
- `w = ceil(3+2+0+4+1)/11 = 1`
- There are 40 tx, so `y1=6`
- `y2=11-1-3-4 = 3`
- `y=min(3,6)=3`
- `y3>y`? no. don't increase `w` but use 3 bits. txindex is encoded as `011`.

Next phase. Let's say there are 2 outputs in that tx.
- `z1=1`
- `z2=11-1-3-4-4 = 0`
- `z=min(1,0) = 0`
- `z3>z` ? yes. increase w. `w=2` and retry
- `z2=22-1-3-4-4 = 11`
- `z=min(1,22)=1`
- `z3>z` ? no. use `z=1`. utxo index is encoded as `0`.
- checksum takes `22-1-3-3-1 = 14` bits

My result is
`1010110xxxx-xxxxxxxxxx0`

Yours is
`10101100110-00110101010`

The beginning is the same. Let's say the checksum is 0110-xxxxxxxxxx
I get `1010110110-xxxxxxxxxx0`

The decoder will think the txindex is yours and fail to validate.
In fact, my address will fail for any value of the checksum because the decoder will look at a different tx than mine.

You are only decoding to one of the possible pairs.
Just walk through the steps with my example if you don't believe me. I could be wrong, so it's good to have another person check. Better yet, post a reference implementation and anyone can verify.

It's ambiguous because given an encoded value, you don't know where the separation between txindex and outputindex is.

To keep things simple, let's say
- x = c = 0
- w = 1
- and 8 bits per word instead of 11.

if i have 0101 0000, is it
- txindex = 0 and outputindex = 1010000 or
- txindex = 01 and outputindex = 010000 or
- txindex = 010 and outputindex = 10000 or
- txindex = 0101 and outputindex = 0000 etc

the checksum introduces another issue. Since it has variable length, where does it start?

It wouldn't be SHA-2 if it used fewer rounds.

Hmmm ... The English description doesn't match the pseudo code (a bug?). Moreover, it looks like the intended algorithm has collisions (different pairs of inputs that lead to the same encoded value pre checksum).

Kinda. SHA-2 hasn't been cracked (i.e nothing better than brute force) but versions with a reduced number of rounds have. It's not very important because it's not the full SHA-2 and even there the complexity is still much too high for a practical crack. Of course, if you only perform a few rounds you are dead.

Yes

A computer is generally better at producing random numbers than a human. Methods like shuffling cards, flipping coins, have been shown to be worse than a CRNG. Of course it relies on having access to one. The examples you mentioned just show that popular means little. Two fun facts:
- Casino slot machines use RNG
- Flipping is coin is biased towards the starting state

In any case, it's a matter of being practical too. Flipping a coin 128 times to get a seed is fine. Doing it for every address generated is crazy. I remember a story about the one time pad. During WW2, a team was in charge of making the pads. After a while, they got tired and started reusing them. It didn't take long before the codes were broken.

Dealing with unsigned tx is a wallet job and therefore not part of the P2P protocol. There is no standard for their format and wallets serialize them with various degree of information attached. Just putting the raw bytes is usually not deemed secure enough because it gives no indication of the values of the inputs. It's a tough choice that offline wallets have to make.

On a related note, what's the reason why the tx-count in the block header retrieved by getheaders always 0? It seems it would be as easy to return the actual count.

These diagrams have to be read as if everything executes in parallel because that's what the hardware will do. Each box contains one word (= 4 bytes) and on the next clock tick, every arrow is 'executed' and it repeats. It's not a description of the algorithm that someone will use to write code but it shows how to do it in hardware. It is better for finding the critical paths, i.e. the paths that take the longest time because they involve more steps.

Yes, the expander part is the message schedule.

- First, the message is padded.
- Hashing starts with a predefined value as the intermediate hash
- then it takes a block of message input (64 bytes) and it expands it to an array of 64 x 4 bytes. It is called the message schedule.
- then it runs 64 times the same bit manipulation function (the compression function) on the intermediate hash value. Each time is called a round and it uses one element of the message schedule `Wt` and one predefined constant `Kt`.
- After 64 rounds are finished, it goes to the next message block.
- Once the message is consumed, the intermediate hash is the result.

Each little rectangle with an arrow in the expander contains one element of Wj. It's basically a buffer of 16 x 4 bytes. The first 16 elements are the same as the input message block.
The rest is defined as Wj = o1(Wj-2) + Wj-7 + o2(Wj-15) + Wj-16. The expander calculates one element of Wj that it feeds into the compression function. In the next round, the buffer shifts and one new Wj gets calculated.

A bip 32 seed is 128 bit long and takes 12 words. How did you figure out to use only 4?

No, you take the txindex and interpret it as a position in the merkle tree. The tree has all the tx ordered by index as its leaf. It's the same value.