--- Log opened Mon Jan 21 00:00:26 2019 03:21 < stevenroose> I'm trying to parse a transaction from the Core functional tests: 0100000000010000000000000000066a047465737400000000 "test fundrawtransaction with OP_RETURN and no vin" 03:21 < stevenroose> I'm getting this error: Execution failed: invalid tx format: ParseFailed("data not consumed entirely when explicitly deserializing") 03:36 < stevenroose> So it seems if there is no inputs, the segwit implementation somehow fails to parse the outputs. 03:36 < stevenroose> Core's decoderawtransaction somehow does this correctly and gives a tx with 0 inputs and the correct outputs 03:37 < stevenroose> In all fairness, this kind of "partial transactions" will be superceded by PSBT soon, but still. I'm annoyed by it because I use rust-bitcoin/rust-elements to port these tests from Core to Elements 04:47 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #rust-bitcoin 04:49 -!- TamasBlummer1 [~Thunderbi@p200300DD672D1A37B547C165C10C8C31.dip0.t-ipconnect.de] has joined #rust-bitcoin 04:50 -!- TamasBlummer [~Thunderbi@p200300DD672D1A571807362A33D2C728.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 04:50 -!- TamasBlummer1 is now known as TamasBlummer 07:24 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has quit [Quit: ZNC 1.6.3+deb1 - http://znc.in] 07:25 < andytoshi> heh, i don't remember any of the detais of the difficulty calculation at all. i remember having a very hard time sussing out what core was doing 07:25 < andytoshi> but i synced both testnet and mainnet with that code, i'm sure it's correct 07:33 < icota> BlueMatt TamasBlummer: is there a crate or just some sample code that integrates rust-lightning with rust-bitcoin-spv and/or rust-wallet? akin to rust-lightning-bitcoinrpc 07:38 < BlueMatt> icota: I believe rust-bitcoin-spv has a rust-lightning dependency? I presume its kinda integrated already, but I may be wrong 07:38 < BlueMatt> icota: I believe rust-bitcoin-spv is still a bit early, and rust-lightning is still very much a bit early 07:44 < icota> BlueMatt: precisely what makes them fun :) I see rust-bitcoin-spv implements your ChainWatchInterface, would be exciting to see what happens when you get the ball rolling 07:45 < BlueMatt> icota: no idea, I assume TamasBlummer has tested it, but I havent :p 07:46 < BlueMatt> icota: have fun :p 07:46 < BlueMatt> note that there's a million bug fixes on rust-lightning master, I intend to push a new release in the coming week or so once I land a few more in-flight things 07:47 < icota> BlueMatt: bugs are to be expected at this stage, but the foundations are strong, code looks awesome 07:48 < BlueMatt> icota: if you feel like contributing, https://github.com/rust-bitcoin/rust-lightning/issues/289 should be pretty doable 07:48 < BlueMatt> oh i need to tag that one good first issue 07:52 < icota> BlueMatt: thanks man. i'm a noob at rust and all this fuzzing business but i'll take a look 07:53 < BlueMatt> icota: so was I when I started :P 08:07 -!- icota [~igor@58-138.dsl.iskon.hr] has quit [Remote host closed the connection] 08:08 -!- icota [~igor@58-138.dsl.iskon.hr] has joined #rust-bitcoin 08:48 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has joined #rust-bitcoin 09:06 < stevenroose> I opened 3 PRs in an attempt to resolve dongcarl's util::key PR that has been open for a while. 09:07 < stevenroose> Basically they remove all key-types from rust-bitcoin, using secp256k1 keys instead. Taking a Network param where needed and always doing compressed pubkey serialization by default and having an `_uncompressed` variant method for uncompressed pubkey use. 09:07 < stevenroose> WIF got pushed into a util::wif module 09:08 < stevenroose> And another one removes the Address::p2pk constructor (and the address::Payload::Pubkey variant) because they are not addresses. (Though that change if of course independent of the other PRs.) 09:13 < dongcarl> stevenroose: My PR has been waiting on https://github.com/rust-bitcoin/bitcoin_hashes/issues/10#issuecomment-445492303 from andytoshi 09:14 < dongcarl> But I think I can just rebase and make it work 09:14 < dongcarl> It's not as efficient as I'd like it to be but wtv 09:15 < dongcarl> I'm not sure I'm the biggest fan of your WIF changes. Especially because encode and decode have no symmetry. 09:24 < stevenroose> dongcarl: they are compatible 09:24 < stevenroose> encode does compressed by default and decode can do all 09:24 < stevenroose> the method name of the full decode (with network and compressedness) is up for discussion, didn't have inspiration 09:26 < dongcarl> No what I mean is that the method signatures are not symmetric. This is mostly because you didn't define a struct of (Network, compressedness, PublicKey) 09:26 < stevenroose> dongcarl: alternatively I can make a `struct WIF(pub secp256k1::SecretKey pub, bitcoin::Network, pub bool)` type or so to sit there in the middle. 09:27 < stevenroose> I can do that.. 09:27 < stevenroose> Than it's just Display and FromStr, right? 09:30 < dongcarl> stevenroose: Sure yeah, but then you literally just end up with what I have but in a different module :p 09:33 < stevenroose> With a lot less bells and whistles, right? 09:34 < stevenroose> Just 2 methods basically. 09:35 < stevenroose> I'd still use encode and decode to be honest, just make them symmetrical using that tuple type. Can be a struct type for ease of use I guess. 09:35 < stevenroose> Or just have the tuple return value on decode, but the idea is to hide all uncompressed stuff from the user. 09:35 < stevenroose> To remove a layer of abstraction. 09:36 < stevenroose> To remove a parameter* 09:36 < stevenroose> lol finger memory 13:19 < dongcarl> nothingmuch: Did you end up finding the cause of the panic? I forgot 21:58 < nothingmuch> dongcarl: nope, sorry, i kept failing for a while longer but didn't manage to make time for it over the weekend 22:00 < nothingmuch> the limiting constraint is both my lack of rust knowledge and actual experience, so still motivated to keep at it, but alas i have made 0 actual progress as far as addressing the actual issue 22:02 < nothingmuch> i'm not even precisely sure where the error arises, it's somewhere between strason parsing the txid and before the impl of Deserialize is called (if i'm even understanding the intended code path right) 22:03 < nothingmuch> (serde_macros.rs in bitcoin_hashes) 22:04 < nothingmuch> my next attempt was going to be to revert back to the util::hash sha256 type, confirm my expectations of how serde interacts, and to see if i can produce a similar failure with that code 23:36 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 268 seconds] --- Log closed Tue Jan 22 00:00:27 2019