Token Daily

2

6

2

6

2

4 6

5

3

2

1 2

2

1 2

4

2

1 2

2

3

11 3

twitterologist 4 hs ago

Wrote down some initial impressions from Veil at https://dyor.io/veil-market-first-impressions

2

_dredge 6 hs ago

How can we be sure there will be enough ETH to cover all payouts?

1

msagansk 4 - 5 years account age. 250 - 500 comment karma. 1 h ago

ETH is escrowed when you make a trade.

2

_dredge 26 mins ago

But what if the payouts are larger than the quantity of ETH held in escrow? (e.g. take a short position on BTC/USD and then all crypto assets fall)

1

mashina55 Bullish bear 7 hs ago

Nice! Looks pretty simple so far.

2

atLeastAverage 7 hs ago

This is going to become everything I hoped for. I kicked around a little and I love it.

1

zantho 10 hs ago

Fantastic! Anything that works around the terrible Augur interface is good news!

3

Poyo-Poyo Yesterday

F.

0

ninja_batman Yesterday

Any idea why an 'account' is necessary? I thought that was one of the benefits of crypto..

3

ItsAConspiracy 4 hs ago

Can you sign in with just an account before having ETH? A lot of people are trying to ease the onboarding process so people can jump right in, instead of installing a client and buying ETH on Coinbase before they can do anything.

2

DDDNN 8 hs ago

The account creation doesn't even require other information than email (which is good) but why even have it in the first place then. One of the things like the most about dapps is that no specific account is required since you already have a wallet that is usable everywhere.

5

stevej11 Yesterday

I agree, was pretty disappointed to have to create an account

3

blackestadder Yesterday

Serious question: Why are you building this on top of Augur at all?

Veil is not permissionless to use. You seem to require customers to "white-list" their ethereum addresses, which requires an email-based registration process. You are even blocking entire countries.
Veil bypasses Augur's on-chain orderbook in favor of a centralized 0x-based off-chain relayer.
Correct me if I'm wrong, but I don't believe Veil shares or consumes liquidity from the Augur orderbook, except indirectly via arbitrage.
Veil defines the rules and conditions for markets, and does not allow users to create free-form markets (though I see in your blog post you are considering allowing other markets in the future).
Veil acts as the oracle with "instant settlement" by buying out customer positions early.

I can only think of a couple advantages:

You can raise funds from VCs who have drunk the Augur kool-aid for whatever reason.
If users don't like the prices you offer to settle at, they can appeal to the Augur dispute system. Of course this arbitration is far from ideal, locking up funds for months and putting yourself at the mercy of the REP mob. Disputing would probably also be very risky because Veil will be the adversary in any dispute, and they have a privileged position in the Augur eco-system and are backed by VCs with deep REP pockets.

Am I missing any other reasons to build on top of Augur? Because it just seems like a really expensive, slow, and unpredictable back-end for a derivatives platform, especially one that is centralized to the degree yours is. Don't get me wrong, some degree of centralization is clearly needed here, I just don't see what Augur is bringing to the table for this project.

In any case, good luck!

5

ntomaino 11 hs ago

paul and team can better address your specific questions, but i'm one of the investors involved in the project and thought i'd share my 2 cents the simple answer for why build on top of augur imo is that there's a strong protocol and community behind augur you're right in your assessment that as a centralized company, you can't directly benefit from a lot of the killer features a community owned and operated protocol can. A truly open, global product is not achievable when you're a company that needs to comply with different regulations around the world. This was also the case when we launched coinbase to make it easy to buy and use btc; a lot of the purists thought (and still think) that coinbase was useless, because users can't get any of the true benefits of cryptocurrency (open, global, censorship resistant) when using the product. if you go back to r/bitcoin in 2013 a lot of this sentiment was shared. the reality though is that while there are many disadvantages to being centralized when building financial products, there's one major advantage: you can coordinate quicker and build a better product faster. this is what the veil team has done; they started on this less than 6 months ago and in a short period of time have built a quality product for people in the appropriate jurisdictions to get exposure to augur markets. they certainly don't \*need\* to be on augur and i suspect that they shift to another prediction market protocol if a better one emerged, but i think there can be a positive symbiotic relationship btw augur and veil where veil benefits from from momentum of the protocol and community around augur and augur benefits from gaining a lot of new users who the lower level app is too clunky to use 

3

blackestadder 1 h ago

I appreciate your response, thank you. You're right I hadn't accounted for the benefit of leveraging Augur's community. And I agree that if Veil becomes widely used there is a good chance they will shift to another prediction market protocol.

2

Poyo-Poyo Yesterday

are you the guy who made Guesser?

2

joselfgaray 1 h ago

I can verify he isn't lmao

1

Poyo-Poyo Yesterday

please press F. this man had been writing this thing up for weeks getting it ready for this moment.

1

throwawayp892734089 Yesterday

I think they plan to do things besides derivatives markets, it's just hard to do anything else for now because bets still use ETH instead of DAI.

1

laugrig Yesterday

I would've taken your comments more seriously if your Reddit account was not 3 days old.

3

PlayedCougar Yesterday

he has a couple of good points. why the attack?

8

saddit42 Yesterday

looks awesome so far! Great job!

2

Tyre77 Yesterday

This feels like one of the first crypto projects built as a product company vs. an infrastructure company selling to other crypto-enthusiasts. It's cool to see third-layer products built on lower level protocols (0x and Augur, themselves built on Ethereum). Definitely makes a stronger case for the potential impact of Ethereum and crypto.

23

reuptaken Yesterday

~~Not working for me (503)~~

1

cointon Yesterday

>medium.com/veil-b... [https://kovan.veil.co/](https://kovan.veil.co/)

1

pfletcherhill Yesterday

Still having issues? Jump into the Veil discord for support: [https://discord.gg/aBfTCVU](https://discord.gg/aBfTCVU)

3

reuptaken 6 hs ago

Looks like it was temporary.

1

25 9 18

Chandra Duggirala MD - @csentropy

RT @BobMcElrath: So how does one "postpone" such an upgrade with one day to go? Do they have this control? Or is it that it wasn't going to activate anyway? https://t.co/yY6tYrkR0l

2 37

Henry Brade ⚡ - @Technom4ge

RT @aantonop: Ethereum Constantinople hard fork postponed because of security issue - all node operators need to upgrade node software TODAY to prevent being forked out of consensus - https://t.co/cpxtpziDot

147 279

an overwhelming surplus of diggity - @spudowiar

oops https://t.co/9MaFZ0G2iS

0 0

Chris Burniske - @cburniske

RT @lrettig: PSA: Constantinople is being postponed out of an abundance of caution due to a security issue. Instructions and information follow. If you are a node operator, *you need to follow these steps immediately.* Please help get the word out. https://t.co/20zkBWmWd0

21 57

Andreas M. Antonopoulos - @aantonop

Ethereum Constantinople hard fork postponed because of security issue - all node operators need to upgrade node software TODAY to prevent being forked out of consensus - https://t.co/cpxtpziDot

27 37

Anne Connelly - @Anne_Connelly

RT @ethereum: [SECURITY ALERT] #Constantinople upgrade is temporarily postponed out of caution following a consensus decision by #Ethereum developers, security professionals and other community members. More information and instructions are below. https://t.co/p2znO8HGxf

717 1011

Samson Mow - @Excellion

RT @jmcorgan: ok can you guys stop upgrading https://t.co/JGQVWk8k5m

15 75

Dovey Wan - @DoveyWan

https://t.co/5LtP4CibWS anyone who’s updating or has updated please be alerted. seeing how this has been communicated and handled I totally understand the pain of whoever running ETH full node for last 3 years you have all my respect

0 1

cacheonomics - @CacheBoi

RT @jmcorgan: ok can you guys stop upgrading https://t.co/JGQVWk8k5m

16 90

Dan Held - @Dan-Held

Commands sent via the decentralized official @Ethereum handle and via decentralized official blog https://t.co/rnVA1RpGi5

20 113

Aaron van Wirdum - @AaronvanW

RT @jmcorgan: ok can you guys stop upgrading https://t.co/JGQVWk8k5m

6 32

Ragnar Lifthrasir ⚑ - @Ragnarly

RT @jmcorgan: ok can you guys stop upgrading https://t.co/JGQVWk8k5m

11 63

Santi - @santisiri

RT @lrettig: PSA: Constantinople is being postponed out of an abundance of caution due to a security issue. Instructions and information follow. If you are a node operator, *you need to follow these steps immediately.* Please help get the word out. https://t.co/20zkBWmWd0

3 6

Joseph Lubin - @ethereumJoseph

RT @ethereum: [SECURITY ALERT] #Constantinople upgrade is temporarily postponed out of caution following a consensus decision by #Ethereum developers, security professionals and other community members. More information and instructions are below. https://t.co/p2znO8HGxf

308 402

Jonny Moe - @JonnyMoeTrades

@ThomasAFink @crypto_rand I wasn't watching it live, but according to the Ethereum blog, the decision was made at 3:08pm ET, 38 minutes after the sell off started, and published via blog channels at 4:30pm ET. https://t.co/SvI8KH24Wr

0 0

Christopher Wheeler - @Stocktrader

RT @ethereum: [SECURITY ALERT] #Constantinople upgrade is temporarily postponed out of caution following a consensus decision by #Ethereum developers, security professionals and other community members. More information and instructions are below. https://t.co/p2znO8HGxf

94 169

Preston Byrne - @prestonjbyrne

Postponed? According to whom? Repeat after me: Ethereum. Is. Centralized. https://t.co/eKBWBXeHW6

13 74

Taylor Monahan - @tayvano_

RT @ethereum: [SECURITY ALERT] #Constantinople upgrade is temporarily postponed out of caution following a consensus decision by #Ethereum developers, security professionals and other community members. More information and instructions are below. https://t.co/p2znO8HGxf

120 141

Mattzballs 3 hs ago

#yikes

1

TheJesbus 7 hs ago

Damn, I just removed all my manual SSTORE optimizations. Guess I'll Ctrl + Z them back in xD

2

KIN2CanDo Redditor for 3 months. Yesterday

Thanks to the people reviewing code and saving us all again from a DAO type hack

3

Greatprogrammer Yesterday

Just a few more blocks to go...

1

akoumjian contract dev Yesterday

32 hours to get everyone to update their nodes to versions of software which aren't released yet. Unbelievable. All to protect a re-entry attack not yet found on-chain in the wild. It's a tough decision, but this kind of thing makes me really skeptical about the practicality of this kind of upgrade process for a distributed network like this.

1

Bradley195 Yesterday

Noob question but what’s the reason people have to update their nodes, if they’re not doing a form anymore?

1

flygoing Yesterday

Because the version they have I'd programmed to fork St block 7080000. They need to upgrade to the version that removes the fork

2

psswrd12345 Yesterday

I will be running a "forked" geth constantinople node out of protest until the actual fork occurs. This is the only thing I know how to do in protest beyond bitching on reddit. Get it fixed, people. Stat.

1

DexVitality Yesterday

Sad about another delay but totally necessary with the potential of re-entrance vulnerabilities... I guess moving forward with this... perhaps they can have a little more time to discuss the potential PoW change whether ProgPow or another EIP for when they set the HF date, I’m assuming it will take around a month or so at least in this delay?

3

Rappingthegame Yesterday

Lol

1

UndeadWolf222 Yesterday

While disappointing, I appreciate the fact that it was discovered before it was on the mainnet. Keep up the hard work guys.

5

stevieyongieg Yesterday

Nothing is easy in the world of blockchain and smart contracts. What matters is the solid team and foundation behind ETH. It's better to realize the vulnerability now than later.

5

neuromancer4867 Yesterday

And back to $80 we go. Best possible outcome but still a terrible thing.

0

parasitemite Yesterday

Will probably go to $200 since it was a good outcome and shows the team is not afraid to face an issue quickly.

0

atown36 Yesterday

Can I have what you're smoking?

10

spucci 10 hs ago

The parroting responses are absolutely astounding aren’t they? And how dare any customers express anything other the patting the Devs on the back for a job well done!

2

datwolvsnatchdoh Yesterday

puff puff pass plz

2

florianleber Yesterday

Indeed a disaster. The massive eth inflation is now taking us below usd 100 again.

4

superflyj416 Yesterday

Can anyone make an educated guess on how long this delay will be? Are we talking weeks or months? And why do you think that?

3

insomniasexx MyCrypto - Taylor Yesterday

Exact timing will likely be decided on Friday. It can't be that long off because the difficulty bomb is set to go off at some point. So I would say that the delay will last longer than 3 days and shorter than the impending difficulty bomb timeline, if I had to give it my best guess.

7

5chdn Parity - Afri Yesterday

I say, it lasts longer than 2 weeks and shorter than 6 weeks, if I had to give it my best guess.

4

Folx_Ughington-Yikes Yesterday

Like a user said in the other thread: An upgrade oracle could have been a nice last line of defense to have. For anybody that doesn't know the oracle would be a smart contract where a few people that are responsible for the fork can give a go/no-go signal all the way up until the final block in case a critical vulnerability shows up.

9

METALFlNGERS Redditor for 12 months. Yesterday

Contracts that increase their probability to being vulnerable are contracts that utilize a transfer() or send() function followed by a state-changing operation. An example of such a contract would be one where two parties jointly receive funds, decide on how to split said funds, and initiate a payout of those funds.

3

redundantrevolution Yesterday

Hey do you happen to know what will happen to maker dao cdp's? Is there any risk of having one open during this time? 

2

sandakersmann Yesterday

Update your nodes folks!

2

millerkm87 Yesterday

As much as I was looking forward to the upgrade, postponement shows the maturity of the ethereum community. Timing is unfortunate, but I am thankful this was caught, communicated, and appropriate action was taken. Thank you Devs for your continued commitment!

63

spucci 11 hs ago

Catching it now does not show maturity. It shows disorganization in their QA process that almost allowed a bug that could have ruined it’s brand name and have had huge financial consequences. Sure we are all glad they caught it but I have heard the same sugarcoating statements made every time the upgrade is delayed.

0

ascendantlogic 3 hs ago

No organization has QA that catches 100% of the bugs. It doesn’t happen.

4

mWo12 Yesterday

Well, this and the November failed hard fork make you wonder, how many other bugs like this are present. If not now in Constantinople, then in future during much more complicated upgrades, to PoS for example.

1

thepipebomb 11 hs ago

I wouldn't hold my breathe for PoS being ready any sooner than 5 years.

2

psswrd12345 Yesterday

It is really, really hard to stay positive after yet another delay. Yet another indefinite delay for reasons that should have been identified during the last delay. Really disappointed. Of course it is better to postpone but really hard to keep the faith right now. This feels darker than after the DAO fork, tbh...

13

c-i-s-c-o Yesterday

lol, you sound like a little cry baby, tbh.... Building the decentralized web won't happen overnight, nor without it's fair share of setbacks. Get used to it or focus on something else less volatile.

0

psswrd12345 Yesterday

You really need the insult to make your point? This is the first time I've ever seriously questioned Ethereum's ability to transition from PoW to PoS. Sorry if this offends you, buddy.

6

celeduc Yesterday

Get real.

0

Stobie Yesterday

Delay will be about a few weeks, not that bigger deal.

0

psswrd12345 Yesterday

About a few weeks literally means nothing. Developers need to do a better job communicating time frames, but unfortunately their credibility has been shot.

0

Stobie Yesterday

It means you can have high confidence of 2 - 4 weeks, if you think it literally means nothing you are literally an idiot. Afri said he was optimistic it could be done in a couple weeks. When research tasks are involved estimates have massive variance, there are unknown unknowns so it's impossible to be accurate. If you're this depressed about it go join another community for weak people.

0

thepipebomb 10 hs ago

> you are literally an idiot Pot meet kettle.

0

Stobie 10 hs ago

What are you still doing here? Pure ashes.

0

thepipebomb 10 hs ago

What are you doing here?

0

robodebt Yesterday

This far exceeded the gas stipend of 2300 sent along when calling a contract usingtransfer or send.

Can someone explain briefly how this limit is generated or imposed? It sounds like its hard-coded in solidity output, and switched off/on based on the specific method name encountered ('send' or 'transfer' ) ?

4

vbuterin Just some guy Yesterday

It's a protocol rule that a minimum of 2300 is required (or rather, charged to the caller and given to the callee) automatically.

7

sandakersmann Yesterday

Update your nodes folks!

1

sandakersmann Yesterday

Update your nodes folks!

8

sandakersmann Flippening Yesterday

Update your nodes folks!

9

aznar Yesterday

Good catch, hardforks are no joke!

8

SpacePirateM Yesterday

Thanks for keeping the community at large aware of the issues, which helps reduce FUD.

I have full confidence in the Devs to resolve these minor issues.

10

spucci 10 hs ago

How will it not increase FUD? Letting this slip until the night of the upgrade does not instil confidence.

5

SpacePirateM 10 hs ago

They issued a clear statement, outlining the problems and the steps they were taking to address these problems. This prevents unfounded rumors and FUD. Imagine if they instead went silent and delayed the fork without giving reasons. FUD would be like a wildfire. Although the situation is extremely unfortunate, i think the right approach was taken to deal with the issue

3

spucci 10 hs ago

Ok I understand your statement now. The communication should help reduce FUD. The fact they found it this late in the game and the multiple delays do not.

4

consideritwon Yesterday

Quality blog post. A couple of questions if I may....

We have other operations that can lead to re-entrancy type attacks and which are often dealt with by avoiding certain patterns. Is the intention to continue to deploy this EIP once it is confirmed there are no existing contracts impacted and deal with the re-entrancy in this way? Or is it back to the drawing board for the EIP?

Secondly, on how this slipped through for so long. Is there any way automated testing can be improved to catch this sort of thing or is it something that needs to be manually discovered? Any lessons learned?

19

spucci 10 hs ago

Yes it’s called quality assurance. ;)

1

insomniasexx MyCrypto - Taylor Yesterday

> Is the intention to continue to deploy this EIP once it is confirmed there are no existing contracts impacted and deal with the re-entrancy in this way? Or is it back to the drawing board for the EIP? These are great questions and being discussed on gitter. I pulled some key quotes (below), but here is a good place to start: https://gitter.im/ethereum/AllCoreDevs?at=5c3e3fcc20b78635b62b9798 Conversation continues for quite some time on possible implementation strategies. Further discussion on how to address this EIP: https://ethereum-magicians.org/t/remediations-for-eip-1283-reentrancy-bug/2434/3 I believe plan of action beyond delaying the fork will occur on Friday's All Hands call (or whatever its called). > Secondly, on how this slipped through for so long. Is there any way automated testing can be improved to catch this sort of thing or is it something that needs to be manually discovered? Any lessons learned? Some light conversation around this has happened further discussion is certainly necessary. Because the discussions thus far have been so focused on short term (do we delay. okay we delay. okay shit we have 30 hours to get everyone updated again), someone from Ethereum Cat Herders made a github issue for follow-up discussions and a retrospective here: https://github.com/ethereum-cat-herders/hard-fork-checklist/issues/1 --- Key quotes: > Yoav Weiss 12:15 PM > Since we're delaying the fork and have time to fix it now, I'd like to re-propose the fix I brought up earlier: Accept the EIP to lower the SSTORE fee, but add a condition that reverts storage access if gasleft < 2300. This preserves the original intention of the EIP (lowering the fees) while preventing exploitation. It is unlikely that a legit transaction will need to access storage while gasleft < 2300. > Nick Johnson @Arachnid 12:21 > I really like Yoav's idea; in my mind it's the purest expression of the current invariant (that 2300 gas is not enough to make a state change). > Alex Beregszaszi @axic 12:21 > I think it is a reasonable workaround to fix it, but we also need to keep in mind it is another tiny condition introduced into the design. Will this limit us even further in the future? > ledgerwatch @AlexeyAkhunov 12:39 > Also, regarding the intent of EIP-1283 (which was previously EIP-1087), it was mainly to enable inter-frame communication within the same transaction. I wrote an alternative EIP, which has the same intent, but does not have the issue of EIP-1283 (1087): https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1153.md. Of course, I did not know about the the problem with EIP-1283/1087. What I am saying - if the demand for this change is really high, we can still do it, and even cheaper > Jordi Baylina @jbaylina 12:31 > For me, this is the best way to transfer ETH without the reentrancy danger: https://www.reddit.com/r/ethdev/comments/6ekz2j/a_secure_way_to_make_a_send_in_ethereum/ > Micah Zoltu @MicahZoltu 12:48 > While I am a fan of backward compatibility, I'm not a fan of getting locked in to decisions forever either beacuse people wrote code that makes assumptions it shouldn't have made. I can appreciate delaying a change like this for some amount of time to give people time to deal with it, but I'm not a fan of asserting that "we will always have this debt because one or more people may have made an inappropriate assumption while writing code". Knowing that the stipend value was set at the EVM layer may be enough to gain my support in delaying this EIP for a whole HF cycle, but I'm not convinced that we should permanently hack around it or indefinitely support the idea that < stipend means no storage changes. > Nick Johnson @Arachnid 12:49 > I mean, I'm not a fan of that either. But I don't think breaking existing code like this is an option we have. Part of the point of deploying on Ethereum is that your code will keep functioning the same way tomorrow as it does today. It'd be particularly nasty to make non-backwards-compatible changes in an environment where there's no built in mechanism for upgrading code. One of the big selling points of using Ethereum is that if I want, I can eliminate all trusted parties from my code: no owner, no trusted upgrade mechanism, nothing. We break that if we start introducing changes that retroactively make secure contracts insecure. > Micah Zoltu @MicahZoltu 12:52 > I have always suspected that Ethereum will eventually need to fall into that sort of mode (I call it Enterprise mode), where there are strong guarantees of no breaking changes. I guess I had hoped that we weren't there yet because I think Ethereum still has a lot of improvement necessary that won't be possible under that sort of constraint. Perhaps the saving grace is Ethereum 2.0? We can run Ethereum 1.x in Enterprise mode indefinitely, yet gain benefits from lessons learned in Ethereum 2.0 where we can make all sorts of breaking changes. > Nick Johnson @Arachnid 12:56 > I think we've always been in "no breaking changes" mode, personally, ever since mainnet launch. People use the network to do real things with real stakes. And yes, 2.0 gives us lots of opportunity to make things better.

10

McDongger 8 hs ago

What are the ethereum cat herders and who chose this name? It certainly doesn’t help make this space understandable for newcomers with names like this.

1

consideritwon Yesterday

Thanks for taking the time to provide these quotes and link, will be sure to check out the gitter channel in future. Good to know a retrospective will follow also, appreciate it was a bit of an odd vulnerability that might not be so easy to catch compared to the usual consensus bugs.

3

Xazax310 Yesterday

My question exactly, how was this missed? Glad they caught it and are fixing it. That could be been a small disaster.

10

mWo12 Yesterday

That's interesting question. There are three teams working on eth main implementations. Aleth and geth are both officially supported by EF, while Parity is separate. And none of the teams cough this, just like the issue in november's failed fork was unknown until fork happened.. This can make you think, how many other issues like this are present, but not yet discovered or disclosed?

0

vbuterin Just some guy Yesterday

All of the really nasty security issues that we had have been around the _interactions_ between different components. The quadratic DoS attacks combined EVM memory and the call stack frame or reverts and the call stack frame, this potential threat arose because of interactions between the default gas in send, SSTORE gas costs and re-entrancy issues. So if you have N protocol features, there are N^2 ways they could potentially break. I would say my personal takeaway from this is to be much more explicit about writing down invariants (properties guaranteed by the protocol) that we rely on so we can check against them when changing things.

38

asic-resistant 3 hs ago

That's a really fancy way of saying "Most bugs are complicated, so we didn't catch this one despite it staring us in the face from day 1". My takeaway would be keep it simple.

2

a_random_user27 11 hs ago

> if you have N protocol features, there are N^2 ways they could potentially break. This seems to assume one particular model of how things break: if you have N protocol features, there are O( N^2 ) potential interactions between pairs of them...but then there are O( N^3 ) potential interactions between triples of features, O( N^4 ) interactions between groups of four features, etc etc. If unexpected outcomes could result from combinations of several features, the number of potential problems to think about is a lot more than N^2.

4

vbuterin Just some guy 10 hs ago

True, it was a model that's wrong but useful like all models are. Though I don't think the rate at which potential errors appear is that much higher than N^2; if that were the case, then much more complex systems that exist in production today would not survive a nanosecond.

3

kekcoin 39 mins ago

O(2^N) >>> O(N^2)

2

Xazax310 Yesterday

I see, thanks for the breakdown.

2

aakilfernandes - @aakilfernandes Yesterday

Yikes. And this is why we don't use "clever" solutions.

For some context, gas (or operations expense) usage was never designed for re-entrency protection. After the DAO attack, in order to prevent re-entrency attacks the Solidity interpreter limited the gas of external calls.

It's clever way to solve the problem. However now when we're trying to change around the gas for certain operations, it's jeopardizing previous contracts that relied on this "clever" solution.

To be honest, this is really bad, cause I'm not sure how Ethereum can ever safely adjust gas.

Edit:

I'm not sure how Ethereum can ever safely adjust gas... until they go back and "monkey patch" all the smart contracts that used the external gas call limit. Since we only can see the compiled code, there's no real way to know if a deployer explicitly wanted that external gas call limit, or was just using it for re-entrency protection.

panarky - @panarky Yesterday

Detail on how the exploit works

https://medium.com/chainsecurity/constantinople-enables-new-...

Animats - @Animats Yesterday

"We want you to install this new version of a program that handles your money by tomorrow or else, and we haven't finished the patch yet."

What could possibly go wrong?

xiphias2 - @xiphias2 Yesterday

,,key stakeholders around the Ethereum community have determined that the best course of action will be to delay the planned Constantinople fork that would have occurred at block 7,080,000 on January 16, 2019''

Who are those key stakeholders? And what happens if they don't agree?

ascendantlogic - @ascendantlogic Yesterday

Glad they caught the bug before the fork instead of after.

geoah - @geoah Yesterday

Was this vulnerability disclosed beforehand to any of the eth foundation or other parties or did they learn about this after it went public? There doesn't seem to be any mention about this being responsibly disclosed.

Nanocurrency - @Nanocurrency Yesterday

I wish they could have continued without it. Issuance reduction was really important, we've had too much selling pressure for too long. It might have eased it.

kpcyrd - @kpcyrd Yesterday

Is there a CVE yet?

gammateam - @gammateam Yesterday

How much did they win from the Ethereum Foundation's bug bounty program? I can't tell how things are valued

Show all comments on Hackernews

13 3

pyggie 9 hs ago

Given that so many Solidity vulnerabilities depend on reentrant calls, and that such vulnerabilities are so hard to find even with careful audits, is there any discussion about allowing the developer to disable them entirely? I did find this EIP that suggests a new function modifier to prevent a function from having two instances on the same call stack:

https://github.com/ethereum/EIPs/issues/122

Or, you could flip this around and say that reentrant calls are forbidden by default, and the developer would enable them with a keyword, like we have "payable" for receiving funds.

2

Guy-Lambo Yesterday

I dont understand this line of code in the attack contract:

PaymentSharer x = PaymentSharer(a);

Won't this line of code fail since it doesn't match the constructor's parameter (i.e. init(uint id, address payable _first, address payable _second))?

1

akira_fmx Yesterday

Why is this a problem in Solidity and not in other clients?

1

robodebt Yesterday

This far exceeded the gas stipend of 2300 sent along when calling a contract usingtransfer or send.

Can someone explain briefly how this limit is generated or imposed? It sounds like its hard-coded in solidity output, and switched off/on based on the specific method name encountered ('send' or 'transfer' ) ?

1

earlzdotnet 7 hs ago

It's not "hard coded" per se, but Solidity uses this amount of gas by default for transfers/sends. You can override it, but it must be done explicitly.

1

robodebt Yesterday

This far exceeded the gas stipend of 2300 sent along when calling a contract usingtransfer or send.

Can someone explain how this limit is generated or imposed? It sounds like its hard-coded in solidity output, and turned off/on based on the method name encountered ('send' or 'transfer' ) ?

1

WeaponizedMath Yesterday

Thank God we don't have a single core team of devs making all decisions and the community has say

16

hitmybidbitch Yesterday

suggest going to another platform if thats how you feel. that aint changin

0

WeaponizedMath Yesterday

Try reading my post again, slower

8

x_ETHeREAL_x Yesterday

This is a security flaw exploitable by developer error and not a problem with the protocol. This issue can only occur in a narrow edge case if and only if you make an insecure assumption (.transfer or .send must consume enough gas that no state change can occur). Why would anyone rely on the gas price of a state change to ensure that one cannot happen in a fallback function transfer? There's no evidence anyone made such a bad assumption. It's not a protocol error, it's a possible dev error that is unlikely to have ever occurred.

It's like if you have a buggy piece of code that after some cludgy hack seems to work on a specific machine setup and so you just assume the machine won't change and go with it; but then the machine updates its OS and the code completely breaks. Your code was wrong, you made a bad assumption that the machine would never change. That's this situation...

3

1solate Yesterday

Considering the only thing you can rely on is that gas stipend limitation, there's not much a dev can do to prevent this. What's the options here? Check for code at the destination address? Then that prevents users from using contracts with is kind of an Ethereum anti-pattern if you ask me.

1

ItsAConspiracy Yesterday

After the DAO hack I saw a lot of recommendations to prevent reentrance attacks by using `.send`.

2

hitmybidbitch Yesterday

Sounds like core devs are drafting a memo to confirm a delay and further testing.

5

maxitrol Yesterday

>already reporting a delay. Like I said months ago... less Twitter and more work. 100 of them cannot write a good code in 2 years... ah. Free fall for eth

0

destinationexmo Yesterday

coindesk is already reporting a delay.

1

hitmybidbitch Yesterday

yip

1

5chdn Parity - Afri Yesterday

It's confirmed, stay tuned for announcement.

6

j-brouwer Yesterday

I have tried performing a similar attack on ropsten. This does not work. I think ChainSecurity has found a bug into ganache / ethereum-js.

The EIP states that storage slots are dirty if these are already changed in the current transaction. However, I think that with transaction the current CALL is meant and not the entire transaction. I would like to know if this is the case since this is not discussed very clearly in the EIP.

Pinging /u/vbuterin /u/nickjohnson /u/5chdn /u/Souptacular hoping to get this clear.

EDIT: My attack is apparently wrong. EDIT2: It is wrong because I do not change the storage field in the attack contract. This means that this field, when it is changed later on (in the transfer) 5000 gas is used. If I had changed it earlier (in the initial contract call) it would be marked as dirty and then it would only cost 200 gas which would not end up into an "out of gas" issue. As a feedback for ChainSecurity (and possibly poster /u/hitmybidbitch ) please show that this works on actual environment as geth/parity instead of test environment like ganache. In this case Ropsten would "prove" it.

The truffle test suite which is provided by ChainSecurity works. I have confirmed this on ropsten.

9

maninthecryptosuit Yesterday

I think u can't page more than 3 people in a single message.

1

shemnon Yesterday

Looks like it [does work](https://ropsten.etherscan.io/tx/0xeb2f153c618f86c8a097b6ea26837b0b410ac1d28fdb2046108784e791eb3aa8) \- posted by the article author onto ropsten. Not just a ganace/ethereun-js issue.

3

mhswende Ethereum - Martin Swende Yesterday

No, it's the entire transaction

9

j-brouwer Yesterday

Thank you. So this does mean that this re-entrancy attack is possible?

3

mhswende Ethereum - Martin Swende Yesterday

yes

3

j-brouwer Yesterday

Can the writers of this article perform this attack on ropsten and show that this is indeed the case? I have tried performing an attack like this but I ran out of gas. Changing a storage value from 1 to 2 costs me 5000 gas on ropsten.

1

hitmybidbitch Yesterday

potentially, but not able to fully vet during the 36hr period i would think. no reason not to spend the 3-4 weeks necessary to fully test vs rushing something out and potentially having a security hole that could be a repeat of the DAO.

5

j-brouwer Yesterday

The truffle tests are around which should take a few minutes to setup on ropsten.

1

j-brouwer Yesterday

I have never thought of it this way but this starts to ring some alarm bells to me. A developer could expect in the past that transfer and send are re-entrancy safe. However, this hard fork changes this. Why did no one raise this point in the EIP? Why is it implemented like this? While the article says they did not find any contracts which are vulnerable I am sure that there are lots of vulnerable contracts out there. Of course the larger ones have been checked by ChainSecurity but small contracts could be vulnerable!

EDIT2: Reverting my original comment. The attack is possible. Since this opens up a lot of edge cases and re-entrancy attacks since developers assume that transfer and send defend against these it should indeed be delayed. A simple example is in an audit: if an auditor sees that transfer or send is used while afterwards storage is changed (making it susceptible to a re-entrancy attack) they can comment this to the developer but also raise that "this is not an issue since these calls prevent against these types of attacks". These comments are just for the future that the developer does not accidentally call another contract (and hence forward all gas instead of 2300) and then end up with a re-entrancy. I am fully behind the delay of the HF because of this.

21

besoisinovi Yesterday

Nobody raised a point, probably because nobody was aware of this side effect. Now before everybody starts panicking, this does not mean that .transfer() and .send() all of the sudden vulnerable to reentrancy attack, a lot of things have to line up in order to execute this kind of an attack, that's why currently nobody found a contract that is vulnerable (not saying there aren't any). Whenever you make .transfer() or .send() to an address that is an contract, you are calling it's fallback method, a reentrancy attack is when an attacker makes a contract where the fallback method calls the contract again, possibly taking money again if the state isn't updated before the call. To stop this .transfer() .send() allow very small gas 2300 usage, so an attacker can't do much in the fallback method (like they say in the article, before the lowest cost of the state change was 5000 gas), with the new fork a memory slot that has already been modified in the same transaction, when modified again costs only 200 gas. So only if you have a contract that is updating the state after .send() .transfer(), and has a function that can be executed at less than 1600 gas (this is very low) and that same function somehow affects the state that conflicts with the original function being called. So I'm not saying this is not possible, certainly is and proper security precautions should be set in place, but this doesn't mean that .transfer() and .send() are now totally useless in protecting against reentrancy just that a new edge case has occurred. Kudos for the team @ chainsecurity for a great find.

20

cratchit Yesterday

I’ve been trying to understand this bug, and the one thing I’m confused about is why this would only manifest if you are trying to change state after the send or transfer. Can someone clarify?

1

1solate Yesterday

> To stop this .transfer() .send() allow very small gas 2300 usage, so an attacker can't do much in the fallback method (like they say in the article, before the lowest cost of the state change was 5000 gas), with the new fork a memory slot that has already been modified in the same transaction, when modified again costs only 200 gas. That seems like a poor choice of protection that is only limited by the efficiency of the EVM. Was this intentional, or a side effect providing security? What are the proposed solutions that aren't just more gas limitations?

5

mcgravier Yesterday

> To stop this .transfer() .send() allow very small gas 2300 usage Relying on gas usage for security doesn't sound like a good idea

20

WeaponizedMath Yesterday

That's literally the entire purpose of gas.

0

mcgravier Yesterday

Nope. Purpose of gas is spam protection and transaction priority. Preventing smart contract exploits was never the scope of gas mechanism

12

AQuentson Yesterday

But if it does prevent it, what does it matter what the scope is?

0

mcgravier Yesterday

[Relevant xkcd](https://xkcd.com/1172/)

8

alsomahler Yesterday

New features need to be used safely. You can always write bad smart contracts. Great write up to warn devs using the new codes to avoid making some mistakes.

7

hitmybidbitch Yesterday

sounds like constantinople will be delayed. makes sense to prioritize any potential security concerns.

0

alsomahler Yesterday

Where did you read that?

4

5chdn Parity - Afri Yesterday

Please wait for further announcements. We are confirming the report, investigating the severity, and considering next steps.

14

earlzdotnet Yesterday

When is Ethereum going to let contracts disable or detect reentrancy? There's so many easy ways to prevent this that Ethereum just does not expose enough info for. Off the top of my head:

Expose callstack depth (function can check if they aren't the originally called contract and exit)
Expose callstack address count (function can check if their own address is in the callstack more than 0 times)

7

TheJesbus Yesterday

IMHO we shouldn't strive to prevent reentrancy. The equal abilities of human accounts and smart contracts is a major feature of Ethereum. Instead, you should only perform calls to other contracts when the state of the current contract is valid and finalized, i.e. ready to receive another function call, and you shouldn't assume that your contract state is the same after an external call. I guess we need a smart contract language which enforces these things, or a lot of work on additional compiler warnings.

0

earlzdotnet Yesterday

You could use the same rationale for not wanting to include the new static_call stuff in EVM, and probably a few other features. Not everything can be fixed by expecting compilers to be smarter and humans to be closer to perfect. There are some use cases for reentrancy, but many concepts have no need for it. For instance, paying out.. idk, an escrow. Is there ever anything to be gained by allowing contracts paid to call back into the escrow program? It's similar in traditional programming to not wanting to implement optional memory protection because there are some obscure use cases that can only be done without memory protection, despite how many attack vectors there are without it. edit: and just to rant a bit further. There's a ton of use cases for passing all gas upon transfer(), much more than reentrancy. Yet, it was made non-default because of how many security issues it has. Why has the same level of scrutiny not been given to this?

1

HRitzdorf ChainSecurity Yesterday

You can also use the new reentrancy guard inside OpenZeppelin: https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/utils/ReentrancyGuard.sol This is based on the work of different people.

1

blackestadder Yesterday

After Constantinople, won't your implementation cost a lot more gas than the naive approach of locking a mutex before the function and unlocking it after? For example: [https://github.com/0xProject/0x-monorepo/blob/development/contracts/utils/contracts/utils/ReentrancyGuard/ReentrancyGuard.sol](https://github.com/0xProject/0x-monorepo/blob/development/contracts/utils/contracts/utils/ReentrancyGuard/ReentrancyGuard.sol)

2

earlzdotnet Yesterday

Oh forgot about the `_;` bit for modifiers, so it is possible to ensure a mutex is always reset at function end. Unfortunately this is still too expensive to be reliably used in the fallback function (it can only be used if the mutex has already been changed previously by the contract before the fallback is called)

2

earlzdotnet Yesterday

Quick selection of suitable EIPs for this too: * https://github.com/ethereum/EIPs/issues/128 (open, but with "review needed" tag removed, thus dead) * https://github.com/ethereum/EIPs/blob/master/EIPS/eip-3.md (not directly compatible with current Ethereum, but would've been a rough fix in the past) * https://github.com/ethereum/EIPs/issues/122 (open, reviewed, dead?) * https://github.com/ethereum/EIPs/issues/118 (a more extreme approach, mostly disapproving comments, open, reviewed, dead?) * https://github.com/ethereum/EIPs/blob/ed621645c8f3bc5756492f327cda015f35d9f8da/EIPS/eip-1153.md .. Holy hell, some of the [inspiration](https://ethereum-magicians.org/t/eip-transient-storage-opcodes/553/6) for the SSTORE accounting change comes from this EIP which was intended to fix reentrancy problems. Wow, irony Also, a bonus: this comment basically revealed this exploit (though using storage refunds instead of new semantics) back in May 2018 https://github.com/ethereum/EIPs/issues/1048#issuecomment-385830642 To be fair, there is a way to prevent reentrancy, in some cases, using a mutex in storage. Not sure how much this would end up costing the contract in final gas costs, but a mutex can be set in the contract, then cheaply read in the fallback function. However, this doesn't help in the case where the fallback function is made to call itself, as the mutex can not be reliably set from the fallback function.. It also relies on the programmer to put a lot of risk on bricking their contract if a programming bug allows for the mutex to remain set after execution without revert. Solidity doesn't really make this easy either. Though it does the nifty modifier feature so that the mutex can always be set, there is no ability to always call something on exit of a function to unset it.

4

Stay up to date on all things crypto and blockchain

Select

© 2018 Token Daily

Stay up to date on all things crypto and blockchain

Select

© 2018 Token Daily

🙌 Login to Token Daily