Live data from Hacker News

Building for the Blockchain

blog.ycombinator.com

121–130 of 337 posts

Re: Building for the Blockchain

#121
post #68

Naval does a much better job of explaining what the tech is about : https://startupboy.com/2014/04/01/the-fifth-protocol/ However, OP nor Naval, really understand the protocol, or wouldn't be supporting non-blockchain things like ethereum (there is nothing that you can do with ethereum but not with git). >One of these developers, Vitalik Buterin, was frustrated by Bitcoin’s immobilism I am amazed at how HN is selling…

Bitcoin is slow as hell. So you can do an order of magnitude more with Ethereum than Bitcoin.

Technically, decentralized system will be always slower than centralized one. Its a good thing its slow. 1 hour blocks are even safer (and effectively we do convert blocktime to an hour by waiting for 6 confirmations).

So no, you can't "do" more, only be more noisy.

Re: Building for the Blockchain

#123
post #112
post #65

Earlier quoted context omitted.

Does your problem gets easier/solved with a permissionless ownerless database, if "yes" then you need a public blockchain, if "no" you need something else.

If "yes", then you still don't need blockchain . There are better protocols, like DHT. The only time you need blockchain is when you need to tell which of the two related statements was issued earlier and at the same time you absolutely have to have no trusted third party that assigns timestamps to the statements.

There's another aspect, unforgeability. The interesting thing about the blockchain is that it is a very hard to forge data-set, by design. You can take a proof of work blockchain and look at the hashes of the blocks in it, and based on the number of 0's in each block (the difficulty), you can know how much energy (and cost) went into mining that block.

So if there's a danger of forgery, or you have an interest in security, a blockchain with proof of work provides a really trustworthy way to know you're getting authentic data, because you can look at the chain, and know things like it would cost about 100,000,000 to forge this full history, and 1,000,000 to forge to last block.

Re: Building for the Blockchain

#124
post #78

Monegro believes that this paradigm shift affects the way that developers should think about their applications: “The combination of shared open data with an incentive system that prevents “winner-take-all” markets changes the game at the application layer and creates an entire new category of companies with fundamentally different business models at the protocol layer.” Ok, thin protocols + fat apps --> fat protocol…

It solves some problems, especially when it comes to networks of shared information where no one actor trust any other single actor.

But as usual, as soon as a lot of money is to be made, non-techies get dollar signs in their eyes and --without understanding the tool-- jump in and start using it for everything.

It will be very amusing to watch, for sure.

Re: Building for the Blockchain

#125
post #83
post #63

It's all the same thing every year on HN. People trying to find all sorts of excuses for Bitcoin existence - blockchains, smart contracts, ICOs - as long as they don't have to accept that Bitcoin's main purpose is and always was to have an alternative to the financial system, crippling regulations, government control and taxes. In other words, everything people hate about libertarians, they try to ignore in Bitcoin.…

I agree. "Bitcoin as anarcho-capitalist proof of concept" does seem to be the correct framework for understanding why it exists, why it works the way it does, and what one might find valuable about it. On that front it's been at least a partial success. I can't buy a cup of coffee with Bitcoin, and I doubt I ever will, but the fact that it works at all is a lot more than I suspected we would see at this point. It's d…

Tracking ownership of some intangible set of rights is actually basically the one thing that BTC/ETH-esque tech is really useful for, so the Kodak thing is far from the craziest coin announced. A sane thing to do would be to piggyback on one the existing blockhains and their pre-existing hashing power. In this scenario, Kodak would create some kind colored-coin or side chain representing ownership of certain photographs and take a cut as basically a notary, providing easy tools to store a [ image_hash, owner_id ] tuple on the blockchain for posterity. This has the advantage of /continuing to exist if Kodak goes away/, which is what you want as a rights holder.

Trouble with that, is that then Kodak doesn't get to issue its own token, and therefore doesn't get to indulge in securities manipulation. It also means they can open themselves up to competition on ease-of-use, since now anybody can run a company doing the same thing.

There is also the VERY BIG question of whether or not such a distributed ledger would ever be accepted in a court as proof of ownership of rights to those photos. If it can't be, there's no point in any of it.

Re: Building for the Blockchain

#126

Earlier quoted context omitted.

> I don't understand the common sentiment on HN that "you don't need a blockchain, just an append-only decentralized database with Merkel root logs", as if that's something easy to build. In my case, this sentiment accompanies an implementation in the form of an easily-deployable open source microservice. https://github.com/paragonie/chronicle If it's too hard for people to build, they can use what I wrote. > What is…

This sounds a lot like ripple: ... Are people still fighting about this or have they come to a consensus? I'm probably the worst person to represent whether there's a consensus or not since I'm one of the designers of Ripple. But the important thing, at least in my opinion, is that there is no "secret sauce". The software is open source. People are free to modify it however they please. We run the exact same software…

> This sounds a lot like ripple:

It's way more like Certificate Transparency than Ripple. Chronicle has nothing to do with payments or currency. It's just a ledger.

Re: Building for the Blockchain

#127
post #3

> For one, Ethereum is unable to access real time data from outside the blockchain. Developers need to rely on trusted third party data providers, called oracles, to provide smart contracts with outside information like weather, random numbers, or currency values. I feel like this is more of a feature than a bug. If you're weaving applications into the blockchain, would it really be wise to have that chain communicat…

> Developers need to rely on trusted third party data providers, called oracles

It's ironic that they mention Augur by name in the article, but are apparently unaware its main innovation is the decentralized oracle that just so happens to have a prediction market built on top of it.

> I feel like this is more of a feature than a bug.

That is indeed 100% by design. All smart contract code in Ethereum has to be deterministic to guarantee computational consensus, and of course this can only be done by having a closed EVM.

Re: Building for the Blockchain

#128
post #78

Monegro believes that this paradigm shift affects the way that developers should think about their applications: “The combination of shared open data with an incentive system that prevents “winner-take-all” markets changes the game at the application layer and creates an entire new category of companies with fundamentally different business models at the protocol layer.” Ok, thin protocols + fat apps --> fat protocol…

You’re seeing everything just fine. Imagine you’ve spent your whole life investing millions of dollars in entrepreneurs. Building models and testing hypotheses with no real agency: you can’t control what the CEO does or the product the engineering team builds or the way they market the product. Your job is to provide returns for your LPs. That’s it. Now imagine, instead of spending thousands of hours interacting with…

I can think of one scenario where being public and 100.0% reliable has meaning.

The scenario where accountants and human intervention are the thing you want to be rid of.

Financial transactions. Before someone just points out those are just more tokens and that we're all betting on their value, etc., etc., I'm deliberately skipping the meta-argument.

The point is that finance systems do exist, already, and adding a trusted distributed transaction ledger does add value.

Re: Building for the Blockchain

#129

People are trying to solve a lot of interesting problems with blockchain, but I fear it's become the ultimate shoehorn solution for the modern era. See also: https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoc... I've had meetings with prospective clients that opened with, "We have $problem, can we use blockchain to solve it?" where anything that doesn't qualify as a blockchain is cast to the wayside because…

How the DDOS problem is solved there?

Re: Building for the Blockchain

#130

Earlier quoted context omitted.

Here's some good background on ChainLink: https://medium.com/@signal_capital/https-medium-com-signal-c...

Reading up on ChainLink: > Several data providers respond to this service agreement with a bid in the form of a data reply — when enough data providers have responded, the majority response is taken (or average depending on the request), outliers are removed, and data is fed into the contract. What's to stop me from setting up 10,000 different data providers that initially provide good data to get a good reputation s…

Bingo. Most cryptocurrencies/contracts/anything in the field/realm -- they don't attack the problem of "person" vs address/wallet/account. ChainLink might think they are clever but like you said..when accounts in your network are free, then don't expect any kind of consensus to work. Accounts or rather, more abstractly, entry into your network -- needs to cost something that can't be easily done to gain majority. Another way to attack the issue is to do antes..so accounts dont cost anything unless the account holder is caught doing something bad -- ie. every entry requires a refundable collateral.
Post reply on HN