ikken
Joined 16 years ago
Karma
173
Submissions
36
Member since
Dec 28
Recent submissions
Comment · 5 years ago
Comment · 6 years ago
You're referring to the Terms of the website, not "Ethereum 2.0". It's like agreeing to the Terms of Use of a Bitcoin wallet. It doesn't mean that Bitcoin is a "centralized joke".
Comment · 6 years ago
It's not my field, but I remember reading that your example doesn't represent entanglement because when put into envelopes, one marble is already red and another blue.
In quantum entanglement they are both truly and really random until you measure one. And it's not random in a sense that you closed your eyes when putting them into envelope. They actually both don't have a "selected" color. They "snap into one of two colors" when you measure (look at) one. And the "unbelievable" thing is that when you measure one, the other one immediately snaps into opposite color, no matter how far it is.
Comment · 8 years ago
This reminds me the bet in the bitcoin community [1]. If on average bitcoin blocks are produced every 10 minutes, and you learn that 5 minutes ago someone found a block, what is the average time you will wait for the next block? It turns out it's 10 minutes, not 5 minutes as you would intuitively think. (it's a memoryless process, so average expected time till block is always the same - 10 minutes - no matter how many blocks were recently found).
In other words, when you're waiting for bitcoin transaction to be confirmed and go to check how long ago the most recent block was produced, in order to estimate how soon the next one will come - you're doing it wrong. Even if previous block was found 9 minutes ago, you're average waiting time for the next block is still 10 minutes.
[1]. https://www.reddit.com/r/btc/comments/7rs8ko/dr_craig_s_wrig...
Comment · 9 years ago
This is because running code on Ethereum VM and storing data is hugely expensive (rightly so, as it's being done on all nodes in the world). Therefore Solidity will try to compile into a VM code that uses the least numbers of cheapest instructions and pack data into as small memory package as possible.
Comment · 10 years ago
I think that many people miss the most important thing here: it is not important if a currency hard-forks or not - what is important is that it can.
I have no confidence that Bitcoin or any other currency doesn't fork in the future, because it is possible at any moment. The fact that the fork has happened or not changes nothing - it always stays as a possibility.
In other words the chance of Ethereum or Bitcoin hard-forking in the future wouldn't change if the hard-fork didn't happen right now.
Comment · 10 years ago
This is a very one-sided discussion which makes it seem like it was written by a person who wants Monero's value to rise. It doesn't mention any drawbacks of Monero - like poor scalability - that blocks it's wide adoption. There's also a good deal of FUD around Dash and Zcash, which has been quickly refuted on reddit [1].
Apart from that I liked this post and it shone some light on issues I wasn't aware of.
[1] https://www.reddit.com/r/btc/comments/4nai1r/on_fungibility_...
Comment · 11 years ago
Please check aiopg [1]. There's also an interesting list of packages for asyncio [2].
Comment · 11 years ago
Yes, it is a single process application. But to utilize all cores I use Gunicorn to spawn multiple processes.
Comment · 11 years ago
Unfortunately the code is not open source - I'll try to open parts of it in the future.
But please do check this simple gist I found some time ago that helped me understand how powerful asyncio is:
Comment · 11 years ago
We see people hyping all the time for NodeJS mainly because it can handle millions of concurrently open connections. Now we get a much cleaner (IMHO) way to achieve the same thing in python (of course python is slower) - i.e. see aiohttp as websockets server. I would not call it a disaster.
Comment · 11 years ago
I've been using the new async/await syntax to write beautiful asynchronous websockets server and I fell in love with it. It handles hundreds of thousands of concurrent connections (on top of aiohttp) and the code is so much cleaner than it would be with i.e. NodeJS and Express and Promises. It reads like a serial code.
I think benchmarking asyncio with any type of CPU bound tasks misses the point. Previously we were relying on hacks like monkeypatching with gevent, but now we've been presented with clean, explicit and beautiful way to write massivly parralel servers in Python.
Comment · 11 years ago
It's not only a distraction but outright dangerous. People got used to accept every banner with word "cookie" in it. There were cases in Poland where scammers would add "and I subscribe to X and will pay Y monthly" onto the cookie banners and then send invoices to customers (as long as they could get their address, e.g. when they came via email link).
For example, one reason for the existence of transaction fees is to prevent network from being DoSed (overwhelmed in terms of processing and storage) by flood of "free" transactions. How can e.g. Nano handle this problem with no fees? This and other problems are discussed in section "V. ATTACKVECTORS" of their whitepaper [1].
Unfortunately, rather than provide concrete, mathematical solutions, the white-paper provides mostly "discussions" of why those issues are not really a problem or that some feature will prevent them (e.g. PoW attached to each transaction - which in itself is form of a fee, non eco-friendly and might be prohibitivly slow at scale). Those discussions are not researched enough to give assurance that Nano would function efficiently and securely if it were ever to get popular.
Blockchains are very inefficient and a we're still figuring out how to make them faster and cheaper without sacrificing too much security and decentralization. But as is often the case - there's no free lunch. And extraordinary claims require extraordinary proofs.
[1]. https://content.nano.org/whitepaper/Nano_Whitepaper_en.pdf