OneName again: Blockstore

Post Reply
domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

OneName again: Blockstore

Post by domob »

OneName contacted me, with a link to their newest project:

http://blog.onename.com/blockstore-bitcoin/

Basically, they implement a key-value system using OP_RETURN (similar to what I did with Isracoin).
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: OneName again: Blockstore

Post by domob »

They also propose to use a DHT to store large name values, and just include a hash of the data in the blockchain. This allows to avoid blockchain bloat, while it still gives the same security guarantees. However, it prevents "offline" lookups (and may be a potential privacy issue).

This made me think: Should we try to implement a DHT ourselves, as an (optional) way to store extra data? This could be handled at the NMControl level. For instance, similarly to "import", I could include a "dht: random-key" field with a name. NMControl would then look up the value corresponding to the key in the DHT. The value could be signed by the name's address to ensure authenticity. This way, one could have both larger values without blockchain bloat, and could update one's names without the need to pay for a renewal fee. (Just update the DHT entry.)
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

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

Re: OneName again: Blockstore

Post by biolizard89 »

domob wrote:They also propose to use a DHT to store large name values, and just include a hash of the data in the blockchain. This allows to avoid blockchain bloat, while it still gives the same security guarantees. However, it prevents "offline" lookups (and may be a potential privacy issue).

This made me think: Should we try to implement a DHT ourselves, as an (optional) way to store extra data? This could be handled at the NMControl level. For instance, similarly to "import", I could include a "dht: random-key" field with a name. NMControl would then look up the value corresponding to the key in the DHT. The value could be signed by the name's address to ensure authenticity. This way, one could have both larger values without blockchain bloat, and could update one's names without the need to pay for a renewal fee. (Just update the DHT entry.)
How would using a DHT to store data affect censorship resistance? Right now, every full node is required to store the full blockchain, otherwise the system is designed to break. If you use a DHT, what would stop a large number of nodes from refusing to hold name data for "undesirable" names? Can a DHT be designed so that this isn't a problem? Would something a la Freenet be secure against this attack?

I think offline/private/fast lookups would be addressable if the client's default setting is to pre-download all of the DHT data. To improve scalability, you could have a rule that only DHT data with a size below X gets pre-downloaded.

From a security point of view, I don't think it's great to store signatures in the DHT, because it doesn't provide a good way to invalidate data later. Putting a hash into the blockchain and updating the name whenever the data changes seems more secure, and probably wouldn't be a scalability issue.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

johnc
Posts: 89
Joined: Sun Dec 28, 2014 10:03 am

Re: OneName again: Blockstore

Post by johnc »

I think the general idea is good, in the sense that regular nodes are more usefull and have less data. As Jeremy says it will be mandatory to update the name every time the data changes, since the datahash will change as well. i think. If not it would be possibly a new attack vector.

I'm reading the link and this should be heavily planned and specify what kind of data can be embebbed in where, or we can end up with crazy things on the DHT. I think it will be wise to state what actual data goes there and that files should be on format magnet: and DHT must be used just for dns, id, etc of small size information (possibly even to store namecoin blocks in a distributed fashion) . So there will actually be dinamic and static information on the DHT, dinamic to provide peer sources that have the object and static for the objects themselves.

Image
So, like this but with arrows pointing down from the DHT nodes to big files stored encrypted encrypted on participating nodes.

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: OneName again: Blockstore

Post by phelix »

Why did they contact you about this, does it concern Namecoin?

IMHO it would be better to use the BitTorrent DHT than to reinvent the wheel. In general I think using a DHT for large, signed data should be explored and specified.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

Post Reply