eordano

It seems that SHARD is a term used already in 1988, meaning "System for Highly Available Replicated Data"

Source: https://scholar.google.com/scholar?cluster=14914487445955020...

I use to explain it this way: nowadays, bits and bytes are everywhere, most everybody you know has a notion of what a `megabyte` is. But this is a shockingly recent idea.

My grandma was 20 when a guy named Claude Shannon in 1949 invented/popularized the concept of a "bit" and described what information is, the way Newton described matter and how to model physics with mathematics.

Really, "information" was a just vague concept until Shannon and this was just 70 years ago!!1

It's only natural that a lack of generations of craftsmanship in this industry makes it pretty low quality/hard to master. On the other hand, imagination is the limiting reagent, since (arguably) the bottleneck is good ideas, specially with all these decades of Moore's law.

The article is fairly low-quality. It's more focused on fear-mongering around the perils of machine-judges and trying to make a headline around "if there's someone with commit power then in the end, it's not a decentralized system".

It makes a number of errors, most notably, calling the hashing power spent on securing the network "donations" (quotation marks sic).

Bitcoin has one job: securing the network of transactions.

Bitcoin is a mechanism to aggregate hashing power in order to make it possible to semi-objectively measure the risk of a block being reverted, in fact, this is the only formula in bitcoin's white-paper.

The paper examines a system of economic incentives, and somehow dismiss its key activity as an altruistic "donation". The article goes downhill from this statement onwards, and I couldn't feel like it makes a huge (yet ineffective) effort of deconstructing Bitcoin's governance model.

Some quotes that reinforce the superficial understanding of the Author:

> There are times, however, when two miners can find the correct nonce for a new block within a few seconds of each other and both broadcast their valid block of transactions (nigh on) simultaneously to the network. This causes a split, or fork, where miners go ‘rushing off’ to mine on top of two competing blocks. Because this form of divergence is endemic to the blockchain’s mechanics it is referred to here as a systematic fork; the discrepancy should be quickly resolved by network mechanisms (this happens, on average, two or three times a week). Systematic forks are temporary glitches...

These forks are essential to maintaining decentralization as a mechanism to make the network secure: trust the info, not the people that delivered the data, trust the signing mechanism (hash power spent), not the people running the machines.

> Furthermore, the political strategy of a user activated soft fork still requires code developers to create a client that reflects the political will of the market and thus demands the obligatory passage point of a Lead Developer found in version control systems.

Not true -- the UASF measures were not merged into the Bitcoin Core branch. Some code was merged to protect users from potentially problematic interactions with Bitcoin Cash fork.

Modeling Bitcoin's governance system is a daunting task. The author essentially confuses the power developers have with regards to miners: developers know there are things that would never fly with miners, and miners are way more powerful than what is described in the paper.

I'm sometimes shocked by the bad quality of browsing through code on GitHub. For example, you can't do a code search on forked repositories! The usability of the search bar is also quite lacking...

Also, "reward" is not appropriate. It has been historically referred to as "miner subsidy": it was intended to be a way to make mining attractive for early adopters.

I'd like to see more products/interaction/experiments in the way ChangeTip is going:

https://www.changetip.com/

It feels way more human than a big corporation's effort, and way more direct.

Yep, storing your bitcoins in a plain web app is definitely a bad idea. The current trend in the bitcoin space is a mixture of:

* Discouraging the use of the webapp (if any available) in favor of a browser application (chrome app, firefox app, etc)

* 2 factor auth to login

* Bitcoin "multisig" transactions: require at least N out of M valid private keys (allowing the storage of these keys to be on different devices/services/media) before releasing funds

And of course encryption before storage.

I think that the project is a bad idea because you can't impersonate me and take donations in my name without my consent, no matter which currency is being used.

I feel like we shouldn't miss the point here: you can't impersonate me and take donations in my name without my consent, no matter the currency (or regulations or whatever) being used. Make it opt-in, not "opted in by default and no way to opt out".

They shouldn't use a new cryptocurrency, instead, https://medium.com/@barisser/an-open-letter-to-reddit-why-yo...

I smell compatibility hell.

"Hey, take my credit from X gateway" "Sorry, I don't trust X"

Very cool! Though it looks like "less than 600 lines" made you write awfully styled code :/

I wonder why doesn't it show up on the top of the page

It uses the IP of the address that first relayed that transaction to blockchain.info

I think that a simple prompt for user's password before doing this would be an amazingly effective solution.

Oh! So it was real? I remember downloading a file called "HL2 Source Code.rar", long time ago, from eDonkey network. Never payed enough attention to it, thinking it was a fake!

Sir, excanvas is as slow as it can get. I am currently working on a web visualization and let me take you to earth, there are two graphic libraries to plot graphs (the ones with nodes and edges, not charts) out there: 1. The distinguished Protovis (http://vis.stanford.edu/protovis/) which doesn't run on some outdated versions of IE8 (and due to company policy I can't run Windows Updates) 2. JIT (http://thejit.org/), which performs poorly (I hardly get more than 2 FPS, whereas in Firefox 3.6 and Chromium Dev it's running well, well over 15 FPS, the target I aim for).

And let me note that making my app work on IE took me two days of work. That is what IE doesn't get and why web developers are mad at IE.

It slows down the pace of amazing UX growth in the web.

There is no Chrome for smartphones, and so far no one has said anything about dropping H.264 on Android (although you can see it happening as soon as WebM extensions for ARM start being more popular).

(edited: typo)