--- Log opened Mon Mar 04 00:00:06 2019
01:26 -!- TamasBlummer [~Thunderbi@p200300DD6744836125C327E25BCC31D9.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
02:33 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #rust-bitcoin
02:40 < stevenroose> andytoshi: curious how you'd approach the API. I'm not very sure about what possibilities there are. Things like `prepare(&miniscript, &psbt::Input)` that fills all the witness/redeem script data. But a `finalize(&psbt::Input, unsigned: &Transaction)` doesn't really need miniscript.
02:56 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Remote host closed the connection]
02:56 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #rust-bitcoin
03:01 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 244 seconds]
03:25 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
03:44 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
03:51 < real_or_random> andytoshi BlueMatt: why is Secp256k1 Sync even though we expose randomize()?
04:02 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
04:03 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
04:07 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #rust-bitcoin
04:10 -!- TamasBlummer [~Thunderbi@p200300DD670F9D5125C327E25BCC31D9.dip0.t-ipconnect.de] has joined #rust-bitcoin
04:12 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 245 seconds]
04:41 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #rust-bitcoin
04:46 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 240 seconds]
06:14 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #rust-bitcoin
06:19 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 240 seconds]
06:34 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #rust-bitcoin
07:02 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-kjhlhgjsqypzidhf] has joined #rust-bitcoin
07:39 < BlueMatt> real_or_random: cause you still need a &mut ref for randomize
07:40 < BlueMatt> so it should be safe?
07:40 < real_or_random> oh
07:40 < real_or_random> yes, sorry, missed the obvious
07:40  * BlueMatt went and read the comment on impl Sync :p
07:47 < real_or_random> :P
08:17 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Remote host closed the connection]
08:17 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #rust-bitcoin
08:22 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 250 seconds]
08:25 < andytoshi> ariard: that would be amazing if you could write an ivy frontend
08:26 < andytoshi> though FYI i'm going to break the API a whole bunch this week as i start trying to use it in liquid (afaik this will be the first attempted production use of it)
08:26 < andytoshi> my understanding is that ivy is much more expressive than bitcoin script can be, though
08:26 < andytoshi> stevenroose: what do you mean "doesn't need miniscript"? how do you turn a bunch of signatures into a witness without miniscript?
08:28 < andytoshi> ariard: you are correct that Policy is not really human-friendly; but OTOH it is a simple language that directly expresses most of what Script can do, and nothing else. my guess is that if you try to create a more imperative-looking language it will wind up feeling super restrictive because of the need to map to bitcoin/miniscript semantics
08:31 < stevenroose> ah true
08:32 < stevenroose> for witness construction you don't even need the &Transaction
08:33 < andytoshi> heh, this is true
08:39 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #rust-bitcoin
08:40 -!- mikethetike_ [sid308076@gateway/web/irccloud.com/x-ingztfjotwrdnmnw] has quit []
08:41 -!- mikethetike_ [sid308076@gateway/web/irccloud.com/x-xhkjhhkgwsrbaocd] has joined #rust-bitcoin
08:41 -!- harding [~quassel@li1258-130.members.linode.com] has quit [Ping timeout: 245 seconds]
08:43 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Remote host closed the connection]
08:43 -!- harding [~quassel@li1258-130.members.linode.com] has joined #rust-bitcoin
08:43 -!- schmidty [~schmidty@104-7-216-111.lightspeed.austtx.sbcglobal.net] has joined #rust-bitcoin
08:43 -!- schmidty [~schmidty@104-7-216-111.lightspeed.austtx.sbcglobal.net] has quit [Changing host]
08:43 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #rust-bitcoin
08:44 -!- mikethetike_ is now known as mikethetike
09:52 < andytoshi> rust-bitcoin 0.17.1 https://github.com/rust-bitcoin/rust-bitcoin/pull/242
10:28 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Remote host closed the connection]
10:29 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #rust-bitcoin
10:34 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 246 seconds]
10:49 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #rust-bitcoin
11:05 < TamasBlummer> BlueMatt: sent you a PR for lightning to migrate to rust-bitcoin 0.17. This is a minimal invasive migration, just to get it compile and pass tests. I think that preferred use of 0.17 features could be incremental after this is merged.
11:06 < BlueMatt> nice! thanks, will try to take a look today
12:08 -!- kanzure [~kanzure@unaffiliated/kanzure] has quit [Ping timeout: 246 seconds]
12:09 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #rust-bitcoin
12:17 < andytoshi> dongcarl: what are your thoughts on merging https://github.com/rust-bitcoin/bitcoin_hashes/pull/36 ?
12:18 < dongcarl> andytoshi: I guess I didn't fully understand https://github.com/rust-bitcoin/bitcoin_hashes/pull/36/files#r262141549
12:19 < andytoshi> if some format wants to encode strings as bytes, this is needed
12:19 < andytoshi> because it will also deserialize strings as bytes
12:19 < andytoshi> cf https://github.com/serde-rs/serde/blob/master/serde/src/de/impls.rs#L328-L336 which does basically the same thing
12:20 < dongcarl> Ah okay
12:26 < stevenroose> andytoshi: let me know when you published 0.17.1 :)
12:27 < andytoshi> stevenroose: just did
12:27 < stevenroose> thanks
12:27 < andytoshi> and i pushed my current miniscript/psbt code, though it's not on crates yet
12:27 < andytoshi> need to test it with the liquid code, which i can't do til https://github.com/rust-bitcoin/bitcoin_hashes/pull/36 is in
12:29 < andytoshi> oh, and also https://github.com/ElementsProject/rust-elements/pull/14
12:29 < andytoshi> stevenroose: can you take a look at that ^
12:31 < stevenroose> andytoshi: ah damn it
12:32 < stevenroose> I wanted to PR the `serialize(&self) -> Vec<u8>` method for PublicKey. Totally forgot about it because of the weekend.
12:32 < andytoshi> we can put it in 0.17.2 if you want it
12:33 < stevenroose> Now the shortest way (in lines) to get the bytes is `hex::decode(pk.to_string()).unwrap()`, which is kinda stupid :D
12:33 < andytoshi> personally i'd avoid it, it's not a ton of extra code to branch on the compressedness and react to the two different arrays
12:33 < andytoshi> lol
12:34 < andytoshi> yeah definitely if you don't mind the allocation, `serialize` is way better than that
12:34 < stevenroose> well yeah, I can probably use the serialize method on the inner key, but yeah then I have to branch. Now there is only write_into in the rust-bitcoin type.
12:35 < andytoshi> yep
12:35 < andytoshi> frustrating that there's no way to make that ergonomic, cuz it's much more efficient
12:36 < stevenroose> Depends on what you're doing. I usually prefer to have all the options. If you want the Vec<u8> to throw it around, it's silly to go through extra hoops.
12:37 < stevenroose> I'll PR it, not high priority, though.
12:37 < andytoshi> kk cool
12:37 < stevenroose> I can do with the 3-line workaround :)
12:38 < stevenroose> looking at rust-elements tomorrow morning, going afk soon
12:40 < andytoshi> kk thanks!
12:42 < andytoshi> thanks dongcarl !!
12:42 < dongcarl> <3
12:43 < andytoshi> published
12:43 < dongcarl> I feel that someday we need to outline what we mean by `serialize`, we've been overloading it with too many definitions
12:43 < dongcarl> and `encode`
12:44 < andytoshi> Yeah, in retrospect we should have left `serialize` to only be serde-related
12:44 < andytoshi> and `encode` for ConsensusEncodable stuff
12:44 < andytoshi> but then, what do we call these "serialize to vector" functions? :)
12:44 < dongcarl> `to_vec`
12:44 < andytoshi> also, upstream libsecp uses _parse and _serialize naming
12:44 < andytoshi> and if we serialize to an array?
12:45 < dongcarl> to_arr ?
12:45 < dongcarl> Idk
12:45 < andytoshi> yeah, that sounds fine
12:45 < dongcarl> Just something that's consistent
12:45 < andytoshi> wish we'd done that a while ago..
12:45 < andytoshi> maybe in a few months we can afford to do an API overhaul
12:45 < dongcarl> Next big release I guess :-)
12:45 < andytoshi> or maybe we should do it alongside the bitcoin_constants overhaul
12:46 < andytoshi> unsure whether we should annoy users all in one shot
12:46 < andytoshi> or over multiple versions :0
12:46 < andytoshi> :)
13:19 < stevenroose> andytoshi: dongcarl: prefer me to rename those methods with `to_bytes()`? I don't have strong opinions on the naming. Just wanted to be conform with rust-secp.
13:19 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 244 seconds]
13:20 < stevenroose> Ok so hal now has PSBT support in master :) Pretty happy about it. Talking with the owner of the long-unmaintained `hal` package. He's willing to give it up so that we can have `cargo install hal`. Meanwhile looking how to package to Arch's AUR.
13:21 < andytoshi> if `to_bytes()` is correct naming for something that returns an owned byte array, i'm fine with that
13:22 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #rust-bitcoin
13:24 < stevenroose> andytoshi: yeah AFAI'm aware is `into_` for something taking `self` returning an owned object, `to_` for taking `&self` and returning owned object and `as_` for taking `&self` and returning reference
13:25 < andytoshi> yeah, that sounds right
13:36 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Quit: quit]
13:38 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-kjhlhgjsqypzidhf] has quit [Quit: Connection closed for inactivity]
13:49 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #rust-bitcoin
14:09 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Quit: quit]
14:11 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #rust-bitcoin
14:11 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
16:56 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
18:52 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 255 seconds]
18:57 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #rust-bitcoin
18:59 < ariard> andytoshI: on ivy, once miniscript API stabilize and when I'm done with some bolt5 stuff, will allocate time to clean/rewrite my proto frontend
19:04 < ariard> the ivy version I've seen directly maps to bitcoin script, so you don't get more expressivity but imo benefice is in being able to reason more easily about contract
19:05 < ariard> particularly for non-programmers thanks to the clause-style of expressing locks
--- Log closed Tue Mar 05 00:00:07 2019