Live data from Hacker News

Welcome to Web 3.0

welcome2web3.com

251–260 of 309 posts

Re: Welcome to Web 3.0

#251
post #240

Earlier quoted context omitted.

> More accurately, it could if it actually worked but since it doesn't all you're doing is paying more for lower quality of service. A key concept to understand is that when blockchain sales people say “no authority” they mean “except the miners, software developers, exchange and oracle operators, and the governments which have jurisdiction over them”. Critics like to say "it doesn't work", then the next day complain…

It worked as long as nobody was trying to go after it. That's been changing and as we've seen the parties involved have plenty of real-world presence which various authorities have been able to take advantage of. This is why the absolute claims about “free speech” are simply reflecting a deeper misunderstanding: it's true that nobody can stop you from making a Bitcoin transaction unless they block the protocol entire…

> It worked as long as nobody was trying to go after it. That's been changing

I see no evidence of this. Authorities have been going after crypto-currencies users very effectively ever since the early days of Bitcoin; from the first darknet market takedowns, to arresting people on LocalBitcoins because they didn't register as money transmitters.

It sounds like we agree on the limitations of a ledger, but saying it "doesn't work" simply because the physical world exists and governments can arrest you, attempt to track you, make rules for exchanges and merchants etc is nonsense. Of course they can.

They can equally block encrypted chat apps, VPNs, prevent device makers from allowing them onto the hardware, force backdoors, effectively threaten people who use them, or spy on your communications locally.

None of these things mean that encryption doesn't work, or that it isn't useful.

Re: Welcome to Web 3.0

#252
post #246

Earlier quoted context omitted.

Assuming you mean a Merkle tree (a Markov chain is a statistical concept). A Merkle tree provides an efficient way to compute hashes (not signatures) of data. It provides neither properties that you claim for Markov chains.

You're correct - Merkle tree. Words are hard some days. > A Merkle tree provides an efficient way to compute hashes (not signatures) A signature is a hash, in that it is effectively unique for the content. It simply has the additional property of being generated using cryptographic keys, proving that not only is the hashed content what's expected, it was generated using the specified key.

Signing and hashing are specific cryptographic operations with well defined properties. You can’t use them interchangeably if you want to be taken seriously.

Re: Welcome to Web 3.0

#253
post #16

This parody is quite funny, but it's actually a take on the micro-transaction model more than web3. Web3 sites could work exactly the same as web2 sites except for the bits people want to own themselves. I don't imagine many people care about owning a Like or a comment. What's perhaps even more fun to think about is that somewhere in a lofty corner office at Instagram there's someone with a math or compsci PhD doing…

The shift in incentives would encourage more transactions for the sake of monetisation.

Re: Welcome to Web 3.0

#254

Earlier quoted context omitted.

If I have an IP address I can host anything and anyone anywhere on the internet can access it right now. There's no company controlled centralized database I have to get permission from to host an apache server with cat photos for example. Isn't this problem already solved?

If you want to share control of that data with me—and say that the data represents something valuable (or is itself valuable somehow) and we don’t really trust each other not to tamper with it—then the classic “single server hosting data on the internet” doesn’t really do the trick. If the number of people needing to collaborate is arbitrarily large, and includes people who don’t know each other and don’t trust each…

Does that happen a lot?

Re: Welcome to Web 3.0

#255
post #231

Earlier quoted context omitted.

> Implementing the weapon. Implementing an in game item? That's already part of your game, right? > Paying for that implementation. You can buy an NFT entirely on chain, that's surely not in doubt. > Plus, implementing a "yes, person with email address N owns sword X" rest API is pretty straightforward. You could even implement public/private key signatures for authentication of the receipt. It just would be stored i…

> That's already part of your game, right? Nah, not for the usecase of moving items between games - one of the biggest features touted by NFT enthusiasts. But that aside... > get people to manage their own public/private keys For a receipt, the individual users don't need keys. For proof of ownership, that ship has already sailed off into the sea of fraud and pyramid schemes, and we don't expect to see it again. When…

> Nah, not for the usecase of moving items between games - one of the biggest features touted by NFT enthusiasts.

That's not what I've been talking about though.

> For a receipt, the individual users don't need keys. For proof of ownership, that ship has already sailed off into the sea of fraud and pyramid schemes, and we don't expect to see it again. When people are trying to sell NFTs of artwork to the original artist (aka blackmail), you know it's jumped all the sharks.

That wouldn't apply at all for an in game item. Do you understand that two NFTs pointing to the same url would still be entirely distinguishable?

> One, the existing and working infrastructure already exists. All the elements of a purchasing stream are implemented as libraries.

"There is a library" and "there is already running maintained infrastructure" is quite different.

> And it's not as if you can stop caring about how money flows, because there are laws that require you to do a lot of bookkeeping and pay taxes on that money (no matter the form the transaction initially took).

I would be involved in the initial sale, but no auctions/trades/secondary sales.

> And by using a blockchain as a database, I'm actually adding a lot of complexity to my system.

I've outlined the steps required and can't see what you think would add a lot of complexity.

> Why would the first party need to check an external database, when their game engines literally require them to implement it internally?

How are you managing trading items between users without some database external to either users machine - unless you're talking about an entire p2p db of ownership which sounds frankly even more complex.

You're jumping into a use case I've not posited and then bringing up things which don't seem to make sense (art NFTs created by random people).

I don't think this is very productive so I will just leave you with one thought:

Imagine you were already using the blockchain for this, and that was normal for games to do so. Now someone tells you that you could actually use these other libraries, and maintain your own database, and stop users from selling/trading however they wish but only through you, and you could build your own site for trading instead.

Would you say "Yes, that brings me the features I really need - I should change to this different architecture"?

Re: Welcome to Web 3.0

#256
post #252

Earlier quoted context omitted.

You're correct - Merkle tree. Words are hard some days. > A Merkle tree provides an efficient way to compute hashes (not signatures) A signature is a hash, in that it is effectively unique for the content. It simply has the additional property of being generated using cryptographic keys, proving that not only is the hashed content what's expected, it was generated using the specified key.

Signing and hashing are specific cryptographic operations with well defined properties. You can’t use them interchangeably if you want to be taken seriously.

A merkle tree that uses cryptographic signing instead of hashing is still a merkle tree.

Though if we really feel it's necessary, we could simply say "a merkle-tree like implementation that uses cryptographic signatures in place of a hash function".

Pedantry about the difference between hashes and signatures doesn't change the validity of the structure as a response to the original question.

Re: Welcome to Web 3.0

#257
If you're going to make a satirical website, make a satirical website. The author wants to make it so clear that they're not into Web 3 that the first thing you see is a standard-issue rant against it with all the usual talking points.

There's a lot to satirize about Web 3, but not a great implementation here.

Re: Welcome to Web 3.0

#258
post #255

Earlier quoted context omitted.

> That's already part of your game, right? Nah, not for the usecase of moving items between games - one of the biggest features touted by NFT enthusiasts. But that aside... > get people to manage their own public/private keys For a receipt, the individual users don't need keys. For proof of ownership, that ship has already sailed off into the sea of fraud and pyramid schemes, and we don't expect to see it again. When…

> Nah, not for the usecase of moving items between games - one of the biggest features touted by NFT enthusiasts. That's not what I've been talking about though. > For a receipt, the individual users don't need keys. For proof of ownership, that ship has already sailed off into the sea of fraud and pyramid schemes, and we don't expect to see it again. When people are trying to sell NFTs of artwork to the original art…

> Do you understand that two NFTs pointing to the same url would still be entirely distinguishable?

So is a cryptographically signed receipt. So is an internal database log. These are all that are required for the sale of items in videogames.

> "There is a library" and "there is already running maintained infrastructure" is quite different.

You'd still need a library (or a dozen libraries) to implement a NFT DB in your game. And probably some custom coding to wire it into your local DBs required for the game.

Also, RDS. And databases built into the game engines (such as Unreal, Lumberyard, Unity, et.al.). Running and maintained infrastructure already exists for databases.

> I would be involved in the initial sale, but no auctions/trades/secondary sales.

NFTs can be set up in a way when funnels a portion of future sales/trades back to the generating party. So yes, you most likely will be legally involved in the future sales, unless you explicitly opt out when creating NFTs (which doesn't make much sense, from a "we're doing this as part of our revenue generation" point of view.

> How are you managing trading items between users without some database external to either users machine

This must be done regardless. See previous comments about the NFT DB being too slow to act as the source of truth for videogames.

> Would you say "Yes, that brings me the features I really need - I should change to this different architecture"?

From a purely capitalistic point of view, definitely. It gives me more control over how my product is being used. Why would I want to allow people to trade cash shop items (based on your earlier comments, without letting me take a portion of those trades/sales) when I can make two sales instead?

It'd also save me the CS costs associated with anything that goes wrong with a NFT auction/trade/sale for items in my game. Because I know they're not going to blame OpenSea, they're going to blame me. How do I know this? Because players already blame the game provider for things like DDOS attacks and internet outages.

Corporations love control. Even today, they'll spend more money on infrastructure and development to maintain that control. You can see proof of this in the NFT space with how game companies are implementing their own private blockchains to do NFTs. No need for "what if" games.

Re: Welcome to Web 3.0

#259
post #252

Earlier quoted context omitted.

Signing and hashing are specific cryptographic operations with well defined properties. You can’t use them interchangeably if you want to be taken seriously.

A merkle tree that uses cryptographic signing instead of hashing is still a merkle tree. Though if we really feel it's necessary, we could simply say "a merkle-tree like implementation that uses cryptographic signatures in place of a hash function". Pedantry about the difference between hashes and signatures doesn't change the validity of the structure as a response to the original question.

I challenge you to build a Merkle tree using a digital signature scheme in place of a cryptographic hash function where a Merkle tree constructed by Alice can be used by Bob without revealing Alice’s secret key.

Re: Welcome to Web 3.0

#260
post #250
post #105

Earlier quoted context omitted.

There you go. Cryptocurrencies are here to stay no matter how much they hate it or continue to waste time on repeating the same old arguments even though there are far better cryptocurrencies out there that already exist. The fact that they are unable to ignore them and continue to spread the same debunked nonsense tells you that it is not going away and it is getting boring. Just look at the first few sentences: > a…

> The internet isn't new. Its 'killer app' (The world wide web) came decades afterwards and took decades more for adoption. The Internet started in the mid 1980s and became available to consumers in about '89[0]. The WWW was created in '90. By '94 it was wildly popular. Netscape IPOed the next year, with millions of users. Generously, you could call that about 5 years from public availability to cultural dominance. B…

The first version of the internet was called Arpanet and it was apparently released in 1969 according to Wikipedia. It only became widespread in its current incarnation much later. Moreover, there was an immense amount of hype around the internet during the 90s that culminated in the dotcom bubble, wiping out most ventures and leaving only few companies which still exist today.

If you ask me, the story of the internet and cryptocurrencies seems pretty similar.

Post reply on HN