Segregated Name Values

biolizard89
Posts: 1968
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Segregated Name Values

Post by biolizard89 » Fri Jan 19, 2018 6:36 am

biolizard89 wrote:
Sat Jul 29, 2017 5:05 pm
domob wrote:Sounds like an interesting approach. One question, though: Why would you keep the values in a Merkle tree? Isn't it enough to just push the value's hash and allow for the values to be transmitted fully "out of band" with respect to the blockchain? The hash ensures that the values are still secured as they are now. In fact, such an optimisation could be implemented completely on a higher level - say, by adding a separate P2P network layer for transmitting values (not consensus relevant) and then modifying the d/ spec to require the actual values to be transmitted out-of-band and the actual d/ name value to be the hash. This could then be paired with a softfork to restrict the actual in-chain value length to 32 bytes.

Am I missing something, why is it necessary to include the actual values (not just their hashes) in a root hash? The only reason I can think of for now is that this may be used to "force" full nodes (and miners) to keep the values around for some time.
So it occurred to me that there is a reason to have a Merkle tree for this: it allows us to permanently discard the value hashes too.

Under the scheme I originally described, each name output needs to store a 32-byte hash, which is kept forever. However, consider an alternative scheme where the name output contains a 0-byte value field, and the coinbase transaction commits to a Merkle tree where the leaves of the Merkle tree contain both the full value and signatures for the full value. (Presumably you could also apply SegWit to this, so that the the values and value signatures are in separate Merkle trees.) This means that you need to download twice as many signatures for the not-yet-discarded name values, but it means that you can permanently discard the value hashes (and of course their signatures) after some period of time (say, 72 kiloblocks).

Asymptotically this should be an improvement. Also, if most of the signatures for the block are Schnorr, you might be able to do some kind of signature aggregation to eliminate most of the overhead (similar to what's being proposed for Bitcoin).
It occurs to me that we probably wouldn't actually need 2 sets of signatures; we could plausibly use Andrew Poelstra's "Scriptless Scripts" (specifically the OP_RETURN variant) to make the main block signatures sign the SegVal data as well. Not sure if this is actually necessary (or if there's some interesting quirk of how the math works that would make it infeasible), but it seems worth looking at.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply