--- Log opened Fri Aug 07 00:00:42 2020
00:01 < kcalvinalvin> Or maybe not..? I guess some database stuff could use a rollback
00:03 < icota[m]> hi all. how would a already-synced CSN deal with keys import? i imagine it would have to IBD again?
00:08 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #utreexo
00:20 < kcalvinalvin> icota[m] Hello! That would be one way of going about it. In a scenario where you're coming from a wallet with Utreexo support, you would just import the Utreexo proofs with everything else. If you're coming from a non-Utreexo supporting wallet, you can ask a bridgenode for the proofs for your utxos
00:23 < kcalvinalvin> Though I guess chainanalysis companies will then be all over the bridgenodes. You could re-ibd by only doing the accumulator operations. Then at your saved tip, check if that matches the one you previously stored.
00:25 < icota[m]> does the bridge node support such operations at the moment?
00:26 < kcalvinalvin> It does not. With the current released binary, you'd have to resync
00:26 < kcalvinalvin> adiabat We should put this feature on github projects
00:30 < icota[m]> thanks kcalvinalvin . it didn't occur to me that a utreexo client can export the proofs along with the keys
00:36 < kcalvinalvin> One thing I should mention is that because the proof for a given utxo changes every block, the CSN client has to keep updating them. So it isn't possible to save a proof as you would with a key
00:37 < kcalvinalvin> Well, I guess you can. One would have to do ibd from the height of which that proof was stored
00:38 < icota[m]> yeah as long the height is stored somewhere it's okay. but the files can get a bit stale :)
01:23 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #utreexo
01:24 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
05:14 -!- reallll [~belcher@unaffiliated/belcher] has joined #utreexo
05:17 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
05:18 -!- reallll is now known as belcher
06:04 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
06:05 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #utreexo
07:36 -!- slivera [~slivera@217.138.204.138] has quit [Remote host closed the connection]
07:37 -!- dergoegge [uid453889@gateway/web/irccloud.com/x-lhrltkwqzknesmzr] has joined #utreexo
08:48 < adiabat> icota[m] : yeah it's not supported yet, right now need to resync, but CSN nodes don't actually need proofs for their own utxos
08:49 < adiabat> as long as there's a bridge node somewhere out there, they can broadcast the transaction to the non-utreexo network and it'll come back with proofs attached by bridges
08:49 < adiabat> so you could even do a neutrino filter type search for your own coins
08:50 < adiabat> another option would be asking a bridge node for the whole leaf set, which is pretty big but much smaller than re-syncing
08:51 < adiabat> also the verification is minial in that you just have to make sure it matches your accumulator roots
08:52 < adiabat> kcalvinalvin: the mainnet sync is crawling huh.  mostly signature checking I guess..?
08:52 < adiabat> 2 days and it's at height 526465... getting there I guess
09:33 -!- Guest95604 [uid458593@gateway/web/irccloud.com/x-wmqexezvfmpyppgg] has joined #utreexo
09:36 -!- Guest95604 is now known as sam
09:36 -!- sam is now known as Guest98205
10:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
10:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #utreexo
10:18 -!- mattdrollette is now known as MDrollette
10:25 < kcalvinalvin> adiabat That's the mainnet sync for forest. There's only 16GB of memory on the server so I put in on disk. No signature checking
10:25 < kcalvinalvin> I'm current overhauling how forest is put on disk... painfully slow at the moment
10:26 < kcalvinalvin> And it's been there for 6 days now I think?
10:26 < kcalvinalvin> spinning disk is probably hurting it like crazy too
10:28 < kcalvinalvin> adiabat wouldn't the leafset from the forest have to be the entire bottom row on forest?
10:29 < kcalvinalvin> There's ~67,000,000 utxos so with 32 bytes per leaf it'd be around 2GBs
10:29 < kcalvinalvin> I guess it's doable
--- Log closed Fri Aug 07 10:58:26 2020
--- Log opened Fri Aug 07 10:58:26 2020
11:29 < adiabat> yeah probably ends up being more than 2GB, but that's still a lot less than a re-sync
11:29 < adiabat> yeah I guess it's on mechanical disk which is very slow
11:30 < adiabat> thing is, GCE SSDs are also very slow, at least when I've tried them
11:30 < adiabat> I think in all cases, the disks are in a separate machine somewhere else in the data center
11:30 < adiabat> so your latency for disk access is 1ms or so, even for SSD
11:31 < adiabat> oh... "De Bruijn sequences" in PR 182... I assume it work
11:31 < adiabat> I mean the tests show it works so ... I guess I don't have to know exactly why :)
11:52 -!- Guest98205 [uid458593@gateway/web/irccloud.com/x-wmqexezvfmpyppgg] has left #utreexo []
14:34 -!- slivera [~slivera@217.138.204.153] has joined #utreexo
17:22 -!- slivera [~slivera@217.138.204.153] has quit [Ping timeout: 246 seconds]
19:29 -!- fanquake [sid369002@gateway/web/irccloud.com/x-olctokxewerkqszl] has quit [Ping timeout: 244 seconds]
19:34 -!- Guest91961 [sid369002@gateway/web/irccloud.com/x-zekgqkmvbqqcurtw] has joined #utreexo
19:35 -!- Guest91961 [sid369002@gateway/web/irccloud.com/x-zekgqkmvbqqcurtw] has quit [Client Quit]
19:35 -!- Guest91961 [sid369002@gateway/web/irccloud.com/x-ahfvlybjfkwblmbw] has joined #utreexo
19:54 -!- Guest91961 [sid369002@gateway/web/irccloud.com/x-ahfvlybjfkwblmbw] has quit [Ping timeout: 260 seconds]
19:57 -!- Guest91961 [sid369002@gateway/web/irccloud.com/x-pvvhjyneczendkuj] has joined #utreexo
19:58 -!- Guest91961 [sid369002@gateway/web/irccloud.com/x-pvvhjyneczendkuj] has quit [Client Quit]
21:48 -!- Guest91961 [sid369002@gateway/web/irccloud.com/x-ryqjzqmihwjotfar] has joined #utreexo
22:23 -!- Guest91961 [sid369002@gateway/web/irccloud.com/x-ryqjzqmihwjotfar] has quit []
23:15 < icota[m]> @ad
23:18 < icota[m]> adiabat kcalvinalvin would CSN keeping the utxo leafset reduce the p2p overhead?
23:22 < icota[m]> i mean in cases other than the key import scenario we were talking about
23:24 < icota[m]> and how does keeping it compare to the utxo set, storage wise? serialized utxo is 4GB i think, about double?
23:39 -!- slivera [~slivera@217.138.204.153] has joined #utreexo
--- Log closed Sat Aug 08 00:00:42 2020