[HN Gopher] Israeli researchers discovered the first consensus-l...
___________________________________________________________________
Israeli researchers discovered the first consensus-level attack on
Ethereum
Author : cryptoisthekey
Score : 161 points
Date : 2022-08-05 12:03 UTC (10 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| NickRandom wrote:
| See also - Uncle Maker: (Time)Stamping Out The Competition in
| Ethereum (
| https://www.researchgate.net/publication/362482526_Uncle_Mak... )
| ogogmad wrote:
| ETH price unaffected by the news, it seems.
| timbit42 wrote:
| As Eth is moving to PoS soon, I'd expect it have to affect
| Bitcoin's price more.
| doomroot wrote:
| This does not work on bitcoin. Bitcoin's difficulty targeting
| algorithm only retargets every 2016 blocks. This attack is
| only possible for diff target algos that retarget within a
| single block slot.
| spookthesunset wrote:
| Cryptocurrency never seems to track against real world events.
| Kinda makes you wonder how much of its volume is legit.
| spamizbad wrote:
| Ah but it does get impacted by things like interest rates and
| tech stocks.
| spookthesunset wrote:
| Very true. And arguably government stimulus checks too.
|
| But bad news? Your crypto coin has a documented flaw that
| allows it to be manipulated? Good news for your coin!
| cryptoisthekey wrote:
| The attack is called "Uncle Maker", as it allows attackers to
| displace main-chain blocks with their own blocks, thus making
| these displaced blocks become uncles. By analyzing the timestamps
| of the last 3 million blocks, it becomes apparent that F2Pool has
| performed the attack in the wild.
| [deleted]
| aaaaaaaaata wrote:
| What is the implication of the findings?
| sschueller wrote:
| ETH 2.0 delayed by another year...
| quickthrower2 wrote:
| ETH 2.0 sounds like commercial fusion power.
| api wrote:
| There's steady but slow progress in fusion in energy
| density and power output, so no.
| inphovore wrote:
| The issue with fusion has been the same for the last 50
| years.
|
| Harvesting the gamma's full electron volt right out of
| the reaction.
|
| We're still 50+ years away. Nothing in modern technology
| suggests otherwise.
|
| Science media has to explain why billions are dumped into
| these programs each year (as though edge science isn't
| enough.)
|
| In the meantime, everyone will be happy if we can harvest
| just enough to make the cost of the exchange worth while.
| most optimistically through harvesting the heat from a
| sustained reaction (which is 1000 x less potential).
| pelagicAustral wrote:
| Half-Life 3 much?
| shakezula wrote:
| Why would this have anything to do with Eth2 when it's
| explicitly a vulnerability in Proof of Work systems?
| oneoff786 wrote:
| Good for crypto
| dang wrote:
| Could you please stop posting unsubstantive and/or
| flamebait comments? You've been doing it a lot,
| unfortunately, and it's not what this site is for.
|
| https://news.ycombinator.com/newsguidelines.html
| xbar wrote:
| Probably that if you weren't mining on f2pool for the last
| few years you were severely disadvantaged, and that if every
| other pool doesn't start executing this "attack", they are
| not playing the ETH game correctly.
| mistrial9 wrote:
| exaggeration does not lend clarity .. an advantage is
| short-lived, like so many opportunistic moves in real life?
| the math says that the "severity" of the disadvantage is
| related to the change in difficulty at that juncture
| ogogmad wrote:
| This might not even be news to the people in the knows.
|
| @foldfinance says _We have known this to be the case with F2Pool
| for awhile but flashbots refuses to do anything_
|
| See
| https://nitter.42l.fr/foldfinance/status/1555477252736897024...
|
| @railgun_project says _This is a well known drawback of proof-of-
| work systems that was talked about even before Ethereum was
| launched. It is inaccurate to say that this is a recent
| "disclosure"_
|
| See
| https://nitter.42l.fr/railgun_project/status/155556027729019...
|
| @mesquka says _Not as big of a discovery as it 's made to seem
| IMO. Essentially just intentionally caused temporary chain forks
| to gain a competitive mining advantage. Known as an issue in PoW
| since Bitcoin launch (see any discussion about 'Longest Chain
| Rule' and things like 'Selfish Mining')_
|
| See https://nitter.42l.fr/mesquka/status/1555562671575023618#m
| Ar-Curunir wrote:
| All the tweets about it being a well known drawback are missing
| the point: yes, we knew that there's a general class of attacks
| affecting PoW this way, but it's the first time AFAIK that
| there's been public evidence of this attack actually occurring.
| paulmd wrote:
| > @railgun_project says This is a well known drawback of proof-
| of-work systems that was talked about even before Ethereum was
| launched. It is inaccurate to say that this is a recent
| "disclosure"
|
| this isn't an inherent weakness of proof-of-work systems, it's
| a weakness of proof-of-work systems _that allow difficulty
| back-off if a block is not found quickly enough_.
|
| It's always been kinda hilarious watching the various crypto
| factions slapfight and strawman each other to hell and back...
| ladies, please, you're all awful, each in your own way.
|
| (coming from a person who backs neither and merely follows
| crypto-tech in order to refute the arguments more accurately)
| dickmd wrote:
| paulmd wrote:
| > created: 13 minutes ago
|
| hmmmmmmm
| ironSkillet wrote:
| Maybe it's just that hindsight is 20/20, but given how simple
| this trick is, I'm surprised this wasn't obvious to someone when
| declaring the policy.
| Majromax wrote:
| It seems to me that there's a delicate, probably impossible
| balance: the difficulty decreases at the critical times, but
| not fast enough to compensate for the tiebreak.
|
| Suppose the difficulty decreased by a _lot_ : at 0:59 it is
| effectively impossible to mine a block but at 1:00 it is so
| easy that a speak-and-spell could do it. In that case, it seems
| like the optimum strategy for a selfish miner would be to try
| to post-date the timestamp and mine an "easy" block. It would
| still lose to a legitimately-mined "hard" block, but it would
| profit in expectation by being the first "easy" block to reach
| the network.
|
| On the other hand, setting a difficulty schedule such that
| there is no single optimum timestamp might impose a too-fast
| decay on difficulty.
| yuan43 wrote:
| > Whenever F2Pool's block timestamps reach the point where mining
| difficulty is supposed to decrease, they artificially set them to
| be one second earlier. F2Pool has been executing this attack over
| the past two years, and the evidence has been hiding in plain
| sight! ...
|
| This has the effect of making it harder for the rest of the
| network to compete against F2Pool's blocks. In this way, F2Pool
| can, or so it appears, give itself an advantage while taking zero
| risk. It would be irrational _not_ to adopt this strategy. The
| thread doesn 't say what happens if the entire network adopts
| this strategy - maybe it's in the paper...
| TacticalCoder wrote:
| Is this an attack on PoW or PoS? For Ethereum, since quite a
| while, is already mining blocks on both the PoW and the PoS
| chain.
| vivegi wrote:
| From the paper:
|
| > We introduce a novel attack vector on proof-of-work (PoW)
| cryptocurrencies which relieson timestamp manipulations,
| instead of traditional ones such as block withholding
| creeble wrote:
| Has this strategy been used successfully in Bitcoin, or why not?
| Synaesthesia wrote:
| As the 2nd tweet explains, the difficulty of Ethereum changes
| dynamically amd can decrease the longer that a block hasnt been
| mined, this is not the case in Bitcoin.
| infthi wrote:
| Bitcoin also adjust difficulty - but does that every two
| weeks or so. would it make sense to mine for a sibling for
| the last block before the difficulty increase while everyone
| else mines for a child block with increased difficulty? thus
| having twice the relative hashrate for 10 min every time
| difficulty increases.
| game-of-throws wrote:
| No, this attack wouldn't work on bitcoin. Bitcoin chooses
| the chain with the most total work (which is blocks x
| difficulty), not the most blocks. Else someone could fork
| the chain from a block sometime in 2009 when difficulty was
| very low and outpace the rest of the network.
| shakezula wrote:
| This is not true. Bitcoin has a difficulty adjustment.
|
| https://www.blockchain.com/charts/difficulty
|
| https://www.coindesk.com/learn/bitcoin-mining-difficulty-
| eve...
| delaaxe wrote:
| Guess what? Ethereum is switching from proof of work to proof of
| stake in about a month, so all of this is irrelevant
| xeromal wrote:
| This seems like a bit hostile for some cool research
| mr90210 wrote:
| Ok
| mypastself wrote:
| Even for someone with a reasonable amount of knowledge in the
| area, this was a difficult read.
|
| "...the attack does not entail any behavior which has a non-zero
| probability of earning less than mining honestly..."
| mjburgess wrote:
| > Although most mining pools produce relatively inconspicuous-
| looking blocks, F2Pool blatantly disregards the rules and uses
| false timestamps for its blocks. Specifically, whenever a block
| should have a timestamp difference from its parent which is
| divisible by 9 (precisely the time at which mining difficulty
| decreases), F2Pool hangs at the preceding second a while longer,
| thereby increasing mining difficulty and profits. Thus, in the
| past two years, F2Pool didn't have even a single block with a
| timestamp which is divisible by 9.
|
| from the medium post
| quickthrower2 wrote:
| Having read bits of the paper and the article I don't get why
| divisibility by 9 matters.
|
| Can anyone ELI-9 this?
| tromp wrote:
| It matters according to equation (48) on page 7 in the
| Ethereum design specification [1].
|
| This section specifies how to adjust the difficulty target
| for each new block. The optimization (I hesitate to call it
| an attack) identified in the paper could have been rendered
| ineffective if rounding down (for division by 2048 and by 9)
| was delayed until _after_ the multiplication in equation
| (45), resulting in a much smoother adjustment.
|
| The so-called "yellow paper" sadly lacks a motivation of all
| the seemingly arbitrary numbers involved.
|
| [1] https://ethereum.github.io/yellowpaper/paper.pdf
| horsawlarway wrote:
| I haven't done the math, but I believe it's because of two
| points:
|
| 1 - The "difficulty" of mining a block is based on how long
| it's been since the last block was mined, with a drop off in
| difficulty at 9 seconds
|
| 2 - If two blocks "tie", the the block that was more
| difficult to mine is the winner, and takes the rewards.
|
| ---
|
| So essentially, it's a way of breaking ties in their favor -
| reliably - by cheating a smidge on the timestamps they send
| for their blocks.
| __s wrote:
| What's the implication if everyone does this? Does it
| eventually converge on a working consensus?
| arisAlexis wrote:
| doesn't matter, ETH turns to PoS very soon
| bombcar wrote:
| chpatrick wrote:
| Seems like it's been a PoS for a few years.
| foepys wrote:
| This has the same energy as fusion power is only 30 years away.
|
| I have been hearing this since at least 2019.
| affinepplan wrote:
| ok but---it's literally set to merge in like a month. It did
| get delayed for quite a while yes, but it's happening now for
| realsies
___________________________________________________________________
(page generated 2022-08-05 23:02 UTC)