federicobond

They are probably exchanges doing batch withdrawals (large number of outputs) or consolidating their holdings into a single large output for economic reasons (large number of inputs)

Most transactions will have two outputs. One is the actual destination and the other is change that goes back to the spender wallet. There is nothing unusual going on here.

Not sure which audience you are targetting but I would love to read more on modern compiler design. There is very little information on the web on how to design a compiler to provide good error messages and code intelligence features even in the face of incomplete or incorrect source code.

A good starting point would be some of the themes touched towards the end of this article: https://blog.adamant-lang.org/2019/dreaming-of-a-parser-gene...

The US is much richer than 80 years ago, so it’s way more likely than billionaires come from comfortable middle-class families, of which there are many more now. If Warren Buffett or any of the others mentioned had been born the year Mark Zuckerberg was born, they would have probably enjoyed a similar upbringing.

There's a PubSub implementation for IPFS that can provide support for dynamic content in this case. I'm pretty sure there is another way to provide fast updates through some indirection mechanism though.

https://ipfs.io/blog/25-pubsub/

Firefox has already whitelisted the IPFS protocol so that extensions can provide implementations. It won't be long before this can be decentralized.

https://blog.mozilla.org/addons/2018/01/26/extensions-firefo...

I have quite a few years of experience with Django and in general, I have found it to be quite easy to set up. I don't think you can avoid much of what you describe with any other template engine, in Python or any other platform.

I mentioned that no one had much experience with the implications of Ethereum's model and you point me to a bunch of articles but I fail to see how they apply to the case of Solidity.

What are the big ideas from E that Solidity is missing?

Also, the article by Nick Szabo has some interesting ideas, but as far as I understand, it does not describe a language for programming arbitrary smart contracts, just some notation for common financial contracts.

Speaking seriously, there is an assembly for Ethereum called LLL. I would love to see code that performs exactly that example you mention and is easier to audit than the equivalent Solidity version.

Yes, that's definitely a good idea. I will go back to my magnetized needle now, I have some bit flipping to do in order to finish my task for Monday.

Not that difficult. There is not much point in creating immutable contracts since they act like singletons.

This is different from the kinds of objects that you would instantiate in a language like Java, where best practices suggest defining as immutable unless you have a good reason not to.

I may have enough funding to pay more that Brendan Eich is making right now. That does not mean that he will join my project. Good talent is scarce regardless of funding.

This is true for Haskell, but "most" other functional languages don't suffer this issue: SML, OCaml, F#, Rust, etc.

I don't have much experience with the ML family of languages, so I may have jumped to conclusions based on my previous experience with Haskell/Elm, but I did not intend it to sound as a dismissal of functional languages at all.

In fact, there is a growing community of researchers working on functional language design for the EVM, but I would wager that it's way more complex to build such a compiler than something a bit more "close to the metal", especially since no one had much experience with the implications of the memory/storage/execution model of Ethereum at the time work started on Solidity, let alone the kinds of vulnerabilities these contracts would be exposed to.

Hindsight is 20/20.

They may be enforceable but for many cases, it's just not cost effective to pursue legal action.

The problem is that decision tables usually end up really big for anything but the most trivial smart contracts.

Things are not always simpler at a lower level of abstraction.

Most of these observations are well-known to the Solidity devs. I know because I participate in many of the conversations around it. While it's not easy to evolve a language (the API surface is pretty wide compared to many other programs), Solidity is indeed changing and improving regularly, only limited by the available time of their contributors.

Being a good, secure language for writing smart contracts is absolutely one of the most important goals for Solidity. I can say so because I have been involved as a regular contributor to the compiler for more than a year. If onboarding a lot of people to the platform quickly were the goal instead, they would have ported some crippled version of Java or JS and called it a day.

The problem is that it's just not easy to get all those details right from day 1, and interest in Ethereum has grown way faster than its capacity to produce a reliable, mature set of tools around it.

None of the languages that you mention target the EVM, and the changes required to do so would turn them into restricted versions that look kind of like the original ones but have several differences that you need to keep in mind while programming in them. It makes quite a lot of sense to create a new language that takes advantage of the particular features provided by the EVM.

It's also quite hard for programmers to reason about performance or complexity in most functional languages. In the EVM, all functions should either be O(1) or bounded O(n) and should strive to use the most economical bytecode available to perform each task.

Disclaimer: I am a regular contributor to Solidity.

No, that's called end-to-end or client-side encryption. Zero-knowledge is a property of a certain class of methods that allow one party to prove to another that a certain statement is true, without revealing anything else about it.

A recent graduate from an Ivy League university in the US with thousands of dollars in debt and an job offer in Wall Street is accounted as poorer than a farmer in Congo by Oxfam.

This shows how stupid it is to measure wealth without taking human capital into account.

I also have no idea how you reach the conclusion that capitalists are the most benefited from it, but I guess it comes from the old labor-capital analytical framework. You completely ignore the benefits of less intrusive unions to consumers which, at least to me, seem to be the most obvious ones.

"We can almost always find someone who will do a job for less money". Where does this come from? Try hiring someone equally capable for half the salary you are paying now.

Spanish: La vida de los que se me ocurre mejor forma de reconstruir nuestra esencia social del hombre aumentan cuando hay una falta de claridad.

Sounds like the corpus had a little too much philosophy or sociology texts.

What a shallow discussion there. Very poor history of economic ideas and lots of straw men and intellectually dishonest arguments. I have come to expect it from journalists and non-academics in general, but it's sad to see them in academics too.

Iron law of wages? I thought that debate was over a hundred years ago, together with all the Malthusian doomsday predictions. I guess I was wrong.

I recommend you read some of the articles that the economist Donald Boudreaux has written on this topic. Most of them are short and well written.

http://cafehayek.com/?s=reich

I believe your reasoning, while correct, misses the bigger point: most of that wealth is not in the form of huge stacks of dollar bills in a bank safe, but company stocks. The only way to give a check to every citizen is to dismantle all these companies, which would destroy millions of jobs and make everyone much poorer.

But if we are going to provide a modern, standard API, then we better make it right.

A possible attack scenario could be showing a certain Bitcoin address but copying a different one to your clipboard.

There is also "define( 'WP_AUTO_UPDATE_CORE', 'minor' );" which should break a lot less.