Re: Range of Security : Nonce

On 15 April 2014 03:33, Herbert Snorrason <odin@anarchism.is> wrote:

> On 14/04/14 11:49, Melvin Carvalho wrote:
> > The use case I'm interested is to mark up a nonce in the bitcoin block
> > chain header.  In the case of bitcion it's a 4 byte integer starting at
> 0.
> > ( ie xsd:unsignedInt )
>
> These types don't specify encoding. xsd:unsignedInt doesn't mean it's
> laid out as four bytes, just that it's possible to do so. Any
> xsd:unsignedByte is also an xsd:unsignedShort is also an
> xsd:unsignedInt. This means that translating from integers to nonces
> requires you to be absolutely certain that endianness issues and
> possible changes of declared type through reasoning of some sort haven't
> mucked up your integer.
>
> Or you could store the four byte sequence as an xsd:hexBinary or
> xsd:base64Binary and making sure that RDF stuff preserves both the
> encoding and length.
>
> Or is there a downside to those types that I'm just completely blind to?
>

I would be quite happy to use any of those types.  But the "range" of nonce
is limited to string.  So if I did so, I would be violating the ontology.

Commonly in cypto currencies nonces are stored as ints, bigendian hex and
little endian hex

So if I had

"10000000"

It would be unclear to the software what this was unless communicated out
of band, which is not ideal, from a scalability perspective.

I think it would make most sense for me to create a new nonce predicate,
then refactor once this issue becomes more stable.


>
> With greetings,
>   Herbert Snorrason
>
>