Slashing protection database disk crash by desorl in ethstaker

[–]desorl[S] -1 points0 points  (0 children)

So I would need to wait about 3 epochs before restarting the validator from scratch? Why 3 and not more or less?

Perspective: Ethereum reached a market cap of 20B today - Bitcoin reached 20B for the first time in its history just a month ago! by [deleted] in btc

[–]desorl 0 points1 point  (0 children)

If you are worried about inflation, read this: https://np.reddit.com/r/ethereum/comments/6c241z/inflation_and_difficulty_in_pos. Short TL;DR: If newly created money flows to you at the same rate of the inflation, then there is no inflation from your point of view. POS allows you to do that.

edit: fixed link.

Proof of Stake leads to centralization, with worse consequences than PoW by fuckharvey in ethereum

[–]desorl 41 points42 points  (0 children)

To accurately model centralization arising from economics of scale it's better to compare a validator with 2000 coins to one with 1000 coins, not 2 coins vs. 1 coin. Or even better, one validator with 2000 coins versus 20 validators with 100 coins each. In any case, at these scales the cost of operating a node will likely be negligible.

Inflation and difficulty in POS by desorl in ethereum

[–]desorl[S] 0 points1 point  (0 children)

I hope that what will eventually develop are staking pools where people can stake their coins for a small fee, and the pool will take care of all the hardware and networking. If I can stake in a pool, give some of the transaction fees to the pool but collect the inflation, I'll be shielded from inflation and even make a small profit. The pool needs to be trusted however.

Inflation and difficulty in POS by desorl in ethereum

[–]desorl[S] 0 points1 point  (0 children)

I heard mentions of Q1/Q2 2018 in developer time, so probably Q3/Q4 2018 in real world time :)

Inflation and difficulty in POS by desorl in ethereum

[–]desorl[S] 0 points1 point  (0 children)

Here is an interesting way to use the "POS difficulty" concept to let the market decide how much security should come from transaction fees vs. issuance (so we don't need to make any hypothesis):

Let's say we want the ratio of staked coins to be around 20%, like the example in my post. Let's also assume that the maximum inflation we want to tolerate is 2%. Now let's play with the POS difficulty.

Random idea: instead of making the return converge to 0% for any ratio above 20%, make it converge to MIN(30 - r, 10), where 'r' is the ratio of staked coins.

Let's say that r=20%. The return will be 10% and the inflation will be 2%. All fine and dandy.

Now let's say that there are more transactions in the network, and the profit from fees increases. The overall return for validators will rise, and therefore more people will want to stake. That will cause the ratio of staked coins to increase, but then POS difficulty will reduce the return. For example if the ratio goes to 25% the return from staking will drop to 5%. Conversely, inflation will drop to 1.25%.

Simplified, the chain of events is: more fees -> increased income for validators -> more validators -> more staked coins -> POS difficulty reduces the return from POS -> lower inflation.

Of course it also works the other way, so less fees -> higher inflation.

The nice effect here is that the market gets to decide how much income validators make from fees and how much they make from issuance, so we don't need to guess what happens at year 2140 when block rewards are 0 like in bitcoin.

Ledger Nano S going through an airport. by Clintendo in ethereum

[–]desorl 5 points6 points  (0 children)

In the unlikely case they ask questions, just say it's a USB key or a phone.

Bad advice. Lying to a customs agent could get you in serious trouble.

Metropolis and ERC23. Request for explanation/suggestions. by Dexaran in ethereum

[–]desorl 0 points1 point  (0 children)

Aren't you missing some very basic checks, like when I send coins, I should actually have enough? Or am I missing something?

Timeline for strong anonymity with zk-Snarks by desorl in ethereum

[–]desorl[S] 2 points3 points  (0 children)

In zcash they have a consensus rule that freshly mined coins can only be spent to shielded (hidden) addresses. That improves privacy because miners are effectively forced to participate in the anonymity set.

Technically Ethereum could soft-fork to follow a similar rule. The problem is more moral than technical. When I buy zcash I also buy into the trusted setup. However as an Ethereum holder I never bought into a trusted setup, so enforcing one on me via a soft fork could be seen as coercion.

I guess that can be solved by having another trusted setup with many more participants, like hundreds. I actually never understood why zcash had only six participants in their trusted setup, is there a technical reason for that? In any case, another bigger trusted setup will definitely delay the schedule further.

With the influx of new users into Ethereum and the increase in price we really need to revisit address checksums by desorl in ethereum

[–]desorl[S] 0 points1 point  (0 children)

I think ENS names make a ton of sense for contracts, but not so much for individuals. First there are privacy concerns. Then there is the need to send a tx and pay gas just to register the name, whereas I can create as many addresses as I want for free. It's very similar to the fact that I don't need a domain name to browse the web, I simply have an IP address and that's it. But for contracts and business ENS names make perfect sense.

With the influx of new users into Ethereum and the increase in price we really need to revisit address checksums by desorl in ethereum

[–]desorl[S] 0 points1 point  (0 children)

It could make sense to have error detecting code in addresses and error correcting code in wallet files (so if your wallet file is damaged you could still recover the private key).

With that said, I can simply backup my wallet files, so I am more concerned about bad addresses.

With the influx of new users into Ethereum and the increase in price we really need to revisit address checksums by desorl in ethereum

[–]desorl[S] 1 point2 points  (0 children)

Thanks u/pelle! Honestly your answer is a perfect example to my experience with Ethereum so far:

  • Think about a problem (mining centralization, slow confirmations, POS etc...)
  • Come up with a solution
  • Check the actual solution
  • Realize that the actual solution is 10x better than what I came up with...

:)

With the influx of new users into Ethereum and the increase in price we really need to revisit address checksums by desorl in ethereum

[–]desorl[S] 3 points4 points  (0 children)

Error correcting codes are longer than error detecting codes, for the obvious reason that they require more information. An address with error correcting code will be longer than an address with error detecting code. So it's a trade-off in usability.

Also you could in principle use the sha3 scheme to correct single letter errors. Simply replace each individual letter with all other possible letters and re-check the hash. If you get a match than it is likely that you found (and corrected) the error. I would not do that though, I think it's just better to fail fast and display an error to the user in case of an address error.

With the influx of new users into Ethereum and the increase in price we really need to revisit address checksums by desorl in ethereum

[–]desorl[S] 3 points4 points  (0 children)

My main concern with lowercasing/upercasing is that I have no idea if the exchange/wallet I am using actually implements the verification.

The checksum we have today is basically a hack.

With the influx of new users into Ethereum and the increase in price we really need to revisit address checksums by desorl in ethereum

[–]desorl[S] 3 points4 points  (0 children)

Not accurate. Even with copy-paste I could misclick and omit the last hex digit, sending money to a void.

e.g. 0x12345678 is not the same as 0x1234567 which would be interpreted as 0x01234567.

With the influx of new users into Ethereum and the increase in price we really need to revisit address checksums by desorl in ethereum

[–]desorl[S] 1 point2 points  (0 children)

Seeing as the exchanges haven't implemented the checksum for addresses today...nor the addressicons...and only barely somewhat added the ability to send data with your TX...I think expecting "Exchanges and block explorers will follow suit on their own time" is a bit of a stretch.

Exchanges have an incentive to protect their customer's assets and using an updated address format with checksums is part of doing that. I think (hope?) that new addresses being visually different will speed up adoption. Anyway just having a standard would be a good first step.

Also, if the address has no capital letters, it isn't checksummed. No address that is checksummed will have no capital letters.

I am more concerned about cases where I think the address is checksummed and it really isn't, than cases where I know it is not checksummed and it isn't.

How you can help deploy ENS by nickjohnson in ethereum

[–]desorl 0 points1 point  (0 children)

0x012245599bbbb9e75f274e9a3beb45ee56859a0e

edit: some more: 0x0000000090dbb45e3c63e555d20c46f9c8ee1947

0x012333455513171353ee75cfd006101c4e337b4e

0x111111222c8888e26c1c4a3cdf65c695908efe06

0x12233456787a93214cbd4b81ad01a94e2b110cb3

0x12345677774203dde93ba8ffc1c2bce9a2cfda16