02:25 <uiuc-slack> <mikerahqc> Is checklocktimeverify a pure function?

02:26 <uiuc-slack> <amiller> It's not that its a pure function, many opcodes that are pure functions could still be a problem

02:27 <uiuc-slack> <amiller> Basically first of all, with checklocktimeverify he resulting UTXOs are fully described when the transaction is signed

02:28 <uiuc-slack> <amiller> With something like OP_UNISWAP, to implement it seems like you'd have to have resulting UTXOs rhat depend on the price offered by the market maker, which could move based on other tx in the block

03:54 <aj> amiller: you need two assets for uniswap to manage; but assuming you have a multi-asset utxo thing like liquid, you then need a covenant that lets you have a utxo of asset A and a utxo of asset B, and allows you to "spend" both, creating a new utxo of asset A, a new utxo of asset B, where the balance of one increases, the balance of the other decreases, and the change matches the AMM rule. not sure if

03:54 <aj> liquid's script has good enough covenant things to examine the balances easily

19:35 <fltrz> I'd like some kind of "reading roadmap" to get up to speed with the main competing FHE systems, not just as a library user, but actually grasping the math behind it. While I have studied other areas of cryptography, I have not yet devoted anything beyond cursory reading on FHE. I try to avoid the situation of reading the literature chronologically because that would inevitably involve studying currently-apparent-dead-ends and then later on

19:35 <fltrz> reading that its considered a dead end / abandoned. (I'm aware insights, tricks and techniques may be revived, but I don't think I want to include this for getting up to speed, I'd rather learn those avenues as they get revived))

19:37 <fltrz> I don't find many books on FHE, and since the young field seems to be moving quite rapidly, I fear that most books would be significantly outdated. If someone could ask around say some teachers or professors for a reading list I would highly appreciate it.

19:39 <fltrz> Another more specific question, have FHE "figures of merit" been identified? Have objective figures of merit and their tradeoffs been mapped?

19:40 <fltrz> Alternatively, should I just take the wikipedia page's reference on implementations, and recursively get the mentioned papers?

19:41 <fltrz> Another question: how thoroughly understood is the hardness of Ring Learning With Errors?

19:51 <uiuc-slack> <mikerahqc> I would recommend reading Craig Gentry's PhD thesis on FHE

19:52 <uiuc-slack> <mikerahqc> PhD thesis tend to have all the backgrpund necessary to understand the topic at hand

20:57 <fltrz> uiuc-slack, thanks!

20:59 <fltrz> uiuc-slack, thats solid advice, but it *is* not a complete reading list, it describes his FHE system, and its from 2009, according to wikipedia a lot has happened since then

22:32 <uiuc-slack> <amiller> second of all there is this monotonic property with op_checklocktimeverify that seems to hold, this is "reorg safety", what i mean is: once an honest transaction becomes valid according to op_checklocktimeverify, it is also valid in every other fork of that height Basically once the time is valid in a block, it's also going to be valid in subsequent blocks This "reorg safety" is separate from the previous one

22:32 <uiuc-slack> that bitcoin devs have stuck to but I think it's overrated

23:04 <uiuc-slack> <mikerahqc> Can't you just have probabilistic bounds on reorg safety as opposed to definite reorg safety as you describe?

23:05 <uiuc-slack> <mikerahqc> There's always a possibility that Bitcoin itself (and most definitely its forks) may reorg

23:10 <uiuc-slack> <amiller> you can have probabilistic bounds yes, like you can applly Bitcoin Backbone to know that you can wait for k blocks and get any k bits of security in your guarantee it wont fork

23:12 <uiuc-slack> <amiller> there's a kind of non-robustness to this though in that to do this, you have to pick parameters for \Alpha the adversary power as well as the network delay

23:45 <fltrz> hi, my firefox had memory leak... I noticed someone said something, and since i recently asked a question, was it a reply to me?

23:45 <fltrz> nm I see theres logs