doc: the test fixtures we really need #4
Description
In simple terms: We need a functional test to create the intermediate and final data / byte representations related to registering an identity with tested test fixtures:
- a test wallet phrase and paths
- Wallet Phrase: doc: what the bytes look like #3
- the actual private keys used (there's probably 5 of them)
- a test TX, ready for signature
- (we produce this, but there may be one byte we don't know where it goes yet)
dashhive/DashTx.js@786715c#diff-dcba0694ad59e9893af33895826b399745c8e3ace322c260c2e9ab5244bb0427R1166
- (we produce this, but there may be one byte we don't know where it goes yet)
- a test TX, fully signed and ready for broadcast
- we have this, which implies that we also have the former
Needs test for L2 AssetLockProof TX DashTx.js#86
- we have this, which implies that we also have the former
- a test JSON or CBOR or bincode (we don't know which), ready for signature
- a test JSON or CBOR as a counterpart to the one that's actually signed
- a test
bincode, fully signed and ready to broadcast- BroadcastTransition request doc: what the bytes look like #3, starting after the grpc header
00000003ce0acb07
- BroadcastTransition request doc: what the bytes look like #3, starting after the grpc header
- a test JSON or CBOR as a counterpart to the one that's actually broadcast
- a curl (or grpcurl or netcat) example of the broadcast
- BroadcastTransition request doc: what the bytes look like #3
(the grpc header + bincode)
- BroadcastTransition request doc: what the bytes look like #3
That's more important than documentation, code samples, etc.
What does the CPU need to operate on?
What does the network card send out to the world?
I think these are just the basic things you'd give to anyone that you expect to implement a protocol - what are working inputs, what are working outputs, and what are the intermediate representations necessary to check that the bits in the middle are correct.