Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Peer-to-peer is too general and too useful to be spoilt by "blockchain". But there is so much money behind this crap it is a formidable virus that can infect any project.

ConsenSys is a company formed by Ethereum co-founder. He has sold out to the big banks, in the opinion of some Consensys shareholders.

https://finance.yahoo.com/news/consensys-shareholders-readyi...

"Falls says he believes both MetaMask and Infura - what he calls "the crown jewels" of ConsenSys - could have been decentralized and tokenized, and that their projected use is "completely anathema" to the peer-to-peer principles of the space.

Meanwhile, a number of teams are looking to bring "institutional DeFi" - with its known counterparties and compliant custody arrangements - to the marketplace.

"Forget about the shareholders for a minute," Falls said. "Think about the consequences of the change in the influence over these infrastructure pieces.""

Out of curiosity I was looking at the evolution of IPFS hashes. They have gotten more complex. IPFS now uses base58btc exclusively. That's "btc" as in Bitcoin. Something like rhash, which has traditionally supported hashes used in peer-to-peer protocols, has no support for base58btc.

People are now trying to associate IPFS with "Web3". For example, check out this paper published a couple of weeks ago.

"Studying the workload of a fully decentralised Web3 system: IPFS"

https://arxiv.org/pdf/2212.07375v1.pdf



> IPFS now uses base58btc exclusively

That's blatantly wrong. IPFS supports 25 different base representations (https://github.com/multiformats/multibase/blob/master/multib...).

In fact, recently, two community members decided to implement a new base encoding with emojis for fun:

https://cid.ipfs.tech/#%F0%9F%9A%80%F0%9F%AA%90%E2%AD%90%F0%...

https://github.com/multiformats/multihash supports at the very least SHA1 SHA2-256 SHA2-512 SHA3/Keccak Blake2b-256/Blake2b-512/Blake2s-128/Blake2s-256 Blake3 and Strobe. Hashes in IPFS are being standardised through the IETF and W3C https://www.ietf.org/id/draft-multiformats-multihash-05.html.

If you need rhash, you are welcome to submit a PR! We also have a grants program you can use to be rewarded for this.



Above I stated, "IPFS now uses base58btc exclusively." A more precise statement would have been something like, "IPFS CIDs originally used base58btc exclusively." It looks like IPFS is moving to a new CID protocol that allows use of non-BTC hashes. That's a step in the right direction, IMHO.

"In CIDv0, hashes are always encoded with base58btc. Always."

https://web.archive.org/web/20200810110206/https://proto.sch...

"Converting CID versions

You can convert any CIDv0 to CIDv1, because the implicit prefixes from v0 become explicit in v1. However, because CIDv1 supports multiple codecs and multiple bases and CIDv0 does not, not all CIDv1 can be converted to CIDv0. In fact, only CIDv1 that have the following properties can be converted to CIDv0:

multibase = base58btc multicodec = dag-pb multihash-algorithm = sha2-256 multihash-length = 32 (32 bytes, equivalent to 256 bits)"

https://proto.school/anatomy-of-a-cid/06/

Thank you @2color for the correction.


Again, ConsenSys isn't behind IPFS. These are two different things.

> People are now trying to associate IPFS with "Web3". For example, check out this paper published a couple of weeks ago.

IPFS has been used to host dApps for a long time — eg the Uniswap frontend. This isn't a recent thing.


> IPFS now uses base58btc exclusively. That's "btc" as in Bitcoin.

It is true that Base58 is named for its original implemention in bitcoin but other than the name it has nothing to do with bitcoin.

The difference from Base64: It excludes non-alphanumeric characters and visually similar characters (I, l; O, 0) to make the output more human-friendly[0].

The problem it attempts to solve: Making bitcoin addresses more human-readable. That is likely also why IPFS uses it.

[0] https://en.bitcoinwiki.org/wiki/Base58#How_it_works.3F




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: