Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 .. 5022
— 502,152 events total
2020-11-18 13:17:24 <dminuoso> "to verify that your data is correct and up to date"
2020-11-18 13:17:46 <idnar> there's an incrementally updated data structure shared between server and client, this lets the client detect an incorrectly applied update
2020-11-18 13:17:46 <idnar> but this whole API is madness
2020-11-18 13:17:49 <dminuoso> If you feed the CRC32 with bad data, you still get a valid CRC hash...
2020-11-18 13:18:24 <dminuoso> So the only thing this seems to protect against, is a modification in transport. But like hc pointed out, TLS gives us the guarantee of no modification already.
2020-11-18 13:18:42 × thc202 quits (~thc202@unaffiliated/thc202) (Ping timeout: 260 seconds)
2020-11-18 13:19:04 <dminuoso> 14:17:46 idnar | there's an incrementally updated data structure shared between server and client, this lets the client detect an incorrectly applied update
2020-11-18 13:19:06 <dminuoso> oh
2020-11-18 13:19:10 → machinedgod joins (~machinedg@135-23-192-217.cpe.pppoe.ca)
2020-11-18 13:19:13 → geekosaur joins (82659a09@host154-009.vpn.uakron.edu)
2020-11-18 13:19:16 <dminuoso> So this is a poor mans merkle tree?
2020-11-18 13:19:27 <dminuoso> With CRC32 instead of a cryptographic hash?
2020-11-18 13:19:35 <idnar> sort of
2020-11-18 13:19:42 <dminuoso> Shameful. They should just dub it "a blockchain" and make that much more money.
2020-11-18 13:19:49 <dminuoso> And trick investors
2020-11-18 13:19:52 × ericsagn1 quits (~ericsagne@2405:6580:0:5100:bdf6:510e:2b42:888e) (Ping timeout: 260 seconds)
2020-11-18 13:19:59 <hc> lol, true
2020-11-18 13:20:21 <int-e> cyclic redundancy blockchain?
2020-11-18 13:20:22 × merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds)
2020-11-18 13:20:55 <dminuoso> I mean to be absolutely fair, a merkle tree with CRC is a perfectly valid thing to do.
2020-11-18 13:21:08 → merijn joins (~merijn@83-160-49-249.ip.xs4all.nl)
2020-11-18 13:21:12 <dminuoso> It just has a much larger attack surface.
2020-11-18 13:21:18 × __monty__ quits (~toonn@unaffiliated/toonn) (Ping timeout: 265 seconds)
2020-11-18 13:21:26 <dminuoso> And it gives less guarantees
2020-11-18 13:21:51 <dminuoso> If you have a high volume/low latency situation, then it's possible a cryptographic hash might just be too expensive
2020-11-18 13:22:19 × Sk01 quits (~sky3@1aac.wls.metu.edu.tr) (Quit: WeeChat 2.9)
2020-11-18 13:23:00 <int-e> secretly you've always wanted mutable Merkle trees
2020-11-18 13:23:27 <hc> =)
2020-11-18 13:23:35 <dminuoso> Oh boy. "mutable merkle trees"
2020-11-18 13:23:46 <dminuoso> int-e: Can I expect a publication from you about this? :>
2020-11-18 13:23:46 <hc> you might even sell it
2020-11-18 13:24:05 <hc> too bad the mit paper generator only lets you choose the authors, not title
2020-11-18 13:24:10 <dminuoso> https://github.com/EdgyEdgemond/mutable_merkle
2020-11-18 13:24:13 <dminuoso> Good lord. This already exists.
2020-11-18 13:24:32 dminuoso scratches his head
2020-11-18 13:25:15 <boxscape> hm, I think I can use the symbols library and 26 individual comparison cases (or 64 for upper and lower case + digits) to get a comparison type I can construct at the type level :)
2020-11-18 13:25:23 <boxscape> for symbols
2020-11-18 13:25:47 → da39a3ee5e6b4b0d joins (~da39a3ee5@cm-171-98-78-149.revip7.asianet.co.th)
2020-11-18 13:26:35 <int-e> dminuoso: that's just a persistent data structure, I think
2020-11-18 13:27:16 <int-e> (and every update changes the root hash (with high probability, blah), which is how it's supposed to work)
2020-11-18 13:27:24 <dminuoso> int-e: I think it's rather sort of like `git rebase -i`, where it just recalculates/resigns the entire tree
2020-11-18 13:27:58 → __monty__ joins (~toonn@unaffiliated/toonn)
2020-11-18 13:28:12 <int-e> dminuoso: But it's a tree and you can still reuse the subtrees that haven't changed.
2020-11-18 13:28:47 → SanchayanMaity joins (~Sanchayan@106.201.35.233)
2020-11-18 13:28:55 <int-e> (though hmm, the structure has to be very rigid for this to work; so it will have rewrite the whole tree on occasion at least)
2020-11-18 13:29:05 <int-e> hve -> have to.
2020-11-18 13:29:15 <dminuoso> "sub-trees", you partial nodes from above
2020-11-18 13:29:23 <dminuoso> (or partial sub-trees above the mutation points)
2020-11-18 13:29:42 <dminuoso> which is pretty much what git rebase does
2020-11-18 13:30:16 <int-e> Oh, you're looking at the whole repo as a tree, not just the commit objects as a blockchain.
2020-11-18 13:30:20 <dminuoso> right
2020-11-18 13:30:44 <dminuoso> (so perhaps rather in the sense of a zipper)
2020-11-18 13:30:56 × SanchayanMaity quits (~Sanchayan@106.201.35.233) (Client Quit)
2020-11-18 13:30:57 <dminuoso> We could have zippers for merkle trees I guess
2020-11-18 13:31:04 <int-e> indeed
2020-11-18 13:31:25 → thc202 joins (~thc202@unaffiliated/thc202)
2020-11-18 13:31:32 <dminuoso> It's an interesting thought. Coupled with lazyness, that could have some nice properties
2020-11-18 13:31:55 → ericsagn1 joins (~ericsagne@2405:6580:0:5100:53e4:af5e:8890:d6d0)
2020-11-18 13:32:00 <dminuoso> Could lead to relatively cheap mutations, even closer to the root, if you dont need the hashes on all the leafs all the time
2020-11-18 13:32:14 <dminuoso> I dont just dont have any problems that require merkle trees, sadly
2020-11-18 13:32:34 <int-e> I really think the persistent data structure analogy is perfect. The property that is problematic is that they want to ensure that if they have the same key-value map, they also end up with the same root hash, which means they need to have the same underlying tree structure regardless of the history of insertions and deletion.
2020-11-18 13:33:01 <int-e> (or is it just keys? I didn't pay enough attention)
2020-11-18 13:33:45 <dminuoso> Well, if the hash differs, they wont have the same "ancestory"
2020-11-18 13:33:57 <dminuoso> Dunno if merkle trees exist in both directions
2020-11-18 13:34:10 × Axman6 quits (~Axman6@pdpc/supporter/student/Axman6) (Remote host closed the connection)
2020-11-18 13:34:25 → Axman6 joins (~Axman6@pdpc/supporter/student/Axman6)
2020-11-18 13:34:30 <dminuoso> (say where the root of the tree is the cumulative signing of all leafs, or in the other direction where the leafs are the cumulative signing of the entire path from the root)
2020-11-18 13:35:58 <dminuoso> oh wait, it's just the first
2020-11-18 13:36:02 → jakob_ joins (~textual@dynamic-093-135-025-031.93.135.pool.telefonica.de)
2020-11-18 13:36:05 <int-e> Typeable is based on Merkle trees <-- can't remember seeing it put like that anywhere.
2020-11-18 13:36:09 → SanchayanMaity joins (~Sanchayan@106.201.35.233)
2020-11-18 13:37:13 × geekosaur quits (82659a09@host154-009.vpn.uakron.edu) (Remote host closed the connection)
2020-11-18 13:37:21 × Sanchayan quits (~Sanchayan@106.201.35.233) (Quit: leaving)
2020-11-18 13:38:04 <int-e> (It's not a pure Merkle tree in that there are several node types, and they have varying degree. And you never look at paths from the root, only at the root identity, so... it's not perfect.)
2020-11-18 13:38:22 → geekosaur joins (82659a09@host154-009.vpn.uakron.edu)
2020-11-18 13:39:04 × oish quits (~charlie@228.25.169.217.in-addr.arpa) (Ping timeout: 256 seconds)
2020-11-18 13:41:45 → Yumasi joins (~guillaume@2a01cb09b06b29ea21daa97718c35c9f.ipv6.abo.wanadoo.fr)
2020-11-18 13:43:07 <int-e> Hmm, if you make a perfectly size-balanced binary tree (L <= R <= L+1, where L is the size of the left child and R is the size of the right child) then insertions and deletions should take the usual O(log(n)) time, and you get the property that the tree shape is determined by the number of nodes. In other words, you *can* avoid having to update the whole tree for a single insertion or deletion.
2020-11-18 13:44:29 → vacm joins (~vacwm@70.23.92.191)
2020-11-18 13:44:34 → dcoutts_ joins (~duncan@33.14.75.194.dyn.plus.net)
2020-11-18 13:44:50 × vacm quits (~vacwm@70.23.92.191) (Client Quit)
2020-11-18 13:46:25 → FreeBirdLjj joins (~freebirdl@101.228.42.108)
2020-11-18 13:46:31 hackage zydiskell 0.1.0.0 - Haskell language binding for the Zydis library, a x86/x86-64 disassembler. https://hackage.haskell.org/package/zydiskell-0.1.0.0 (nerded)
2020-11-18 13:47:28 → alx741 joins (~alx741@181.196.68.148)
2020-11-18 13:48:41 → bliminse joins (~bliminse@host109-156-197-211.range109-156.btcentralplus.com)
2020-11-18 13:50:27 × SanchayanMaity quits (~Sanchayan@106.201.35.233) (Quit: SanchayanMaity)
2020-11-18 13:50:34 → Sanchayan joins (~Sanchayan@106.201.35.233)
2020-11-18 13:51:05 × PacoV quits (~pcoves@16.194.31.93.rev.sfr.net) (Ping timeout: 240 seconds)
2020-11-18 13:51:16 → SanchayanMaity joins (~Sanchayan@106.201.35.233)
2020-11-18 13:52:06 × Sanchayan quits (~Sanchayan@106.201.35.233) (Client Quit)
2020-11-18 13:53:58 → urodna joins (~urodna@unaffiliated/urodna)
2020-11-18 13:56:21 × todda7 quits (~torstein@2a02:587:d96:adb6:c7fc:9428:5ead:614f) (Ping timeout: 272 seconds)
2020-11-18 13:57:15 → Chi1thangoo joins (~Chi1thang@87.112.60.168)
2020-11-18 14:00:15 × dftxbs3e quits (~dftxbs3e@unaffiliated/dftxbs3e) (Remote host closed the connection)
2020-11-18 14:00:30 × Tario quits (~Tario@201.192.165.173) (Read error: Connection reset by peer)
2020-11-18 14:00:34 × LKoen quits (~LKoen@169.244.88.92.rev.sfr.net) (Quit: “It’s only logical. First you learn to talk, then you learn to think. Too bad it’s not the other way round.”)
2020-11-18 14:02:07 → dftxbs3e joins (~dftxbs3e@unaffiliated/dftxbs3e)
2020-11-18 14:03:29 → jlamothe joins (~jlamothe@198.251.55.207)
2020-11-18 14:03:30 hackage graphula-core 2.0.0.1 - A declarative library for describing dependencies between data https://hackage.haskell.org/package/graphula-core-2.0.0.1 (PatrickBrisbin)
2020-11-18 14:03:35 → wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
←Prev  Next→
Page 1 .. 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 .. 5022

All times are in UTC.