--- Log opened Thu Aug 08 00:00:34 2019 01:11 -!- cypherpunk2140 [~cypherpun@2a02:2450:1027:60d:e523:64ae:ef45:8d6e] has joined #rust-bitcoin 02:02 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 245 seconds] 03:02 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:71ed:f390:47b2:7cf9] has joined #rust-bitcoin 03:09 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:71ed:f390:47b2:7cf9] has quit [Ping timeout: 252 seconds] 03:33 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:71ed:f390:47b2:7cf9] has joined #rust-bitcoin 03:35 -!- cypherpunk2140 [~cypherpun@2a02:2450:1027:60d:e523:64ae:ef45:8d6e] has quit [Quit: cypherpunk2140] 03:36 -!- cypherpunk2140 [~cypherpun@gateway/tor-sasl/cypherpunk2140] has joined #rust-bitcoin 03:38 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #rust-bitcoin 03:39 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:71ed:f390:47b2:7cf9] has quit [Ping timeout: 264 seconds] 04:05 -!- stanimal [~stanimal@195.159.29.126] has quit [Quit: Ping timeout (120 seconds)] 04:05 -!- simian_za [~simian_za@195.159.29.126] has quit [Quit: Ping timeout (120 seconds)] 04:05 -!- CjS77 [~caylemeis@195.159.29.126] has quit [Quit: Ping timeout (120 seconds)] 04:05 -!- Blackwolfsa [~Blackwolf@195.159.29.126] has quit [Quit: Ping timeout (120 seconds)] 04:05 -!- neonknight64 [~neonknigh@195.159.29.126] has quit [Quit: Ping timeout (120 seconds)] 04:09 -!- Blackwolfsa [~Blackwolf@195.159.29.126] has joined #rust-bitcoin 04:11 -!- simian_za [~simian_za@195.159.29.126] has joined #rust-bitcoin 04:13 -!- stanimal [~stanimal@195.159.29.126] has joined #rust-bitcoin 04:13 -!- neonknight64 [~neonknigh@195.159.29.126] has joined #rust-bitcoin 04:16 -!- CjS77 [~caylemeis@195.159.29.126] has joined #rust-bitcoin 05:31 -!- mauz555 [~mauz555@i19-lef01-t2-89-85-247-26.ft.lns.abo.bbox.fr] has joined #rust-bitcoin 06:05 -!- mauz555 [~mauz555@i19-lef01-t2-89-85-247-26.ft.lns.abo.bbox.fr] has quit [] 07:52 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 260 seconds] 07:55 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-xylbruckdqjsoaki] has joined #rust-bitcoin 08:01 < elichai2> andytoshi: It looks like our only options are 1. alignment 8. 2. bump rustc version 08:03 < andytoshi> elichai2: ah, shitty 08:03 < andytoshi> alignment 8 it is then 08:03 < elichai2> andytoshi: can we somehow check for the alignment upstream and call the callback if it's not enough? 08:03 < andytoshi> i guess, by using a `*mut [u64]` ? 08:03 < elichai2> yeah 08:04 < andytoshi> no, we can't, see tim's comments in #secp256k1 ... in C you can't check if a pointer is aligned 08:04 < andytoshi> and in C89 you can do basically nothing wrt alignment 08:04 < andytoshi> in rust 1.22 we have far more power than in C89 ... so if that's not enough then we're stuck :/ 08:05 < elichai2> what about https://github.com/bitcoin-core/secp256k1/blob/master//src/util.h#L87 08:06 < elichai2> altough that's not a good solution, because if the max alignment is bigger than 8 this might fail even though we might not use such big alignments 08:07 < elichai2> should we use u64 or the bigger of usize/u64? (in case pointer width is somehow bigger than 64bit or has bigger alignment?) 08:08 < elichai2> in the ffi.rs we used usize 08:11 < andytoshi> i think i was confused about "the alignment of a pointer" vs "the alignment of a pointer type" 08:11 < andytoshi> and that we should've used u64 there 08:12 < andytoshi> like, an &T has the same alignment as usize ... which means that if you have an appropriately aligned pointer to point to usize, you can also point to a &T 08:12 < andytoshi> it does _not_ mean that such a pointer can point to a T 08:13 < andytoshi> so actually, i think we should change the ffi.rs code to use u64 rather than usize 08:13 < andytoshi> and we should write `type AlignType = u64;` to emphasize this 08:14 < elichai2> I'm not sure that I understand what you mean by `it does _not_ mean that such a pointer can point to a T` 08:14 < elichai2> but I agree that we should use the highest alignment possible to at least try match what malloc does. my only fear is for future u128 pointers 08:18 < andytoshi> i'm not sure how "it does _not_ mean that such a pointer can point to a T" could be more straightforward :) 08:18 < elichai2> if I have an aligned pointer shouldn't be able to point to *anything*? 08:19 < andytoshi> no, if it's aligned correctly for usize, it can point to usize 08:19 < andytoshi> or &T for any concrete T 08:19 < andytoshi> not necessarily anything else 08:19 < andytoshi> good point about using the max of {usize, u64}. is there a way we can do that? 08:20 < elichai2> hmm with cfg pointer-depth 08:20 < elichai2> I think 08:20 < andytoshi> u64 can only point to 16 EB which is plausible for giant clusters 08:20 < elichai2> EB? 08:20 < andytoshi> exabytes 08:21 < elichai2> oh 08:21 < andytoshi> thousands of petabytes, millions of terabytes 08:21 < andytoshi> oh, neat, good call about cfg pointer-depth 08:21 < elichai2> we could do `#[cfg(any(target_pointer_width="32", target_pointer_width="16", target_pointer_width="8"))]` for u64, and the rest usize 08:22 < andytoshi> +1 08:22 < elichai2> i'm not sure what architecture pointer width does rust officially support right now 08:23 < andytoshi> i think only 32 and 64 bits, but i'm sure everything is intended to work with 128 08:23 < andytoshi> and 8/16 can be made to work with hacks and avoiding some libs 08:25 < wumpus> i don't think rust supports anything with 128 bit pointers, might as well just fail on that for now 08:26 < andytoshi> i'm fine with that too 08:26 < andytoshi> though fwiw i think elichai2's suggestion will support it easily 08:26 < wumpus> (there are these RV128/Cheri experiments, but it'll be a long time before that has rust support, heck, LLVM only recently got 32/64 bit RISC-V support) 08:32 < elichai2> well llvm already provides u128 08:32 < elichai2> I think it's a matter of time until Intel/ARM puts out a 128bit system 08:32 < wumpus> secp256k1 never stores 128 bit integers though 08:33 < wumpus> (it uses it for multiplication in one place, but only on the stack) 08:34 < wumpus> a matter of time, yes maybe 200 year 08:35 < wumpus> :) 08:35 < andytoshi> i will approve a PR that supports 128-bit pointers. i will also approve a PR that fails on them 08:35 < andytoshi> s/fails/refuses to compile/ 08:36 < wumpus> neither can be tested :) 08:37 < andytoshi> hehe, good point 08:49 < elichai2> wumpus: andytoshi feel free to comment/test :) https://github.com/rust-bitcoin/rust-secp256k1/pull/141 08:52 < wumpus> looks good to me, wish rust had compile-time assertions 08:55 < elichai2> on newer versions there are tricks to do this when size_of/align_of are const fn's 08:57 < wumpus> there's the std::transmute trick to check if types have the same size, but I don't know if any others 08:58 < elichai2> wumpus: this is possible in rust 1.24: https://play.rust-lang.org/?gist=945eb7ed7bef63a0bc30aa08d1d8b714 09:01 < elichai2> And I think since 1.31 you could even do this: https://play.rust-lang.org/?&gist=f88dedcd9779c94789f5d391bcdc7298 09:19 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:b523:9b26:7d33:44f5] has joined #rust-bitcoin 09:30 < wumpus> elichai2: interesting, good to know, thanks! 09:57 < elichai2> andytoshi: are you seeing this? https://travis-ci.org/rust-bitcoin/rust-secp256k1/jobs/569431514#L1174 09:57 < elichai2> I think I know what this is, but I don't get why now and why only in the emscripten target 10:00 < andytoshi> elichai2: oooo 10:00 < andytoshi> that is super weid 10:01 < andytoshi> weird 10:01 < elichai2> I always knew that there's a problem with empty vecs: https://play.rust-lang.org/?gist=0ef27e34f1c46b7fd444d2241bd285d2 10:02 < elichai2> but empty slice? this is just weird 10:02 < andytoshi> oh this is very interesting 10:03 < andytoshi> in C, malloc(0) is allowed to return NULL even when it "succeeds" 10:03 < andytoshi> C doesn't have zero sized types 10:03 < andytoshi> in rust, i don't think there's any reason that `&zero_sized_obj as *const _` needs to be non-null 10:04 < andytoshi> i think this is actually a general bug in the bindings. and that maybe we need to explicitly check for empty slices in the rust API 10:04 < andytoshi> and not give those to ffi 10:04 < elichai2> yeah. and passign memcpy/memset (NULL,0) is implementation defined 10:05 < elichai2> When I worked at enigma I implemented a `as_c_ptr()` trait that promises to always give a valid pointer, even for zero sized types: https://github.com/enigmampc/enigma-core/blob/develop/enigma-types/src/traits.rs 10:05 < elichai2> but that's not a good solution for us. we should just check them as you said 10:06 < elichai2> I just don't get why this is only happening now 10:14 < real_or_random> I feel half of all our problems in rust-secp are the rust ecosystem and the other half is ugly C shit 10:14 < real_or_random> :/ 10:15 < elichai2> yeah... 10:16 < elichai2> at least I know that my implementaion of `secp256k1_default_illegal_callback_fn` works :) 10:17 < elichai2> (first time I've seen a callback triggered heh) 10:20 < dpc> Is there somewhere where I can read the context of this conversation? It's interesting, but I'm missing the root cause. :) 10:21 < elichai2> dpc: https://github.com/rust-bitcoin/rust-secp256k1/issues/138 10:22 < elichai2> Sorry I'm mixing a lot between github and IRC 10:22 < andytoshi> it's really amazing to me how shitty C is 10:23 < andytoshi> there is no excuse, even in 1972, for the lack of alignment accessors 10:23 < andytoshi> well, ok, i guess in 1972 there wasn't a notion of UB 10:24 < andytoshi> but in 1989 there was 10:24 < andytoshi> and it should've been clear to everyone involved that if there is a wide class of UB related to alignment, there should be some way to tell if a pointer is aligned 10:25 < elichai2> Or at the very least make them less UB and more crashable/testable 10:26 < dpc> I get confused here. What's the problem with checking if a pointer is aligned? cast to int and check against `sizeof (x)` ? 10:28 < dpc> (or a `sizeof(*x)` if `x` is a pointer) 10:32 < elichai2> dpc: that's implementation defined 10:32 < elichai2> and afaik even the fact that you have an unaligned pointer is UB 10:32 < dpc> AFAIR, the general ABI requirement was that types have to be aligned to their own size. Any other requirements (like SIMD) are something else. 10:36 < dpc> Can types require alignment bigger than the natural alignemnt (their size)? Really? 10:36 < dpc> I love how in C I'm never actually sure about anything. :D 10:42 < elichai2> yeah. even in rust they can 10:43 < elichai2> dpc: https://play.rust-lang.org/?gist=615a6726e5c6d55ddcb674387a816ae6 10:43 < elichai2> but not in 1.22 10:43 < dpc> I just ctrl+f through a spec of C11 and no word about natural alignment. :/ 10:44 < dpc> Well, this is for a type with a custom directive. I was thinking only about primitive types. 10:45 < andytoshi> having an unaligned pointer is fine, only dereferencing is UB 10:45 < elichai2> andytoshi: even in C? ha 10:45 < andytoshi> and you cannot check by casting to an integer, the result of that is implementation defined and not related to alignment at all 10:46 < andytoshi> the C standard also has no notion of an ABI 10:48 < dpc> In https://github.com/rust-bitcoin/rust-secp256k1/issues/138, what actually have to be the alignment of that preallocated buffer? 10:50 < andytoshi> according to upstream, the maximum alignment for any object 10:50 < andytoshi> which is literally impossible to determine in C or Rust 10:50 < dpc> Any object? Not any primitive type? As elichai2 just demonstrated, any object can have arbitrarily big alignment, no? 10:51 < andytoshi> but on IRC sipa suggseted we weaken that in upstream to "max alignment of all integer types and pointers" 10:51 < andytoshi> which is merely very irritating to determine 10:51 < andytoshi> dpc not in C 10:54 < elichai2> dpc: yeah in C malloc returns a magical pointer that is aligned to everything haha 10:56 < dpc> I think now I understand the uter crappiness of this problem. :D 10:58 < dpc> But in libsecp , don't you know exactly what structs will be used? 10:59 < dpc> If you did you could just write a constant and/or function that calculates the exact alignment? 11:01 < elichai2> dpc: this means that every time we update upstream we need to remember to check if anything context related has changed and if so think what and how should we change too 11:01 < elichai2> if we could've had runtime repr's we could've made a pointer which is aligned to the size of the prealloc lool 11:02 < elichai2> anyway, we should probably fix this before: https://github.com/rust-bitcoin/rust-secp256k1/issues/142 (so feel free to comment what you think/feel) 11:06 < dpc> Could upstream just have a function that returns the value, so this can be asserted on initialization? 11:06 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:b523:9b26:7d33:44f5] has quit [Remote host closed the connection] 11:07 < dpc> With a bit of `build.rs` magic it could be probably checked in compile time too. 11:07 < real_or_random> elichai2: "and afaik even the fact that you have an unaligned pointer is UB" no it's just UB when you deference it 11:07 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:b523:9b26:7d33:44f5] has joined #rust-bitcoin 11:11 < real_or_random> dpc: it suffices to look at primitive types 11:11 < real_or_random> when determining the maximum alignment, a struct/union/array can't arbitrary add to that 11:12 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:b523:9b26:7d33:44f5] has quit [Ping timeout: 264 seconds] 11:13 < real_or_random> in practice it probably suffices to look at the largest integer type, which is intmax_t even in C99 11:14 < real_or_random> (or even with stdint.h) 11:15 < real_or_random> and if there's an intptr_t, then this is large enough to hold a pointer, and it's an integer type, so intmax_t is larger or equal 11:16 < real_or_random> so in the end the maximum alignment of intmax_t and intmax_t is a good value 11:18 < dpc> Agreed. Through I would probably add a sanity test or something. 11:18 -!- reallll [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 11:18 < real_or_random> (all of this assumes that we don't use floats, which is true in secp. apparently for floats it's not even guaranteed that float_t and double_t from math.h are not larger than long double -.- not to mention complex numbers ^^) 11:21 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 244 seconds] 11:26 -!- reallll is now known as belcher 11:28 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:b523:9b26:7d33:44f5] has joined #rust-bitcoin 11:33 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:b523:9b26:7d33:44f5] has quit [Ping timeout: 250 seconds] 11:38 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:b523:9b26:7d33:44f5] has joined #rust-bitcoin 11:43 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:b523:9b26:7d33:44f5] has quit [Ping timeout: 264 seconds] 11:58 < elichai2> real_or_random: I assumed it's like out of bound pointer arithmetic but I guess I was wrong 11:59 < real_or_random> yes, that difference is surprising at first glance 12:01 < real_or_random> I'm not even sure whether having an oob pointer is UB but computing one via pointer arithmetic is -- and the reason makes sense: the pointer could overflow, which will trap on certain architectures 12:02 < elichai2> still weird to me lol, I would've assumed pointer arithmetics have the same properties as integer arithmetics 12:02 < real_or_random> well signed overflow is UB too 12:03 < real_or_random> but you're right, you could except that pointers internally behave like unsigned integers... no idea 12:05 < elichai2> half of the UB feel to me a bit like a UX dev saying "Well the user didn't use my app correctly" when his app crashes 12:05 < elichai2> like that's *not* how we should design software 12:07 < real_or_random> well now you know why the web is so slow :P 12:14 < real_or_random> elichai2: oh indeed weird that rust outputs only 8 for u128. maybe that's just a godbolt thing? who knows where they run gcc and rust? 12:16 < elichai2> no even on my machine rust output 8 alignment for u128, I'll try to research it, because I would've thought that clang and rust uses the same uint128 that llvm exports 12:17 < real_or_random> ok 12:22 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:b523:9b26:7d33:44f5] has joined #rust-bitcoin 12:25 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:b523:9b26:7d33:44f5] has quit [Read error: Connection reset by peer] 12:25 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:b523:9b26:7d33:44f5] has joined #rust-bitcoin 12:49 < elichai2> real_or_random: https://github.com/rust-lang/rust/issues/54341 12:49 < elichai2> :( 12:56 < wumpus> real_or_random:pleease don't use floats in secp256k1 :-) 13:15 < andytoshi> elichai2: pointers are not remotely like integers 13:15 < andytoshi> you can't do any arithmetic on them except subtracting two pointers which point into the same object, and the result of that is not a pointer 13:24 < dpc> It might be implemented as two u64s 13:59 < elichai2> I'm a little bit bothered by the `mem::uninitialized` usage in the lib. theoretically it should be fine with arrays of u8/u32 etc. but the second you have bool or something different in there it can easily become UB 13:59 < andytoshi> you can remove it 13:59 < andytoshi> just replace it wit 0s 14:00 < andytoshi> you're right, we should not be using that function 14:09 < dpc> andytoshi: Regarding floats in the Bitcoin Core API - nothing has to ever get broken, only slowly phased out. The fact there are floats all over bitcoincore api *forces* all software to implement float conversions for dealing with Bitcoin Core, which seems silly. There could be some architectures that do not even have hardware floating point (RISCV), that will have to pull in some softfp emulation just to convert something 14:09 < dpc> that both bitcoin core and the software using it should and probably is storing as an integer (satoshis). 14:10 < andytoshi> such specialzed users would probably have their own json parser 14:10 < andytoshi> which they could modify to read decimals as satoshis 14:12 < dpc> :S 14:15 < dpc> UTXO balance is a integer (in sats), but because Satoshi for some stupid reason decided to return them as floats, so all software forever should deal with converting these back and forth and implement own json parsers etc. 14:15 < wumpus> don't use floating point for monetary amounts, never 14:16 < andytoshi> wumpus: the issue is that you literally have to to use off-the-shelf json parsers with bitcoin core 14:16 < andytoshi> and in rust, if we want to use serde 14:16 < wumpus> bitcoin core doesn't do so either 14:16 < andytoshi> yes, bitcoin core has its own json library 14:16 < wumpus> I had a PR to send amounts as strings instead, once, no idea what happened to it 14:17 < dpc> Noone stores this numerics in floats, except they are being sent as such in JSON APIs. 14:17 < wumpus> no, they're sent as *numbers* 14:17 < wumpus> how you parse them is up to you 14:17 < andytoshi> for a while we maintained our own json library as well, strason, and it was too much of a maintenance burden 14:18 < andytoshi> yes, sure, it's "up to us" whether we want to write and maintain an entire json parser 14:18 < andytoshi> we've chosen not to 14:18 < wumpus> with serde you can't implement your own parsing? 14:18 < wumpus> well, that's fine 14:18 < andytoshi> you can implement your own parsing, but you can't parse some numbers as 8-digit decimals and others as normal numbers 14:18 < dpc> I'm not talking specifically about rust-bitcoin. I'm talking generally. UTXO `value` is an integer. 14:19 < dpc> Bitcoin as an unit is just some arbitrary higher-level concept. 14:19 < andytoshi> anyway this has been beaten to death 14:19 < wumpus> there's two functions you need to change in bitcoin core to send/receive amounts in another format: `AmountFromValue` and `ValueFromAmount` 14:20 < wumpus> that could be integers, strings, whatever, good luck trying to get anything accepted upstream though, even an option to change it, it's not like no one tried 14:20 < wumpus> yes imagine how sick I am of it 14:22 < dpc> :D Well, I'm not sick, but it's just silly. Some decisions that Satoshi made are set in stop, but for API, one could just add a switch or new set of apis, but phase out old APIs. 14:23 < andytoshi> dpc: core is not a single person 14:23 < wumpus> FWIW it already accepts input as decimal string "0.00000000", just no way to output it, there were PRs for this https://github.com/bitcoin/bitcoin/pull/9882 https://github.com/bitcoin/bitcoin/pull/9855 https://github.com/bitcoin/bitcoin/pull/3759 there's just no one really interested and it results in eternal bikeshedding 14:24 < wumpus> these kind of things really such in bitcoin tbh 14:26 < dpc> Thanks! :) 14:27 < wumpus> andytoshi: "you can implement your own parsing, but you can't parse some numbers as 8-digit decimals and others as normal numbers" there's no annotation or such to change the parser per field? that's somewhat disappointing 14:28 < andytoshi> the rust type system is used for that 14:29 < andytoshi> but the type system interacts with the parser by asking the parser to parse one of a fixed list of primitive types 14:29 < wumpus> could have a custom type for amounts then 14:29 < wumpus> oh 14:29 < andytoshi> yeah :/ 14:30 < andytoshi> this is a limitation of serde, but it's only that rarely causes trouble ... except with arbitrary precision numbers 14:31 < andytoshi> (serde_json actually has a flag that will parse all numbers as strings so you can deal with this, but if rust-bitcoin sets the flag, our users will be unable to get the normal behavior, which has perf consequences) 14:31 < andytoshi> (this is a limitation of cargo) 14:33 < wumpus> in any case, feel free to make a PR to add an option to output amounts another way (especially as strings *should* be uncontroversial as it's already accepted as input, and impossible to confuse with the current type, unlike decimal numbers), maybe it will get through this time 14:34 < wumpus> maybe "rust really cannot do this" changes the equation 14:39 < wumpus> or maybe the people that blocked it in 2014 are gone now 14:52 < andytoshi> the latter may be true 14:52 < andytoshi> though i really would prefer to fix it on the rust side .. it's a bit frustrating, we had hacks that worked with serde 0.6 but none that work with 1.0 14:53 < andytoshi> actually, i shuold take a look at serde_json's arbitrary_precision hack and see if i can hook into that even when the arbitrary_precision flag is on 14:53 < andytoshi> off 14:54 < wumpus> it could be a global option or something in the RPC request itself (e.g. a HTTP header, a different path, etc) that changes how amounts are sent 15:42 -!- cypherpu_ [~cypherpun@gateway/tor-sasl/cypherpunk2140] has joined #rust-bitcoin 15:46 -!- cypherpunk2140 [~cypherpun@gateway/tor-sasl/cypherpunk2140] has quit [Ping timeout: 260 seconds] 15:55 -!- cypherpunk2140 [~cypherpun@gateway/tor-sasl/cypherpunk2140] has joined #rust-bitcoin 15:59 -!- cypherpu_ [~cypherpun@gateway/tor-sasl/cypherpunk2140] has quit [Ping timeout: 260 seconds] 16:03 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 244 seconds] 16:13 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:b523:9b26:7d33:44f5] has quit [Remote host closed the connection] 16:14 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:b523:9b26:7d33:44f5] has joined #rust-bitcoin 16:16 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #rust-bitcoin 16:16 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host] 16:16 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #rust-bitcoin 16:18 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:b523:9b26:7d33:44f5] has quit [Ping timeout: 250 seconds] 16:46 -!- cypherpunk2140 [~cypherpun@gateway/tor-sasl/cypherpunk2140] has quit [Quit: cypherpunk2140] 17:00 -!- cypherpunk2140 [~cypherpun@gateway/tor-sasl/cypherpunk2140] has joined #rust-bitcoin 17:02 -!- cypherpunk2140 [~cypherpun@gateway/tor-sasl/cypherpunk2140] has quit [Client Quit] 17:03 -!- cypherpunk2140 [~cypherpun@gateway/tor-sasl/cypherpunk2140] has joined #rust-bitcoin 17:06 -!- cypherpunk2140 [~cypherpun@gateway/tor-sasl/cypherpunk2140] has quit [Client Quit] 17:07 -!- cypherpunk2140 [~cypherpun@gateway/tor-sasl/cypherpunk2140] has joined #rust-bitcoin 17:29 -!- cypherpunk2140 [~cypherpun@gateway/tor-sasl/cypherpunk2140] has quit [Quit: ZZZzzz…] 17:47 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 17:54 -!- cypherpunk2140 [~cypherpun@gateway/tor-sasl/cypherpunk2140] has joined #rust-bitcoin 17:56 -!- cypherpunk2140 [~cypherpun@gateway/tor-sasl/cypherpunk2140] has quit [Client Quit] 18:11 -!- TamasBlummer1 [~Thunderbi@p200300DD67126430586CA50BF0656CBC.dip0.t-ipconnect.de] has joined #rust-bitcoin 18:13 -!- TamasBlummer [~Thunderbi@p200300DD6712648390C9D658F0F85F27.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 18:13 -!- TamasBlummer1 is now known as TamasBlummer 19:06 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-xylbruckdqjsoaki] has quit [Quit: Connection closed for inactivity] 20:18 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-ijsgycygcvfvtbdh] has joined #rust-bitcoin 22:58 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-ijsgycygcvfvtbdh] has quit [Quit: Connection closed for inactivity] --- Log closed Fri Aug 09 00:00:35 2019