--- Day changed Fri Nov 16 2018
00:50 < ariard> BlueMatt: after thinking seems that we hit a deadlock with staticoutputdescriptor: if generated into ChannelMonitor, in watchtower mode, to avoid balance leak, need to send a false-positive
00:51 < ariard> And if generated in closing_signed, as each closing_tx may be broadcast by the other peer without our knowledge, we should also generate descriptor for each one but only would be valid
00:54 < ariard> I think we can go back on this latter as watchtower mode will need some kind of message passing without being able to distinguish which output is our
02:21 <+andytoshi> dongcarl: yeah, the descriptors we want for rust-bitcoin are much simpler than what we want for miniscript. maybe in future we can unify them but it's not obvious to me how to do that
02:22 <+andytoshi> sgeisler: i'm thinknig that addresses would just not have pubkeys associated to them, they'd be purely serializations of scriptpubkeys (much like they are in the current code) .. but we'd encourage wallet devs to track descriptors rather than addresses, in general
02:28 < dongcarl> andytoshi: w/re descriptors, yeah I think I'll come up with obscure API challenges after trying to implement a bit lol
02:30 < sgeisler> andytoshi: you mean like this: https://gist.github.com/sgeisler/0b5e9825dd181c24121900e8c6a9a46d#file-example-rs-L22 ?
02:31 < sgeisler> descriptors as optional source for public keys etc.? that would seem redundant.
02:32 < dongcarl> w/re addresses not having pubkeys associated to them, that was what I was thinking for making pubkeys and addresses separate... I believe we actually implicitly clone in p2pk as we dereference secp::PublicKey, which implements Copy, which Clones on deref: https://github.com/rust-bitcoin/rust-bitcoin/blob/master/src/util/address.rs#L117
04:34 < dongcarl> Updated: https://github.com/rust-bitcoin/rust-bitcoin/pull/183
04:35 < dongcarl> Also, TIL about the difference between Copy and Clone... memcpy feels much better than arbitrary Clone
11:36 < stevenroose> andytoshi: is there a convention that grants "witness" a capital W in abbreviations? :D ShWpkh
11:36 < stevenroose> ah it's because it's nested
11:36 < stevenroose> nvm
11:41 < stevenroose> So conclusion is Address *just* has data that can be *deserialized* from a string address, and we use script descriptors for wallet to track pubkeys? that's cool
11:41 < stevenroose> > the descriptors we want for rust-bitcoin are much simpler than what we want for miniscript
11:42 < stevenroose> andytoshi: what's the difference? if we were to take descriptors in rust-bitcoin, could miniscript extend on top of them?
11:44 < stevenroose> unrelated: What permissions would I need to be able to restart CI processes on rust-bitcoin PRs?
13:01 <+andytoshi> sgeisler: oh, yeah, we could def put an Option<Descriptor> into the address
13:01 <+andytoshi> i hadn't even considered doing that
13:02 <+andytoshi> stevenroose: miniscript is much bigger than all of rust-bitcoin
13:03 <+andytoshi> we are not going to more-than-double the size of the library to make addresses more ergonomic :P
13:23 <+andytoshi> if miniscript were well defined (had a bip or a spec document or something) it might be reasonable to move some of the miniscript lib into rust-bitcoin ... the bulk of the library is the policy language/compiler and satisfaction code, which can be separated from the data structures and de/serialization
13:23 <+andytoshi> though even the script -> miniscript mapping is a huge lisp-style recursive macro ad-hoc parser I wrote
14:36 < BlueMatt> ariard: we can add more data to the channelmonitor for non-watchtower-only mode?
14:37 < BlueMatt> we already have a watchtower mode
14:37 < BlueMatt> well watchtower/non-watchtower distinction
16:20 < stevenroose> this sucks
16:20 < stevenroose> I know Rust is all proud that it's code snippets in documentation are compile-checked etc
16:21 < stevenroose> but I write some serde serializer code and just want to give an example of the serializatoin
16:21 < stevenroose> and it complains that there is no crate serde_derive defined
16:21 < stevenroose> Do they really expect people to add dependencies *for docs*?? Is there a [doc-dependencies] for that? /s
16:32 < BlueMatt> stevenroose: cant you just write the doc on a function thats only compiled in serde mode?
16:35 < stevenroose> BlueMatt: yeah, but still we don't need serde_derive
16:35 < stevenroose> only serde
16:36 < stevenroose> But I just did ```rust,ignore
16:37 < stevenroose> I know it's not possible due to the complex variants that have variables inside them, but it would be nice to be able to iterate all values of an enum in a unit testw
17:07 < stevenroose> Has anyone ever had a #[derive(Copy, Clone)] being ignore? I'm suddenly getting "use of moved value" :/
17:09 <+andytoshi> stevenroose: dongcarl: sgeisler: so, the latest version of rust that mrustc supports is 1.19 ... and unfortunately I think that's important enough that we should pin our compiler version to it even if debian's packager has moved ahead (and we should even try to add mrustc to our CI)
17:09 <+andytoshi> which sadly means no associated constants in traits
17:59 < stevenroose> That Copy, Clone thing I ran into seems to confuse not only me.. https://github.com/rust-lang/rust/issues/56008
18:06 <+andytoshi> yeah phantomdata is werid
18:06 <+andytoshi> and #derive is a bit surprising here but this is by far the most ergonomic thing they could've done
18:08 < stevenroose> Well the problem is that PhantomData implements Copy with no Copy requirement on the generic type, only ?Sized.
18:08 < stevenroose> So it should work. And the compiler also doesn't complain about the derive statement like it would do before I used PhantomData.
18:10 <+andytoshi> oh i see what you're saying. hmm
18:11 <+andytoshi> i guess you've gotta write `impl Copy {}` ... unsure if that's a bug, it certainly requires understanding the #derive impl to see why this is what happens..
18:11 <+andytoshi> specifically #derive always looks for trait bounds on all parameters before implementing any traits
18:13 <+andytoshi> it can't know what's actually implemented, it's just an AST transform
18:18 < dongcarl> andytoshi: We can mrustc bootstrap to 1.19, then compile 1.20 from 1.19 tho right?
18:23 <+andytoshi> yeah, we can, and maybe it's reasonable to accept one layer of bootstrapping
18:23 <+andytoshi> but like, we can't say "let's use 1.24, and users can just use mrustc for 1.19, then 1.20 then 1.21 then 1.22 then 1.23 then 1.24, easy!" :)
18:24 <+andytoshi> in particular, every additional version introduces a new "trusting trust" vulnerability and somebody serious about toolchain provenance would need to take a look at every one of those diffs
18:27 < stevenroose> andytoshi: what's the use case for mrustc? Seems like a one-man's project.
18:28 <+andytoshi> compiling rustc
18:28 <+andytoshi> without downloading random binaries from the rustc developers
18:35 < stevenroose> ah, because rustc is written in Rust.. makes sense
18:36 < stevenroose> andytoshi: now that I was looking at the Amount type: any string feelings on i64 vs u64?
18:38 < stevenroose> strong*
18:38 < stevenroose> Or just any opinion
18:45 < gwillen> I am pleased that mrustc exists
18:45 < gwillen> because I've heard people bitch about the rustc trusting-trust problem before and I didn't have an answer for them
18:49 <+andytoshi> stevenroose: i prefer u64
18:49 <+andytoshi> though i guess we'd need a SignedAmount in some contexts
18:49 <+andytoshi> well, actually i guess internally it should be an i64. but maybe we should have a method to extract a u64 and maybe that should panic if it's negative, or something
18:51 < stevenroose> I thought output amounts were int64's in the wire protocol, no?
18:52 < stevenroose> I mean I agree u64 makes more sense, especially there.
18:53 <+andytoshi> yes, they are i64s in the wire protocol, and this irritates me to no end
18:53 < BlueMatt> they aren't i64s or u64
18:53 < BlueMatt> they're 64 bit numbers maxed out at 21 mill * 10^8
18:54 < BlueMatt> which is like u50-something :p
18:54 <+andytoshi> right, numbers on the wire are always between 0 and that max .. so the distinction is purely academic
18:54 <+andytoshi> though i believe Core deserializes them into int64_t's (or at lesat it used to)
18:55 < BlueMatt> it appears it still does, yes
18:56 < BlueMatt> or, really, it deserializes it into 64 bits and checsk that the high bit is 0 and that the rest of the high bits are zero separately :p
18:56 < stevenroose> https://en.bitcoin.it/wiki/Protocol_documentation
18:56 < stevenroose> int64_t is used there
18:56 < BlueMatt> though, actually, I'll bet gcc optimizes that out
18:56 < BlueMatt> so, at an instruction level its probably u64 :p
19:44 < stevenroose> Rust-doc: There is a small difference between the two: the derive strategy will also place a Copy bound on type parameters, which isn't always desired.
19:51 <+andytoshi> stevenroose: right, #[derive(Copy)] will impl Copy on your type whenever its parameters all have a Copy bound
22:23 < sgeisler> stevenroose: at first I thought having negative amounts would be useful to avoid underflows in case of invalid transactions with negative fees for example. But that could still happen with i64 as long as there are multiple outputs. So we will need checked_{add, sub} anyway for this use case. Since I can't really think of other use cases of negative amounts I'd prefer stronger guarantees provided by the type (=> u64).
22:43 < sgeisler> andrew: dongcarl: stevenroose: what do you think about this address design https://gist.github.com/sgeisler/55bdbd2a5718515e2d415ca9fda8b321 ?
22:43 < sgeisler> ^^^ andytoshi I meant :D
23:10 <+andytoshi> sgeisler: i think `to_script` should be renamed to `to_scriptpubkey` ... and that there should be an accessor for the network
23:10 <+andytoshi> and i have half a mind to suggest having separate types for p2sh, p2pk, etc., rather than continuing to use the Payload enum
23:11 < sgeisler> Yes, once we have a address trait that sounds like the better solution.
23:11 <+andytoshi> and i have a non-disjoint half a mind to suggest somehow implementing Address directly on Descriptor
23:11 <+andytoshi> but then we'd have to have a network field in Descriptor which maybe doesn't make sense
23:11 <+andytoshi> i see sipa is not in this room..
23:11 < sgeisler> do descriptors include the network?
23:11 <+andytoshi> no :/
23:12 <+andytoshi> which i think i prefer actually, it lets them interoperate with public keys much better
23:12 <+andytoshi> lol, we cooould implement Address on (Network, Descriptor) instead of giving it a named struct
23:15 < sgeisler> I don't know if I really like that idea, it only safes one newtype and you want to implement more functions than the one in the Address trait
23:15 < sgeisler> *ones
23:18 < sgeisler> I thibk we don't want different types for different address types because we couldn't easily convert from (Descriptor, Network) to SimpleAddress anymore, but we had to know which kind of address is represented byt the descriptor
23:19 < sgeisler> one solution would be to make the Payload enum the new SimpleAddress and just include the Network in every variant
23:23 <+andytoshi> yeah, if we split into multiple types we'd have to put the Network in each one
23:23 <+andytoshi> i think you're right, that's dumb
23:23 <+andytoshi> i wonder though if we should just add a Descriptor variant to SimpleAddress?
23:23 <+andytoshi> probably not, there are cases where you want the descriptor and cases where you want to treat them as p2sh/p2pkh/whatever
23:26 < sgeisler> If you have a descriptor other than raw/addr (which I would forbid in that context) you can implement more functions than if you only have a hash and know that's the hash of some compressed pubkey
23:26 < sgeisler> so it makes sense to treat them as different types
23:28 < sgeisler> I think the former allows a strict superset of functionality compared to the latter
23:31 <+andytoshi> yeah agreed