Quote from: Pieter Wuille on May 12, 2013, 06:38:13 PM

Quote from: thanke on May 12, 2013, 01:05:05 PM

Quote from: thanke on May 05, 2013, 09:13:48 AM

1. Can we reserve more than one bit of the number i for different kind of derivations, not only the highest bit? This would allow addition other kinds of derivations or tweaks of existing ones in the future.

Adding more flag bits is certainly possible, but we can extend the length of the serialized i value in that case, so the only thing that needs to change is the serialization format.

Do you mean to change the serialization format even for the two derivations that we have now? Like add another byte?

Quote from: Pieter Wuille on May 12, 2013, 06:38:13 PM

If smartcards have a problem with SHA512, they'll have a huge problem with ECDSA.

Ok.

Quote from: Pieter Wuille on May 12, 2013, 06:38:13 PM

Quote from: thanke on May 12, 2013, 01:05:05 PM

And third, can you change

Code:

I = HMAC( cpar, Kpar || i)

in the public derivation to

Code:

I = HMAC( HMAC(cpar,i), Kpar)

? I see the provability of the link as a quite an important property (cf. #228).

That provability argument is interesting, but can you come up with use cases?

iddo and you asked about use cases. Say a company has two departments A and B that have publicly known pubkeys P (for A) and Q (for B). They receive incoming payments on derived keys P_i and Q_i. At the end of the fiscal year the company wants to prove their balance sheet to an auditor. They want to prove to the auditor that A had this amount of income, and B that amount of income. I am assuming they don't want to give the chaincodes to the auditor. So for each i they tell the auditor the multipliers I_L such that P_i=I_L*G+P, and also the multipliers such that Q_i=I_L*G+Q. Right? No! The company can set up P and Q from the beginning so that they can decide at the end of the fiscal year to which department they like to associate each individual incoming payment. Dividing the incomes however they like between A and B, as long as they don't exceed the total sum of course. If we have P_i=HMAC(I_L,P)*G+P they can't do that.

The "setup" works like this: The company picks P and r and sets Q:=P+r*G. Say P_i = I_L*G+P. If they want to associate P_i to P they give the auditor I_L, if they want to associate P_i to Q they give the auditor I_L-r instead (never both, of course, because then they blow up).