--- Day changed Wed Oct 03 2018
00:35 -!- Tralfaz [~none@103.254.153.99] has joined #rust-bitcoin
15:12 < Blackwolfsa> I hope I can get some clarification on the Bolt 7 spec of lightning. When sending out node_announcement Messages, must the messages be signed by by your Sk, but with the other node_id
15:12 < Blackwolfsa> This is in relation to initial_routing_sync flag set on the init message.
15:13 < Blackwolfsa> Or am I completely mis reading the spec and I should only send out one for me and not all connected nodes?
15:51 < stevenroose> andytoshi: when a method can produce two different types of errors
15:51 < stevenroose> Is there another way to easily do that other than creating a new enum error type with two instances?
16:54 < andytoshi> stevenroose: you could use a Result, or you could add the two intances to an existing error type
16:57 < stevenroose> Would that make sense here? https://github.com/rust-bitcoin/rust-bitcoin/pull/177
17:00 < andytoshi> i think this is fine .. though you should add a variant to util::Error or whatever the "main rust-bitcoin error type" is these days with a `ParseOutPointError`
17:02 < stevenroose> andytoshi: where does that one live?
17:02 < stevenroose> ah in util :D
17:02 < andytoshi> yeah, util/mod.rs
17:03 < andytoshi> or you can use crate::Error
17:03 < stevenroose> Why is that useful?
17:03 < andytoshi> it's just easier to remember
17:03 < stevenroose> For the case where other parts of the code start using the from_str method?
17:03 < stevenroose> No I mean adding that error there
17:04 < andytoshi> it's useful for people who don't want to deal with multiple error types from rust-bitcoin
17:04 < stevenroose> so should I also return that type
17:04 < stevenroose> ?
17:04 < andytoshi> yeah
17:04 < andytoshi> maybe
17:05 < andytoshi> i wish that we would always return that type, but we already don't in deserialization (for example)
17:05 < andytoshi> so maybe what you've got now is fine, it's consistent with the rest of the code
17:05 < andytoshi> and we can rethink errors in the far future when the `failure` crate is mature or whatever
17:06 < stevenroose> Yeah personally I think like this makes more sense. If ever we use that function internally and we need to return something more general, it could be added.
17:06 < stevenroose> But returning the generic error in that method feels awkward.
17:07 < andytoshi> ok, fair enough
17:46 < stevenroose> Oooh
17:46 < stevenroose> Remember this PSBT decoding issue. I set both a non_witness_utxo and witness_utxo (to decide later which one I was to use).
17:47 < stevenroose> dongcarl: can that result in an error like this: ParseFailed("data not consumed entirely when explicitly deserializing")
17:48 < stevenroose> I don't think it's that actually. Since I also store somewhere else just a psbt::Input and that one decodes without any issues.
18:39 < stevenroose> Aha, got that one solved!  Had to manually construct an entire legit PSBT in Rust form though :D Manual labour
18:47 < stevenroose> dongcarl: I'm still giving you comments on the PR :)
18:54 < andytoshi> no rush - the PR is blocked on having a PublicKey type that can round-trip