--- Day changed Tue Oct 02 2018 04:40 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] 04:55 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #rust-bitcoin 10:36 < stevenroose> I have a problem with PSBT :D 10:37 < stevenroose> Is it possible to have an OP_TRUE script in segwit-style scripting? 11:07 < stevenroose> dongcarl: Have you ever tried to create a PSBT of any kind with your PR? 11:07 < stevenroose> Seems like it's impossible except though deserialization. Fields are private, no methods to set them.. 13:37 < andytoshi> stevenroose: thanks for trying to use the PR :P i was waiting until we'd gotten roundtripping down 14:11 < stevenroose> Yeah I'm using it for the proof of reserve thing. Since the PSBT spec should be aware of all possible information potentially needed for signing transactions, I'm just piggybacking the psbt Input struct and using a full psbt while signing the tx. 14:12 < stevenroose> One thing I'm struggling with is how to decide to set either non_witness_utxo or witness_utxo. I'd probably need script inspection somehow. Not too familiar with the segwit spec actually in practice, will have to look at the BIP to look into that. 14:13 < stevenroose> andytoshi: rust-bitcoin doesn't have much script inspecting stuff, right? Specifically just telling is a script needs segwit.. I'm especially confused with what to do if you get a segwit wrapped in p2sh. So I'm just filling both fields whenever I'm not sure. 14:13 < stevenroose> (Even though you could of course recreate the txout field from the transcation field.) 14:18 < andytoshi> right, that's something that script descriptors will eventually support 14:19 < andytoshi> i'm pretty sure we have a function called `is_v0_witness_output()` or something which will tell you if a scriptpubkey is a segwit output 14:19 < andytoshi> oh, so you call https://docs.rs/bitcoin/0.14.2/bitcoin/blockdata/script/struct.Script.html#method.is_p2sh on the outside ... if it's not p2sh, that's easy, you don't need either 14:19 < andytoshi> if it is p2sh you need a redeem script 14:20 < stevenroose> andytoshi: how material is work on script descriptors, esp in Rust? 14:20 < andytoshi> it's basically done https://github.com/apoelstra/script_descriptor just waiting on a writeup/BIP draft to nail down the API 14:20 < stevenroose> Oh nice it actually has all the inspectors that I'm looking for :D 14:22 < stevenroose> I really like the rust-bitcoin concept :D Code is so much more readable than ever would be possible in C/C++ :D 14:23 < stevenroose> That's mostly why I was working on the btcd (Go) codebase before, code is organized and structured in a way that makes sense, awesome documentation, ... You can actually learn things from the code, which is hell in Core. 14:24 < stevenroose> Things like this just make me shiver: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L215-L245 14:27 < andytoshi> well, at lesat there are types.. 14:27 < andytoshi> go has no generics, it's really hard to read or write code 14:27 < andytoshi> but sure, i believe that the documentation of btcd is better 14:31 < stevenroose> To be honest, I've never missed generics in Go. I don't know how, but using it for 2 years full time for all kinds of things, never needed it. It has this amazing feature that is implicit interfaces where any struct implementing the methods an interface requires (without explicitly implementing the interface) fits the interface type. 14:32 < stevenroose> Not sure how, but I didn't miss it. Rust heavily relies on generics I guess because it doesn't have dynamic interface types. 14:32 < stevenroose> Compared to the "traditional interfaces thing" like Java has, traits is kind of the opposite way of Go's flexibility with interface types. 14:33 < stevenroose> But I've been loving the past month or so doing Rust :) 14:48 < andytoshi> do you mean "any struct implementing methods with the same name as those on a interface will be considered to implement the interface, regardless of whether that makes any sense"? 14:48 < andytoshi> because that sounds like python 14:48 < andytoshi> which is basically a toy language because of it 14:49 < stevenroose> Yeah something like that. just s/same name/same signature/ 14:49 < andytoshi> eek 14:49 < andytoshi> right, same signature makes more sense :) 14:51 < stevenroose> It's really useful dependency wise f.e. You're not dependent on the packages with the interfaces you want to implement f.e. Or if you want to write tests on a foreign type of which you're just using some methods, you create an ad-hoc interface with those methods and then you can pass dummy objects in it without having to mock the entire foreign object, just the few methods you care about. 14:51 < andytoshi> C++ concepts are similarly broken https://www.reddit.com/r/rust/comments/9jtzir/c_gets_concepts_aka_traits/e6ud6pm/ 14:51 < andytoshi> right, i can see how it would be useful if you want to hack up some tests with minimal amount of typing 14:52 < andytoshi> having no types whatsoever would be even more useful 14:52 < stevenroose> Yeah traits are totally different. Instead of being able to use a trait as a type, in Rust you use generics to not-define a type and specify the traits that type needs. 14:52 < andytoshi> but if you're trying to write real code that people can reason about, you need to specify the contracts that all of your datatypes and functions require 14:59 < stevenroose> Not gonna argue in favor of Go while I'm moving away from it atm :D I just never was as productive in any other language both because the compiler does a very good job and the language itself is super simple :) 14:59 < stevenroose> Just my 2 cents :) 14:59 < stevenroose> And now I resolved my "Invalid length" error and got this one in return for a psbt input :D ParseFailed("data not consumed entirely when explicitly deserializing") 15:06 < andytoshi> lol 15:07 < andytoshi> and you got this from serializing a psbt from rust-bitcoin ? 15:08 < andytoshi> i wonder how we could fuzz for these things 15:15 -!- yuntai [3a7a20f1@gateway/web/freenode/ip.58.122.32.241] has joined #rust-bitcoin 15:17 -!- yuntai [3a7a20f1@gateway/web/freenode/ip.58.122.32.241] has quit [Client Quit] 15:20 < stevenroose> The other one was subtle. I used those new (not sure they're new, but didn't find them in 0.14.2) bitcoin::encoding:;serialize and ::deserialize methods to serialize a Transaction and then accidentally deserialized into an Option and that gave the "Invalid length" error 15:20 < stevenroose> Strange that the compiler let me deserialize into an Option actually. 15:20 < stevenroose> when I did Some(deserialize(...)) it worked. 15:20 < treyzania> oh I heard we were bashing on Go here? 15:21 -!- yuntai [3a7a20f1@gateway/web/freenode/ip.58.122.32.241] has joined #rust-bitcoin 15:21 < stevenroose> treyzania: just andrew a tiny bit. I still love it as an app development language. It's safe enough and incredibly productive. But of course we all know Rust is the superior language in here :D 15:23 < treyzania> I find it useful for small things that you'd use Python for but need some kind of parallelization, but I find it really cramped for anything beyond that 15:23 < treyzania> (I know Python has threads and the multiprocessing lib but those are limited) 15:24 < stevenroose> What I also liked about it is the "one folder one package" approach. Gets in the way of doing the module and import things and allows you to structure things beyond inside one file like in Rust 15:24 < treyzania> funny, that's one of my complaints about go 15:25 < treyzania> not so much the approach itself, but the way they did it 15:25 < stevenroose> :) I really like it. It just gets out of your way. 15:28 < treyzania> most of my complaints with go are things that make me feel like the devs said "this works well enough" and didn't think everything through. I feel like it just repeats a lot of the problems C and js (backend) have while trying to be "so much better" than both of them 15:29 < andytoshi> yeah, that is weird that we can de/serialize Option 15:29 < andytoshi> maybe we should remove that ... i remember in the long distant past there was a reason for this 15:31 < stevenroose> How does it do that? 15:32 < stevenroose> Just a 0 byte is none and a non-zero byte gets dropped and the rest deserialized like normal or so? :D 15:33 < andytoshi> it treats it as a vector of length 0 or 1 15:33 < andytoshi> no, if it's a Some then it's 1-prefixed 15:33 < andytoshi> i'm pretty sure i only had this for the patricia-tree stuff, which in turn was used only to efficiently represent the utxotable in ram 15:40 < stevenroose> I created an issue that I could look into after finishing this. 15:52 -!- yuntai [3a7a20f1@gateway/web/freenode/ip.58.122.32.241] has quit [Ping timeout: 256 seconds] 20:19 < andytoshi> dongcarl: we should add base64 stuff for psbt ... we can make it optional and have the Display and FromStr traits conditionally compiled based on whether people include that dep