monokh

This is great. I especially like that it follows the protocol's implementation for the most part. i.e. you still have utxos and script verification even if it doesn't actually support the array of script op codes.

There is a fully compatible JavaScript implementation that you could use as reference to extend yours: https://github.com/bcoin-org/bcoin

With my post, I tried to boil down the concepts as much as possible to save some mental bandwidth and make understanding the overall easier. We will see how that turns out

(author here) I'd love to know the inaccuracies so I can address it. Generally I tried to simplify things to make it easy to follow in code. Anything worth noting can be added and I've done this with some things brought up in this thread. I'd love to do the same with your suggestions.

I already qualify for the "blockchain expert" tag by working in the space for 2 years, though I don't find it that desirable. Maybe a few years ago.

The article mentions the hash is required to begin with a certain number of 0s in hex digits (half byte) whereas the Bitcoin whitepaper refers to it as number of bits. I'm unsure about the comparison (== or >) but the whitepaper seems accurate with regards to the target.

(author here) Absolutely. Thanks for pointing this out. If difficulty adjusted in factors of two, the ability of the network to accurately maintain its 10 mins blocktime become impaired.

I try to keep these concepts rather simplified to ease the reading and learning process. Perhaps there should be a note for these situations.

I'm not sure it's accurate to say that doing open source gives you "complete freedom". In some way, you are responsible to your contributors / users and they are kind of paying your bills.

It's probably worth noting the horrible privacy characteristics of Ethereum. With the right resources, It's straightforward to track down the identity behind the seeders.

And the result is?

The consequence of playing in a walled garden.

Is there still no way to release an iPhone app out with the iOS app store?

Zoom can either

a) Keep their moral code and be happy in the idea that they will probably be cut off from that market (China)

or

b) Drop their morals, appease to the local laws as unjust as they may be in the hope that their business there continues.

They chose the latter and still want to pretend they are doing both. That's a problem.

Hi HN,

We developed this extension to overcome several key security and usability issues that exists with crypto wallets today. You can send, receive, interact with websites and exchange using an array of coins. All in the one wallet while maintaining full control of your funds.

Happy to answer any questions you may have!

This might be true for a service with a basic setup of providing the same address for deposits. If they did it the right way, they would provide a unique address each time. Such a list of addresses is only known to the key holder unless they were to share it. https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi...

Exactly. The difficult part of creating these kind of value systems isn't just providing more beneficial incentives. It's also about providing the right combination of incentives that remove (as much as possible) any malicious intentions.

You might be misunderstanding my position. I think IPFS is great and should be used. But this specific project is not really attending to any problems.

It's in the core functionality of IPFS to be able to host a file and the http proxy is available by default by IPFS. So the real problems are distributing and decentralising the file (such as by running an IPFS node) and this project is not making the slightest attempt at that. Without that there is little point in using this service as it is just like any other centralised hosting service, just so happens that the file is on IPFS.

Yes it does. But I don't believe this app is using any actual seeding mechanisms of IPFS from a user perspective. Which is why i'm asking about where the nodes would be to make this distributed and decentralised.

My guess is that the server of this project uploads and "pins" this file in IPFS, in which case it would be no different than a centralised solution. If the server goes down, your file is unaccessible.

Also, when you use this app, you aren't doing this through an IPFS node to then be able to seed it. You are just downloading the already hosted file using a HTTP proxy service that can download from IPFS.

Sure, I guess the difference is, torrents have an inherent mechanism of becoming distributed. Once someone else has a whole/part of the file, they begin seeding immediately (unless stopped of course). In the case of this app, I just receive a download link which is a proxy for pulling something from the network. It would be something else, if the way to get a hold of this file would be through an IPFS node that the user was running.

I'm trying to figure out how this would be decentralised. As far as I understand, merely hosting something on IPFS doesn't make it decentralised if there is only one node.

- Where is my file hosted when I receive it?

- Has your server pinned and seeding that file?

- Is there a distributed set of nodes that also host it?

Nice one. Have been looking everywhere for a block explorer that could be used on local instances.

Still pretty dissapointed that etherscan isn't open source, would make local development a hell of a lot easier.

> See how the hash-chaining mechanism of a blockchain means that even a single corrupt or tampered-with block will invalidate the entire chain after it.

Is that strictly required to understand that the entire chain is invalidated? Since blocks are in order, if block X's previous hash doesn't check out, can't we just assume that every block thereafter is also invalid? Effectively a fork has happened at X-1 block.

I'm guessing there are more dynamics (speed?) that come into this. Maybe the following questions will make it more clear:

1. How do the blocks update when there is a change in a past block?

2. In the real world, what process does a node use to validate the chain on an ongoing basis?

But you'd rather go to the non AMP version which is 10x as bloated?

It seems like the vision in your head is: AMP vs. Perfectly optimised site. In reality it's publishers who have built their main site over several years with massive bloat and are unable for whatever reason to optimise.

Oh I see. So low end devices in india which are predominantly android smart phones do not have the capacity to cache 500kb of frequently used JS?

Reducing the overall page size of a given page doesn't help

Optimizing rendering for content first and images loaded as required doesn't help

Serving pages from a super fast global CDN doesn't help

And prefetching content behind the scenes also doesn't help

I think you should take these to Google because it seems like they've totally goofed this AMP thing!

It is helping this when you consider all the JS is cached because they've visited an AMP page before.

So slow page load speed is a non problem and speeding up delivering content is not a solution? Whether you like it or not, if you search on Google, you are using THEIR platform and you are THEIR user. What they have determined is that their users want to consume content faster than what is traditionally available on the web. So you'd rather wait 3 seconds to see your ebay listing than half a second? For the open web, javascript bloat and google is taking over the world reasons. That suits you fine but not the majority of users on Google. Why would Google be implementing a technology that is BAD for their users?

AMP plugins are (supposedly) designed to be the fastest/lightweight/user-friendly implementation of a specific functionality.

Yes, if all you consider by "bloat" is how many kilobytes of javascript you have on the page, AMP is not doing well. This is a crucial mistake in this post. In reality "bloat" is more than that. It also refers to whether there's active javascript slowing the browser down, whether resources are cached etc.

The purpose of having these small plugins that enable functionality is that they are all individually cached by your browser for a good amount of time. Any Google user would have them cached as they are all using the same reference that any other AMP page would. This is unlike other "bloat" where resources are fragmented and come from any number of sources that users probably haven't hit before. In addition these JS resources wouldn't have been written for a specific experience - which AMP is