--- Log opened Thu Apr 30 00:00:08 2020
00:11 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:5d17:dfd5:86c9:227] has joined #rust-bitcoin
01:56 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-odacgarsbbtcwjvf] has quit [Quit: killed]
01:56 -!- dpc [dpcmatrixo@gateway/shell/matrix.org/x-yvbbyccotzemsbcj] has quit [Quit: killed]
01:57 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 260 seconds]
02:03 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #rust-bitcoin
02:03 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host]
02:03 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #rust-bitcoin
02:10 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-inrfpbneyedsmhht] has joined #rust-bitcoin
02:36 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
02:36 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
02:36 -!- dpc [dpcmatrixo@gateway/shell/matrix.org/x-oiwtqckejfnaxglc] has joined #rust-bitcoin
03:27 -!- Jalon6Luettgen [~Jalon6Lue@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin
03:42 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin
03:45 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
03:56 -!- Jalon6Luettgen [~Jalon6Lue@static.57.1.216.95.clients.your-server.de] has quit [Remote host closed the connection]
04:13 -!- Kaya15Dach [~Kaya15Dac@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin
04:14 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
04:14 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin
04:18 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
04:19 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
04:20 -!- stanimal [~stanimal@195.159.29.126] has quit [Quit: Ping timeout (120 seconds)]
04:21 -!- stanimal [~stanimal@195.159.29.126] has joined #rust-bitcoin
05:13 -!- Kaya15Dach [~Kaya15Dac@static.57.1.216.95.clients.your-server.de] has quit [Remote host closed the connection]
05:32 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
05:34 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
08:08 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds]
08:10 -!- jonatack [~jon@213.152.162.89] has joined #rust-bitcoin
08:10 -!- jonatack [~jon@213.152.162.89] has quit [Client Quit]
08:11 -!- jonatack [~jon@213.152.162.89] has joined #rust-bitcoin
09:35 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]
10:01 -!- prusnak [sid403625@gateway/web/irccloud.com/x-huaafpzwimkrhpiy] has joined #rust-bitcoin
11:02 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
11:02 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
11:59 < BlueMatt> whats the ongoing plan re: rust-jsonrpc/rust-bitcoincore-rpc? mostly andytoshi. I have stuff that uses async/await and latest-hyper for rpc calls that I'd like to expose optionally in rust-lightning and would ideally like to use the likely-better-maintained stuff in rust-bitcoin, but right now its all pretty ancient hyper etc :/
11:59 < BlueMatt> also stevenroose
13:29 < stevenroose> yeah I have a PR on rust-jsonrpc that makes it transportagnostic
13:30 < stevenroose> but it got blocked somehow because it uses the http crate for http Request and Response messages but that crate seemed to have quite a high number of deps as well and would also somehow tie it to HTTP (even though IIRC JSON-RPC spec is only specified for HTTP), but f.e. c-lightning uses jsoonrpc over unix sockets
13:30 < stevenroose> as far as I'm concerned, I would be ok with doing some work to finish/fix issues with the abstraction
13:31 < stevenroose> and then we can have a rust-jsonrpc-hyper0.10 crate and a rust-jsonrpc-hyper crate that uses latest hyper fwiw
13:31 < stevenroose> not sure how sync and async would be unifiable in a single interface, though
13:32 < stevenroose> perhaps that the actual interface could happen on the rust-jsonrpc-<client impl> level
13:32 < stevenroose> BlueMatt: how does hyper async work when it comes to interface? I suppose they still support sync usage, no?
13:33 < stevenroose> I had the same struggle with my experimental bitcoin-p2p crate where I eventually just ended up using sync and thinking that anyone that wanted async could wrap something around it. it would still use its own 2 threads but well
13:34 < BlueMatt> hum, right. yea, i mean merging sync and async is, like, not really a practical thing, sadly, at least in most interfaces
13:35 < BlueMatt> i mean in my stuff I'm just using async and not worrying about it
13:35 < BlueMatt> I'm not sure how hyper handles things...the sync interfaces is probably some crazed "spawn tokio instance, run request to completion as async, close tokio instance, return value"
13:53 -!- Netsplit *.net <-> *.split quits: raj_, kanzure, ariard
13:53 -!- Netsplit over, joins: ariard
13:53 -!- Netsplit over, joins: kanzure
13:54 -!- raj_149 [~quassel@ec2-18-217-191-36.us-east-2.compute.amazonaws.com] has joined #rust-bitcoin
13:59 -!- jonatack [~jon@213.152.162.89] has quit [Ping timeout: 260 seconds]
14:01 -!- jonatack [~jon@37.165.84.239] has joined #rust-bitcoin
15:41 < ariard> BlueMatt: what exactly deriving witnessScript by an external signer mitigate?
15:42 < ariard> they're committed in sigs so you can still swap them like you want after signature
15:42 < ariard> witness finalization doesn't have to be on the signer side
15:45 < ariard> oh no, they are commited in fact part of bip 143
15:47 < ariard> but still if can feed you with invalid script, I obtain invalid signatures, what an attacker can do with that ?
15:50 < ariard> real question is what advantage of doing keys derivation and script construction on the signer side?
16:14 < BlueMatt> ariard: hmmmm
16:14 < BlueMatt> ariard: I think, overall, we should prefer to *always* reduce what we pass to the signer and make them re-derive it
16:14 < BlueMatt> "<ariard> they're committed in sigs so you can still swap them like you want after signature" <-- I dont get this - you have to assume everything except the signer is a part of the counterparty
16:15 < BlueMatt> and that would imply the counterparty could provide a witness script that is signed with their key?
16:15 < BlueMatt> its just really good hygene for an interface like this to have limited input
16:19 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
16:19 < andytoshi> i think maybe we shuold just break protocol for rust-jsonrpc
16:19 < andytoshi> and just use all the newfangled shit
16:19 < BlueMatt> that would probably be my preference
16:20 < andytoshi> as best we can we could try to genericize it so that you could swap out a more conservative HTTP layer down the road
16:20 < BlueMatt> like, anything using it is gonna want newfalgned stuff......
16:20 < andytoshi> but like, nobody is going to do that work for years at least
16:20 < andytoshi> and yeah exactly
16:20 < andytoshi> blockstream might sponsor it if we have any spare developer bandwidth becuase we would actually like a single-threaded ascii only shitty jsonrpc lib
16:21 < andytoshi> but we won't for a while
16:23 < BlueMatt> and, if you were gonna do that, you'd probably just do it in native async modulo having an async tcp thing
16:23 < BlueMatt> cause thats pretty trivial
16:23 < BlueMatt> in other news, fuzzing of u128 vs Uint128 is lookin good
16:32 < ariard> BlueMatt: "I dont get this - you have to assume everything except the signer is a part of the counterparty" an attack can give you a wrong per_commitment_point
16:32 < ariard> and so you witnessScript can be invalid and your sigs too
16:33 < ariard> I agree that's good hygiene even if can't come with a good argument why in this case you're prevented off
16:36 < BlueMatt> yea, hmm, maybe its the case that it doesnt matter. i could see if there's some crazy nonsense around it being non-nuldummy or something, but thats nonstadnard
16:36 < BlueMatt> so, whatever, maybe its useless, even though I still prefer we do it :)
16:37 < BlueMatt> (on the flipside, it means we wont have a case where a user is trying to parse the witness to figure out what kind of transaction it is)
16:40 < ariard> yeah doing the move, we may come later with a good argument that it protects you against something
16:40 < ariard> but it also means building witness locally they MUST be standard as you point out, I will add this in documentation
16:41 < BlueMatt> right, well they *should* be using our utility functions on the signer
16:41 < BlueMatt> and just calling that :)
16:41 < ariard> that's where verify_standard in core would make sense, I mean what are doing hardware wallets right now
16:41 < ariard> they don't fancy scripts I guess
16:42 < ariard> but you want to be sure your signer hasn't committed to some non-standard stuff, and you can't verify outside
16:42 < ariard> because it's part of the hash
16:48 < ariard> BlueMatt:  should we return a tuple (Signature,Script) to let input finalization happens outside of signer?
16:48 < ariard> or we assume both signer and outside-world rederive witnessScript
16:49 < BlueMatt> assume both can figure out the script
16:49 < ariard> currently sign_local_commitment lean towards 2)
17:41 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
17:43 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:5d17:dfd5:86c9:227] has quit [Read error: Connection reset by peer]
19:40 < ariard> BlueMatt: okay I pushed a bunch of changes on 610, most notably is moving all signers function signatures to return a Result<Signature, ()>
19:40 < ariard> and therefore let callers detect any errors, as devrandom made the comment
19:41 < ariard> I also moved witnessScript re-construction on the signer side for sign_delayed_tx and sign_payment
19:42 < ariard> BlueMatt: but haven't done it for sign_justice and sign_remote I need to pack more stuff in InputDescriptors because HTLC scripts are pretty complex to rebuild
19:42 < ariard> BlueMatt: aand while doing so I notify I reintroduce MINIMALIF bug due to a rebase :(
19:43 < ariard> so I propose to move forward with 610 at it is, and finish witnessScript dry-up in a follow-up
19:43 < ariard> I fixed MINIMALIF with a comment, but sadly we can't test to check for regression...
20:18 -!- raj_149 [~quassel@ec2-18-217-191-36.us-east-2.compute.amazonaws.com] has quit [Read error: Connection reset by peer]
20:18 -!- raj_149 [~quassel@ec2-18-217-191-36.us-east-2.compute.amazonaws.com] has joined #rust-bitcoin
--- Log closed Fri May 01 00:00:08 2020