Hacker News Reader

I would be curious to understand what problems these blockchains solve. Intuitively, they do not seem like obvious candidates for financial transactions.

1. They really shine in a p2p architecture where no party trusts each other. But that's not how the financial system works. Banks trust central banks, exchanges and clearing houses, and it is very much a club where players have to be vetted and monitored by a regulator, quite far from the open and wild nature of p2p systems.

2. Market participants need anonymity. Morgan Stanley might not know who hides behind the cryptographic key xxxxx until they do a trade with Goldman Sachs, see that trade appearing in the public ledger and then suddenly they see every single transaction Goldman has done since the dawn of times. Markets need anonymity otherwise market participants can arbitrage you based on what they know you need or plan to do. And the transparency of the public ledger is a fundamental problem.

3. Regulators need transparency. The regulators will need a centralised place where they can put a name against every transaction. That I would thought almost defeats the purpose of the ledger since a traditional transaction log will have to be maintained on the side. Now you have two ledgers.

I remember this excellent blog article explaining when blockchains are pointless and unless I missed something, financial transactions do not meet conditions 3 (Absence of Trust), 4 (Disintermediation).

http://www.multichain.com/blog/2015/11/avoiding-pointless-bl...

> I would be curious to understand what problems these blockchains solve.

Buzzword compliance. I predict you will see "Blockchain" products that contain transactions in a Merkle tree as the only technological link to actual blockchains. (R3 have one already, R3 Corda.)

I'd say there are a few ways to think about blockchain's utility in private contexts (public chains are pretty different because of their ability to allow for anonymous participation). The two best ones are the intra- and inter-organization use cases.

For intra-organization, one way to view private blockchains is to look back to the days of mainframes and the shift to databases. While you technically never need a DB and can get things done with code, DB's are incredibly useful as a general utility because of the baseline features you get by using one. Private blockchains are similar, in that they give you some new features (e.g. sharable DBs) and are much easier to build with as they raise the baseline on how bad a solution can be that is built with them.

While you can have a pretty messed up DB schema, bespoke mainframe solutions can be much worse. Private blockchains are like that (especially when they have smart contracts) -- sure you can really mess up the systems setup but issues that DB's can have like high availability and disaster recovery are 100% commoditized. Also, they demand a higher bar for authorization making them generally as more robust the most hardened DB by default.

That isn't to say that a private blockchain will replace the DB as blockchains can be wild overkill for many domains. A small company that needs a DB doesn't need a blockchain's feature set, but a large company that needs a globally distributed DB for holding a ledger (of anything) would be well served by one. When you're working with a system that by default is BFT, incredibly paranoid about authorization, perfectly replicated and highly available then build a solution gets much easier.

As for the specific problem that they solve, it's the settlement problem: organizations currently hold internal ledgers of truth about what they own but they can't inherently trust other organizations' ledgers of truth about what they own, so we need 3rd parties to settle cross-ledger. Currently, institutions handle this role but private blockchains represent an algorithmic solution.

Kadena seems like a solid team, kudos for their work.

Smart contracts require you to work in a completely new language and toolset.

You don't need smart contracts to create a blockchain application, if you use the right libraries (e.g. go-merkle) and write your application to be deterministic. See Basecoin in the page below:

http://tendermint.com/ecosystem

If you want the benefits of Tendermint BFT consensus but w/ Ethereum's virtual machine, take a look at Ethermint.

http://github.com/tendermint/ethermint

Disclaimer: I'm a founder at Tendermint, the OG BFT blockchain engine. ;)

Smart contracts definitely have a tradeoff between new toolset/languages vs infrastructure level features. With smart contracts, anyone can write code for the chain vs the "write your application to be deterministic" approach where new code needs to be at a minimum vetted by some central org/group, though they're usually written by the vendor/provider/etc. Each has its strengths/use-cases. For inter-org I prefer the smart contract approach vs the intra-org can see the benefit of using regular code -- it's not like you're worried about malicious code in the intra-org case. I do think that smart contracts increase the utility overall (sorta like having SQL for a DB > not) and improve its reliability (accidentally non-deterministic code can be a bit worrying).

As for Tendermint BFT, it's one of the few that somehow I never got to dig into at JPM. Do you know if Tendermint BFT's performance & performance-vs-scale numbers are published? These are notoriously hard to come by and I'm always curious for more data-points on the matter.

If you want a deterministic smart contract language, you're better off avoiding the EVM, or worse, Solidity.

Tezos (plug, plug, I'm the lead on the project) has a VM with a full formal specification, and even a rudimentary embedding in Coq. It's statically typed and purely functional.

https://tezos.com/language.txt

We should plug Tendermint into Tezos as well.

My thinking for v2 is to use Honey Badger BFT, with multi party computation for bonding / unbonding

Overall I agree with Tendermint (and contra Casper or DFinity) that it's better to just drop availability and to have a less subjective security model. It sucks to get stuck if the validator set becomes compromised, but it's not the end of the world.

Whats the benefit of HB over Tendermint? There's a good reason we don't use threshold signatures... to guarantee accountability. We could add threshold signatures on top of Tendermint, but for most use cases this isn't very helpful (yet).

In any case, building on TMSP will make Texas future proof to any consensus engine that favors safety. Let's discuss.

Yes, getting accountability needs to be addressed, we're looking at several ways. Makes no sense to build on TMSP, governance that introspects over the consensus mechanism is a key feature. We aspire to be a utility, not a vassal.

Does anyone have a good solution for bugfixing and updating defective smart contracts yet, other than "fork the entire blockchain" Ethereum DAO passim?

If they are to be immutable then you're going to have to code to NASA standards.

You can implement a function that migrates all of the contract's assets and data to the new version. Obviously, you need to be careful about who can call this function, maybe requiring the agreement of all (or at least a majority) of stakeholders. Also, there is a risk of hitting the gas limit, preventing you from executing a "heavy" migration.

Pact[1], the language we've built, has the idea of an `admin keyset` that enables admins with the right number of signatures from the right number of keys to migrate contracts. Our approach is rather different from the EVM's as smart contracts interact with/guard a table in a DB (think stored procedures accessing a table) and the system has modules.

This way, if a bug is found, the admin can update the smart contract module guarding the DB table directly vs having to track down the on-chain contracts for migration (if it's even possible). From a normal user's pov, they don't see a difference (unless the admin decides to change the namespace or something).

It's a subtle but important difference. When someone using Pact sends the transaction `(payments.transfer "me" "you" <amt>)` the transaction (after doing a bunch of auth with ppk-sigs) looks up the `payments.transfer` command from the on-chain smart contract and executes it with the provided args. As such, the admin can update buggy contracts without issue (and roll-back, fix tables that have bad data).

[1]: http://kadena.io/pact/

If it's going to be a permissioned system anyway, wouldn't you get better performance from a non-blockchain solution?

The permissioned blockchains are being called "a horseless carriage with a horse" by Andreas Antonopoulos.

True.

I think that there is no way to compete against the speed and relative non-complexity you can get from "closed group, trusted 3rd party" solutions.

There is so much hype and confusion spread around the issue - as there are some genuine threats to some of the bread-and-butter services the banks do, like accounts and payments.

But to put it mildly, the bank executives are for the most time not really in the right career to sort out what's what, and due to the way the banks work, they are not likely to listen to the people that actually know how to do that until a lot of money is wasted and very little has been gained.

Maybe, our system gets 8k-12k transactions per second with full replication + crypto up to a few thousand consensus nodes (slows down around 4k nodes). That type of performance opens up a lot of potential applications.

As for "a horseless carriage with a horse" perhaps, we'll see. These systems do give you something that you can't get otherwise which is a distributed DB that you can share with competitors without worrying about them stealing from you/breaking it. Blockchain is to overloaded right now, but it's the name that has stuck likely because "a Byzantine-Fault-Tolerant Consensus database" (BFTCDB) is just too impenetrable. If one of these BFTCDB take off, if may not actually be a blockchain (though I suspect it will be because cryptographic data structures are just too useful for them) but I bet it will be called one.

But that the end of the day, that's what a permissioned blockchain is -- a DB you can share, which is a seriously new capability.

Why doesn't the financial industry consider a public blockchain?

How do big financial companies consider resolving adversity like judgments/liens/etc against an settlement based system that's an automaton?

the real answer is because they have a monopoly on clearance mechanisms in the status quo, and want to retain control over it.

Almost none of the use cases financial institutions look to blockchain to solve have anything to do with settlement or clearance.

Financial companies and banks already trust each other. It doesn't make sense for them to be held under public scrutiny with a public ledger. Therefore, blockchain is a solution without a problem for financial institutions. Their needs are already well met and there's little incentive to change. It worked for a 1000+ years why uproot everything for a buzzword ? Of course they aren't going to change.

Actually modern finance has its roots in the coffee houses of London, circa 1650.

http://www.history.co.uk/study-topics/history-of-london/lond...

These were the meeting places in which the maritime insurance deals were made at a time of increasing maritime exploration by the British. These also evolved to be the places such materials were bought and sold - and in fact the trading pits were (and in some cases are) based on these gathering locations.

It's interesting to visit the London Metal Exchange which although computerised has the trader pit (complete with circular sofa) in which trades are still conducted between traders.

In an interesting turn of fate the very docks that the traders made possible subsequently collapsed with the introduction of container shipping and ships which were too large to navigate the Thames, and pushed shipping ports to the periphery of the country. In an ironic twist of fate these docks then became the Docklands and home to London's financial district.

Right up until Brexit, when the financial centre was destroyed by petty minded little England, ending four hundred years of global outlook for the sake of believing in lies.

> when the financial centre was destroyed by petty minded little England

Perhaps if the 'financial centre' were not so ... self-centered ...

Nice comment, right up until your final sentence, which just drips with bitterness.

If we do end up picking a path to brexit that fucks over the London financial sector, in hindsight his comment will probably look like merely an impassioned statement of fact.

I'm moderately hopeful than we won't, but, well, 2016 has been 2016 and I have a horrible feeling 2017 is going to go "Hey, 2016, hold my beer and watch this!"

I'm not sure accurate this is. Paper money and the first stock exchange came from Amsterdam. A lot of the words, like Bank (board where the money was counted, breaking the bank meant breaking the board), nostro Account, vostro Account came from Latin/Italian.

> Their needs are already well met and there's little incentive to change.

This is definitely not true. It takes some financial assets 3-5 days to settle after the initial transaction goes through, weaving its way through many database systems (some many decades old) and middlemen who each take a cut, e.g. clearing houses. Any established industry has lots of cruft that builds up.

For this reason Santander estimates that banks can save $15-20bn per year collectively by using blockchain technologies to make their infrastructure more efficient[1][2]

[1] http://www.coindesk.com/santander-blockchain-tech-can-save-b...

[2] http://santanderinnoventures.com/fintech2/

I agree that the current systems are very far from optimised. But what benefit does the blockchain per se give them, given they already trust all participants? It only seems to introduce unnecessary costs, such as mining, when compared to the alternatives.

> It only seems to introduce unnecessary costs, such as mining

Who says you need mining? There's different ways to achieve blockchain consensus, such as proof of stake or proof of existence, you don't need proof of work like Bitcoin uses. Since with a private banking settlement blockchain you know in advance who the players are (individually-invited banks) you can give them a percentage of the network and have each node verify the transactions across the network. You could even give nodes to regulators or consumer advocacy groups to achieve regulatory compliance or consumer oversight if required.

As for cost, you could technically run a PoS node with a raspberry pi, a large USB drive, a wifi connection, powered by a solar panel and an old car battery on the roof of a building. Proof of stake only needs minimal computing power and a persistent internet connection.

Seriously, a lot of the scorn heaped on blockchain technology is unwarranted. Yes, there's loads of hype and bullshit (we're going to get rid of nation states and fiat currency!!!1!), but no more than the internet in 1994 or during the dotcom boom. Yes, lots of crap ideas, but some gems too. It's too early to see what real impact it will have. Criticising current blockchain technology is like criticising early broadband or smartphones.

That 1-5 days to settle isn't due to slow and disconnected systems though, which is what many looking from a tech perspective believe. Most financial transactions are matched in settlement systems the same day they are traded. The 3-5 days is for prefunding of underlying accounts, tear ups and other asset class idiosyncratic reasons.

> Financial companies and banks already trust each other

They most definitely do not, 2008 took care of that.

> It doesn't make sense for them to be held under public scrutiny

That's a matter of debate. The banks are held to, more or less, realtime scrutiny by the regulators on behalf of the public. Actually making transactions truly public would have tricky client confidentiality issues. That's why the focus has been on settlement and clearing as that's potentially more tractable.

> Therefore, blockchain is a solution without a problem for financial institutions

Possibly. The idea of a single version of the truth is very appealing to banks as a huge amount of time and effort is expended on reconciling trades, settlements etc. Whether a global transaction ordering has a use is debatable. Things like proof of work even less so.

Bear in mind, as others have said, you can take some of the features that have been applied to blockchains and use them separately. It's not a one size fits all. However, if you take away enough stuff then you often find that other technologies could be more appropriate.

> Their needs are already well met and there's little incentive to change

Not at all. No-one's really happy with the status quo. The regulators want to be sure that the banks are well risk managed. Even further, they want semi-continuous proof that it's so. The banks need to satisfy the regulators and still make money. The banks are a long way from that today.

> why uproot everything for a buzzword

They may well not but you underestimate the ability of senior folk in big organisations to get distracted by the shiny, shiny. Banks are no exception, they are just as susceptible to fads as anyone.

On the positive side, they are surprisingly good at accepting experimental technology. They've been early adopters of relational DBs, XML, Java, Smalltalk, Haskell, OCaml, object DBs, FPGAs etc etc. Of course, they're also one of the biggest users of COBOL so it's swings and roundabouts.

Accounting, auditing and compliance are a massive cost for business globally. (Fines alone have cost banking $200 billion since 2009.) Blockchain accounting could help cut those costs. For example, instead of a company employing its own auditors to examine the books of its various units, all transactions could be logged on an internal blockchain, and recorded centrally. Likewise, external auditors or even regulators could inspect a corporation’s books in real time. Even the accounting firms that make their money from auditing see the value in the technology: “This solution could significantly reduce the reliance on auditors for testing financial transactions,” Matt Spoke http://qz.com/629662/the-unsexy-future-of-blockchain-is-acco...

Banks typically already have some sort of realtime risk management system. Goldman's SecDB is quite famous. Banks typically have whatever risk controls in place they want. Blockchains aren't going to provide any magic here. The fines banks have faced haven't come from the lack of a central repository of trades.

> Why doesn't the financial industry consider a public blockchain?

- Unnecessary uncertainty: public blockchains can fork (i.e. ethereum) or change (bitcoin block size debate, segwit, etc) unrelated to your needs.

- Dealing with forks, and various other behaviors adds lots of unnecessary complexity.

- Less secure since publicly open for anyone to attack.

- Constrained feature development that requires consideration of all actors.

- Slower and more expensive: public blockchains require world-leading mining power and lots of time (60+ mins, 6 confirmations) to remain secure from government-scale attacks.

- If proof of stake is used (untested), instead of proof of work, to mitigate the cost and time issues, then you introduce many unrelated actors influencing core aspects of your business.

I can't see why a private consortium of banks would replace their currently custom, private, controlled databases and code, with public ones.

> How do big financial companies consider resolving adversity like judgments/liens/etc against an settlement based system that's an automaton?

The system isn't an automation, there are still the same decisions being made, they are just being recorded in a smarter way that cuts out a lot of unnecessary verification/trust work. They still have relationships with each other, each other's identities, and legal agreements enforcing all their actions. If funds need to be returned, a new transaction is created to return them. Liens can be coded into assets for convenience, etc. Any automation they choose to add in smart-contract type things is optional, and can be done gradually.

Without all the public features, the core blockchain becomes very simple, basically a chronological db of signed transactions - but it still gets to keeep the sexy name.

> - Signed Transactions (TLS based authentication trades security & audibility for speed)

I think you meant "auditability".

How are "Signed Transactions" an upgrade from TLS 1.2? How is TLS trading security for speed?

I did, though I can't edit it now sadly. And it's not that TLS isn't secure but about what features TLS gives the system.

The gist of this is that TLS doesn't give one a durable/persistable form of security vs ppk-sig's ability to verify that x signed y at any time. TLS is much faster than verifying the sig with every transaction on every node but after, say, a cluster restart the question of "who sent x" is answered via consensus and not cryptography.

There are a couple other issues too. Using ppk-sigs means that the mail clerk and the CEO use different keys to sign transactions vs TLS where you'd either have a logical "from:" field or a different connection for different users. Both of the TLS solutions have rather obvious flaws. Finally, a TLS based approach puts an attacker 1 server away from impersonating, potentially, an entire organization because the system using TLS cares only that it came via the correct pipe.

Overall I'd describe systems using TLS as not being paranoid enough about who authored a transaction, as PBFT/SmartBFT are by default very trusting of a client's transactions vs Bitcoin's model where everything is to be questioned/require independently verifiable cryptographic proof. Hence the tradeoff.