carrotsmuggler

@banditx0x Why is it just ev_next and not (1-excess_probabilty)*ev_next in the addition?

All the answers to this quant interview question are wrong or incomplete. Here's how to solve it 👇 We accept any roll above 0.5 * EV_next_roll + 0.5. We can start from the final roll and work back recursively to the solve all rolls. Here's a detailed explnation 🔍: Consider the last roll Let's say this is your last roll. What is your EV? It is $50K. Now consider the second last roll. We know that the EV of the next roll is $50K so we will keep any roll > 50K and otherwise reroll. Calculating EV of second roll What is our EV in during the second roll? - We have 0.5 chance of re-rolling for an EV of $50k - We have 0.5 chance of accepting a number of $50K. Each number between 50k and 100k is equally likely, so the average amount exactly between the max and min - $75k So the expected value is 0.5 * 50K + 0.5 * 0.75 The expected value for the second roll is $62.5k Generalizing to all rolls Let's create a general formula of the above logic that takes in the EV of the next roll and gives the EV of the current roll given optimal play: Instead of representing the EV_next as a number, let's represent it as a portion of the maximum roll, so 100k is 1 and 62.5k is 0.625. This makes the maths easier as $EV is converted to the same scaling as probability (0 to 1). What is the general EV calculation? No matter the roll, the EV is at least EV_next. We account for the EV of rolling higher than EV_next by adding probability of a roll exceeding EV_next multiplied by the average excess value you get when rationally accepting the current roll. EV_current = EV_next + excess_probability * average_excess_value Let's express the above equation in terms of only EV_next: Average_excess_value is average of the minimum acceptable roll that we would accept and the maximum (100k). We know the minimum acceptable value is EV_next so we can use the average between EV_next and 100K: average_excess_value = (1-EV_next)/2 The probability we accept the current roll is the same as the probability it is higher than EV_next. For example if EV_next is 0.7 (70K), then the probability we have a higher roll is 1 - 0.7 = 0.3 excess_probability = (1 - EV_next) Substitute into original equation: EV_current = EV_next + (1 - EV_next)/2 * (1-EV_next) Now let's expand and replace EV_next with n EV_current = 0.5n ** 2 + 0.5 Now we have to start from the final roll where EV = 0.5 and recursively apply this formula to get the EV from 10 iterations ago. Final answer I wrote a python script that outputs uses the formula for all 10 iterations. Here are the thresholds over which you should accept the current roll: Roll 10 must accept Roll 9 62.5k Roll 8 69.53k Roll 7 74.17k Roll 6 77.51k Roll 5 80.04k Roll 4 82.03k Roll 3 83.64k Roll 2 84.98k Roll 1 86.11k cc @ChShersh

@p_misirov 🤫

reply with 🤫 to receive a DM with the magic dark mode command

@elliot_1698 Actually, if you are creating the PDA with an anchor init constraint, its not an issue. Anchor init checks if the PDA is already funded or not. Its only an issue when using the raw create_account of solana

4/ Now, when the protocol tries to create the PDA, the address is taken—owned by the system program. Since it can’t reassign ownership, the protocol can’t use it as intended.

How are my fellow @solana SRs? A few days ago, I encountered an amazing bug in a Private Audit. The bug is tied to Program Derived Addresses (PDAs), and would love to share it with you all in this thread 🧵👇 #Solana #BlockchainSecurity

To demonstrate @burraSec's expertise, we’re offering a free full-day security review/consultation for projects integrating with LayerZero or Arbitrum—whether you’re already deployed or still in development. We’ll thoroughly review: LayerZero: Configuration (DVNs, Executor, and overall integration), functionality (LzRead, OFTs, vanilla OApps, and more). Arbitrum: Native bridge or token bridge integrations, use of retryable tickets, or custom Orbit chains (e.g., custom gas tokens, USDC bridge standard). DM me to schedule your review!

Crazy how you can get paid to learn completely new things. Won my first cosmwasm audit attempt thanks to @code4rena

@0xterrah Was great for learning. Read a ton of different codebases.

@CarrotSmuggler You seem to take part in all available contests (or most of them). Was this good approach (from your current perspective)?

Twitter SR space is full of flashy wins and overnight success. So I decided to share my slow painful grind over the last two years of my life. I don't really like talking $$ figures, but I think some are needed to put things in perspective. A🧵

@00xSEV Your post inspired me to share my experience x.com/CarrotSmuggler…

I don't see much struggle, disappointment, or anyone facing challenges in SRs on X It seems like everyone just makes a lot of money, is happy to work and overwork, and enjoys a happy professional life overall Does anyone know about counterexamples (accs to follow, posts)?

Don't believe in luck, believe in the grind!

Eternally grateful to all the people I have crossed paths with in this space. Some of the sharpest and smartest people I have ever met were at the DSS conferences. I owe ALL of my progress to others since it's their work I studied and skilled up with.

@code4rena Source- c4 chainlink-payment-dec server

New escalation method just dropped on @code4rena

When we say crypto takes security seriously, this is what we mean 🪐 @eigencloud is relentlessly pursuing the pinnacle of security standards with the largest-ever, $2,500,000 code review competition starting in February. More info coming soon.

@milotruck Dlete nodemodules and dependencies. Then it goes down to a few mbs per repo. Need to also remove .git sometimes

How does everyone store codebases from past audits? I have this local folder where I chuck everything into but it's getting huge Maybe a Github repo with branches?