--- Log opened Mon Nov 25 00:00:01 2024
05:25 -!- angusp [9e8eed9774@2a03:6000:1812:100::1048] has quit [Remote host closed the connection]
05:26 -!- angusp [9e8eed9774@2a03:6000:1812:100::1048] has joined #bitcoin-rust
05:30 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 272 seconds]
05:31 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-rust
05:36 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 244 seconds]
05:38 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-rust
05:58 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
06:24 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-rust
06:57 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 265 seconds]
06:59 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-rust
07:17 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
07:18 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-rust
09:45 -!- tankyleo [~tankyleo@2601:645:8080:1d00:c930:2b49:c6e:4a1b] has joined #bitcoin-rust
09:48 -!- tankyleo [~tankyleo@2601:645:8080:1d00:c930:2b49:c6e:4a1b] has quit [Remote host closed the connection]
10:14 -!- darosior [~darosior@109.205.214.46] has quit [Ping timeout: 272 seconds]
10:15 -!- darosior [~darosior@109.205.214.46] has joined #bitcoin-rust
10:24 -!- SmithRoger [~SmithRoge@179.251.61.241] has joined #bitcoin-rust
10:27 < SmithRoger> Hey guys, I'm trying to learn how to use the rust-bitcoin library for the first time. I'm going to redo an exercise done in shell on Bitcoin Dev launchpad. I need to connect to the node and look for a specific block, but I didn't understand or found how to make this connection with the lib. Do I need to mount the rpc with another library?
10:32 < andytoshi> yeah -- rust-bitcoin has no network stuff. you can use rust-bitcoincore-rpc which should work for you, though it's no longer maintained. we have a replcement we're working on but i don't think it's ready
10:35 -!- sanket1729_web [~sanket172@2a09:bac0:1001:1e2::2db:1a] has joined #bitcoin-rust
10:36 -!- Test28 [~Test@179.251.61.241] has joined #bitcoin-rust
10:36 -!- Test28 [~Test@179.251.61.241] has quit [Client Quit]
10:39 < sanket1729_web> Is this channel logged? andytoshi just me (sanket1729) some discussion about TaprootBuilder::with_huffman_tree from Ademan
10:40 < SmithRoger> Thank you very much andytoshi
10:41 < andytoshi> sanket1729_web: the /topic says "channel logs forthcoming" :(
10:41 < andytoshi> oh wait
10:41 < andytoshi> https://gnusha.org/bitcoin-rust/2024-11-25.log
10:41 < andytoshi> lemme update the topic with that
10:41 -!- mode/#bitcoin-rust [+o andytoshi] by ChanServ
10:41 -!- andytoshi changed the topic of #bitcoin-rust to: Discussion of rust-bitcoin, rust-lightning and related crates | For rust-miniscript see ##miniscript | For general bitcoin discussion #bitcoin | Logs at https://gnusha.org/bitcoin-rust/
10:42 < sanket1729_web> Nice
10:43 < sanket1729_web> So, I think Ademan is asking about TaprootBuilder::with_huffman_tree and the changes andytoshi is planning to do are on rust-miniscript repo.
10:44 < sanket1729_web> I don't think we are planning on changing that?
10:46 <@andytoshi> sanket1729_web: yes, i am planning to change it
10:46 <@andytoshi> i have to change it because it's a constructor for TapTree, so any changes i make to TapTree will be reflected there
10:46 <@andytoshi> and yeah, we should probably be in ##miniscript for this discussion ... but i think here is fine
10:49 -!- sanket1729_web [~sanket172@2a09:bac0:1001:1e2::2db:1a] has quit [Quit: Client closed]
10:49 -!- sanket1729_web [~sanket172@2a09:bac0:1001:1e2::2db:1a] has joined #bitcoin-rust
10:49 < sanket1729_web> What changes are you planning to make to TapTree? I don't see how any change there can affect the ordering the leaves from huffman encoding. There is only one way to encode the tree optimally with binary heap method.
10:50 < sanket1729_web> The data structure for TaprootSpendInfo will change, but the ordering of the leaves and tree strcture should remain the same? Since there is only one optimal structure for leaves with given odds
10:52 < sanket1729_web> As in, the bitcoin address and spending control block data should be the same.
10:53 < sanket1729_web> We should also check that sorting in the binary heap is stable sort. (meaning gives the same output always for equal values of weights)
10:54 < sanket1729_web> Might be simpler to discuss after you open the PR.
10:55 <@andytoshi> sanket1729_web: there is not only one way if leaves have the same weights
10:55 <@andytoshi> and even if all the leaves have different weights, it can happen that internal nodes have the same weight
10:56 <@andytoshi> i suspect the binaryheap is not stable ... the docs don't say it will be stable https://doc.rust-lang.org/std/collections/struct.BinaryHeap.html
10:57 < sanket1729_web> We can add leaf_hash to the Ord operate of <(wight, leaf_hash)> to get a stable ordering. But this will be breaking change....
10:57 < Ademan> oooh that's a good point, even if I kept my own copy of the current algorithm, I could still end up in trouble
10:58 < Ademan> that sounds sane to me, especially if andy is already going to break the API
10:58 <@andytoshi> sanket1729_web: oh, that's a good idea (assuming we are willing to break at all)
10:58 <@andytoshi> although it may be hard to come up with a leaf hash, since this constructor does not assume Pk: ToPublicKey. but i think i can figure something out
11:00 < sanket1729_web> Ademan: In this long run, I think you should use output descriptors. They are the recommended way to do backups. We will always guarantee that descriptor will always resolve to the same address! Otherwise it would be critical bug on our side.
11:05 < Ademan> sanket1729_web: thanks but I don't think backing up descriptors is feasible in my particular use case. I'm precomputing a massive tree of transactions with a potentially huge tap tree per-transaction.
11:06 <@andytoshi> how are you backing up the policies that you expect to compile consistently?
11:06 <@andytoshi> or are they being programmatically generated somehow?
11:07 < Ademan> yeah generated
11:11 < Ademan> I have some more boring code to write after work (tonight?) and then I can share and talk a bit more concretely about it
11:12 < Ademan> I want to prove the concept to myself before I potentially embarass myself haha
11:12 < sanket1729_web> I reviewed the code for BinaryHeap, and it appears to be stable. The same order of operations will result in the same output. But there is no mention in the docs about this being stable
11:13 <@andytoshi> Ademan: wait, i might be confused about what function you're using ... are you using rust-bitcoin's TaprootBuilder huffman tree function?
11:14 <@andytoshi> or the one in the rust-miniscript compiler?
11:15 <@andytoshi> the rust-miniscript one is the one i plan to break. the rust-bitcoin one shouldn't change (and i'll bet that stdlib's BinaryHeap won't ever change, because if it's stable now then peoople will complain if it stops being stable0
11:18 < sanket1729_web> ooh, we are not relying on equal values!!! Our binary heap is on tuple BinaryHeap::<(Reverse<u32>, NodeInfo)
11:19 < sanket1729_web> We should be good, even if two leaves have the same odds, they will be deterministically sorted because they have different NodeInfo (merkle hash)
11:19 < sanket1729_web> Unless they have the same hash, in which case they are the same and it does not matter
11:21 < sanket1729_web> And for rust-miniscript, we have always been saying that the compiler output is not guaranteed across versions, or even the same version across runs. We encourage users to compile once and use the compiled descriptors for backups.
11:21 < Ademan> andytoshi: ah! yeah no I'm using TaprootBuilder
11:22 < sanket1729_web> Ademan: you are good. We should never change that. There maybe breaking changes to API, but we should make sure that the tree created from huffman_tree should remain the same
11:23 < Ademan> I was confused by your comment earlier about "the compiler output is not stable and has no stability guarantees even with same version on same system" but I assumed you were saying by analogy I shouldn't rely on TaprootBuilder being stable heh
11:23 < sanket1729_web> andytoshi: I think this means manually implementing Ord(as it currently implemented) to future proof against breaking it
11:24 < sanket1729_web> #[derive(Debug, Clone, PartialOrd, Ord)]
11:24 < sanket1729_web> pub struct NodeInfo {
11:24 < sanket1729_web> If we change this struct, things will break badly and auto-derive breaks, things can break badly
11:26 < sanket1729_web> Ademan: Thanks for bringing this up, highlighted more areas in taproot APIs that we need to careful about
11:26 -!- sanket1729_web [~sanket172@2a09:bac0:1001:1e2::2db:1a] has quit [Quit: Client closed]
11:26 -!- sanket1729_web [~sanket172@2a09:bac0:1001:1e2::2db:1a] has joined #bitcoin-rust
11:28 <@andytoshi> sanket1729_web: yep -- good call. we should make NodeInfo in rust-bitcoin explicit. i'll open an issue
11:28 <@andytoshi> Ord in NodeInfo*
11:28 <@andytoshi> and for the compiler, i'll try to do something similar to help make this deterministic
11:28 <@andytoshi> but i will break it relative to its current behavior :P
11:29 < sanket1729_web> I think our compiler can break. Our stance has always been "We make best effort to make it deterministic, but don't guarantee it".
11:30 <@andytoshi> https://github.com/rust-bitcoin/rust-bitcoin/issues/3654
11:33 -!- sanket1729_web [~sanket172@2a09:bac0:1001:1e2::2db:1a] has quit [Quit: Client closed]
11:40 -!- SmithRoger [~SmithRoge@179.251.61.241] has quit [Ping timeout: 252 seconds]
13:02 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 245 seconds]
13:15 -!- greypw1 [~greypw@user/greypw] has quit [Read error: Connection reset by peer]
13:16 -!- greypw1 [~greypw@user/greypw] has joined #bitcoin-rust
16:25 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-rust
17:17 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
18:34 -!- cmc [~methos@gateway/tor-sasl/cmc] has quit [Ping timeout: 260 seconds]
18:35 -!- cmc [~methos@gateway/tor-sasl/cmc] has joined #bitcoin-rust
19:15 -!- greypw1 [~greypw@user/greypw] has quit [Remote host closed the connection]
19:16 -!- greypw1 [~greypw@user/greypw] has joined #bitcoin-rust
19:34 -!- b10c [~quassel@user/b10c] has quit [Ping timeout: 264 seconds]
20:16 -!- b42 [~mmilata@2a03:3b40:fe:1e5::1] has quit [Ping timeout: 260 seconds]
--- Log closed Tue Nov 26 00:00:02 2024