Answering those questions:

- version byte is transmitted. Although it isn't needed, we already have
the data (since we have the tx) and it's not a big deal to publish it. I
also include the block height, block hash and actual tx.

- The expected ordering for the blocks is the same as the binary_type
object in libbitcoin. Or how it's documented in the examples here:
https://github.com/genjix/bips/blob/master/bip-stealth.mediawiki
That's the same as in Python, for instance: 4abe

>>> bin(0x4a)
'0b1001010'
>>> bin(0xbe)
'0b10111110'

4a = 01001010
be = 10111110

Thanks for the notes, didn't think of that but should be fine. :)

On 01/23/2015 08:15 AM, Eric Voskuil wrote:
> Can you provide some more detail on the "Protocol format" section?
>
> Obviously all sizes are bytes, so the valid values for bitsize would be
> [0..255].
>
> Blocks (the value of N) would therefore be restricted by the parser to
> [0..32], with the last bit of 32 bytes not addressable. If the protocol
> was ever expanded to include a 256 bit hash (i.e. for a tx search), this
> would become a pertinent question. In the presumed implementation one
> would be precluded from specifying all bits. By the same token the
> current design prevents one from specifying no bits (get all). Not an
> issue, just clarifying.
>
> For stealth I would expect bitsize to be restricted to [0..32] and for
> address [0..160]. Therefore the number of blocks required on the wire
> would be round_up(bitsize/8) for a max of 4 for stealth and 20 for address.
>
> I'm assuming above that the version byte is not expected on the wire -
> that we are only transmitting the pubkey hash, please confirm.
>
> The last question is the what is the expected ordering of the bits/bytes
> on the wire?
>
> e
>
> On 01/22/2015 09:40 PM, Amir Taaki wrote:
>> Check the page:
>>
>> https://wiki.unsystem.net/en/index.php/DarkWallet/Subscriber
>>
>> Server now uses prefixes and also supports stealth.
>