--- Log opened Mon Nov 01 00:00:21 2021
02:17 < devrandom> OK, so I was looking at the wrong thing :)
02:18 < devrandom> maybe update the utreexo repo README to point people at utcd as a starting point
02:24 < devrandom> also I don't see a README for utreexo in utcd, so here are some questions:
02:24 < devrandom> - looks like the interesting part is `FlatUtreexoProofIndex` and it does support reorgs, right?
02:27 < devrandom> - is it possible to get an arbitrary proof for an active UTXO at the chain tip from utcd?
02:28 < devrandom> - is it possible to get an existence proof for a UTXO that was active at some block in the past, as of that block?
02:28 < devrandom> s/- is it possible to get an arbitrary proof for an active UTXO at the chain tip from utcd?/- is it possible to get an arbitrary proof over RPC for an active UTXO at the chain tip?/
02:28 < devrandom> s/- is it possible to get an arbitrary proof for an active UTXO at the chain tip from utcd?/- is it possible to get an existence proof over RPC for an arbitrary active UTXO at the chain tip?/
02:29 < devrandom> - is it possible to get the accumulator state as of some arbitrary block over RPC?
04:10 < devrandom> s/- is it possible to get an arbitrary proof for an active UTXO at the chain tip from utcd?/- is it possible to get a batch existence proof over RPC for a set of active UTXO at the chain tip?/
04:11 < devrandom> s/- is it possible to get an existence proof for a UTXO that was active at some block in the past, as of that block?/- is it possible to get an existence proof for UTXOs as of a past block? (this may not be strictly required for our use case, but I'm curious if it's possible)/
08:20 < kcalvinalvin> devrandom: devrandom > looks like the interesting part is `FlatUtreexoProofIndex` and it does support reorgs, right?
08:20 < kcalvinalvin> Yes. That and UtreexoProofIndex. The only difference is that FlatUtreexoProofIndex stores them in a normal file and not in the leveldb.
08:20 < kcalvinalvin> > is it possible to get an arbitrary proof for an active UTXO at the chain tip from utcd?
08:20 < kcalvinalvin> Yes. That's how proof for tx messages are generated at the moment
08:20 < kcalvinalvin> > - is it possible to get an existence proof for a UTXO that was active at some block in the past, as of that block?
08:20 < kcalvinalvin> Yes. You save proof for all the utxos created in each block as you ibd. As of now, you'd have to send the proof for the entire block though. You could write code to filter out all the other stuff you don't need.
08:20 < kcalvinalvin> > is it possible to get an existence proof over RPC for an arbitrary active UTXO at the chain tip?
08:20 < kcalvinalvin> That's not implemented yet but that's easily doable since you'd just need to implement the rpc part.
08:20 < kcalvinalvin> > is it possible to get a batch existence proof over RPC for a set of active UTXO at the chain tip?
08:20 < kcalvinalvin> Not implemented as an RPC but it's also easily doable as you just need to implement the rpc part.
08:20 < kcalvinalvin> > is it possible to get an existence proof for UTXOs as of a past block?
08:20 < kcalvinalvin> Not quite understanding the question here since a UTXO can only be spent once.
08:20 < kcalvinalvin> In general, proving a single UTXO and proving a bunch of UTXOs is the same since the code is designed to take in multiple UTXOs
08:21 < kcalvinalvin> For proving a UTXO, you just pass in an array with 1 element
08:22 < kcalvinalvin> https://github.com/mit-dci/utcd/blob/9b19805dfd801d56aa5af0d0b6a67034d6cc3988/blockchain/indexers/flatutreexoproofindex.go#L260-L272
08:23 < kcalvinalvin> This is the function used to generate proof for UTXOs at the chain tip
08:23 < kcalvinalvin> https://github.com/mit-dci/utcd/blob/9b19805dfd801d56aa5af0d0b6a67034d6cc3988/blockchain/indexers/flatutreexoproofindex.go#L215-L237
08:24 < kcalvinalvin> You fetch the proof for all the utxos created in a block with this function
08:24 < kcalvinalvin> The proof is batched together so you'd need to implement code that gets rid of all the stuff you don't need
08:25 < kcalvinalvin> But if you send that over, you could prove a UTXO that was active at that block
08:25 < kcalvinalvin> https://github.com/mit-dci/utcd/blob/9b19805dfd801d56aa5af0d0b6a67034d6cc3988/blockchain/indexers/flatutreexoproofindex.go#L118-L181
08:26 < kcalvinalvin> This is the main function that generates proofs for block that come in
08:55 < devrandom> OK, I think we are talking about slightly different things
08:56 < devrandom> when you say "block proof", I think you mean by that a proof of the UTXOs that are spent in that block
08:56 < devrandom> but the proofs we need are that a UTXO that was created in a previous block is still active as of the current block
10:32 < kcalvinalvin> Ok so is the situation like this?:
10:32 < kcalvinalvin> a UTXO was created at block 1,000 and the current chain tip is 1,100. This UTXO has not been spent. Can you prove this UTXO was created at block 1,000
10:34 < kcalvinalvin> If this is the case, I'll have to ponder on that a bit more.
10:34 < kcalvinalvin> You could prove that the UTXO in question exists in block 1,000 and still exists in block 1,100
10:34 < kcalvinalvin> You can't prove that it didn't exist in block 999
10:35 < kcalvinalvin> (with the current code at least)
10:35 < kcalvinalvin> The verifier would have to save the accumulator roots at block 1,000 though
10:36 < kcalvinalvin> Which isn't too much :) like 1KB at worst
10:40 < kcalvinalvin> To actually answer that question, the current code can't really do that
10:42 < kcalvinalvin> The easiest way to add that functionality would be to generate inclusion proofs of newly created UTXOs at each block
10:43 < kcalvinalvin> Hmm I'll have to ponder about how to implement that nice and clean
10:44 < kcalvinalvin> I'll also look at lightning signer in more detail...
11:40 < devrandom> <kcalvinalvin> "You could prove that the UTXO in..." <- this is what is needed
11:40 < devrandom> <kcalvinalvin> "You can't prove that it didn't..." <- this can be proven with an SPV proof of the creating tx in block 1000, so no need to involve Utreexo
11:41 < devrandom> * involve Utreexo.  this particular type of proof is also not necessary for this use case.
11:42 < devrandom> <kcalvinalvin> "I'll also look at lightning..." <- the specific requirements arise from the design in https://gitlab.com/lightning-signer/docs/-/blob/2021-10-oracle/oracle.md
13:27 -!- pigeons [~pigeons@androzani.sysevolve.com] has joined #utreexo
20:15 < adiabat> You can prove the block height of the creation of every UTXO with utreexo
20:15 < adiabat> since the leaves have the blockhash (as a hash) and the height (as a 32 bit int) in the preimage data that goes into the leaf
20:16 < adiabat> I mean even if utreexo didn't give you that data, you could get it with a separate SPV proof
20:16 < adiabat> but fortunately, it does.  A utreexo proof will tell you:
20:16 < adiabat> This UTXO still exists in the global UTXO set,
20:17 < adiabat> pkScript, amount of satoshis, creation block height, creation block hash, txid:index
20:18 < adiabat> if you want the unix time of the block that created it, you'd need to also send the 80 byte header with that field in it
20:18 < adiabat> we commit to the blockhash though so in a sense that data is "in there"
20:19 < adiabat> I guess in theory txid:index (outpoint) is the only thing you need to commit to, and everything else can be proven from there
20:20 < adiabat> but in practice that's annoying and it ends up more efficient to put more into the leaf data, since you'll need to know amount, pkscript, height, etc anyway
--- Log closed Tue Nov 02 00:00:21 2021