google / trillian

In trillian.proto, tree size is uint64.

Lines 237 to 242 in f12f919

    
           // log_root holds the TLS-serialization of the following structure (described 
        
           // in RFC5246 notation): Clients should validate log_root_signature with 
        
           // VerifySignedLogRoot before deserializing log_root. 
        
           // enum { v1(1), (65535)} Version; 
        
           // struct { 
        
           //   uint64 tree_size;

In trillian_log_api.proto, tree sizes are int64.

trillian/trillian_log_api.proto

Lines 269 to 274 in f12f919

    
           message GetConsistencyProofRequest { 
        
             int64 log_id = 1; 
        
             int64 first_tree_size = 2; 
        
             int64 second_tree_size = 3; 
        
             ChargeTo charge_to = 4; 
        
           }

This mismatch makes it necessary to cast from unsigned to signed integer when creating requests.

My vote is in favour of uint64 for tree sizes (and int64 for timestamps, see

trillian/trillian.proto

Line 244 in f12f919

// uint64 timestamp_nanos;

for example).

This might not be the only mismatch. I think some of the proof code uses int64 for tree sizes.

Code can be fixed up a bit more easily, but protos define higher level interfaces between potentially distant (both in time and space) processes, so getting those right is quite important.

Realistically we're not going to make these breaking changes. But we pinky promise to be consistent with this on new APIs.

	// log_root holds the TLS-serialization of the following structure (described
	// in RFC5246 notation): Clients should validate log_root_signature with
	// VerifySignedLogRoot before deserializing log_root.
	// enum { v1(1), (65535)} Version;
	// struct {
	// uint64 tree_size;

	message GetConsistencyProofRequest {
	int64 log_id = 1;
	int64 first_tree_size = 2;
	int64 second_tree_size = 3;
	ChargeTo charge_to = 4;
	}

Mix of uint64 and int64 tree sizes