Comment by lappa | Hacker News Reader

Comment by lappa | Hacker News Reader

Parent Full thread

This really doesn't make any sense.

>blockchains introduced three new characteristics: centralized / shared control, immutable / audit trails, and native assets / exchanges.

Blockchains aren't immutable, they are just expensive to mutate.

Blockchains aren't centralized.

Blockchains didn't introduce audit trails, these have always been possible simply through having a transaction table that is only appended to. This of course does require trust in the central authority.

>(4) Leads to provenance on training/testing data & models, to improve the trustworthiness of the data & models. Data wants reputation too.

Is training set fraud really an issue in training AI?

>(1) Leads to more data, and therefore better models. >(2) Leads to qualitatively new data, and therefore qualitatively new models. >(3) Allows for shared control of AI training data & models.

The author has a poor understanding of both AI and blockchain technology[1]. Blockchains are for decentralized consensus, but it seems the author is vaguely proposing using a blockchain as a mass datastore (with ownership labels) for both training data and AI algorithms.

Of course AI is an exciting field so this means you can generate hype by implying the field of AI has yet to solve the problem of sharing data with fellow researchers until now.

[1] https://download.wpsoftware.net/bitcoin/alts.pdf

Hi, it's the author here.

> This really doesn't make any sense.

Disagree. Below, I respond to each of your points.

> Blockchains aren't immutable, they are just expensive to mutate.

Agreed; very little is truly absolutely immutable. It's all shades of grey. I actually prefer the word "tamper-resistant" and I usually say that next to the "immutable" definition, such as in the first paragraph of https://bigchaindb.com/whitepaper. But "immutable" makes for a good shorthand, especially because that's the label that the community uses.

> Blockchains aren't centralized.

Oops, that was a typo. I meant to say "decentralized". Fixed it. (That was a pretty big oops!)

> Blockchains didn't introduce audit trails ...

Correct.

> ... [status quo] require[s] trust in the central authority

Exactly. And it's crucial to note that once you don't have to trust a central authority to store your audit trail, you have a way more trustworthy audit trail that improves many applications and unlocks new ones.

> The author has a poor understanding of both AI and blockchain technology ... "treatise on altcoins"

Disagree. First, you don't need an "altcoin" to have a blockchain. To understand of what's special about blockchains, you first have to understand what already exists for distributed databases, then what the delta is.

Second, consensus in a distributed database has been around for decades; Satoshi did not invent it. Lamport laid down much of the theory for FT and BFT consensus in 1982. What Bitcoin brought forward, in addition to BFT-ish consensus, was Sybil tolerance (addressing attack-of-the-clones).

Third, as for my understanding of AI: I've been doing it professionally since the late 90s; here are my publications: http://trent.st/publications. Doing AI in the 90s was one of the least popular things one could possibly do, so I certainly didn't do it for the hype.

> vaguely proposing using a blockchain as a mass datastore (with ownership labels)

Obviously I gave much more specific proposals than that. I have other writings that dive into more detail on some of the use cases, such as an IP registry [1] and for AI DAOs [2].

[1] https://medium.com/ipdb-blog/a-decentralized-content-registr... [2] https://medium.com/@trentmc0/ai-daos-and-three-paths-to-get-...

> First, you don't need an "altcoin" to have a blockchain.

Hmm, you're treading on thin ice here. What exactly do you mean by a "blockchain", then? I tend to work on the assumption that people are talking about something closer to the whole Satoshi consensus stack on top of hashed linked lists (the _actual_ blockchain), rather than just the hashed linked list data structure. Which segues into -- Satoshi consensus was designed against a stringent set of requirements, and the security model for the algorithm he devised absolutely demands a miner reward of some sort that's denominated in the same currency as that being used in transactions (in those circumstances, double spend attacks can be proved irrational once a transaction is deep enough inside the chain)

I'm not saying you're flat-out wrong, but you do need to specify which properties of Satoshi consensus you are willing to discard to make that statement true.

Throw a rock in the blockchain space and you'll find a different definition of blockchains, or what it means for one thing to be a blockchain or not. It doesn't really help anyone to argue for hours on end over this, when it's largely a matter of opinion. To me, what's more interesting is to identify what are the new characteristics (in terms of benefits) that blockchains have, above and beyond traditional distributed databases; which in turn unlock new applications or improve existing applications. To me, those characteristics are: decentralized, immutable, assets; I describe them in the article, and also in more detail in https://bigchaindb.com/whitepaper.

> To me, those characteristics are: decentralized, immutable, assets;

How do you achieve fully trustless decentralisation without the currency aspect, while still being resilient to sybil attacks? Or are you willing to sacrifice truslessness? In which case, how are you defining decentralisation?

I define "decentralized" as "no single entity owns or controls". It can be further distinguished with "server-based decentralization" and "server-free decentralization" [1].

You only need to be Sybil tolerant if you want your validating nodes to be anonymous. There's certainly some applications where that's useful. But it's not a requirement for being decentralized. (Some will argue otherwise, and that's ok; once again it depends how you define "decentralized"; my approach is about what benefits come to the application.)

[1] https://blog.bigchaindb.com/the-dcs-triangle-5ce0e9e0f1dc

Care to link to sources for server-based and server-free decentralisation that aren't your own blog posts?

(Also, that blog post you linked is flat out wrong -- Bitcoin, Ethereum, et al are all instances of eventually consistent systems that can and do prevent double spends)

Still -- if you're willing to sacrifice anonymity for the sake of avoiding sybil attacks, then how do your nodes federate without a central authority?

This is why having precise definitions matters: With each question I ask, we're eroding away the guarantees that such a system provides, and the implementation requirements with them. At what point do we just give up on "blockchains", and just adapt a run of the mill distributed log-based db instead, which gives you BFT and immutability, and where the asset layer is easy enough to add to the top?

Alternatively this is why definitions don't matter at all -- it only matters what guarantees (and other properties) a system provides, and not at all what we call it.

That's a fair point too.

I think we're in agreement, though: From the beginning, this discussion is about precisely that -- the word "decentralisation" usually entails a certain set of very specific properties so which properties, exactly, are we talking about here?

Ditto on agreement about what properties (including guarantees) a system provides.

To me, definitions are nonetheless useful to help summarize a set of properties, help communication, and more. Even if people have different definitions, the definitions typically have similar themes; they're not totally arbitrary. For example, with "decentralization" you'd find a lot of people agreeing that "no single entity owns or controls" within the same theme as other definitions.

Indeed.

> Care to link to sources for server-based and server-free decentralisation that aren't your own blog posts?

The best precedent is simply the long-standing difference between servers and clients in computing systems.

In blockchain discourse, this difference had not been acknowledged as much; though of course a similar pattern exists between full nodes vs light/SPV clients.

To my knowledge, no one else had made the clarification of "server-free" vs "server-less" as different types of decentralization. It is a useful distinction as the article discusses.

> Also, that blog post you linked is flat out wrong -- Bitcoin, Ethereum, et al are all instances of eventually consistent systems

As the article states, they can and do prevent double spends, so we agree there. But that's not what "consistent" means in a CAP setting. As the article states, "they they never have a deterministic guarantee of a consistent order; they’re only eventually consistent (in a probabilistic sense). But let’s be generous and call them consistent, because in practice they are used that way, the workaround being higher latency as one waits for a sufficiently high probability of avoiding inconsistency."

> how do your nodes federate without a central authority?

Each node votes on any transaction coming through. The transaction only clears if it gets enough positive votes.

> just adapt a run of the mill distributed log-based db instead ...

Well in some cases that's all that people actually need; sometimes find myself referring people to Kafka and the like.

But Kafka and the like are still controlled by a single admin; you can do more to decentralize. As for immutability, it's all shades of grey, and certainly being a log-based db (read-only) helps a lot. You can do more with Merkle DAGs, continuous backup to write-only media, etc.

To me it's not about "eroding" guarantees. It's about saying "ok, I have this database, what properties do I want?" The potential results might be blockchain-like or not. If decentralization, immutability, or assets are potentially interesting, then a blockchain technology could be interesting. Otherwise it comes down to other questions to choose among traditional DBs.

> As the article states, they can and do prevent double spends, so we agree there. But that's not what "consistent" means in a CAP setting.

You're the one who asserted that CAP-style consistency is required to prevent double-spends. Eventual consistency is a weakened form of consistency in the CAP sense. Both Bitcoin and Ethereum have eventual consistency as much more than a "theoretical" concern. In your own words: "But let’s be generous and call them consistent, because in practice they are used that way, the workaround being higher latency as one waits for a sufficiently high probability of avoiding inconsistency." The only way this is true is if you accept latencies measured in hours. For real-world applications, you absolutely need to deal with the eventual consistency (and, in fact, I've written several applications that deal with precisely that).

> Each node votes on any transaction coming through. The transaction only clears if it gets enough positive votes.

I didn't ask how you establish consensus. I asked how the nodes federate -- if a node tries to peer with you, how do you decide whether or not to accept the node? You suggested anonymity is out the window, so who controls node identity?

> You're the one who asserted that CAP-style consistency is required to prevent double-spends

Could you point me to where? I like my thinking and expression to be consistent (pun intended:)

> I asked how the nodes federate .. who controls identity?

Each node has a list of the public keys of other nodes. There are various ways to handle key distribution, of course.

From the blog post you linked three comments up or so:

> Big “C” means all nodes see the same data at the same time. Being big-C consistent is a prerequisite to preventing double-spends, and therefore storing tokens of value. There are many models of consistency; we mean “consistent” in the same way that the CAP theorem does, except a little bit more loosely (for pragmatism). Little “c” means strong eventual consistency, such that when data gets merged there are no conflicts, but not consistent enough to prevent double spends.

> there are various ways to handle key distribution, of course

Right. Having the public keys advances the discussion precisely nothing, because public key auth is pretty much a given if we're talking about the servers identifying themselves.

What tells us if we have a decentralised system with no central authority is: who's the gatekeeper? Who controls key distribution, and which keys are accepted into the pool?

> Throw a rock in the blockchain space and you'll find a different definition of blockchains, or what it means for one thing to be a blockchain or not. It doesn't really help anyone to argue for hours on end over this, when it's largely a matter of opinion.

It is true that "blockchain" is increasingly a literally meaningless marketing buzzword (e.g. R3 Corda, a "blockchain" product that brags of not actually containing a blockchain). However, this doesn't really help convince.

> increasingly a literally meaningless marketing buzzword Agree, "blockchain" is getting more diluted.

To me, it still has enough information content to be useful. Just because different people have different definitions doesn't mean the information content is zero. People may agree on the broad ideas and disagree about the specifics. And as discussed in another comment, definitions are nonetheless useful to help summarize a set of properties, help communication, and more.

For example, I think most people would agree a blockchain needs to have the property of having a consensus mechanism. Versus say a file system which typically doesn't.

Right. So what about your system is "blockchain" that, say, rsynced git repos (Merkle trees! Globally-identified hashes!) wouldn't be by that definition?

IPFS is very close to what you describe (Merkle trees! Globally-identified hashes!) but it doesn't claim to be a blockchain because it doesn't have a consensus mechanism, let alone a way to prevent double spends.

And that's ok! It's designed for different problems, like file system style blob storage. It's not about "whether something is a blockchain", it's about "what's the right tool for the job"? I see value in complementary decentralized pieces of file systems, databases, processing, and more.

IPFS is very close to BitTorrent entirely using magnet: links, which does indeed have something close to a consensus mechanism (everything is checksummed to the hilt).

> It's not about "whether something is a blockchain"

It arguably is when you call your post "Blockchains for Artificial Intelligence".

> have something close to a consensus mechanism

For this context it's really about whether or not it can prevent double spends. Currently, it can't. Though its protocol stack has a place for consensus algorithms to achieve CAP-style strong consistency; and the IPFS team is working on consistency algorithms.

> It arguably is when ...

Point taken. The post is about things that many people consider to be blockchains or at least blockchain-like; BigchainDB, Ethereum, and others are in that category.

>Disagree. First, you don't need an "altcoin" to have a blockchain.

In a public permissionless blockchain the token is a system-native item of value used to compensate miners/stakers/validators for securing the system. If you remove it from the architecture then you need a compelling answer to the question, how is the system secured? I haven't heard such an answer yet, though it may be out there and I just haven't come across it yet. Have you?

Essentially what I'm looking for is an explanation of a tokenless security-model in similar depth as this explanation of Bitcoin's security model:

http://www.coindesk.com/bitcoins-security-model-deep-dive/

Haven't seen that yet.

To me, incentives can be intrinsic (built into the system) or extrinsic (outside the system). Each has pros and cons. Bitcoin is intrinsic, based on mining reward and tx fees. Traditional private blockchains are extrinsic, where the folks running the network are incentivized to pay for hardware based on cost savings, higher profits, etc, ie something extrinsic to the network itself. IPDB is also extrinsic where the folks running the network participate because they care about the future decentralized internet, and their costs of running a node are covered by SaaS-style transaction fees.

> Agreed; very little is truly absolutely immutable

Dissonance leads to conflicted statements. Parsing conflicted statements often leads to dissonance. Tread carefully.

The only absolute truth is that I exist. That fact, while I'm observing it, is immutable. The cost of this immutability is my life, or my life's suffering in aggregate. The fact my life will end at some point means that, when viewed in aggregate, all existences are mutable at some point.

Which means that nothing is permanent, which means your statement is in conflict. Conflicted statements may be parsed and proved wrong. It is my opinion your thoughts here are valuable and should not be proved wrong until explored fully.

As long as the cost of changing the blockchain is higher than the return on changing it, the chain remains immutable. It may turn mutable someday, but that doesn't mean it's not immutable right now. Anyone arguing contrary to these evident facts is practicing/exploiting inefficiencies in the system.

>As long as the cost of changing the blockchain is higher than the return on changing it, the chain remains immutable

I'm sorry, but that is not a logically correct statement; it's a statement of rational behaviour - I give you that, but there is no bar to an irrational actor altering the blockchain purely out of spite or caprice - possibly incurring mortal harm in the process.

>It may turn mutable someday, but that doesn't mean it's not immutable right now.

Again - this is not a logically correct statement.

canbemutaable(blockchain) -> immutableNow(blochain)

how so?

>Anyone arguing contrary to these evident facts is practicing/exploiting inefficiencies in the system.

Can you explain what "practicing/exploiting inefficiencies in the system" is and why it's wrong?

> > As long as the cost of changing the blockchain is higher than the return on changing it, the chain remains immutable > I'm sorry, but that is not a logically correct statement

I'd love to see a logical argument presenting how a hypothetical irrational actor can alter a blockchain of significant value without either a hypothetical attack vector or a few billion years compute time.

Well, what about collusion of the mining pools in China?

"China" is an aggregate of consensus and cannot act "alone" as an irrational actor. If they colluded to change a transaction, there would be a net split and everyone would know. Again, I'm standing by the cost analysis of acting as an irrational actor indicating those actors will not act unless the aggregate itself is irrational, which is a rare and separate issue as that being discussed.

Reply on news.ycombinator.com