--- Log opened Tue Apr 09 00:00:40 2019 00:16 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 245 seconds] 00:19 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #rust-bitcoin 00:58 -!- somethinglittle [~nothingmu@68.183.99.173] has quit [Ping timeout: 245 seconds] 00:58 -!- slimcognito [~slimcogni@2604:a880:400:d1::b92:7001] has joined #rust-bitcoin 01:33 -!- TamasBlummer1 [~Thunderbi@p200300DD670F9D25075A8AC994230C84.dip0.t-ipconnect.de] has joined #rust-bitcoin 01:35 -!- TamasBlummer [~Thunderbi@p200300DD670F9D096506B7C4D522E0CB.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 01:35 -!- TamasBlummer1 is now known as TamasBlummer 01:48 -!- Ed0 [~edouard@2001:41d0:401:3100::4897] has joined #rust-bitcoin 03:01 -!- belcher [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 03:28 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 03:28 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 05:02 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has quit [Read error: Connection reset by peer] 05:02 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has joined #rust-bitcoin 05:02 -!- simian_za [~simian_za@195.159.29.126] has quit [Quit: Ping timeout (120 seconds)] 05:02 -!- simian_za [~simian_za@195.159.29.126] has joined #rust-bitcoin 06:04 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 06:36 < stevenroose> nickler, andytoshi, sgeisler: about Amount having i64 or u64, any more opinions? 06:37 < stevenroose> My arguments for i64 for where mostly: (1) the prior rust-bitcoin-amount type had it, (2) it's more expressive, (3) we don't need the extra 1 bit of range, (4) Core's CAmount is signed as well and I've seen some uses of the negative values there. 06:38 < stevenroose> But I know most implementations of values currently simply use u64 06:45 < sgeisler> `i64` also has the benefit of allowing "substract first, check later" patterns in addition to "compare first, substract later" when substracting amounts. 06:48 < sgeisler> but maybe that's a pattern we want to discourage anyway? 06:57 < sgeisler> actually, with `checked_sub` that shouldn't be necessary at all, so `u64` sounds kinda appealing in that case 07:00 -!- willpiers [~willpiers@38.75.231.30] has quit [Remote host closed the connection] 07:08 < stevenroose> with checked_sub, you still can't "substract first, check later". Core actually has that pattern a few times. They first to MoneyRange on all of them, making sure there won't be any over/underflow when only adding/subtracting a reasonable number of elements 07:08 < stevenroose> And then do moneyrange on the final sum 07:09 < stevenroose> I just added checked_sub|add|mul|div|neg|rem, ... 07:09 < stevenroose> So we can do that already 07:09 < stevenroose> We could possibly have a method `positive_sub` that is like checked_sub but uses 0 as the lower limit so returns None when going negative. 07:13 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 07:16 < andytoshi> we need `i64` to deal with fees on incomplete transactiosn 07:21 -!- willpiers [~willpiers@38.75.231.30] has quit [Remote host closed the connection] 07:28 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 07:31 < stevenroose> andytoshi, sgeisler: opinions on arithmetics? I added checked_ methods for checked arithmetic (there are no traits for that), but I also still have the normal +, -, * and / operators that are unchecked. Jonas suggests removing them. 07:33 < andytoshi> yeah i'd just remove them 07:34 < andytoshi> or put a #[deprecated] warning on them 07:34 < andytoshi> i guess it's not proper to have "permanently deprecated" functionality but the point is to make the checked_ methods more discoverable 07:41 < stevenroose> There are situations where values are "prechecked", right? If a node gives you a transaction that got confirmed, and you want to know the sum of its outputs, you'd be doing checked_add(x).unwrap().. 07:42 < stevenroose> I'm not objecting entirely, I can remove them. Just saying it'd be a bit sad. I mean I'm quite sure I can find tons of places in current codebases where u64 amounts are simply added without using checked_add :D 07:44 < andytoshi> well, bitcoin had a very famous overflow bug due to doing this.. 07:44 < andytoshi> we could also implement wrapping_add() if people don't want to do unwrap() 07:45 < andytoshi> which is really obviously wrong in the case that any wrapping could actually occur 07:45 -!- willpiers [~willpiers@38.75.231.30] has quit [Remote host closed the connection] 07:45 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 07:46 < stevenroose> Yeah true that. Fair enough. I'll remove them and push later today (on a train with shitty internet and ZNC keeps dumping the history buffer in here on reconnection) and push. I'll also try to look into fuzzing. Never touched that before. If you have suggestions, le tme know. 07:50 -!- willpiers [~willpiers@38.75.231.30] has quit [Ping timeout: 255 seconds] 08:11 < nickler> "16:16 < andytoshi> we need `i64` to deal with fees on incomplete transactiosn" Not sure why, but you can use an i64 for that and not an amount. Imo an Amount type in rust-bitcoin should protect from mistakes involving negative numbers. 08:11 < nickler> Remember when Ethereum's designers thought you can't put negative values on the EVM stack? But actually using a trick you could and then send negative amounts which actually increased your balance. 08:12 < andytoshi> that was not an ethereum bug 08:12 < andytoshi> that was solidity developers 08:13 < nickler> it was the go-ethereum developers 08:13 < andytoshi> lol really? 08:13 < nickler> yeah, they implement the EVM 08:13 < andytoshi> actually, i am not surprised, they use a generic bignum library for their EVM implementation and then guard against invalid values in like 600 separate places 08:14 < andytoshi> (600 is an exaggeration ofc. but "over a dozen" is not.) 08:14 < nickler> negative amounts would be similar 08:15 < andytoshi> nickler: what would the type of the `value` field in `TxOut` be? 08:15 < andytoshi> `u64` as it is now, or `Amount`? 08:16 < andytoshi> my thinking here is, suppose you actually do have a transaction that fails to balance, and you subtract the input amounts from the output amounts, and get a would-be negative number 08:16 < andytoshi> currently you'll get a panic because these types are `u64`, unless you think about it 08:17 < andytoshi> think about this case in advance* 08:17 < nickler> it should be `Amount` 08:18 < nickler> so if you do `input amounts - output amounts` you get an `Option` 08:18 < nickler> because Amounts should be `checked` by default 08:28 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has joined #rust-bitcoin 08:36 < andytoshi> cool 08:36 < andytoshi> yeah, ok, that sounds good to me 10:28 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-kimfsrxegcnscwfh] has joined #rust-bitcoin 10:57 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 11:01 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has joined #rust-bitcoin 11:28 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 11:48 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds] 12:05 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has joined #rust-bitcoin 13:38 < stevenroose> > so if you do `input amounts - output amounts` you get an `Option` 13:39 < stevenroose> More specifically, you'll get an `Option::None` and you'll have to do the reverse to find the difference :p 13:39 < stevenroose> So u64 it is? 14:08 < andytoshi> inside `Amount`? 14:08 < andytoshi> yep 14:08 < andytoshi> maybe we could add our own `.sub_i64` method or something 14:08 < andytoshi> to avoid the check-for-none-and-invert thing 14:08 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-kimfsrxegcnscwfh] has quit [Quit: Connection closed for inactivity] 14:09 < andytoshi> though we'd have to think about how that would handle the case that a number exceeds 2^63 14:43 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 14:54 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has joined #rust-bitcoin 15:20 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 252 seconds] 15:26 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #rust-bitcoin 15:53 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 16:44 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 18:33 -!- schmidty_ [~schmidty@104-7-216-111.lightspeed.austtx.sbcglobal.net] has joined #rust-bitcoin 18:37 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 268 seconds] 19:57 -!- willpiers [~willpiers@38.75.231.30] has quit [Remote host closed the connection] 20:12 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 20:30 -!- willpiers [~willpiers@38.75.231.30] has quit [Remote host closed the connection] 20:42 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 21:04 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 22:21 -!- willpiers [~willpiers@38.75.231.30] has quit [Remote host closed the connection] 22:47 -!- ccdle12 [~ccdle12@175.45.54.238] has joined #rust-bitcoin 22:58 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 22:59 -!- ccdle12_ [~ccdle12@175.45.54.238] has joined #rust-bitcoin 22:59 -!- ccdle12 [~ccdle12@175.45.54.238] has quit [Read error: Connection reset by peer] 23:03 -!- willpiers [~willpiers@38.75.231.30] has quit [Ping timeout: 246 seconds] --- Log closed Wed Apr 10 00:00:43 2019