4 ms·

I gave a poor example. What I wanted to say was an ever changing data in a non-centrally managed context. Some nodes hold hashes for the previous version and th

by kang 11y ago

I gave a poor example. What I wanted to say was an ever changing data in a non-centrally managed context. Some nodes hold hashes for the previous version and then they'd compete for resources. The thing from bitcoin is 51% attack where majority of nodes collude to provide the wrong data(they might not be malicious but just serving old version of a data). This can only be prevented by time-stamping in slow scenarios. In case of neocities, a central server is giving you a hash that the nodes would provide you the data for, but without a central management how does IPFS associate correct file to the correct hash? If it only works for a centralised scenario then it is similar to the http://peercdn.com http://peercdn.com project where instead of a server supplying content, your previous visitor browser cache is supplying the content through p2p webrtc and you save server bandwidth.

reit 11y ago
>In case of neocities, a central server is giving you a hash that the nodes would provide you the data for, but without a central management how does IPFS associate correct file to the correct hash? Mathematics[1]. Your hash is based on the content of the file, therefore you can guarantee that the content is the same as what the original author published. Also, IPFS is not a blockchain, there is no 51% attack. https://en.wikipedia.org/wiki/Cryptographic_hash_function https://en.wikipedia.org/wiki/Cryptographic_hash_function
- kang 11y ago
  I am not native english speaker so perhaps was misunderstood again. You searched for a content by an author, and the network gives you multiple hashes, which one do you trust, without a central authority telling you?
  - Confiks 11y ago
    As with my comment above: you trust the content that is ultimately (up the hierarchy) signed in an IPNS object with a valid signature. And there must indeed by some central authority giving 'ultimate trust'. This is Zooko's triangle. By default IPNS gives you 'decentralized' and 'secure', but you can also opt to tie an IPNS name to a DNS TXT record, and lose 'decentralized' (at least for the initial lookup) but gain 'human-meaningful'.
    - reit 11y ago
      I think there is a level where DNS -> IPNS ID is even then still better than DNS -> IP address. For DNS -> IPNS you could have a facility in there saying 'This DNS TXT record should not change, if it does something is wrong'. You could lock down the record for a period of time, such as the duration of the lease from the registrar. Besides, the idea is that IPFS could happily support Namecoin[1], so there's the decentralized, secure, and human-meaningful DNS service. The only 'non-secure' aspect there is the unlikely event of a 51% attack. [1] https://namecoin.info https://namecoin.info
      - ryan-c 11y ago
        A 51% attack will let you double spend and roll back transactions. If one wanted to steal an established name on Namecoin, they'd need to either roll back to before it's registration, roll back to before it's previous renewal and force an expiration, or mine past it's next renewal to force expiration. Renewal limit is 36,000 blocks. For a name that consistently renews early every 18,000 blocks a 51% attack would need to go on for months to steal it. Still possible, but very difficult. Namecoin is merge-mined with Bitcoin by many miners, so if you wanted to 51% it you'd need a pretty large chunk of Bitcoin's hash power. An evil pool could do this, however it would be visible on the Bitcoin blockchain that they were doing it (although not what transactions are present/not present in the attack chain).
  - nightpool 11y ago
    I think the fundamental misunderstanding here is that you can't search by author. You can fetch by IPFS hash or IPNS pubkey (which is tied to a hash). You can also use existing name services (such as DNS or namecoin) to tie human-meaningful names to a pubkey or hash. (but probably a pubkey)
Confiks 11y ago
I don't really see how your 'competing for resources' scenario would work. New peers that try to fetch the new content at some IPNS name would see a new IPFS object hash, and search the DHT for that new hash. Nodes that have an old version won't be involved (unless of course the object 'hierarchy' contains cached data, which will only speed things up). At first the only peer having the new content will probably be the creator, but this will quickly spread across the network. As long as peers do not decide to keep the data (by pinning the hash), the old content will simply be deleted and replaced with new content. Pinning is extremely cheap, so you can imagine that you would want to auto-pin pages as you visit them. This is not on by default though, and I think that's a good thing. > [B]ut without a central management how does IPFS associate correct file to the correct hash? It does so using cryptographic identities. In IPFS every peer has a private/public keypair, and the PeerId is the hash of its public key. When publishing content under an IPNS name (which always has the PeerId at its root), you must prove that you 'own' the PeerID by signing the object with your private key. Other nodes will not 'mirror' your IPNS object unless the signature matches (which makes a nice consensus). The paper calls this self-certified names: you can distribute the objects, and let them be provided by third parties without losing authenticity. See section 3.7.

by kang 11y ago

reit 11y ago

>In case of neocities, a central server is giving you a hash that the nodes would provide you the data for, but without a central management how does IPFS associate correct file to the correct hash? Mathematics[1]. Your hash is based on the content of the file, therefore you can guarantee that the content is the same as what the original author published. Also, IPFS is not a blockchain, there is no 51% attack. https://en.wikipedia.org/wiki/Cryptographic_hash_function https://en.wikipedia.org/wiki/Cryptographic_hash_function

kang 11y ago
I am not native english speaker so perhaps was misunderstood again. You searched for a content by an author, and the network gives you multiple hashes, which one do you trust, without a central authority telling you?
- Confiks 11y ago
  As with my comment above: you trust the content that is ultimately (up the hierarchy) signed in an IPNS object with a valid signature. And there must indeed by some central authority giving 'ultimate trust'. This is Zooko's triangle. By default IPNS gives you 'decentralized' and 'secure', but you can also opt to tie an IPNS name to a DNS TXT record, and lose 'decentralized' (at least for the initial lookup) but gain 'human-meaningful'.
  - reit 11y ago
    I think there is a level where DNS -> IPNS ID is even then still better than DNS -> IP address. For DNS -> IPNS you could have a facility in there saying 'This DNS TXT record should not change, if it does something is wrong'. You could lock down the record for a period of time, such as the duration of the lease from the registrar. Besides, the idea is that IPFS could happily support Namecoin[1], so there's the decentralized, secure, and human-meaningful DNS service. The only 'non-secure' aspect there is the unlikely event of a 51% attack. [1] https://namecoin.info https://namecoin.info
    - ryan-c 11y ago
      A 51% attack will let you double spend and roll back transactions. If one wanted to steal an established name on Namecoin, they'd need to either roll back to before it's registration, roll back to before it's previous renewal and force an expiration, or mine past it's next renewal to force expiration. Renewal limit is 36,000 blocks. For a name that consistently renews early every 18,000 blocks a 51% attack would need to go on for months to steal it. Still possible, but very difficult. Namecoin is merge-mined with Bitcoin by many miners, so if you wanted to 51% it you'd need a pretty large chunk of Bitcoin's hash power. An evil pool could do this, however it would be visible on the Bitcoin blockchain that they were doing it (although not what transactions are present/not present in the attack chain).
- nightpool 11y ago
  I think the fundamental misunderstanding here is that you can't search by author. You can fetch by IPFS hash or IPNS pubkey (which is tied to a hash). You can also use existing name services (such as DNS or namecoin) to tie human-meaningful names to a pubkey or hash. (but probably a pubkey)

Confiks 11y ago

I don't really see how your 'competing for resources' scenario would work. New peers that try to fetch the new content at some IPNS name would see a new IPFS object hash, and search the DHT for that new hash. Nodes that have an old version won't be involved (unless of course the object 'hierarchy' contains cached data, which will only speed things up). At first the only peer having the new content will probably be the creator, but this will quickly spread across the network. As long as peers do not decide to keep the data (by pinning the hash), the old content will simply be deleted and replaced with new content. Pinning is extremely cheap, so you can imagine that you would want to auto-pin pages as you visit them. This is not on by default though, and I think that's a good thing. > [B]ut without a central management how does IPFS associate correct file to the correct hash? It does so using cryptographic identities. In IPFS every peer has a private/public keypair, and the PeerId is the hash of its public key. When publishing content under an IPNS name (which always has the PeerId at its root), you must prove that you 'own' the PeerID by signing the object with your private key. Other nodes will not 'mirror' your IPNS object unless the signature matches (which makes a nice consensus). The paper calls this self-certified names: you can distribute the objects, and let them be provided by third parties without losing authenticity. See section 3.7.