--- Log opened Tue Jan 22 00:00:27 2019 01:08 < TamasBlummer> @icota @BlueMatt rust-bitcoin-spv implements the Lightning interface. It is under a radical refactoring at the moment, but I expect to be able to fully serve the interface within a month. 01:08 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #rust-bitcoin 01:08 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host] 01:08 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #rust-bitcoin 02:25 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-ttwjdcmyvvongndq] has joined #rust-bitcoin 04:45 -!- TamasBlummer1 [~Thunderbi@p200300DD672D1A3358F786CE8ECD7DD6.dip0.t-ipconnect.de] has joined #rust-bitcoin 04:47 -!- TamasBlummer [~Thunderbi@p200300DD672D1A37B547C165C10C8C31.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 04:47 -!- TamasBlummer1 is now known as TamasBlummer 05:08 -!- icota_ [~igor@58-138.dsl.iskon.hr] has joined #rust-bitcoin 05:12 -!- icota [~igor@58-138.dsl.iskon.hr] has quit [Ping timeout: 245 seconds] 07:29 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #rust-bitcoin 09:19 < stevenroose> Hmm, it seems that Core gave me a transaction that raises UnsupportedSegwitFlag(0) 09:19 < stevenroose> Is that possible? 09:21 < stevenroose> Hmm, at hindsight, I first succesfully parse the output from Core, then serialize and deserialize it again and then I get that error. So it's kinda strange. 09:27 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-ttwjdcmyvvongndq] has quit [Quit: Connection closed for inactivity] 09:30 < dongcarl> andytoshi sgeisler TamasBlummer BlueMatt: I wish to request to be added to the rust-bitcoin repository. I have been mostly contributing to the rust-bitcoin and bitcoin_hashes repositories, and I will allocate a large chunk of my time on improving and reviewing rust-bitcoin. 09:30 < BlueMatt> oh did we not do that yet? yea, i dont see why not, andytoshi? 09:30 < BlueMatt> we should probably start requiring two reviews once we have one or two more people, but we're only, what, 4 now? 09:30 < BlueMatt> or are we 5 now? 09:36 < TamasBlummer> 4 at the moment. lets have two reviewers after including @dongcarl 09:40 < TamasBlummer> BTW Hammersbald reached production quality IMHO. I would welcome help to set it up for travis. 09:41 < TamasBlummer> from now on I would do PRs on this and would welcome reviews if someone fancy of diving into its details. 09:41 < stevenroose> Ok so I discovered something relating the UnsupportedSegwitFlag(0) error: There seems to be an implementation of bitcoin::Encodable for Option that prefixes the encoding of E with a 1 bytes :/ 09:41 < stevenroose> Is that accidental? 09:42 < stevenroose> s/a 1 bytes/a 1 byte/ 09:58 < dongcarl> BlueMatt: I think there's 5 right now, with me added that'd be 6 09:58 < dongcarl> TamasBlummer: I think Clark Moody is also in the org? 10:10 < andytoshi> ack to adding dongcarl, i didn't realize he wasn't part of the ord already 10:10 < andytoshi> org* 10:10 < andytoshi> but i kinda like "order" :) 10:11 -!- mode/#rust-bitcoin [+o BlueMatt] by ChanServ 10:11 -!- BlueMatt changed the topic of #rust-bitcoin to: Order of the Rust-Bitcoin Libraries Maintainers. Artisinal Bitcoin for the rest of us. Do NOT have private conversations on the FreeNode network! | https://github.com/rust-bitcoin | Logs at http://gnusha.org/rust-bitcoin/ 10:11 -!- mode/#rust-bitcoin [-o BlueMatt] by ChanServ 10:12 < dongcarl> Thank you andytoshi, BlueMatt, and TamasBlummer 10:13 < dongcarl> Execute order 66? 10:13 < BlueMatt> ok, I changed rust-bitcoin to require two (2!) reviews 10:15 < dongcarl> Thank you BlueMatt 10:16 < dongcarl> sgeisler TamasBlummer andytoshi: if we can get one more sign-off here that'd be great: https://github.com/rust-bitcoin/rust-bitcoin/pull/210 10:21 < stevenroose> https://github.com/rust-bitcoin/rust-bitcoin/blob/master/src/consensus/encode.rs#L538-L551 10:22 < stevenroose> What is the motivation for encoding Option as a vector of size 1?? 10:24 < dongcarl> stevenroose: is that used anywhere? 10:26 < TamasBlummer> I am not in picture of what rustc versions people use and why not using latest stable. Is there a particular feature change that sets the limit or some other project? 10:31 < gwillen> ... is freenode a shill for Big Bcash? Is there something I should know? (Re the topic) 10:34 < dongcarl> gwillen: I think it was more to say that there's no encryption for almost anything on IRC 10:35 < gwillen> it seems rather more specific 10:38 < BlueMatt> gwillen: actually, kinda...its now owned by pia, who's cto is mark karpeles and who's chief privacy officer is the pirate party kiddie porn bcash guy, forgot his name 10:38 < stevenroose> dongcarl: don't know, I can't tell, really. I could remove it and run the unit tests :D and that doesn't tell us if it's used outside of rust-bitcoin 10:39 < BlueMatt> gwillen: there is some questionable evidence freenode read some folks' private messages, though that part is less clear 10:39 < BlueMatt> gwillen: in any case, best to be careful 10:39 < stevenroose> IMHO Option should not be Encodable to prevent people from making mistakes. I passed an option into encode twice in the last few weeks causing me to get parsing errors of various kinds 10:39 < stevenroose> BlueMatt: just don't do private on IRC and you're fine :) 10:40 < BlueMatt> gwillen: oh, and the handshake/purse bcash troll guy is involved as well 10:40 < BlueMatt> stevenroose: yea, hence the topic :p 10:41 < stevenroose> Oh yeah, I don't read topics, they're usually very long and they're not very noticable in WeeChat 11:54 < stevenroose> Anyone looked at this one? https://github.com/rust-bitcoin/rust-bitcoin/pull/203 11:54 < stevenroose> It's a minor change, but it enables getting the assembly strings for scripts without having to manually substring :) 15:08 < icota_> BlueMatt: i saw your fix for #289... can you clarify why are library clients supposed to handle PaymentReceived and other events? seems like lightning network business logic straight from the bolts so should be implemented in the lib, no? 15:34 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] 15:48 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #rust-bitcoin 15:58 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection] 16:01 < BlueMatt> icota_: its kinda because the bolt11 stuff is a separate library. it doesnt add much for us to track payment hash -> payment preimage mappings because all we'd be doing is exposing an interface directly to a hashmap (ie "add payment preimage", "get payment preimage") and then generating the same event anyway 16:01 < BlueMatt> because the user has to create their invoice manually via rust-lightning-invoice *anyway*, us tracking the preimages is not so useful 16:02 < BlueMatt> post-0.1 or maybe post-0.2 we may want to reconsider, or as we move on integrating into things, but for now, it doesnt take much effort on the client side 16:06 < icota_> BlueMatt: thanks for the explanation :) i agree that the event handling in rust-lightning-bitcoinrpc is quite minimal 16:07 < BlueMatt> I dont think rust-lightning-bitcoinrpc even handles storing them to disk yet :p 16:07 < BlueMatt> (but doesnt take much effort) 16:07 < icota_> are all secrets outside of the lib? 16:08 < icota_> i'm guessing yes since wallet and bolt are both outside 16:09 < icota_> *bolt11 16:12 < BlueMatt> not really? I mean lightning makes you derive keys in certain formats, but the lib doesnt store anything, so how secrets get stored is up to clients 16:12 < BlueMatt> you do need to store channelmonitors/channelmanagers in a safe way as they contain secrets, though 16:14 < icota_> gotcha 17:08 < BlueMatt> ariard: "an enum doesn't fit into Readable trait signature"? huh? 17:09 < BlueMatt> ariard: what am I missing? Why cant you impl Readable for an enum NetAddressDeserResult{NetAddress, UnknownByte}? 17:19 < ariard> BlueMatt: it's doable, just feel a bit gross to add an enum only for that, should we also expect an enum in NodeInfo deserialization or we consider we can't have unknown address from on-disk ? 17:20 < BlueMatt> could skip the enum and return a Result 17:20 < BlueMatt> oh, we should probably change NodeInfo to make the user provide the addresses each time? 17:21 < BlueMatt> but, yea, if you cant create a NetAddress with bad type then reading it off disk means corrupted disk :p 17:21 < ariard> feel cumbersome to him 17:21 < BlueMatt> well, Result, DecodeError> 17:22 < ariard> Ok seems good to me 17:22 < BlueMatt> mostly I just hate that a user could create an Unknown NetAddress and store that 17:22 < BlueMatt> there's 20 other ways to prevent that, though, up to you 17:22 < ariard> Yes, that why I first I get into extending DecodeError 17:22 < BlueMatt> yea, but that just ended up reusing things all over the place 17:22 < BlueMatt> I guess could have added a new DecodeError type but thats awkward too cause its user-facing 17:23 < ariard> we already have UnknownRequiredFeature or UnknownVersion with one use case 17:23 < BlueMatt> UnknownVersion will have another with Router serialization :p 17:23 < ariard> doesn't feel awkward to be user-facing, I mean unknown address could mean you shoud upgrade your stuff? 17:25 < BlueMatt> yea, I guess, I mean my thinking was that we're handling it internally anyway, so we'd never actually expose that to the user (or peer_handler) 17:26 < BlueMatt> so we'd end up with a enum entry that users can never see 17:27 < ariard> Right, so will go with Result, DecodeError> 17:29 < BlueMatt> I guess, yea 17:55 < ariard> BlueMatt: so pushed, just for NodeInfo corrupted disk I return an InvalidValue, should I switch it for a panic? 17:55 < BlueMatt> nono, InvalidValue is right 17:57 < ariard> cool, staying there half an hour more if you want to do another pass 18:07 < BlueMatt> ariard: gave it a once-over, didnt get all the way through but I think I got the meat of it 18:07 < BlueMatt> left a few comments 18:10 < BlueMatt> bbl 18:10 < ariard> BlueMatt: seen, okay rebase was maybe a bit quick :p 18:11 < BlueMatt> heh, nah, just random nits and the usual review shit 18:11 * BlueMatt -> bbl 19:40 < dongcarl> I have identified and fixed the panic that was stopping us from integrating rust-bitcoin with bitcoin_hashes: https://github.com/rust-bitcoin/bitcoin_hashes/pull/29 19:41 < dongcarl> I would like to get bitcoin_hashes integrated into rust-bitcoin ASAP, so please review the fix above and the actual integration PR here: https://github.com/rust-bitcoin/rust-bitcoin/pull/215 --- Log closed Wed Jan 23 00:00:28 2019