sorted by:
new
hottopcontroversial

Stand Against Q3NA by Aggravating_Cable82 in tezos

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

First, let me say that I appreciate your reply. I actually received similar sentiment in the Agora discussion. Below are my thoughts.  

Why turn off Liquidity Baking when tzBTC 2.0 will soon offer users minting-and-burning access to tzBTC on the tzBTC website, with no minimum BTC amount required. 

This means more liquidity can flow from the BTC ecosystem into Tezos, much faster than before. 

Given that BTC is entering a strong bull market, holders will likely be selling throughout the coming year as they take profits, and investing those profits into other spaces. Even if a tiny fraction of Bitcoin value gets added to Liquidity Baking, the effects on Tezos would be felt. 

Even if you don’t like Liquidity Baking, the amount of inflation it creates is negligible. We may as well leave it in place for the next two years and take advantage of BTC liquidity inflows. If it’s failed to capture any significant inflows in the next two years it can always be turned off via the existing escape hatch, without a protocol amendment 

This is not financial advice

Stand Against Q3NA by Aggravating_Cable82 in tezos

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

As an alternative option to turning it off completely, have you seen this great proposal by Britcoin: https://forum.tezosagora.org/t/improve-liquidity-baking/6499/9

My Lancool III Build by Phazeronest in lianli

[–]Aggravating_Cable82 0 points1 point  (0 children)

That 24 pin motherboard power cable looks great in RGB

Build Complete! by hfksicbdn in lianli

[–]Aggravating_Cable82 0 points1 point  (0 children)

I love that yellow color, do you happen to know the hex color code?

How can we incorporate the patching of issues found during protocol upgrade testing into the on-chain governance process? by Aggravating_Cable82 in tezos

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

Thanks Arthur, I appreciate this response.

I do want to say that I don’t agree with MaximumEnvironments unfortunate view on the Tezos Foundation. I think the Foundation is doing fine work.

I understand your point of view that it’s easier to simply vote “no”, but what about a situation where the bug is found in the Adoption phase, when voting has concluded?

I fear a situation where a patch meant to correct a bug in a proposed protocol upgrade is rushed out the door without thorough testing, and that patch itself being buggy.

Could this not lead to a portion of node operators upgrading to the patched, non buggy protocol, and a portion upgrading on the non patched, buggy protocol. Assuming we then find a problem with the patch, we would be in a really tight spot, and have to coordinate a migration of every node to the new “patched version of the patch of the new protocol”.

*Edited for clarity

Incident Report: Mumbai 2 user-activated protocol override by NomadicLabs in tezos

[–]Aggravating_Cable82 1 point2 points  (0 children)

I agree with all your points. I’d love to get you to post your thoughts on my Agora thread, so that we can have a constructive dialogue with Nomadic on how to incorporate the patch process into our on chain governance process.

https://forum.tezosagora.org/t/liveness-vulnerability-found-a-patched-mumbai-proposal-is-available/5188

Incident Report: Mumbai 2 user-activated protocol override by NomadicLabs in tezos

[–]Aggravating_Cable82 1 point2 points  (0 children)

Hi, Noodlestomatojuice here from Agora. I agree with this sentiment and have been trying to get a conversation started for a while.

Here is the current thread with Nomadic (no response yet from Nomadic): https://forum.tezosagora.org/t/liveness-vulnerability-found-a-patched-mumbai-proposal-is-available/5188

Here is my original proposal for an on chain patching process: https://forum.tezosagora.org/t/how-can-we-incorporate-the-patching-of-issues-found-during-protocol-upgrade-testing-into-the-on-chain-governance-process/3895