Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building for the Blockchain

blog.ycombinator.com

Post reply on HN
Print view View original

131–140 of 337 posts

Re: Building for the Blockchain

#131

Post by manderson2080 »

Jasper_ wrote: post #117
manderson2080 wrote: post #107

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…

There's a penalty payment that each node puts up into escrow for each assignment of data, and if the data is not accurate in relation to all the other providers of that same data, the node will lose the payment.

There will also likely be a small amount fo LINK required to start a node with enough reputation to gain assignments which would also increase the cost of a Sybil attack.

Re: Building for the Blockchain

#132

Post by joosters »

dahdum wrote: post #102
Jasper_ wrote: post #42

Earlier quoted context omitted.

What I don't understand is how Ethereum can describe their dapps as "trustless" when all the trust is still centralized in an oracle. This can even happen accidentally, such as with the Mayweather/McGregor smart contract breakage. [0] But now imagine if BoxRec had intentionally reported false results from their website in order to make a lot of money on the bet. People would lose their money, and there would be no re…

A lot of dapps don't need oracles to run. Anything that does is still more trustless than a centralized solution would be, reducing the counterparty risk to the oracle alone. As mentioned elsewhere, a lot of work is also being done on decentralizing the oracles. Like PoW / PoS protection, this raises the cost of an oracle attack high enough to reduce the risk to acceptable levels for more sensitive applications.

If your code doesn't reach out beyond the blockchain, then there's very little it can actually do. You are limited to twiddling balances of coins. This turns out to be great for making casinos and ponzi schemes, but little else.

To do anything more meaningful, code needs to interact with the real world. And this is generally the point at which blockchain apps lose all of their purported benefits, like decentralization, immutability, reliability and so on.

Re: Building for the Blockchain

#133

Post by indigochill »

keithwhor wrote: post #105
rsp1984 wrote: 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…

Thanks. This is probably the most coherent pitch I've seen for tokens (and also helps me understand a little better why certain people are so attracted to them). I was of the opinion they were a pure ponzi scheme, but this gives me a somewhat better balanced understanding of what actual expectations underpin the speculation.

Re: Building for the Blockchain

#134

Post by m3kw9 »

Inevitably because of the ICO component, there will be a lot of applications that tries to use block chain to search for a problem to solve more inefficiently than not using block chain. With the main idea so they can get the ICO to work for them.

Re: Building for the Blockchain

#135

Post by joosters »

ThomPete wrote: post #103
snitko wrote: 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.…

Personally I see a lot of different areas where the blockchain will be extremely useful. The reason I think that is very simple. The blockchain allows us to create scarcity in an otherwise abundant medium. This means that potentially (and yes it will take time) we will see be able to mimic the physical space and create items that are to some extent unique (even though the can be copied. The art market is based on exa…

But all your examples are possible (and have been successfully implemented) without a blockchain. So what does the chain add?

Besides which, when is turning abundance into scarcity a good thing?

Re: Building for the Blockchain

#136

Post by bambax »

CiPHPerCoder wrote: post #11

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…

[Question] What technology, based or not on blockchain, would enable an entity to write relatively large amounts of data in a "sustainable" way -- sustainable meaning, that the data is independent from whoever wrote it (can survive it)?

Writing data to the blockchain solves this problem, but the cost is large and performance is dismal.

Writing hashes to the blockchain at specified intervals, delivers proof of existence, at an acceptable cost and performance, but does not really make sure the data itself will survive its original author.

Is there another way? Can chronicle help?

Re: Building for the Blockchain

#137

Post by tonyjstark »

ericb wrote: post #123
dozzie wrote: post #112

Earlier quoted context omitted.

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 sec…

Only if the community does not decide to fork and everyone jumps to the fork like with The DAO. Then maybe you can look up everything in the old branch of your chain but nobody cares...

Re: Building for the Blockchain

#138

Post by joosters »

albertgoeswoof wrote: post #57
Jasper_ wrote: post #42

Earlier quoted context omitted.

What I don't understand is how Ethereum can describe their dapps as "trustless" when all the trust is still centralized in an oracle. This can even happen accidentally, such as with the Mayweather/McGregor smart contract breakage. [0] But now imagine if BoxRec had intentionally reported false results from their website in order to make a lot of money on the bet. People would lose their money, and there would be no re…

You can solve this by using multiple oracles and a stake-based consensus algorithm to de-incentivize malicious reporting.

Now you have lots of extra complexity and multiple points of failure instead of just one.

Re: Building for the Blockchain

#139

Post by eximius »

keithwhor wrote: post #105
rsp1984 wrote: 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 don't disagree with anything you said.

But, separately, if you asked me if I wanted to use something to store/transmit value that was only reliable 99.9999999% of the time, I would immediately say no. At Visa scale, that means 15 transactions a day are incorrect - not delayed, just straight up incorrect. Maybe that already happens and we just don't hear about it because they can fix it without any one noticing or it's just small enough to not be noticed. But it is still unnerving.

Re: Building for the Blockchain

#140

Post by cturner »

kang wrote: post #121
ShabbosGoy wrote: post #118

Earlier quoted context omitted.

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.

    > Technically, decentralized system will be
    > always slower than centralized one.
This is not a reasonable response to the parent: bitcoin is significantly slower than other systems of its class. Ethereum is an equivalent system and faster. (Others are much faster still)

There are application where speed matters. For example, to sort things out while all the lawyers are in a room.

Post reply on HN