[bmcusick]

Ugh. He completely misunderstands what PoW (or PoS) are for. The entire point of PoW is deciding between two valid & correct blockchain states.

Alice owns a bitcoin. Alice validly signs a transaction transferring that bitcoin to Bob. Alice also validly signs a transaction transferring that same bitcoin to Charles.

WHICH IS CORRECT? Neither is a forgery. Both signatures are valid. If Dave downloads the blockchain, or receives both transactions, he can't just look at them and determine one of them is fake. Neither is fake. He needs a way of arbitrating who actually has the bitcoin now - Bob or Charles.

PoW is that arbitration process. Dave looks at the competing blockchains (one with Bob having received it, and one with Charles having received it) and can trust that everyone in the world will respect the chain with greater PoW behind it.

Paul's system has no way of addressing this other than "trust the central authority to process transactions in the order they receive them". Thanks, pal, that's called e-cash, and was invented by David Chaum in 1983.

[3pt14159]

What I do not understand is why we couldn't build this onto a web of trust + proof of stake. It may require some more state during resolution, and might even require falling back to automatic service denial if there is a severe network interruption (say in the event of nuclear war), but I can't figure out why we couldn't have miners just sign a growing dag of transactions and once a subset of the dag is accepted by 51% of the stake that network can prune the excess data (all the signatures). Work timestamps into the signature process and pin the keys used to sign the dag as only those belonging outside the current resolution. If a key is used to sign a transaction that conflicts with it's own "Verified & Locked" signature then it's coins are burned, including for it's own transaction. So in your example, if Alice signs both transactions and she doesn't have the funds to fulfil both of them the transaction causes Alice to lose 100% of her money.

I'm sure there is a reason, and I vaguely recall some people talking about proof of stake a couple years ago, but I'm surprised we're still melting icecaps running ASICs out of China for new coins.

[bmcusick]

> I can't figure out why we couldn't have miners just sign a growing dag of transactions and once a subset of the dag is accepted by 51% of the stake that network can prune the excess data (all the signatures)

Because of Sybil attacks.

> So in your example, if Alice signs both transactions and she doesn't have the funds to fulfil both of them the transaction causes Alice to lose 100% of her money.

Remember, the goal isn't to punish Alice. She's losing 100% of the bitcoin no matter what happens. The goal is to assure Bob (or Charles) that the transaction they receive will be recognized as valid by the rest of the world.

If you're Bob, and you know that Alice can invalidate the transaction (e.g., burn the bitcoin you just received) by signing a second transaction in the future, why would you ever accept Bitcoin?

Don't punish Alice. Assure Bob.

[3pt14159]

Short of an adversary having greater than 50% of the coins I don’t really see how a sylbi attack is relevant.

As for Bob isn’t he assured once he sees inclusion of his transaction into the 51% signed dag? Also Alice’s punishment is only for double spending before inclusion into the dag. On second thought it should go to the miners, not just get zapped into the void.

[runeks]

> What I do not understand is why we couldn't build this onto a web of trust + proof of stake.

Because the incentives of nodes in a web of trust is not to tell the truth about how much money they have; their incentive is to prefer whichever chain says they have the most money.

With proof-of-stake, an arbitrary number of valid chains can be created from scratch in no time. How do we decide which is the right one? All nodes will prefer the chain that says they’re the richest, and the nodes that most efficiently can coordinate their lying will end up with all the money.

Proof-of-stake solves the wrong problem: the problem isn’t to decide who gets to extend the chain, the problem is deciding which chain to extend in the first place (there can be millions of valid PoS-chains).

[DigitalJack]

Hey said this about proof of work.. is it wrong? It sounded good to me, but I never got into blockchain stuff.

>What is proof-of-work? Proof-of-work is a system for establishing “decentralized consensus.”

Agreeing about the order of events is very difficult in computer networks, especially if you can’t trust the other computers involved. Unfortunately, it’s also very hard to establish trust in a global network which aims to provide open participation. So, we need a way to agree on the order of events without establishing trust.

Proof-of-work solves that problem by putting the network on a trustworthy clock. It’s a kind of computation which takes a predictable amount of time to run, and which can’t be forged by a bad actor.

With proof-of-work, you can have multiple computers make additions to a blockchain without having them trust each other. That’s decentralized consensus.

Decentralized consensus is intended to mean that one entity can’t control the blockchain network. Any newcomer can participate, and ownership is equally distributed among the participants.

[runeks]

> Proof-of-work solves that problem by putting the network on a trustworthy clock. It’s a kind of computation which takes a predictable amount of time to run, and which can’t be forged by a bad actor.

That’s not right. PoW takes a completely unpredictable amount of time. It’s not about a clock ticking, it’s about making the presence of two incompatible versions of history as expensive as possible, thus forcing the network into consensus.

[dozzie]

There's more wrong statements in the quote, like blockchain solving consensus (it's not, it's a document timestamping).

[wmf]

I think the point is that, hypothetically, some non-financial systems don't require ordering or conflict resolution and thus such systems don't need PoW.

[DINKDINK]

>hypothetically, some non-financial systems don't require ordering or conflict resolution and thus such systems don't need PoW.

If you don't need trustless time ordering of data, you don't need a blockchain. You just need... a database

[pfraze]

Actually I appreciate the defense, but that's not what I'm claiming. I'm claiming that decentralized consensus gives only a minor gain over a single node maintaining a well-monitored blockchain. Single nodes don't have the problems of uncertain ordering or conflict resolution because they can provide strict consensus.

[dozzie]

> I'm claiming that decentralized consensus gives only a minor gain over a single node maintaining a well-monitored blockchain.

Do you also claim that a one-way hash function only gives a minor gain over a B-tree? Because document timestamping and establishing consensus are different problems.

[pdkl95]

A proper hash function provides a lot more than a timestamp. A service with a B-tree (or other traditional database) can rewrite history. Even if have a copy of the db, it's difficult to prove that your version is the service rewrote their version.

If a service wrote all transactions into a log in a way that allows for easy verificatio9n of the validity (including order), and the parties using the service regularly check that log, those parties can demonstrate that the service is acting correctly.

Questions about transaction order and consensus are separate problems, which may not be necessary, depending on the nature of the service. The point, I believe, is that some problems only need some of the features usually associated with "blockchains". We are only beginning to find the interesting uses for Merkle trees, and thus shouldn't blindly use the current bitcoin-style design when the current problem could use something similar,

[dozzie]

> A proper hash function provides a lot more than a timestamp. A service [...] can rewrite history.

I think you should verse yourself in cryptography before any discussion about it, including talking about blockchain. You seem not to understand what cryptographic timestamp is and what purpose it serves. Wikipedia has a nice introductory article approachable by a layman under "trusted timestamping" title.

[pfraze]

> Paul's system has no way of addressing this other than "trust the central authority to process transactions in the order they receive them". Thanks, pal, that's called e-cash, and was invented by David Chaum in 1983.

Flatly wrong. Decentralized consensus is not a necessity to create trustless operation. Monitoring service operation via a secure ledger provides trustless operation. As I said, the point of PoW is to provide strict transactional consistency in a decentralized network. You're just describing that process mechanically.

[bmcusick]

Hi Paul. I'm Brock.

I hope we're not talking at past each other, but I read your post as proposing a system where there's a central party that computes transactions "in the open" in a way that third party observers can verify.

That's hardly useless, but it's not a replacement for Proof of Work. PoW is for decentralizing the ability to choose between competing valid blockchains. It prevents double-spending by making the benefit of double-spending (the value of the your transaction) far less than the cost of double-spending (the electrical cost of 51% of the mining power for 1 hour or so).

Your system uses a centralized host (see "Services with Secure Ledgers", paragraph 2), and (I presume) third-party observers can verify a "secure ledger" by seeing which one has been more recently signed and time-stamped by the single host.

I mean, sure, centrally hosted servers are more efficient than Proof of Work. No one who know what they're talking about disputes that. But the whole point of PoW is to allow decentralization without a single host.

[pfraze]

Hey Brock.

My argument is that decentralized consensus is actually a political solution. It has technical merits -- it makes it easier to deal with a host that breaks the contract, because there are lots of nodes, so you just 'route around' the faulty host's output. But that's a technical solution to a political problem: how do you deal with a bad actor. And we deal with that every day with existing services, by switching away from bad actors. You handle bad behavior politically. If we can lower the cost of a switching, and we can build accountability into the system, then we're getting the same kind of value that decentralized consensus provides at substantially lower system cost.

[bmcusick]

How do you "switch" from a global shared ledger that everyone uses to a shared ledger that no one uses? I mean, you an, you can fork Bitcoin and start your own, but what does that get you? No one else will use your coin. There will be no market for it and it will have no value.

I mean if you're REALLY lucky you'll start something that's as popular as Litecoin and it will be worth 1% of what your Bitcoins were worth.

Bitcoins are only worth anything because you can go anywhere in the world and people will accept that there is one and only one blockchain, and if you own bitcoins on that blockchain then you own them, period.

Proof of Work allows you to solve bad actors without switching away to a new network and losing all your Bitcoins. Your solution doesn't. If you have a centralized system that centralized party could refuse to honor your bitcoin holdings and wipe out your balance.

This really isn't a new solution. I was serious before when I said David Chaum's ecash (from 25 years ago) was an approximation of this .

[pfraze]

I think you're right that handling catastrophic failure is the key question for a hosted ledger. You have to find a way for the network to agree on who will rehydrate the balances, so to speak, into a replacement host, and you need to do it quickly. The whole network has to agree on this.

This isn't impossible to solve. You can establish, in the ledger itself, the process for migration after a catastrophic failure. You can set a party which will mediate the issue and decide on the solution. You set up rules for how to reconfigure the network, and trigger them when a corruption proof is published.

I agree it's less elegant than what decentralized consensus provides for handling bad nodes, but you really have to balance this against the expenditure of proof-of-work. The cost of a handling every ledger failure ever will almost certainly be less than the cost of proof-of-work.

Part of my point is also that it's a gamble, which I find questionable, that Bitcoin will become "the blockchain" in the future, because it still has a political reality, and that political reality has involved plenty of forks. So, my point is, between the cost and the political instability, PoW doesn't sustain it's claim.

[cat199]

the post is talking about using blockchains as a systems tool to build a distributed ledger, not how to create a new cool crypto currency that will be more 31337 than bitcoin.

[runeks]

> It has technical merits -- it makes it easier to deal with a host that breaks the contract, because there are lots of nodes, so you just 'route around' the faulty host's output

How do you decide whether a host is faulty unless there’s consensus on what constitutes non-faulty? And how do you reach this agreement in a distributed manner without distributed consensus?

You can’t switch away from a bad actor in a decentralized system unless you have a decentralized way to establish who’s a bad actor.

[wyldfire]

The function of mining is not limited to the PoW, it's also an arbitration mechanism for decentralized minting/scheduled inflation.

The block reward incentivizes participants. Why should I run a monitor node for this new cryptocoin? Who will allocate the coins and how?

> Am I certain that I need strict global consensus?

Perhaps not but IMO it makes things much simpler to design as a result.

[rocqua]

There is value in a blockchain beyond a ledger of currency, and some of that value still remains when using a centralized service.

Specifically, if you want to offer a service where you can guarantee non-repudiation a centralized blockchain is a great solution. By non-repudiation, in the scenario of a double-spend whomever signed both transactions is 'on the hook' for both. This doesn't work for currency but works for systems where it is sufficient to prove your servicer screwed you over.

[runeks]

Where does the blockchain come in? As long as you have a signature from the central authority over two conflicting transactions, you can prove it has defrauded you.

Blockchains specifically solve decentralized consensus. It’s expensive and slow compared to using a central authority, but the advantage is that the system doesn’t suffer from a central point of failure.

[dozzie]

> Blockchains specifically solve decentralized consensus.

Wrong. Blockchains specifically timestamp documents. Consensus is a different problem and blockchains don't even touch that.