Clarify Threshold Fingerprint Generation
sappenin opened this issue · 4 comments
While investing the Java test failures, I noticed that some of the ThresholdCondition's fingerprint generation results don't line-up with the TestVectors published in the CryptoCondition RFC project.
For example, looking at the fingerprintContents binary in 0008_test-basic-threshold.json, I see the following:
308184800102A17FA12B8020451FE15F16299D495993FE692DB989E56A5230A90476F77392A3CD3213C0733F810302040382020308A32780204DD2EA7F85B3EACB8F19058E8360955C32E74C124392A1F44660739709C539C38103040000A4278020799239ABA8FC4FF7EABFBC4C44E69E8BDFED993324E12ED64792ABE289CF1D5F8103020000
However, in the Java code, the following call...
BaseEncoding.base16().encode(CryptoConditionReader .readFulfillment(BaseEncoding.base16().decode(testVector.getFulfillment())).getCondition().getFingerprint());
yields the only following fingerprint value:
31AF10E168BA56AB38BEBF27065413C76896A6683C53D746F15A6438FD2A6C66
I think the source of the problem is that method ThresholdSha256Condition.getFingerprintContents() only looks at the subconditions when computing the fingerprint. When CryptoConditionsReader reads the binary of the fulfillment in the test vector, it yields a ThresholdFulfillment with one subcondition and two subfulfillments (one RsaSha256Condition and then one PrefixSha256Fulfillment and a Ed25519Fulfillment).
Is it possible that the implementation is wrong, and should somehow be considering the genrated Condition of each subfulfillment, too?
As it stands, the fingerprint in the TestVector seems to have much more data than anything I can generate using the Java library.
Off the top of my head that test vector looks wrong. The fingerprint should be a constant length.
@justmoon
I created rfcs/crypto-conditions#27 so this issue doesn't get lost in the RFC project (and for linkage).
Bump @justmoon