pietjepuk88

Yes, I would guess that coins sharing an algorithm with a much bigger brother (in hash rate) are particularly susceptible. Of course, the perceived security and valuation of many coins is somewhat tied together, and I can imagine many miners would avoid attacks on other (smaller brother) chains because they might end up hurting themselves as well. But it only takes one (big enough) actor to do serious damage to a smaller brother coin, possibly looking to gain financially, or maybe just to undermine its credibility/valuation. To do the latter, I would say continuously forcing many large reorgs is the way to go.

You are totally correct :) I figured it would be easier to forgo the explanation of "difficulty" and difficulty adjustments (which ETC/ETH do much quicker than e.g. Bitcoin does).

I'm not sure how easy it would be for exchanges to implement variable confirmations depending on the amount transferred, but I would say that what you suggest is a very reasonable way to limit the risk of suffering such an attack. I would say that especially exchanges that support fringe coins would better look into something like that. Even if the exchange's potential loss is only a couple hundred or thousand dollars, it's worth doing in my opinion, even if only to avoid the technical or legal hassle that would otherwise follow.

I would say that most (other) fringe coins are not as easily attacked as ETC was. They have very illiquid markets, and you cannot really sell a significant amount of them before you basically just deplete the order books. And merchants are typically not accepting anything other than the major coins either. I guess ETC was still riding along on its partially shared name/history with its bigger brother.

Eventually, some more details on the double spend transactions might shed some light on who suffered a loss in this case. It might be an exchange, but most of them require KYC nowadays (so it becomes hard to get away with).

The most typical way to profit from this, is to have quite a bit of ETC, and then sell it on an exchange or buy something expensive. This transaction would then end up on the block chain, and eventually be considered secure / part of history.

Privately, you are building a chain where said transaction did _not_ occur. Because your hash rate is high enough, you are generating blocks at at least the pace of the public chain. You keep mining your chain (without your transaction) privately until the bank transfer from the exchange goes through, or you are sure whatever you bought is on its way. Then you broadcast your private chain as soon as it has at least one block more than the public chain and voila, you have your ETC back and the USD/EUR/crypto you sold it for (or the product you bought). You can have your cake and eat it too. This is because the rule of most cryptocurrencies is that the longest chain is the truth, and everyone mines on top of the longest chain. If a longer chain appears out of nowhere, all miners will jump on top of this one. There is no such thing as "finality" in most cryptocurrencies, where something becomes actually (read: much more) irreversible.

Of course, doing this only makes sense if what you gain outweighs the costs of performing such an attack.

Note that you typically _cannot_ steal coins from specific wallets, as you do not have the keys to those coins. You can however censor transactions that you may not want, but the above is a common way to benefit from a 51% attack.

I agree that sharding/scaling is definitely a problem, but I'm not sure where you got your numbers from. I don't know about Stellar, but for Ethereum a full sync takes 16 hours to a day for me (which I find slow, but it's certainly not a week). And that full sync results in about 125-150 GB of disk usage. Again, I personally still find that quite much, but it's definitely not "well over a TB".

Agreed. 196 cm/6'5" here, and the only thing I found lacking was the width of the chairs on the Tokaido line (3+2 arrangement). I'm not sure what the pitch of the seats is, but I had plenty of leg room (much more than any train in the Netherlands anyway, let alone air planes).

If you ever find yourself in Japan with a rail pass, do use the free reservation option when traveling between Osaka and Kagoshima with the Sakura. That one has a 2+2 arrangement in the reserved seat cars, which makes for a more comfortable ride.

I do agree with things being quite small/low though, bumping my head at least a couple times a week.

Aside from the special case of "1" always being present, I would say that in general you should just use an optimizer to solve knapsack problems. Whether you should do so for an interview question is up for debate I guess; using libraries shows you can get something done quickly and efficiently, but implementing your own solver might show you understand the underlying complexity.

As far as comparing code complexity of Julia to Python is concerned, I would say that when you use JuMP in Julia, you should use Pyomo/CasADi/PuLP/... in Python. That is not to say that I don't find JuMP to be a more appealing framework overall. It has wide support for all kinds of solvers, and some Julia/JuMP authors even wrote fairly good MIQCP/MICP solvers on top of commercial/open-source MILP/SOCP solvers.

I would say that Ethereum is the smart contract platform, but that Ether (ETH) is a currency. That's based both on how it's used, and on how the protocol separates normal transactions from smart contract interactions (including token transfers).

I like the fungibility that Monero offers (making it similar to cash), but I just can't wrap my head around Ripple. I always associated cryptocurrencies with decentralized and trustless (at least at its core), neither of which seem to apply to Ripple. I would have preferred a "trusted party" system on top of a decentralized one to get higher transaction speeds, e.g. when the stakes/amounts are low.

But they always seem to offer English CC though, just not the regular ones (for many movies). And the regular ones should just be a simple transformation of the CC ones (strip all "\[.*?\]" stuff). That said, the other day I watched the movie "Easy A" which did happen to have both English CC and normal English subtitles. Still the only one I've found so far though.

You (the user) decide. If you want to fork Nano/XRB to undo the hack - assuming that is at all possible - just edit the code, and release said version to the public. Then you will have done what happened with Ethereum after TheDAO hack.

NEO is currently quite centralized†, which is an easy trade-off to make for higher throughput (see the traditional infrastructure of the web). It may not become more decentralized in the future, but its consensus mechanism (dBFT) is not really proven yet, which is why they are playing it safe. They will continue developing it of course, as will Ethereum with its proposed and not-yet-rolled-out PoS.

Time will tell which one is safe. If the rewards are high enough, someone powerful/knowledgeable will inevitably try and break or cheat the system.

† Some people like to make a distinction between "distributed" and "decentralized". For me the former is part of the latter.

According to coinmarketcap.com[0], the traded volume of Ripple today was 8 billion USD. That's a bit better than your Yakitori coin.

I am a bit confused about the volume of e.g. Amazon on Yahoo Finance[1], which is either 3 million or 3 billion USD.

So if such calculations are allowed/typical for someone like Jeff Bezos and his AMZN shares, why wouldn't it be for a cryptocurrency?

[0]: https://coinmarketcap.com/currencies/ripple/#markets

[1]: https://finance.yahoo.com/quote/amzn/

When syncing, you can choose to either build and save the state for every block ("archive" mode), or save only the latest state ("fast" mode). The former requires quite a bit more data than the latter (currently 500 GB vs 32 GB for the Geth client) [0]. The default for most contemporary clients is "fast" mode.

Note that with the "fast" mode you still have all the blocks, and with that all the information needed to recreate the state at a certain block somewhere in the past. And you can still help the network by syncing those blocks to newly spawned archive or fast nodes. It's just that requesting the state (e.g. balance) at a certain block in the past takes some computational work. Most people are not interested in that however, which is why it's the default synchronization mode.

[0] https://etherscan.io/chart/chaindatasizefull vs https://etherscan.io/chart2/chaindatasizefast

As seanwilson says above, blockchains work by consensus. Leaving aside the "better", that does mean it is different. The instructions are still executed by computers as it was programmed as you say, but if enough users/miners agree this was not the intention of the contract/code, they can fork.

I do think that calling blockchains "immutable" can be confusing to users not familiar with the concept and its nuances. And I personally hold no opinion on whether the currently locked up funds need to be returned to their owner with a fork. There is something to be said for both options, specifically in this case where there the "rightful owner" is clear (like the other cases mentioned in https://github.com/ethereum/EIPs/issues/156 ).

Well, "traditional" law can be changed as well, so I'm not sure why a blockchain should not be able to. Some changes are more controversial than others, but in the end the majority (more or less) decides. Either by vote in congress/senate, or by users picking a particular client/chain.

Ethereum has had one particularly controversial fork, and so did Bitcoin. In both cases, both chains survived, with one significantly more popular than the other (in both hash rate, transactions, and market cap). (Un)fortunately, traditional law in real life does not permit two realities to coexist, so there the analogy falls apart somewhat.

Although not guaranteed, a soft fork can still result in a (lasting) chain split. Especially in the case of Bitcoin (which has slow difficulty adjustment), if the hash rate of the SegWit miners was lower than that of the old miners, the legacy chain could have easily prevailed/survived. It's a game of chance (read: race) right after the fork though, with the new nodes "winning" as soon as they generate a longer chain than the old nodes. This becomes ever more likely of course with a higher percentage of the combined hash rate.

This is quite clear terminology in cryptoworld, although I can understand why people are a bit confused with the events that unfolded in August. A hard fork is any fork where new nodes produce blocks that old nodes do not accept (and vice versa). A soft fork is one where new nodes produce blocks that old nodes accept, but not the other way around (e.g. new nodes reject blocks made by old nodes). That's it.

So this _is_ a hard fork, albeit not a very contentious one. And it _will_ result in a chain split, with the minority chain probably having low activity/worth due to (1) lack of support (2) the ice age which will increase block times to slowly kill it (and that it itself has to be hard forked to stay alive).

To be fair, the turbochargers in contemporary F1 cars are not powered only by exhaust gases. To get rid of the infamous turbo lag, they are electrically assisted. Still not a super charger of course, but the "assisted" part makes them a bit more similar.

There is only one type of difficult bomb for Ethereum (the ice age), and that is already underway. As linked to in that article, block times would reach about 30 s mid-August (https://www.reddit.com/r/ethereum/comments/5izcf5/lets_talk_...).

The difficulty bomb/ice age is _not_ to force the devs to implement PoS. The reason the ice age(s) exist is to make sure minority chains eventually die. Bitcoin does not have this problem as much, because the difficulty adjustment is much slower, which easily results in hour long (or more) block times for weeks/months for a minority chain. The difficulty adjustment on Ethereum is much faster, so minority chains that arise after a protocol upgrading hard/soft fork could hypothetically survive. To incentivize miners and users to switch to the new chain, there needs to be some other mechanism in place, which is the ice age. The ice age causes block times to keep rising exponentially on the old chain (if no action is taken), so miners will eventually lose their reward and users will not be able to make transactions anymore. They move to the new chain (which postponed the ice age), and eventually the cycle repeats itself.

This cycle has happened a few times already. Usually the fork would have already happened by now, so the impending Metropolis fork is different in that it's a bit late and the initial effects of the (ever worsening) ice age are felt.

I also needed to profile a running process without stopping it, and ended up using pyflame (https://github.com/uber/pyflame) together with the famous flamegraph script. It is not perfect, as it only works on Linux and only does CPU profiling, but it worked well enough for my purposes.

That is weird, I had local anesthetic for my wisdom teeth removal. Granted they weren't that hard to remove, but I wouldn't want to be put under entirely for something so simple. Aside from being a bit pale, I could go home straight after and function close to 100%. Recovery from general anesthesia takes much longer from what I know, and there are more risks involved as well.

Only thing I found out is that paracetamol/acetaminophen doesn't do much for me, and that naproxen is a much more effective OTC painkiller.

I think the analogy holds up quite well, even though they don't go into the details that you mention. Losses in water transmission lines for example are also proportional to velocity squared.

Of course no two persons are exactly the same, so your statement about gain/loss is true no matter what. However, I just want to say that a wide margin is only about ~10%, or two tablespoons of peanut butter for a typical "doing nothing" metabolism. This is assuming roughly the same physique and exercise pattern [1]. People differ, but in my experience the influence of genes is overestimated quite often.

Of course, top athletes can burn through 2-3 times what a desk-worker might burn through. And I think the small number I mentioned above also tells that you can slowly but steadily put on quite some weight, by eating every day just one slice of bread more than you need.

[1] https://examine.com/faq/does-metabolism-vary-between-two-peo...

Just an honest question, but do you like the glossy screens? I personally get quite annoyed by them at times, and find matte screens to be a more relaxing (/dull) experience. The glossiness does however make the iMacs look good in stores. The colors a bit more vivid, and they also tend to show mostly whtie/bright footage on them which hides the mirroring effect.

Please note that Japanese words themselves can also be written in katakana, sometimes as a sort of emphasis. Other reasons can be it being a brand/name, or because it is easier on the eyes, or because the kanji are too difficult. So it's not like every word written in katakana is a foreign one.

That said, most words written in katakana are probably foreign.

I was actually looking into Chebyshev polynomials and minimax optimization to make a fast vectorized implementation of the logarithm function a few days ago. In the process of looking around the internet for information I ran into this: https://github.com/pkhuong/polynomial-approximation-catalogu... (also see link to blog at bottom)

He has nice sets of coefficients derived by taking into account the discrete values of floats/doubles, and the performance gain by setting some coefficients to 0, 1 or 2.

The only thing he did not account for is precision loss when multiplying and adding values when actually calculating the polynomial, which unfortunately results in a large relative error around log(1). Eigen's vectorized implementation does some weird tricks with changing the range to sqrt(0.5) to sqrt(2), and does not exhibit this large relatively error. The unvectorized MSVC implementation does not exhibit this either.

Does anyone how Microsoft and Intel and the like derive the coefficients for their approximations of the elementary functions in math.h?

I have also been at it for a while now. What I notice nowadays is that the same English->Japanese cards keep coming up quite often, because they have very similar cards/synonyms. Therefore, when adding new words, I take extra precaution to come up with a short 2-4 word sentence that is unique enough and captures the meaning quite well. Sometimes it might take me a few tries though, when I end up confusing it with another card anyway. This may also mean that sometimes I have to go and change a card/note I made a few years ago, because it 'conflicts' with something I want to add now.

So with regard to the clippings feature I feel that generating single-word flash cards might come back to bite you. It makes English->Japanese "production" difficult and annoying in the long run. On the other hand, it also makes Japanese->English unnecessarily complicated with all the meanings associated with a single word. A relatively simple example that comes to mind is 手入れ, of which I would rather have two short sentences describing each use case. Or with regards to the clippings feature, I want it to generate the card with the meaning I encountered, because the other meanings of that word might never actually be used by the Japanese.

I am not sure an app will (or even should) be able to generate such cards. Condensing both the Japanese, while getting the English meaning right, is hard enough for a human. It certainly would be awesome, because at the moment I have to resort to generating the cards manually for the words/sentences I encounter while reading manga or books on my Kobo e-reader. History shows that (1) I am too lazy to generate a card for a word that I had to look up, and that I tend to just keep on reading (and forgetting the word again later on), or (2) that I actually stop reading for a few days/weeks because I feel I have to enter the back log of cards in Anki before continuing.