--- Log opened Fri Oct 29 00:00:17 2021 00:16 < RubenSomsen> It's certainly a step removed from the main use case of utreexo. If you run a utreexo node then you won't need exclusion proofs, because you're simply aware of the full state, so it only makes sense in some kind of light client model. 04:31 < devrandom> I understand 04:33 < devrandom> I do have a question about proofs. it seems to me that proofs have to continuously change as new UTXOs are added and deleted, because the merkle trees change shape, right? how does a wallet practically do that? does it need a node to stream all UTXOs to it as blocks come in? 08:54 < kcalvinalvin> devrandom funny you mention this because I was talking with adiabat about this just yesterday. 08:55 < kcalvinalvin> A wallet keeping the roots of the merkle trees and all the nodes that it needs to prove the UTXOs it cares about is one way to do it 08:55 < devrandom> but those change each block, right? 08:55 < kcalvinalvin> But we're not going to implement that since the assumption is that bridgenodes will be around and we won't get to a situation where bridgenodes won't be around 08:56 < kcalvinalvin> Yeah you modify the merkle trees as new blocks come in 08:59 < devrandom> it was my impression when reading the paper that the intention was for wallets to only talk to CSNs 09:00 < devrandom> and it also seems like it should be possible for wallets to update their proofs by streaming the UTXOs added/removed in each block (but of course that's not such a lightweight operation) 09:02 < kcalvinalvin> The merkle tree modification is pretty efficient because it's done in batches (and because there's a lot of overlap) 09:02 < kcalvinalvin> That part doesn't worry me at all 09:06 < devrandom> I'm referring to proof modification for wallets - not the node stuff 09:07 < devrandom> I thought that the vision is that wallets keep track of proofs for the UTXOs they have active (coins in the wallet) 09:07 < devrandom> or is CSN == Wallet ? 09:08 < kcalvinalvin> CSN (compact state node) 09:08 < kcalvinalvin> so not a wallet 09:08 < devrandom> OK 09:08 < kcalvinalvin> But the proof modification for the wallets don't worry me either 09:08 < kcalvinalvin> The overhead for a single block is negligible 09:09 < kcalvinalvin> Sure eventually that'd be the vision. But that's only needed when there are no bridge nodes 09:09 < kcalvinalvin> And also, keeping track of proofs for your UTXOs is a privacy leak 09:11 < devrandom> if you stream all of the UTXO deltas for each new block, it seems you can update your proofs without leaking anything 09:12 < kcalvinalvin> It's more for broadcasting txs 09:13 < kcalvinalvin> Like if you're broadcasting a tx with proof already attached to it, that gives a hint saying you care about some particular utxo 09:13 < kcalvinalvin> Other nodes can probe to see if you're a bridge node or not 09:14 < devrandom> I thought in the Utreexo vision all mempool txs will have proofs attached to the inputs 09:14 < kcalvinalvin> If you're a CSN but broadcast a tx with a proof, that's saying that you care about the inputs to that tx 09:14 < kcalvinalvin> Oh yeah that's still the vision 09:14 < kcalvinalvin> You broadcast without the proof 09:15 < kcalvinalvin> few seconds later, you get your tx back with a proof attached to it (generated by a bridgenode) 09:16 < kcalvinalvin> Eventually we'd want to implement everything where CSNs keep track of proofs 09:16 < kcalvinalvin> But I got convinced by Tadge that it's not a critical feature to implement at the moment 09:17 < devrandom> OK, I thought the intermediate step was something like 1000 CSNs + 20 bridge nodes + existing bitcoin network. so that the CSN side looks more like the final vision, because most CSNs don't talk to bridges 09:17 < devrandom> but sounds like you are thinking of a step before that 09:17 < devrandom> got it 09:18 < kcalvinalvin> Well I hope I was of help :) 09:20 < devrandom> if a bridge attaches a proof to a tx, and sends it on it's way, and a new block comes in, will the CSN update the proof so it's valid for the chain tip? 09:21 < devrandom> thank you. I'm guessing I'll have more questions, including the one above ;) 09:23 < kcalvinalvin> Ok so: 1) at tip (let's just say 700,000), bridge generates proof and sends to CSN. 2) CSN receives block 700,001. 3) CSN receives that proof 09:23 < kcalvinalvin> Is this correct? 09:25 < kcalvinalvin> Maybe I should mention that a "proof" isn't kept separately from the merkle tree. 09:25 < kcalvinalvin> 14 09:25 < kcalvinalvin> |---------------\ 09:25 < kcalvinalvin> 12 13 09:25 < kcalvinalvin> |-------\ |-------\ 09:25 < kcalvinalvin> 08 09 10 11 09:25 < kcalvinalvin> |---\ |---\ |---\ |---\ 09:25 < kcalvinalvin> 00 01 02 03 04 05 06 07 09:26 < kcalvinalvin> So here, we have 8 utxos. If a CSN wants to keep track of 06, 09:26 < kcalvinalvin> 14 09:26 < kcalvinalvin> |---------------\ 09:26 < kcalvinalvin> 12 09:26 < kcalvinalvin> |-------\ |-------\ 09:26 < kcalvinalvin> 10 09:26 < kcalvinalvin> |---\ |---\ |---\ |---\ 09:26 < kcalvinalvin> 06 07 09:26 < kcalvinalvin> It would keep this merkle tree structure 09:28 < kcalvinalvin> Only the root is required to be a full node so by default, the CSNs merkle tree would look like this 09:28 < kcalvinalvin> 14 09:28 < kcalvinalvin> |---------------\ 09:28 < kcalvinalvin> 09:28 < kcalvinalvin> |-------\ |-------\ 09:28 < kcalvinalvin> 09:28 < kcalvinalvin> |---\ |---\ |---\ |---\ 09:59 -!- jamesob [uid180710@id-180710.helmsley.irccloud.com] has quit [Quit: Connection closed for inactivity] 14:12 < devrandom> "Ok so: 1) at tip (let's just say..." <- right, that's the case I was wondering about 14:15 < devrandom> "So here, we have 8 utxos. If a..." <- I think the second tree should have 11 (the parent of 06), not 10 14:16 < devrandom> "Only the root is required to..." <- I didn't understand the third tree - it has no leaves? 14:18 < devrandom> also, if block 700001 deletes UTXO 07, then the proof has to update the provided sibling hashes 14:18 < devrandom> (seems like the update would be a lot simpler if we never compacted trees on deletes - I think you are calling that "swapless"?) 14:19 * devrandom is off for the day --- Log closed Sat Oct 30 00:00:18 2021