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

AWS and Blockchain

tbray.org

Post reply on HN
Print view View original

291–300 of 724 posts

Re: AWS and Blockchain

#291

Post by legutierr »

dmitriid wrote: post #278
legutierr wrote: post #72

Earlier quoted context omitted.

I don't disagree with you. My point is that blockchains can reduce the cost and complexity of enforcing property rights and adjudicating contractual disputes to a meaningful extent such that many of the institutional deficiencies that exist in the developing world in this regard can be overcome. You couldn't realize such a reform, however, without buy-in from the government itself.

> can reduce the cost and complexity of enforcing property rights and adjudicating contractual disputes to a meaningful extent No, they can't. A blockchain is, at best, a database. A database cannot do anything.

So you would assert that the use of centralized relational databases would would not reduce the cost and complexity of enforcing property rights, in comparison to the use of paper records? A database cannot do anything?

Re: AWS and Blockchain

#292

Post by RandomLensman »

TimJRobinson wrote: post #268
runeks wrote: post #167

Blockchain was invented to solve one particular problem: distributed consensus on a sequence of transactions, where the choice of which transaction to include from a set of conflicting transactions is irrelevant. The latter property here is key to understanding where blockchain is useful. It was created to solve the "double spend problem", ie. two transitions that spend the same coin but send it to different recipien…

I used to think this, but working with DeFi on Ethereum for a while I've realized the killer feature is actually permissionless composability. Which is why enterprise block chains make little sense. Having one neutral platform, controlled by no one, with standardized API's and immutable open programs that anyone can permissionlessly build on - is amazing. We've never had this before, and it's incredible how fast the…

My best guess is that unless the rules around large-scale finance change, in the end permissionless composability will go away and the platforms will get controls of some sort, e.g, who can do what, reporting requirements, KYC, ... And that also does not have to come just from direct rules, but could come via capital requirements when touching such systems or users of such systems.

Re: AWS and Blockchain

#293

Post by djbebs »

dtoma wrote: post #289
TimJRobinson wrote: post #268

Earlier quoted context omitted.

I used to think this, but working with DeFi on Ethereum for a while I've realized the killer feature is actually permissionless composability. Which is why enterprise block chains make little sense. Having one neutral platform, controlled by no one, with standardized API's and immutable open programs that anyone can permissionlessly build on - is amazing. We've never had this before, and it's incredible how fast the…

> Having one neutral platform, controlled by no one, with standardized API's and immutable open programs that anyone can permissionlessly build on - is amazing. Isn't that also an open door to bad actors?

Define bad actor.

Re: AWS and Blockchain

#294

Post by mhluongo »

dtoma wrote: post #289
TimJRobinson wrote: post #268

Earlier quoted context omitted.

I used to think this, but working with DeFi on Ethereum for a while I've realized the killer feature is actually permissionless composability. Which is why enterprise block chains make little sense. Having one neutral platform, controlled by no one, with standardized API's and immutable open programs that anyone can permissionlessly build on - is amazing. We've never had this before, and it's incredible how fast the…

> Having one neutral platform, controlled by no one, with standardized API's and immutable open programs that anyone can permissionlessly build on - is amazing. Isn't that also an open door to bad actors?

Freedom always is.

Re: AWS and Blockchain

#295

Post by constantcrying »

onetrickwolf wrote: post #280
runeks wrote: post #167

Blockchain was invented to solve one particular problem: distributed consensus on a sequence of transactions, where the choice of which transaction to include from a set of conflicting transactions is irrelevant. The latter property here is key to understanding where blockchain is useful. It was created to solve the "double spend problem", ie. two transitions that spend the same coin but send it to different recipien…

A reason I have been interested in blockchain is that it seems like a good way to make a decentralized application that could exist beyond the life of the company or person that creates it. I work in a hobby industry where a lot of community run ledgers are suddenly lost forever due to the death of someone in the fandom (or rarely intentional sabotage or hacking). Would this be a good use for blockchain or are there…

A blockchain requires significant, persistent and consistent community effort.

If you can not have one guy taking up the mantle and doing the hosting, how can you get hundreds to do the same?

>A reason I have been interested in blockchain is that it seems like a good way to make a decentralized application that could exist beyond the life of the company or person that creates it.

Community run projects have existed for decades on the internet. They never needed a blockchain to persist. If they died, they died due to lack of interest and effort by their communities. A blockchain can not prevent that.

>maybe other solutions I'm not considering or aware of? IPFS potentially.

Re: AWS and Blockchain

#296

Post by piaste »

mike_hearn wrote: post #222
jacknews wrote: post #141

I think the cost of trust is underestimated. All those shiny skyscrapers that the banks build? It's for trust, along with a good deal of banking licensing requirements and regulation. The example with the farmers' fields is quite valid. We forget in our relatively well-governed western nations that some governments really can't be trusted to simply keep records straight and not 'lose' vital documents, in cases where…

You actually know something about the finance industry, not sure this is the thread for you ;) You're absolutely right about the core problem. I worked for several years on an 'enterprise blockchain' system. We often called it distributed ledger technology because our platform didn't actually use chains of blocks or proof of work, and it didn't have a token or anything like that. It was essentially a type of database…

Haha, this beginning was eerie to read:

> We often called it distributed ledger technology because our platform didn't actually use chains of blocks or proof of work, and it didn't have a token or anything like that. It was essentially a type of database but it had a lot of ideas from Bitcoin in it and was blockchainy enough that customers accepted it as such.

because it was actually how I selected Corda as the infrastructure for a project a few years ago. The customers and managers wanted Blockchain®, and I wanted to deliver something that actually added some kind of value, and I found Corda which - as I told my CEO - was "close enough to a blockchain that our marketing splash wasn't lying".

(Whereas to my fellow devs, I said more or less "look, it's Spring Boot with a replicated event-sourced database and a funny CLI admin panel")

Unfortunately the project never got past the test stage because - this is gonna shock you - the very first, extremely basic smart contract we encoded in Corda was immediately violated by the customer's processes, and they absolutely refused to change.

Still, I want to thank you because your platform enabled me to retain my dignity without pissing off my boss for a half year or so.

Re: AWS and Blockchain

#297

Post by mhluongo »

nosianu wrote: post #248
netfortius wrote: post #242

Earlier quoted context omitted.

I am sorry, but I think I am missing something here: isn't the "double spend problem" actually needing to be resolved by the choice of including one specific transaction (and no others), from a set of conflicting ones, truly relevant (vs. irrelevant)?

The point is that it does not matter which one is included, only that it's only one of the choices that all agree on. Which one that is is not relevant, there is no part of the algorithm that determines one transaction to be "more valid" than another one. There is no ranking of transactions, one of them has to be picked but which one it is can be random, as long as there is agreement. Also see the response from and s…

There are certainly tx validity rules, though, and when presented with a set of equally valid txs, miners will likely choose the one that is best for them (called "MEV", miner extractable value).

Re: AWS and Blockchain

#298

Post by TimJRobinson »

dtoma wrote: post #289
TimJRobinson wrote: post #268

Earlier quoted context omitted.

I used to think this, but working with DeFi on Ethereum for a while I've realized the killer feature is actually permissionless composability. Which is why enterprise block chains make little sense. Having one neutral platform, controlled by no one, with standardized API's and immutable open programs that anyone can permissionlessly build on - is amazing. We've never had this before, and it's incredible how fast the…

> Having one neutral platform, controlled by no one, with standardized API's and immutable open programs that anyone can permissionlessly build on - is amazing. Isn't that also an open door to bad actors?

For sure, it's the same principles as the internet, and that unfortunately is why there are so many bad actors in the space.

There are companies and technologies being created to mitigate them just like how the internet spawned anti-(virus/spam/malware) companies. On the early internet with ActiveX, Flash, and few firewalls it was so easy to get exploited and this is the phase of DeFi we're in now, but it will get better over time.

Re: AWS and Blockchain

#299

Post by inkyoto »

function_seven wrote: post #234
v-erne wrote: post #195

Earlier quoted context omitted.

>>It turns out that append-only databases are well-suited for HR records It may seem so, bu then You find out what are Your governments limit's for storing workers data, and Your company lawyers forces You to make it possible to delete everything that past that limit to limit legal risk and be gdpr compliant. And at this moment You find out that world is not constant and far from Your ideal model of spherical cow.

Can we design an append-only database that also allows for deletions if you replace those deletions with a direct reference to the hash that was once computed at that point in the chain? Yes, I know this isn’t strictly “append only”, but it still gives the ability to prevent silent updates and silent deletes. Any record that’s deleted must be replaced with something that indicates that it was deleted.

Such a database already exists, and it is called AWS QLDB.

Deleting a document revision in QLDB does not actually delete it, but rather moves the last known revision into a shadow history table that accompanies every table in QLDB. The full document change history lookup has to accommodate in the code path a fallback to the history table when a document revision can't be located in the main data entity table. If no document revision exists in either table, it has never existed in the database.

Re: AWS and Blockchain

#300

Post by FabHK »

Nursie wrote: post #267
paulgb wrote: post #250

Earlier quoted context omitted.

Yes, a specific transaction needs to be chosen as the consensus transaction. But if there are multiple to choose from (e.g. in the case of an attempted double spend), the miner can choose either one. The blockchain doesn’t guarantee, for example, that the transaction which appeared earlier will always be chosen (in practice, it’s likely the one with the highest transaction fee)

IIRC there were some hacks on bitcoin ATMs using this sort of knowledge. The attacker would set up a withdrawal of (IIRC) CAD on the ATM, then transfer the bitcoin. The ATM would see the transaction, and dispense the cash. However the attacker would immediately, before the next block was generated, send the same BTC to another address which they controlled, with a higher fee. The miner would discard the first one and…

ATMs would dispense actual cash when a transaction enters the mempool without waiting for (say) 6 confirmations? That seems like a pretty egregious design choice even a decade ago. If that story is true, the ATM designers merited the loss.
Post reply on HN