Re: Range of Security : Nonce

On 11 April 2014 23:56, David I. Lehn <dil@lehn.org> wrote:

> On Fri, Apr 11, 2014 at 12:25 PM, Melvin Carvalho
> <melvincarvalho@gmail.com> wrote:
> > On 11 April 2014 17:27, David I. Lehn <dil@lehn.org> wrote:
> >>
> >> On Sat, Apr 5, 2014 at 3:34 PM, Melvin Carvalho
> >> <melvincarvalho@gmail.com> wrote:
> >> > According to the security vocab the range of a nonce is set to xsd :
> >> > String
> >> >
> >> > https://web-payments.org/vocabs/security#nonce
> >> >
> >> > However wikipedia describes a nonce as a number, and we certainly use
> it
> >> > that way in bitcoin
> >> >
> >> > http://en.wikipedia.org/wiki/Cryptographic_nonce
> >> >
> >> > Would it make sense to remove this constraint from the range of Nonce?
> > ...
> > Thanks for the response.  How about making it a string OR int?  ie have
> both
> > xsd in the range, I think that's allowed, similar to how currency is
> > defined?
> >
>
> Do you mean xsd:int in particular?  Why not long, unsignedInt,
> unsignedLong, integer, nonNegativeInteger, etc?
>
> http://www.w3.org/TR/xmlschema-2/#built-in-datatypes
> http://www.w3.org/TR/xmlschema-2/#built-in-derived
>
> It seems unclear what to use without causing implementations the pain
> of supporting every type.  I think the main restriction we have in the
> usage we've had so far is that we will need to ensure there is a spec
> on how every supported nonce type is encoded as a bitstream suitable
> for use in hashing and signing algorithms.  It seems like using
> xsd:string and using some sort of UTF-8 encoding would work for many
> use cases.  What is the use case for using a numeric type?
>

Thanks again for the pointers.

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 )

https://en.bitcoin.it/wiki/Block_hashing_algorithm

I could either create a custom nonce field for electronic coins, or reuse
the value in the security vocab.  Currently I'm using sec : nonce with
unsignedInt but that would violate the range as things stand.  Im slightly
unsure that using a string value would be the ideal way to model this
value, but open to suggestions!


>
> -dave
>