--- Log opened Tue Apr 16 00:00:28 2024
00:04 -!- Llamamoe [~Llamamoe@188.146.90.23] has joined #hplusroadmap
00:05 -!- Gooberpatrol66 [~Gooberpat@user/gooberpatrol66] has joined #hplusroadmap
01:20 -!- darsie [~darsie@84-112-12-36.cable.dynamic.surfer.at] has joined #hplusroadmap
01:25 -!- darsie [~darsie@84-112-12-36.cable.dynamic.surfer.at] has quit [Remote host closed the connection]
01:26 -!- darsie [~darsie@84-112-12-36.cable.dynamic.surfer.at] has joined #hplusroadmap
04:12 -!- adlai [~adlai@user/adlai] has quit [Ping timeout: 256 seconds]
04:19 -!- darsie [~darsie@84-112-12-36.cable.dynamic.surfer.at] has quit [Remote host closed the connection]
04:19 -!- darsie [~darsie@84-112-12-36.cable.dynamic.surfer.at] has joined #hplusroadmap
05:20 < kanzure> hmph
05:34 -!- Lando-SpaceIzzle [~Lando-Spa@user/meow/Lando-SpacePimp] has quit [Ping timeout: 255 seconds]
06:11 < kanzure> "Another argument which favors this order of magnitude: psychologists have never found situations in which a person can store in long-term memory more than one or two 'items' per second. This suggests an upper bound of the order of 10 million units per year."
06:11 < kanzure> (minsky
06:23 -!- justanot1 [~justanoth@gateway/tor-sasl/justanotheruser] has joined #hplusroadmap
06:25 -!- justanotheruser [~justanoth@gateway/tor-sasl/justanotheruser] has quit [Ping timeout: 260 seconds]
07:08 < kanzure> "Later this year, the White House is issuing new legislation that impacts how federal agencies select life-sciences vendors. By October 24, 2024, all federal agencies are mandating compliance and certification with DNA synthesis screening requirements. Providers like IDT, Thermo Fisher, and Twist Biosciences.."
07:48 < hprmbridge> kanzure> comedy https://www.reddit.com/r/grimezs/s/hVFB0vKUXQ
07:58 < hprmbridge> setecastronomy1891> Someone spent time to produce this.
07:59 < hprmbridge> kanzure> "she knows RAZIB!! anyone who knows RAZIB must be awful."
08:00 < hprmbridge> setecastronomy1891> Lol
08:01 < hprmbridge> setecastronomy1891> Razib is probably the most sensible and studied person I’ve ever met when it comes to race. That quote is obviously bent out of context
08:03 < hprmbridge> setecastronomy1891> He would be disinclined to even call it race in favor of the more anodyne “genetic differences”.
08:49 < kanzure> https://www.youtube.com/watch?v=aWfYxg-Ypm4
12:24 -!- _flood [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Remote host closed the connection]
12:24 -!- _flood [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #hplusroadmap
12:29 -!- _flood [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Read error: Connection reset by peer]
13:18 -!- Llamamoe [~Llamamoe@188.146.90.23] has quit [Quit: Leaving.]
15:47 < fenn> .t
15:47 < saxo> Interview with Senior JS Developer 2024 [NEW] - YouTube
16:09 -!- Gooberpatrol66 [~Gooberpat@user/gooberpatrol66] has quit [Ping timeout: 260 seconds]
16:11 -!- Gooberpatrol66 [~Gooberpat@user/gooberpatrol66] has joined #hplusroadmap
16:44 -!- darsie [~darsie@84-112-12-36.cable.dynamic.surfer.at] has quit [Ping timeout: 240 seconds]
17:23 < hprmbridge> fodagut> @Lev is there better algorithms than GHOST these days? what's the state of the art
17:24 < hprmbridge> Lev> Yis, but ofc depends very much on what exactly you want
17:24 < hprmbridge> Lev> There's an interesting 2022(?) paper for example called Consensus On Demand that basically does no actual work unless you introduce a conflict *needing* consensus
17:25 < hprmbridge> Lev> sadly it has a max byzantine fault tolerance of 1/5th that's optimal
17:26 < hprmbridge> Lev> If we're talking just general fork choice resolution for as-arbitrary-as-possible protocols, Casper CBC is just as applicable to PoW as PoS and the size of your justification set is the number of consensus rounds it resolves in
17:26 < hprmbridge> Lev> plus depending on your fork choice it can be async or not
17:27 < hprmbridge> Lev> There's O(1) consensus algs that have optimal comm complexity (see abraham itai(?)'s recent papers im probably getting the name wrong)
17:27 < hprmbridge> fodagut> @Lev Like if you were implementing bitcoin as a blank slate today and just wanted a better / more fair fork resolution protocol to drop in, what would you use? Casper CBC?
17:28 < hprmbridge> Lev> but they're more niche for stuff like asynchronous gather protocols etc
17:28 < hprmbridge> Lev> I'd probably use  smth akin to it with a DAG underlay
17:28 < hprmbridge> Lev> something phantom-esque, maybe
17:29 < hprmbridge> Lev> CryptoConcurrency is a paper (and references other similar ones) that allow fast-tracking commutative transations
17:30 < hprmbridge> Lev> which is any set of monetary tx that doesn't put your account in the negative, so it's a fairly easy to meet restriction
17:30 < hprmbridge> Lev> If you're interested in partial-synchronicity (I am) there's an optimal construction called snap-and-chat that's described in a paper by the same name
17:31 < hprmbridge> Lev> basically there's tons of pieces of what i would consider to come together to make the 'optimal bitcoin' but nothing hammered out in one protocol
17:32 < hprmbridge> Lev> just plenty of things that are optimal in different directions that could potentially be layered constructively
17:33 < hprmbridge> Lev> the name on this is almost definitely wrong but they also maintain a decent blog on consensus algorithm overviews & research (https://decentralizedthoughts.github.io/)
17:34 < hprmbridge> Lev> this one for example is a good sort of "stretch goals for any consensus system" post: <https://decentralizedthoughts.github.io/2023-09-30-scaling/>
17:35 < hprmbridge> Lev> like one thing to just keep in mind off the bat is that there's proofs of impossibility for fair fork choice resolution under fully async protocols
17:36 < hprmbridge> Lev> well depends on what exactly you're willing to consider 'fair' but, if you for example want to ensure that the actual amount of work done is balanced across all validators
17:38 < hprmbridge> fodagut> This is for a p2pool-like share chain on top of bitcoin, for context.
17:43 < hprmbridge> Lev> I mean i'd probably start with an alternative cryptographic accumulator fwiw
17:44 < hprmbridge> Lev> but like for smth of that sort with frequent merges back to the chain, i might honestly go with the consensus on demand thing
17:45 < hprmbridge> Lev> The 1/5th's tolerance sucks but you can set up an adaptive PoW to get entry into the pool or smth else, and each time a block is found or an attestation is added into the chain some other way, misbehaving members can be culled
18:19 < hprmbridge> fodagut> No I think any of those are pretty far afield of the requirements.
18:19 < hprmbridge> fodagut> Thanks for the feedback though, that helps.
18:20 < hprmbridge> Lev> np
18:32 < hprmbridge> alonzoc> Well that's for an account based model the commutitivity condition for UTXO models is disjoint UTXO sets. Also a UTXO model means you can keep bitcoin script and still exploit commutative txs
18:33 < hprmbridge> Lev> The paper is still relevant
18:33 < hprmbridge> Lev> it references a lot of similar ones and explains a few consensus related pitfalls
18:34 < hprmbridge> Lev> but yes in this case it reduces to consuming nonoverlapping utxosets
18:34 < hprmbridge> Lev> still, same result in effect
18:35 < hprmbridge> Lev> you're just splitting the balances into smaller pieces
18:36 < hprmbridge> Lev> the whole k-non whatever they call it transactions is effectively equivalent to k disjoint utxosets
18:36 < hprmbridge> Lev> it's just saying disjoint & not double spending/going negative
18:40 < hprmbridge> alonzoc> Oh yeah but the issue is the degree of commutativity and how it effects questions of consensus is different. The design space is interesting. With UTXO models parralel transactions from the same wallet that aren't double spends all commute only the double spends yield non-commutation. While in an account based model the moment someone trys to overdraw an account by sending n transactions such that
18:40 < hprmbridge> alonzoc> any n-1 are within balance you end up having a noncommutativity issue requiring a 1-of-n choice for consensus. UTXO reduces the potential choices consensus has to handle by requiring total UTXO consumption. While also simplifying commutativity checks as transaction commutativity is invariant with respect to network state while account based transactions have commutativity dependent on the current
18:40 < hprmbridge> alonzoc> balance as well as their validity.
18:40 < hprmbridge> Lev> utxo doesn't
18:41 < hprmbridge> Lev> not exactly
18:41 < hprmbridge> alonzoc> UTXO has issues though, it's not as easy to model the optimistic no double spend case as a CRDT
18:41 < hprmbridge> Lev> because it's a multi valued consensus, it introduces longer consensus rounds as well
18:41 < hprmbridge> Lev> technically
18:41 < hprmbridge> Lev> it's just better at making that not considered really than it is at actually removing it
18:42 < hprmbridge> Lev> Like it's easy to check for disjoint yes
18:42 < hprmbridge> Lev> but over sets still introduces the same complexity except in the form of which tx consumes which subset
18:43 < hprmbridge> alonzoc> Yeah either setup you can produce large branching factors, tbh the nicest property I've had with UTXO in my sketches is that UTXO transaction commutitivity isn't state dependent while account transaction commutitivity is state dependent which makes exploiting it fully more subtle
18:43 < hprmbridge> Lev> the consensus still ends up handling the same complexity in the end really
18:43 < hprmbridge> Lev> fair but state just makes everything else easier and nicer
18:43 < hprmbridge> Lev> i debated just doing everything as pure message passing and then said absolutely not
18:44 < hprmbridge> Lev> like we've talked about how if ethereum had page-like locking then so many issues in it would be fixed
18:45 < hprmbridge> Lev> me to ethereum devs: "have you heard of this snazzy newfangled idea from the 1960s? it's called cache coderency"
18:46 < hprmbridge> alonzoc> Yeah it's still got some issues but static deceleration of the pages of state allowed for a tx makes some optimisations really easy. But the EVM is such a clusterfuck it's better to start again tbh
18:46 < hprmbridge> Lev> point
18:46 < hprmbridge> alonzoc> eWASM is an okay idea imo tho
18:46 < hprmbridge> Lev> i like my idea more
18:47 < hprmbridge> alonzoc> Which one is this?
18:47 < hprmbridge> Lev> basically virtualize a tomasulo-like processor and have filecoin-style attestments that you're providing a certain functional unit to the global cpu
18:47 < hprmbridge> Lev> and then scheduling algorithm go brr
18:47 < hprmbridge> Lev> compatible with ewasm, but also why are ewasms tables like that
18:47 < hprmbridge> Lev> just why
18:47 < hprmbridge> alonzoc> You give up on binary lambda calc variants?
18:48 < hprmbridge> Lev> oh no those are actually going really well
18:48 < hprmbridge> Lev> i finally got both the sparse merkle tree folding and the thunks working simultaneously
18:48 < hprmbridge> Lev> so no horrible exponential memory blowup like you told me was inevitable
18:49 < hprmbridge> Lev> but i think those might be more for personal ML experiments
18:49 < hprmbridge> Lev> it's so easy to just unfold an MCTS tree over all possible BCL programs because BCL programs are themselves a binary tree
18:49 < hprmbridge> Lev> and then you can just do math on the mcts trees
18:50 < hprmbridge> Lev> imma make a version of oops that aggregates normalize MCTS trees across each round
18:51 < hprmbridge> alonzoc> Hmm dependent on what your interpreter semantics are you'll get them. The question is basically are you performing one single global substitution/rewrite each time step if so I can basically emulate a nondeterministic turing machine on your VM with a 1-to-1 correspondence of VM rewrites to NDTM steps.
18:52 < hprmbridge> Lev> i'm still working on the part that automatically extracts new rewrite rules, so it's basically just basic BCL except that 2nd rule memoizes instead of immediately duplicating
18:53 < hprmbridge> Lev> ```
18:53 < hprmbridge> Lev> 11101xyz → 11xz1yz
18:53 < hprmbridge> Lev> ```
18:53 < hprmbridge> Lev> this one
18:54 < hprmbridge> alonzoc> https://julesh.com/2016/09/22/abusing-the-continuation-monad/ the haskell expression from this blog post when compiled to lambda calc is the poison that'd yield exponential space blow up in finite rewrites
18:54 < hprmbridge> Lev> that's probably this rule because the only other one by default in BCL isn't a blowup capable one
18:55 < hprmbridge> Lev> ```
18:55 < hprmbridge> Lev> 1100xy  → x
18:55 < hprmbridge> Lev> ```
18:55 < hprmbridge> Lev> but basically what would happen in the sat solver case is infinite thunk unrolling just like you're expecting, yes
18:55 < hprmbridge> Lev> luckily i took that into account, so subtree reductions get applied to thunks automaticallp
18:56 < hprmbridge> Lev> and because sparse merkle tree, it doesn't matter where these subtree reductions happen
18:57 < hprmbridge> Lev> I do need to work out a better GC for the dangling thunks, but i'm working on that
19:08 -!- deltab [~deltab@95.154.230.49] has quit [Ping timeout: 260 seconds]
19:18 -!- deltab [~deltab@95.154.230.49] has joined #hplusroadmap
20:56 -!- mxz__ [~mxz@user/mxz] has joined #hplusroadmap
20:56 -!- mxz [~mxz@user/mxz] has quit [Ping timeout: 264 seconds]
20:56 -!- mxz__ is now known as mxz
20:57 -!- mxz_ [~mxz@user/mxz] has quit [Ping timeout: 256 seconds]
22:02 -!- andytoshi [~apoelstra@user/andytoshi] has quit [Ping timeout: 272 seconds]
22:02 -!- andytoshi [~apoelstra@user/andytoshi] has joined #hplusroadmap
22:48 -!- Llamamoe [~Llamamoe@188.146.91.151] has joined #hplusroadmap
23:03 -!- mxz_ [~mxz@user/mxz] has joined #hplusroadmap
--- Log closed Wed Apr 17 00:00:29 2024