--- Day changed Wed Oct 31 2018
01:12 < ariard> Is there any trap setting sequence field of TxIn to satisfy a OP_CSV ?
01:12 < ariard> I mean it's obscure to me how bitcoinconsensus is checking that without access to blockchain height
01:13 < BlueMatt> ariard: OP_CSV *only* applies a set of rules to the nSequence value in the tx
01:13 < BlueMatt> then bitcoin core will apply rules based on the nSequence
01:13 < BlueMatt> so libbitcoinconsensus may say that a tx is valie but its locktimed way into the future
01:13 < BlueMatt> andytoshi: what do you think about https://github.com/rust-bitcoin/rust-bitcoin/issues/184 ?
01:14 < ariard> okay so i can't be a reason why my spend_tx fail in test
01:14 < BlueMatt> nope
01:14 < BlueMatt> I'd lean towards just take it into rust-bitcoin (I havent looked at it, I assume its good enough, but would want to do that first)
01:14 < BlueMatt> I doube jeandudey would be offended since hes contributed to other rust-bitcoin libs before
01:14 < BlueMatt> t
01:15 < BlueMatt> assuming someone wants to commit to maintaining it
01:15 < BlueMatt> maybe wumpus or the dpc reporter guy
01:16 < BlueMatt> at least as far as press-merge kinda maintinence is required
02:13 < andytoshi> BlueMatt: it's good enough code-quality-wise but it depends on reqwest which brings in all the tokio crap
02:14 < andytoshi> so while i trust the parts jeandudey has written (well, i'd be happy to review it more closely anyway) there's not much i can do about the dep tree
02:17 < andytoshi> oh, actually, maybe i'm wrong, it uses hyper 0.10, same as rust-jsonrpc
02:18 < andytoshi> oh i'm an idiot, it literally depends on my own library
02:18 < andytoshi> but unfortunately my feelings are the same ... rust-jsonrpc is under my own name because it has a larger dep tree than i'm comfortable with and it doesn't compile on rust 1.14
09:53 < stevenroose> andytoshi: https://github.com/rust-bitcoin/rust-bitcoin/issues/184#issuecomment-434625954
09:55 < stevenroose> I'd be happy to spend some time on that, tbh.
12:07 < andytoshi> that'd be cool. maybe coordinate with wumpus because there is talk of rewriting bitcoin-cli in rust from time to time, and this is blocking that
14:37 < BlueMatt> andytoshi: I mean I dunno if we have to require everything in rust-bitcoin have zero deps
14:37 < BlueMatt> andytoshi: plus rust-lightning doesn't compile on 1.14, only 1.22
14:37 < BlueMatt> obviously policy around "absolutely minimal deps" is good
14:38 < BlueMatt> but if you need to have an http library, probably better than writing your own
15:07 < wumpus> I don't think 'zero deps' is his goal
15:07 < wumpus> he just particularly doesn't like what hyper pulls in
15:07 < wumpus> the idea in 184 to somehow generalize it so that the choice of http client is up to the user is a good point I guess
15:08 < wumpus> but that assumed http clients offer a common trait interface which... likely isn't possible, especially if hyper seems to be the only feasible one at the moment
15:11 < andytoshi> BlueMatt: i'm not convinced that hyper is "better than writing my own http library" given that it and its dependencies have broken liquid repeatedly in minor point releases
15:11 < andytoshi> and given that for bitcoin core jsonrpc i really don't need a big subset of http
15:12 < andytoshi> wumpus: we could define a trait for common HTTP clients and it wouldn't be hard for people to wrap the various http libs' clients to implement that trait, if it were simple enough
15:13 < andytoshi> BlueMatt: good point about rust-lightning not compiling on 1.14; i think rust-jsonrpc probably falls into a similar category of "doing nontrivial io/network stuff" and it's not reasonable to require 1.14
15:15 < wumpus> andytoshi: and it could still provide traits for popular HTTP clients under features out of user friendlyness, I suppose
15:15 < BlueMatt> well with rust-lightning I also figure buster will be out by the time rust-lightning has any serious real-world usage
15:15 < BlueMatt> so I can require something higher :p
15:15 < BlueMatt> but, ok, fair, if hyper is actually bad fine, I wasnt aware if hyper was any good
15:18 < andytoshi> in general, it's very good for something that's trying to do HTTP in rust ... but that whole ecosystem has been in flux for years and is still kinda in flux
15:18 < wumpus> I think it's good for something that needs to really run a web service
15:19 < wumpus> it's very full featured... it's a bit like importing apache if only want to run local RPC
15:19 < andytoshi> right
15:20 < BlueMatt> yea, ok
15:20 < wumpus> I was happy to not need hyper for rust-lightningrpc because that uses JSON over a pipe instead of HTTP, apart from anything I wish that was done for bitcoind :)
15:21 < BlueMatt> heh, yea, json-rpc is kinda...ugh
15:22 < wumpus> though requiring bitcoind's interface to change is... even more of a pipe dream than a minimal http client
15:24 < andytoshi> iirc sipa told me oncethat bitcoin-cli used to have a hand-rolled http client that would basically just write templated text over a tcp socket ... i haven't looked into how true that is
15:25 < wumpus> miight have been true in boost::asio times, I don't remember, but yes if you *know* which server you're talking to it's almost trivial to mkae a client shim
15:27 < wumpus> though maybe it's brittle as well
15:29 < wumpus> when libevent offered actual http client functionality we were likely happy to switch to it, for all the good that did us, it turns out to be a bit of a problem for supporting HTTP over UNIX sockets
16:05 < stevenroose> wumpus: if a rust-bitcoind-rpc would just depend on an http-agnostic jsonrpc, then for a hypothetical bitcoin-cli in Rust, you'd just need to pick an HTTP client and do argument handling on top of rust-bitcoind-rpc
16:07 < wumpus> stevenroose: right !
16:11 < stevenroose> Any opinions here on the use of macros? I mean in the case of RPC client code, it's solely to avoid code replication. So if they are any concern, they could easily just be avoided with a lot of copy paste and a big facepalm whenever you want to make a change :)
16:14 < wumpus> if they're contained to the library's internals, just to make code generation for all the calls easier (rust-clightningrpc was a lot of copy-paste work for one!), I don't personally see much wrong with them, I do think exporting macros to the user of the library is best to be avoided because it makes learning the API harder (it's somewhat irregular), but I don't think that's the case here?
16:17 < andytoshi> agreed
16:18 < andytoshi> although if it's possible to eliminate the repitition with traits and default methods, we should definitely prefer that
16:24 < wumpus> e.g. most of https://github.com/laanwj/rust-clightning-rpc/blob/master/src/lightningrpc.rs could be generated, it's a matter of accepting parameters, creating call-specific a request structure, and sending it on; I suppose bitcoinrpc does a similar thing
17:35 < esotericnonsense> :>
17:35 < wumpus> welcome esotericnonsense
17:36 < wumpus> there's been some discussion here on rust-jsonrpc and http frameworks and such, see also https://github.com/rust-bitcoin/rust-bitcoin/issues/184
17:37 < esotericnonsense> that discussion echoes a lot of what I've been thinking about really (I wrote the client just to learn some rust, because I haven't used it before, so it's basically intentional-NIH)
17:38 < esotericnonsense> hyper seems like ridiculous overkill for the small subset of HTTP required to do bitcoin RPC
17:39 < wumpus> I think you're right that adding a rust based tool to the bitcoin core repository is going to be a fight in any case, but it's going to be easier if it's more or less self-contained with regard to dependencies
17:39 < wumpus> right
19:53 < dongcarl> wumpus: I think Luke had some concerns w/re Rust not being bootstrappable
19:54 < gmaxwell> any rust with bitcoin will be an uphill thing, but something like -cli is among the most isolated... so easiest to do. (unfortunately it's not really optional...)
19:55 < gmaxwell> rust bootstrapability really needs to improve, not just for us but for everyone.
19:56 < gmaxwell> another way to use rust w/ bitcoin would be to eliminate bitcoin-tx and replace it with a seperate rust-bitcoin package.
21:17 < dongcarl> gmaxwell: Yes replacing those binaries would make the most sense... wumpus suggested that we could possibly replace the network code with Rust, and from my conversations with BlueMatt, and cfields they seem okay with it... What do you think?