--- Log opened Sat May 11 00:00:53 2024
02:21 < RubenSomsen> setavenger: your CBF only contains taproot outputs (not inputs), right? Have you thought through the implications with regards to knowing whether one of your outputs was spent?
02:21 < RubenSomsen> Let's say you're paying to a non-taproot address and there's no change output. How will you know your tx got confirmed?
02:33 < setavenger> RubenSomsen: CBF?
02:33 < RubenSomsen> compact block filters
02:39 < setavenger> oh yeah. It's only outputs, correct. Currently, blindbitd does not have a proper transaction history. It keeps track of all UTXOs (spent or unspent) and distinguishes between spent_confirmed and spent_unconfirmed. A simple transaction history as one knows it from other wallets is still in the works.
02:41 < RubenSomsen> Using my example, how does one move from spent_unconfirmed to spent_confirmed if the filter doesn't register that the tx made it into a block?
02:41 < setavenger> blindbitd periodically checks the balances of the found scriptPubKeys against electrum
02:43 < RubenSomsen> I'm probably misunderstanding something, but doesn't that leak your privacy to the electrum server?
02:47 < setavenger> Was thinking of going via tor for that. But I'm happy to discuss better options as tor opens up a bit more complexity
02:49 < setavenger> Also with regards to broadcasting. There is a similar issue
02:51 < RubenSomsen> Well one approach would be to include taproot inputs in the filter. Then you download the block when you get a hit and see that your output got spent. Of course the downside is that this doubles the filter size.
02:55 < RubenSomsen> Interestingly, the index can also tell you something about confirmation. You know the SP tweak of the tx you made when you paid someone, which you should see back when scanning. This isn't perfect though. If the output gets spent immediately by the recipient then you may miss it, and if you e.g. run your light client on more than one mobile device only one of the two devices will know the SP tweak.
02:58 < setavenger> Maybe I'm not understanding this right but how would I see a tweak if spend to a single non-taproot output?
02:59 < RubenSomsen> Ah yeah, it wouldn't show up in the index, never mind.
03:01 < setavenger> Re filters: Without downloading the block or other block meta data it would not be possible to get the txid and where the tx spent to, right? Currently I'm not even downloading blocks. Only the necessary subsets for a light client to spend the found outputs.
03:06 < RubenSomsen> Yeah, if you're not downloading the full block then that's an issue. You'd need to include data that allows you to check the inputs as well.
03:17 < setavenger> I could create a separate filter which indicates spent taproot UTXOs. This would at least indicate that a UTXO was spent. It must be separate because otherwise it could be confused with the (hopefully unlikely) case of somebody resending to a taproot output that they generated before.
03:18 < setavenger> This opens up an issue though, that I can't track spent_unconfirmed coins across devices/running instances of that wallet. Then the wallet would have to internally track broadcasted UTXOs and rely solely on that information.
03:20 < RubenSomsen> Even with an input-only filter just checking the filter is not enough - you get a probabilistic answer for which you still need certainty.
03:25 < RubenSomsen> So one theoretical full solution that doesn't rely on internal info is if you had a filter that has previous taproot output scripts (i.e. the relevant inputs) as well as new taproot outputs. Then, when you get a hit, you download the full set of previous taproot output scripts + new taproot output scripts & amounts & outpoints (i.e. what's needed to spend).
03:37 < setavenger> Yeah that would work. I guess extracting the exact tx data is a related problem but marking UTXOs as spent is more essential I think.
03:41 < RubenSomsen> Btw you could consider sending an 8 byte (maybe even lower?) representations of the scripts (should probably be salted with the block header). That brings the false positive rate close enough to zero, especially in combination with the false positive rate of the filter.
03:42 < RubenSomsen> So instead of sending a bunch of `taproot_output_script` you'd send `8byte_hash(taproot_output_script||block_header)`
03:55 < RubenSomsen> Slight amendment to the theoretical full solution: downloading the full previous output scripts has issues - better to download the outpoints (can still be reduced to 8 bytes), since the former isn't necessarily unique (e.g. if you received a payment to the same script twice, even though the SP protocol theoretically doesn't allow this).
03:56 < setavenger> Good points, It think I'll implement that. This should be a good replacement for checking final confirmation for spent UTXOs. Not sure one could omit the spent_unconfirmed state. I suspect, this would prohibit RBF. But more importantly the wallet still needs an internal state if several transactions are to be made within one block.
04:04 < RubenSomsen> Can you elaborate on why you think an internal state is required when several transactions are made within one block?
04:15 < setavenger> Within one block is bad phrasing. What I mean is that if I create two transactions and have two utxos (u_a, u_b) I have to make sure that if the first tx spends u_a that the second tx does not try to spend u_a as well. So I need to set a flag that u_a is spent. Currently this happens via electrum and this can be done on different instances/devices running in parallel. 
04:15 < setavenger> If the first tx is confirmed in a block this is no issue as your idea solves for that. But if the first tx is still unconfirmed in the mempool, this will not work.
04:19 < RubenSomsen> OK so to rephrase: if you run the light client on two phones and try to make a payment on both of them simultaneously (or rather: before the two phones sync up their state, either via the mempool or confirmation in a block), they might make a conflicting tx by spending the same UTXO and one of the transactions will fail.
04:24 < setavenger> Yes. On one device this is not a problem as it can be tracked internally. This is technically not even a mobile-only issue but for all light clients in general.
04:34 < setavenger> This problem can actually be expanded. Let’s say I have a low fee tx in the mempool. If I recover the wallet the inputs for this tx. Will also be listed as unspent. This can only be mitigated by checking the outpoints against the mempool.
05:13 < josie> haven't followed the full convo, but just a quick comment that this is a general issue with bip158 (which is why filters contain spent and unspent outputs in a block). i _think_ this is already solved for in bip158 style clients, so we can likely reuse whatever they are doing?
05:54 < setavenger> I think there is a Bip158 Nakamoto client in rust? I'll have a look there.
07:54 < setavenger> Seems like nakamoto matches against the filters and then processes the entire block. I guess one could do the same but serving a taproot focused subset. With my current structure storage requirements for an indexer could increase dramatically though.
07:57 < setavenger> Including spent outputs in the filter should not be a big problem. I guess I could do the 8byte thing for spent utxos. Then the extra storage could be not as bad.
23:40 -!- achow101 [~achow101@user/achow101] has quit [Ping timeout: 268 seconds]
23:40 -!- achow101 [~achow101@user/achow101] has joined #silentpayments
--- Log closed Sun May 12 00:00:54 2024