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).
OneName again: Blockstore
OneName again: Blockstore
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
Re: OneName again: Blockstore
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.)
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/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: OneName again: Blockstore
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?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.)
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.
Re: OneName again: Blockstore
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.
So, like this but with arrows pointing down from the DHT nodes to big files stored encrypted encrypted on participating nodes.
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.
So, like this but with arrows pointing down from the DHT nodes to big files stored encrypted encrypted on participating nodes.
Re: OneName again: Blockstore
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.
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.