VP discovery

[ghost]

Right now, if Alice wishes to send to Bob's address, Alice must somehow know Bob's validity predicate, and also know where Bob's newest validity predicate is located in the Merkle tree (e.g. Alice must know the trapdoor for the VP commitment note)

Bob's address could include the relevant data (VP circuit description, VP note trapdoor, etc) but this would: 1. make Bob's address enormous and 2. Bob's address is not reusable, since the VP part gets consumed in one transaction.

We need to design a VP discovery step that allows Alice to discover and use Bob's VP.

[joebebel]

Right now I think the best approach is to special case it.

• [ ] Design "default" receive VPs that will be permanently integrated (#2) such as allow-all
• [ ] Design public address format to indicate "short" address (uses default VP) #8
• [ ] Implement default VP support into the tx building/verification code heliaxdev/pbc-playground#11
• [ ] Support custom receiving VPs via in-band (on chain) communication
• [ ] Support custom receiving VPs via out-of-band (off chain) communication

Since probably 99% of all use cases will use a "default" receiving VP, doing a special case optimization would allow for common "short" addresses and uncommon, long "custom" addresses separately.

[cwgoes]

Figure out whole-stack tracking of this issue.