AllCoreDevs - Execution #244

Worked too well 😵‍💫

Reacted to "Worked too well 😵‍💫" with 😂

Ill debug what went wrong with the link

Reacted to "Ill debug what went wrong with the link" with 👍

Reacted to "Ill debug what went wrong with the link" with 🙏

Reacted to "Worked too well 😵‍💫" with 😂

gm!

Invalid zoom refresh token in the pipeline 🫠 will sort it before next round

Gm

Boring is great!

Reacted to "Boring is great!" with ❤️

Reacted to "Boring is great!" with ❤️

Reacted to "Boring is great!" with ❤️

Reacted to "Boring is great!" with ❤️

Reacted to "Boring is great!" with ❤️

Reacted to "Boring is great!" with ❤️

Reacted to "Boring is great!" with ❤️

+1 to Toni

Reacted to "Boring is great!" with ❤️

yeah these are separate tests, agree with Toni that they're distinct goals

Reacted to "+1 to Toni" with 👍

Reacted to "+1 to Toni" with 👍

Reacted to "+1 to Toni" with 👍

toni very confident he can break things XD

Reacted to "toni very confident he can break things XD" with 🔥

Reacted to "toni very confident he can break things XD" with 😂

Replying to "toni very confident he can break things XD" now the pressure is up

Reacted to "now the pressure is up" with ❤️

Reacted to "toni very confident he can break things XD" with 🔥

Reacted to "now the pressure is up" with ❤️

Reacted to "toni very confident he can break things XD" with 🔥

I think we are good for sepolia, unless we find something really bad on devnet 9.

Lido I think? was asking for a few more days for Sepolia, to give some time after the preceding devnet(s)

But they'd have to comment if they care

I don’t think lido runs validators on sepolia?

Yeah I can't speak to their motivation in a precise way

Nethermind has also implemented it @Kevaundray Wedderburn

Reacted to "now the pressure is up" with ❤️

Reacted to "Nethermind has also implemented it @Kevaundray Wedderburn" with 🔥

We finished implementing it, currently testing

Reacted to "Nethermind has also ..." with 🔥

Reacted to "We finished implementing it, currently testing" with 🔥

I do see @lightclient 😂

Reacted to "now the pressure is up" with ❤️

Replying to "I do see @lightclien..." But you didn’t see me ;-)

Reacted to "But you didn’t see me ;-)" with 😁

I couldn’t take a look at it yet

Replying to "I do see @lightclien..." We can follow up with Kev offline. Atm I’m not up-to-date on this one

At some point isn't there bound to be some time during which people have to switch to PQ signatures/etc, otherwise they'll lose access regardless? That seems pretty intrinsic to idea of the PQ transition

Replying to "At some point isn't ..." Yeah I believe protecting this is just overplaying this

Do we have a rough idea on how updating to different deposit address would look like?

nice we get PBT and to rewrite contracts!

Reacted to "nice we get PBT an..." with ❤️

Reacted to "nice we get PBT and ..." with 👀

Only problem I can see is that I would rather not do anything for this issue. But then if we don’t do anything we need to ban BLS before Q-day cause otherwise dead ETH will be happily taken

Replying to "Only problem I can see is that I would rather not do anything for this issue. But then if we don’t do anything we need to ban BLS before Q-day cause otherwise dead ETH will be happily taken" We changing trie before Q-day?

As at that point we are rewriting all the hashes, so is a one off event that opens the door to sort it out in a very constrained, non repeatable way

https://github.com/ethereum/EIPs/pull/12249

Replying to "At some point isn't ..." To clarify, there are two different cases: Existing validators need to switch to PQ at the PQ fork or they lose access. New validators need to deposit in order to onboard For the second point, if we have two contracts (old deposit contract and the new pq deposit contract), there will be a fork where the old one is no longer supported and the new one is (without revert functionality for the old one, people would lose money)

Replying to "Do we have a rough i..." You mean for the ecosystem?

Reacted to "We can follow up with Kev offline. Atm I’m not up-to-date on this one" with 👍

Replying to "Do we have a rough i..." in the sense of, do we have a period deposits to both addresses are processed, then eventually one is deprecated, or should it be immediate?

Replying to "At some point isn't ..." Yeah and I think it’s fine to let them lose money if the soak period is of the order of months/years… we’re not talking about just a day and there are many many ways of screwing up and losing money on chain to grant this one an irregular state transition

Replying to "Do we have a rough i..." Ah this was in the design space, if we are okay with an irregular state transition function, then we can do this. If we are not okay with an irregular stf, then we would need a new deposit address that processes both BLS and PQ, have the ecosystem move to this new contract, then make all BLS deposits revert at the PQ fork

Replying to "At some point isn't ..." There are tons of things that can be done downstream: remove UI on the launchpad/ethstaker. Remove wallet supports to send BLS deposits, censor at the builder, etc.

Replying to "At some point isn't ..." If you bypass all of that you really want to lose money

SETCODEFROM ;)

Reacted to "SETCODEFROM ;)" with ❤️

Reacted to "SETCODEFROM ;)" with 🚀

Reacted to "Yeah and I think it’s fine to let them lose money if the soak period is of the order of months/years… we’re not talking about just a day and there are many many ways of screwing up and losing money on chain to grant this one an irregular state transition" with ➕

some of us want to remove SD in hegota btw :) maybe tcreate op code could help here (its pfi'd)

Reacted to "SETCODEFROM ;)" with ❤️

Replying to "At some point isn't ..." Are you proposing here that we deploy a new PQ contract that is only usable at the PQ fork; but we tell the ecosystem in advance to integrate it into their tooling without enabling it?

and by “ideally” nixo means there will be public shaming otherwise

Replying to "At some point isn't ..." No, if we do this, we should be able to use the new deposit contract before PQ too.

Replying to "At some point isn't ..." Right, in that case the new deposit contract would also work for BLS

Replying to "At some point isn't ..." Yes, the new contract should work for BLS and we need to do it in two forks

well, still imo it's should be either have tcreate and selfdestruct removed OR gas refills meanwhile. And def there's not enough time for tcreate

Reacted to "Right, in that case the new deposit contract would also work for BLS" with 👍

Replying to "At some point isn't ..." To be clear, what does “do it” mean here?

BTW the current PBT proposal changes the way code is stored, from address -> code to codehash -> code which opens up a lot more opportunities for how to think about changing code and making code cheaper (eg. I think there will be no point in the whole concept of delegation at that point)

it will impact ours and other people products making it very expensive on ethereum

Replying to "At some point isn't ..." I think he means: First deploy it, so folks have enough time to switch to this new contract with BLS Then disable BLS and enable the PQ one

Reacted to "and by “ideally” nixo means there will be public shaming otherwise" with 😂

Replying to "At some point isn't ..." Why you need the 2 forks? You can hardcode the deadline of the BLS path in the contract, right?

Reacted to "Yeah and I think it’s fine to let them lose money if the soak period is of the order of months/years… we’re not talking about just a day and there are many many ways of screwing up and losing money on chain to grant this one an irregular state transition" with ➕

Replying to "BTW the current PBT ..." Current EIP has a delegation marker. Which signals whether code is delegation or contract code itself. How would we get rid of delegations overall? Do you have this written down somewhere? Or you mean instead of delegation we just store the ref to the code always and we get rid of 0xef..

Replying to "At some point isn't ..." Yeah this is also possible, though if we get it wrong then we would need to redeploy

Replying to "At some point isn't ..." so we would only be able to deploy the new contract once we are 100% certain about PQ deadlines

You just have to hit a date before, and not after ;-)

Reacted to "You just have to hit a date before, and not after ;-)" with 😁

Reacted to "and by “ideally” nixo means there will be public shaming otherwise" with 😂

But a fork saying you have 6 months (just an example) from now to do it seems quite clean messaging.

Replying to "it will impact ours ..." SELFDESTRUCT was deprecated Shanghai https://eips.ethereum.org/EIPS/eip-6049 including a warning not to use it. https://github.com/ethereum/execution-specs/blob/8dbde99b132ff8d8fcc9cfb015a9947ccc8b12d6/network-upgrades/mainnet-upgrades/shanghai.md

Replying to "At some point isn't ..." is the idea that everyone should exit/re-enter in the PQ contract? If thats the case, its gonna lead to years of exit/deposits queues.

Replying to "it will impact ours ..." This was almost 4 years ago. We should not be accommodating new uses.

Replying to "At some point isn't ..." Why could’t we migrate fork-time?

Replying to "At some point isn't ..." @Csaba I guess having it done via a system call, is not that bad/complex; also the hardcoded number would be dependent on the slot time of when we set it I guess?

Reacted to "This was almost 4 ..." with ➕

Replying to "At some point isn't ..." It is just the new PQ contract should also have a BLS part that times out, preferably before Q-day hits

Replying to "At some point isn't ..." @Barnabas they wouldn’t need to exit/enter

Replying to "At some point isn't ..." how would migration work?

Reacted to "This was almost 4 years ago. We should not be accommodating new uses." with ➕

Reacted to "This was almost 4 years ago. We should not be accommodating new uses." with ➕

Replying to "it will impact ours and other people products making it very expensive on ethereum" https://eips.ethereum.org/EIPS/eip-8298 would mean not paying the cost for deploying code at an address (if that code already exists on chain); and not having proxy cost to use

Replying to "At some point isn't ..." Do you see some specific blocker, or just a generic question?

I’m fairly sure wallets, staking guides, launchpad and such will also provide big blinking warnings against depositing using BLS once people can start deposit using PQ another question is what happens with the validators who are using BLS keys, they should be exited asap to avoid them being compromised and used by an attacker

Replying to "At some point isn't ..." Migration for the irregular stf: Users continue like today and when we hit the pq fork, their bls deposits revert and they will need to call the same contract but a different function “deposit_pq” Migration for new contract: Users will migrate today to the new deposit contract and will be given N months to do so When we hit the pq fork, bls deposits will be reverted and they will need to use the pq equivalent method

Replying to "it will impact ours ..." Doesn’t the account creation cost increase significantly impact more the gas count than self-destruct price changes?

Reacted to "This was almost 4 ..." with ➕

Reacted to "This was almost 4 years ago. We should not be accommodating new uses." with ➕

Replying to "At some point isn't ..." I think we would have to exit validators that have not switched to PQ by the pq fork unless we try to support both PQ and BLS signatures at the same time

Reacted to "I’m fairly sure wallets, staking guides, launchpad and such will also provide big blinking warnings against depositing using BLS once people can start deposit using PQ another question is what happens with the validators who are using BLS keys, from a security pov it feels like they should be exited in the hard fork after PQ deposits are possible to avoid them being compromised and used by an attacker" with 👍

Replying to "At some point isn't ..." yeah we shouldn’t do that

Replying to "At some point isn't ..." We should exit bls by that time

we like the trustless log index!

https://github.com/ethereum/pm/issues/2197#issuecomment-5440015938

Replying to "At some point isn't ..." I think once we exit bls validators, we would need to enable pq on the CL

To me, this is what I’m referring to as the pq fork

Could we keep these updates off the call, and just DM these guys directly ?

Reacted to "Could we keep these updates off the call, and just DM these guys directly ?" with 🔥

Reacted to "Could we keep these ..." with 🔥

Replying to "Could we keep these ..." WHIP.jpg

@nixo I can give an update on the 8130<>8141 collab status

Reacted to "@nixo I can give an update on the 8130<>8141 collab status" with 🙏

Reacted to "@nixo I can give an update on the 8130<>8141 collab status" with 🙏

Reacted to "Could we keep these ..." with 🔥

Reacted to "@nixo I can give an update on the 8130<>8141 collab status" with 🙏

Reacted to "@nixo I can give an update on the 8130<>8141 collab status" with 🙏

Reacted to "@nixo I can give an update on the 8130<>8141 collab status" with 🚀

Reacted to "@nixo I can give an update on the 8130<>8141 collab status" with 🚀

There was a pretty heated breakout room for AA, can’t we do some follow up on that topic 🐘

Reacted to "@nixo I can give an update on the 8130<>8141 collab status" with 🚀

Reacted to "we like the trustles..." with 😍

Reacted to "@nixo I can give an update on the 8130<>8141 collab status" with 🚀

Replying to "There was a pretty h..." you thought that was heated? 😅

Reacted to "you thought that was heated? 😅" with 🤣

Reacted to "you thought that was heated? 😅" with 🤣

Reacted to "you thought that was heated? 😅" with 🤣

Reacted to "you thought that was heated? 😅" with 🤣

Reacted to "you thought that was heated? 😅" with 🤣

Replying to "There was a pretty heated breakout room for AA, can’t we do some follow up on that topic 🐘" We need good old days heated :P

Replying to "There was a pretty h..." 😄

Reacted to "We need good old days heated :P" with 🔥

Reacted to "We need good old day..." with 🔥

Reacted to "you thought that was heated? 😅" with 🤣

Reacted to "you thought that was heated? 😅" with 🤣

Replying to "There was a pretty h..." Lol yeah the discussion was pretty balanced tbh

Reacted to "you thought that was heated? 😅" with 🤣

I think that was a good summary

if we think there is a chance we can converge here, would be good to have weekly until decision, no?

Reacted to "I think that was a good summary" with ❤️

Reacted to "if we think there is a chance we can converge here, would be good to have weekly until decision, no?" with 👍

Reacted to "if we think there is a chance we can converge here, would be good to have weekly until decision, no?" with 👍

Reacted to "if we think there is a chance we can converge here, would be good to have weekly until decision, no?" with 👍

Reacted to "if we think there is a chance we can converge here, would be good to have weekly until decision, no?" with 👍

Replying to "if we think there is..." it feels like stakes are relatively high, we want a decision soon

Reacted to "it feels like stakes are relatively high, we want a decision soon" with 👍

Weekly is fine for now

Reacted to "if we think there is a chance we can converge here, would be good to have weekly until decision, no?" with 👍

Reacted to "it feels like stakes are relatively high, we want a decision soon" with 👍

Reacted to "Could we keep these updates off the call, and just DM these guys directly ?" with 🔥

Should we set some deadline or target date to decide on this topic? We are loosing imps time for Frames or whatever we end up at

Reacted to "it feels like stakes are relatively high, we want a decision soon" with 👍

Reacted to "Should we set some deadline or target date to decide on this topic? We are loosing imps time for Frames or whatever we end up at" with 👍

Reacted to "if we think there is a chance we can converge here, would be good to have weekly until decision, no?" with 👍

Replying to "Should we set some d..." I think ~4 weeks is about the maximum that people are OK with

Reacted to "Should we set some deadline or target date to decide on this topic? We are loosing imps time for Frames or whatever we end up at" with 👍

wise words

not spending time more on frames discussion today would be a waste of a very important week imo

Reacted to "not spending time more on frames discussion today would be a waste of a very important week imo" with 🔥

Replying to "not spending time mo..." LFG

Reacted to "not spending time more on frames discussion today would be a waste of a very important week imo" with 💯

Reacted to "not spending time mo..." with 💯

@Chris - Base was the main ask from 8141 to add keystone functionality?

im not sure I understand the need of a new tx type as said by Derek that can support both, i thought 8130 can be implemented by L2s as a stricter 8141?

Replying to "@Chris - Base was ..." A simplified model of it yes

Reacted to "im not sure I understand the need of a new tx type as said by Derek that can support both, i thought 8130 can be implemented as a stricter 8141?" with ➕

Replying to "@Chris - Base was ..." But that may be not what they want - We are still discussing

there are no “blockers”, right? just the hope to have a better proposal that works for both sides

Replying to "@Chris - Base was th..." So frames is to go and we just need to adapt it for the “simplified model of it”?

Reacted to "A simplified model of it yes" with 👍

Replying to "there are no “blocke..." I e.g. heard from Vitalik as well that he is actively working on trying to find a more principled synthesis between the two proposals

Replying to "im not sure I unders..." The outcome is not necessarily to create a “new” transaction type, but rather just to converge on 1 transaction type, which could be frames like you said, but also may not be if it turns out that it’s not possible to get the desired 8130 experience on top of frame txns as spec-ed today

which things don’t you want? 🙂

Reacted to "I e.g. heard from Vitalik as well that he is actively working on trying to find a more principled synthesis between the two proposals" with 👀

Replying to "there are no “blocke..." so the cost of a decision now is to lock in something now that might not be the ideal outcome

Can we at least list out what are needed and what things they want to avoid from both sides

Reacted to "not spending time mo..." with 💯

Replying to "there are no “blocke..." ah wait @vitalik is on the call, I’d be curious about your take

Reacted to "To me, this is what I’m referring to as the pq fork" with 👍

Replying to "im not sure I unders..." What’s an example where just a stricter frame model (i.e. sequencer censoring more) doesn’t work?

what is the base’s timeline?

Hey, we’ve developed the frames devnets for hegota at ethrex for each iteration. Please include us in the separate discussion

Want to shout out both L1 client devs and Base for being willing to be flexible with their timelines in order to reach a common ground

We’ve been at the breakout room, but we have not been included in the discussion to try to reach a common tx type

Reacted to "Hey, we’ve developed..." with ☝️

Reacted to "Want to shout out both L1 client devs and Base for being willing to be flexible with their timelines in order to reach a common ground" with ➕

unite, not fight ❤️

Reacted to "Want to shout out both L1 client devs and Base for being willing to be flexible with their timelines in order to reach a common ground" with ➕

Account header for sure is best

Reacted to "We’ve been at the breakout room, but we have not been included in the discussion to try to reach a common tx type" with ➕

Contract was portable

Reacted to "Want to shout out both L1 client devs and Base for being willing to be flexible with their timelines in order to reach a common ground" with ➕

Replying to "We’ve been at the br..." added u to the telegram chat

Replying to "We’ve been at the br..." Please add me too

Replying to "We’ve been at the br..." Can I be added too?

Replying to "We’ve been at the br..." why not eth r&d?

Reacted to "why not eth r&d?" with ☝️

Reacted to "why not eth r&d?" with 🤷‍♂️

Reacted to "why not eth r&d?" with 🤷‍♂️

Reacted to "why not eth r&d?" with ☝️

Reacted to "why not eth r&d?" with ☝️

Reacted to "why not eth r&d?" with 🤷‍♂️

Replying to "We’ve been at the br..." idk guys i didnt make this chat 😭

Reacted to "idk guys i didnt make this chat 😭" with 😂

Reacted to "why not eth r&d?" with ☝️

Reacted to "why not eth r&d?" with ☝️

Reacted to "why not eth r&d?" with ➕

Reacted to "why not eth r&d?" with ➕

Lets ensure it works together at the very least. End users P0

Reacted to "why not eth r&d?" with ☝️

Reacted to "why not eth r&d?" with ➕

It has benefits for the ecosystem overall, no?

my take is: if you allow frame tx from default account in 8141 and then modify the default account in 8141 to use the keystore (on L2s) to read the authenticator, determine actor policies, etc. if you only allow the default account in frames and it uses the keystore with canonical authenticators you can reason about it statically and that should address the concerns raised

I do have to run, talk soon! Cheers

Reacted to "I do have to run, talk soon! Cheers" with 😅

Reacted to "my take is: if you allow frame tx from default account in 8141 and then modify the default account in 8141 to use the keystore (on L2s) to read the authenticator, determine actor policies, etc. if you only allow the default account in frames and it uses the keystore with canonical authenticators you can reason about it statically and that should address the concerns raised" with ➕

Reacted to "I do have to run, talk soon! Cheers" with 😅

Reacted to "my take is: if you allow frame tx from default account in 8141 and then modify the default account in 8141 to use the keystore (on L2s) to read the authenticator, determine actor policies, etc. if you only allow the default account in frames and it uses the keystore with canonical authenticators you can reason about it statically and that should address the concerns raised" with ➕

Reacted to "my take is: if you allow frame tx from default account in 8141 and then modify the default account in 8141 to use the keystore (on L2s) to read the authenticator, determine actor policies, etc. if you only allow the default account in frames and it uses the keystore with canonical authenticators you can reason about it statically and that should address the concerns raised" with ➕

Reacted to "I do have to run, talk soon! Cheers" with 🏃‍♂️‍➡️

Reacted to "I do have to run, ta..." with 😐

Reacted to "I do have to run, talk soon! Cheers" with 😅

Reacted to "I do have to run, talk soon! Cheers" with 🏃‍♂️‍➡️

Reacted to "I do have to run, talk soon! Cheers" with 🏃‍♂️‍➡️

Reacted to "I do have to run, talk soon! Cheers" with 😅

None of this really blocks us from SFI’ing 8141 though? Can still make tweaks after

Reacted to "None of this really blocks us from SFI’ing 8141 though? Can still make tweaks after" with 👍

Reacted to "None of this really ..." with 👍

Reacted to "None of this really blocks us from SFI’ing 8141 though? Can still make tweaks after" with 👍

Replying to "None of this really ..." This is true

Reacted to "None of this really ..." with 👍

Replying to "None of this really ..." 🚢

Reacted to "None of this really blocks us from SFI’ing 8141 though? Can still make tweaks after" with 👍

Replying to "None of this really ..." @nixo

Reacted to "None of this really ..." with 👍

Replying to "None of this really ..." But if the transaction type may change, what are we actually SFI-ing? I think we should first de-risk the outcome that there won’t be significant changes to the Frame txns type, which is probably going to be true, but can’t say for certain until we at least give this collab exercise another week or two

Replying to "None of this really ..." is it still possible that another EIP is being written that converges on a solution?

Replying to "None of this really ..." the same thing we always SFI?

Replying to "None of this really ..." the general concept and framework for solving

Replying to "None of this really ..." right, I am a bit unsure what specifically the decision here would be? I think we as a group already decided that AA will be the major EL side Hegota focus, right?

Replying to "None of this really ..." is it still possible that another EIP is being written that converges on a solution? That’s within the realm of possibility, yes

Replying to "None of this really ..." That said even in that world, I think 8141 will exist; it just would refer to this new EIP for the base transaction type

Reacted to "That said even in that world, I think 8141 will exist; it just would refer to this new EIP for the base transaction type" with 👍

Replying to "None of this really ..." so it seems to me SFI'ing wouldn't meaningfully impact either the outcome or speed things up, it may confuse the ecosystem though if the specific implementation is likely to change

Reacted to "so it seems to me SFI'ing wouldn't meaningfully impact either the outcome or speed things up, it may confuse the ecosystem though if the specific implementation is likely to change" with 👍

Replying to "my take is: if you a..." This sounds very simple to me… I struggle to understand why this doesn’t settle the debate already

Replying to "None of this really ..." SFIing frames will set a clear path and then we can put more efforts on sorting out what needs to be done to satisfy the majority

Replying to "None of this really ..." Yeah not sure what we lose by waiting at least till the next ACDE, just so we can have more clarity from this collab exercise

Replying to "my take is: if you a..." yeah i agree

Replying to "my take is: if you a..." @Derek Chiang | Ethlabs you know maybe?

Reacted to "This sounds very simple to me… I struggle to understand why this doesn’t settle the debate already" with 👀

Reacted to "my take is: if you allow frame tx from default account in 8141 and then modify the default account in 8141 to use the keystore (on L2s) to read the authenticator, determine actor policies, etc. if you only allow the default account in frames and it uses the keystore with canonical authenticators you can reason about it statically and that should address the concerns raised" with 👀

Yeah this really smells EOF all over again lol

Reacted to "Yeah this really smells EOF all over again lol" with ➕

+1 on Tomás

Reacted to "+1 on Tomás" with ➕

Reacted to "+1 on Tomás" with ➕

Replying to "Yeah this really sme..." nooo don’t say that 😭

Reacted to "Yeah this really sme..." with ➕

Reacted to "my take is: if you allow frame tx from default account in 8141 and then modify the default account in 8141 to use the keystore (on L2s) to read the authenticator, determine actor policies, etc. if you only allow the default account in frames and it uses the keystore with canonical authenticators you can reason about it statically and that should address the concerns raised" with ➕

Reacted to "+1 on Tomás" with ➕

Replying to "Yeah this really sme..." Far from it

Reacted to "+1 on Tomás" with ➕

Reacted to "nooo don’t say that 😭" with 😂

Replying to "Yeah this really sme..." Got no clue what was discussed as I was not on either room, but if there’s ACD + regular breakouts, and then on the next ACD the results of a private meeting are brought up, it’s really a failure of governance

I think it’s pretty normal that on active collaboration topics, there are a lot of side conversations in small groups, no? I agree that the default should be public comms channels, but realistically people DM all the time

Reacted to "nooo don’t say that 😭" with 😂

Reacted to "I think it’s pretty normal that on active collaboration topics, there are a lot of side conversations in small groups, no? I agree that the default should be public comms channels, but realistically people DM all the time" with 👍

if everyone would just chat on eth r&d it’s better 😅

Reacted to "if everyone would just chat on eth r&d it’s better 😅" with 💯

Reacted to "if everyone would just chat on eth r&d it’s better 😅" with 💯

Reacted to "if everyone would ..." with 💯

Reacted to "if everyone would ju..." with 💯

Reacted to "if everyone would just chat on eth r&d it’s better 😅" with 💯

Reacted to "if everyone would ju..." with 💯

Reacted to "if everyone would just chat on eth r&d it’s better 😅" with 💯

Reacted to "nooo don’t say that 😭" with 😂

Reacted to "if everyone would just chat on eth r&d it’s better 😅" with 💯

Reacted to "Far from it" with 👍

Reacted to "nooo don’t say th..." with 😂

Reacted to "Got no clue what was discussed as I was not on either room, but if there’s ACD + regular breakouts, and then on the next ACD the results of a private meeting are brought up, it’s really a failure of governance" with 👍

Wasn't there just someone 10-20 minutes ago who did not agree with this?

Reacted to "if everyone would just chat on eth r&d it’s better 😅" with 💯

Reacted to "if everyone would just chat on eth r&d it’s better 😅" with 👍

Replying to "I think it’s pretty ..." For sure, I’m not forbidding people from talking in their own channels, just against people presenting the outcomes of those channels as the outcomes of the public discussion, when they are different

we can just update 8141

Reacted to "we can just update 8141" with 👍

Reacted to "we can just update..." with 👍

We cannot base our decisions on hypothetical scenarios

Reacted to "we can just update 8141" with 👍

Reacted to "we can just update 8..." with 👍

Reacted to "we can just update 8141" with 👍

Reacted to "we can just update 8141" with 👍

yeah lets just adjust the spec of 8141 to whatever L2s are happy with too

Reacted to "yeah lets just adjust the spec of 8141" with 👍

Reacted to "yeah lets just adjus..." with 👍

Reacted to "yeah lets just adjust the spec of 8141" with 👍

Reacted to "yeah lets just adjust the spec of 8141 to whatever L2s are happy with too" with 👍

Reacted to "yeah lets just adjus..." with ☝️

Reacted to "yeah lets just adjust the spec of 8141 to whatever L2s are happy with too" with 👍

and lets SFI 8141 and lets get to work

Reacted to "if everyone would just chat on eth r&d it’s better 😅" with 💯

Reacted to "and lets SFI 8141 and lets get to work" with 🚢

Reacted to "and lets SFI 8141 and lets get to work" with 🚢

Reacted to "and lets SFI 8141 an..." with 🚢

Reacted to "and lets SFI 8141 and lets get to work" with 🚢

Reacted to "and lets SFI 8141 and lets get to work" with 🚢

SFI

SFI

We should try everything to make sure 8141 is fine with L2s. Independently, we should give L1 devs and users certainty as early as possible.

Reacted to "and lets SFI 8141 and lets get to work" with 🚢

Reacted to "We should try everyt..." with 👍

Let’s not make emotional decisions at the last 3 min of the meeting

Reacted to "Let’s not make emotional decisions at the last 3 min of the meeting" with 👍

Reacted to "Let’s not make emotional decisions at the last 3 min of the meeting" with 👍

Reacted to "and lets SFI 8141 and lets get to work" with 🚢

Replying to "Let’s not make emoti..." let’s stop wasting time with this discussions

Replying to "Let’s not make emoti..." Let’s not call people’s arguments emotional

They are not emotional, is not that frames appeared from out of nowhere

Reacted to "we can just update 8141" with 👍

we’re going to keep improving 8141

Reacted to "yeah lets just adjust the spec of 8141 to whatever L2s are happy with too" with 👍

I don’t think L2s are ultimately decision makers here. I will say I am very confused by this intention to make the decision now, but if the core devs want to make the decision, nothing is stopping them from doing so today

Replying to "Let’s not make emoti..." It’s not about emotions, we need to move on and do actual work

Reacted to "It’s not about emotions, we need to move on and do actual work" with 👍

Reacted to "It’s not about emotions, we need to move on and do actual work" with 👍

Reacted to "It’s not about emotions, we need to move on and do actual work" with 👍

Replying to "Let’s not make emoti..." @Stavros Vlachakis agreed, we need to ship 🚢

Reacted to "It’s not about emotions, we need to move on and do actual work" with 👍

Reacted to "Let’s not make emotional decisions at the last 3 min of the meeting" with 👍

Replying to "I don’t think L2s ar..." personally I’d still prefer to make that decision 2 weeks from now, but seems like clients all want to do that today

Reacted to "let’s stop wasting time with this discussions" with 💯

Reacted to "@Stavros Vlachakis agreed, we need to ship 🚢" with 🚢

Reacted to "let’s stop wasting time with this discussions" with 💯

a lot of clients feel it is pretty valuable to SFI it ?

Reacted to "@Stavros Vlachakis agreed, we need to ship 🚢" with 🚢

Replying to "I think it’s pretty ..." I think the failure mode here is thinking the group was “large enough”. IMHO that’s what creates the most misunderstanding. Not speaking of this case specifically, but more in general

Reacted to "a lot of clients fee..." with 🤝

Reacted to "personally I’d still prefer to make that decision 2 weeks from now, but seems like clients all want to do that today" with ➕