--- Day changed Thu Oct 04 2018 02:30 < dongcarl> Woah, lots to look at it seems, I’ll be in Tokyo soon and probably more time to look thru things. Thank you stevenroose for being thorough! 11:30 < stevenroose> https://docs.rs/crate/secp256k1/0.11.2/builds/116606 11:30 < stevenroose> docs.rs build of secp256k1 fails something with features "rand serde" 11:33 < stevenroose> it somehow adds r#" '--features "rand serde"' "# to the rustdocs argument list, note the single quotes around it. Are those somehow specified by the Cargo file or is that a docs.rs bug? 12:00 < stevenroose> Reported it, let's see -- https://github.com/onur/docs.rs/issues/23#issuecomment-426985828 13:09 < stevenroose> andytoshi: you know any of the Dalek guys? they seem to do cool stuff https://github.com/dalek-cryptography 13:13 < andytoshi> stevenroose: yes, i know some of them 15:44 < stevenroose> Should the use of the PSBT unknown field generally be discouraged? 15:44 < andytoshi> no 15:44 < andytoshi> it's needed to do pay-to-contract right now, for example 15:44 < stevenroose> I'm currently using the PSBT standard only half because I also want to keep some extra information like the block number/hash a block is valid in. So I basically keep custom objects that is a PSBT INPUT + some extra meta. 15:45 < andytoshi> also in liquid we will need it to carry around some aux utxo information i think 15:45 < stevenroose> Then when I start adding signatures, I construct a full PSBT. 15:45 < andytoshi> so, it would be cool if there was a trait or something you could implement to make that more ergonomic 15:45 < stevenroose> The thing is that this information is not relevant for signing specifically. 15:45 < andytoshi> i guess psbt::Serialize is that trait.. 15:47 < stevenroose> I'm thinking it should not be used as a general "data storage" place for an application since the data will (if not carefully removed beforehand) be sent to hardware devices as well and they have very narrow limits. 15:54 < andytoshi> they should be ignoring anything they don't understand 15:54 < andytoshi> the spec is specifically designed to make this easy for them 17:15 < stevenroose> Yes I know, but I was thinking if it's 1 MB for an input, their buffers might get full. Or you mean they can ignore on a stream-basis so they don't have to store the full thing before parsing it? 17:16 < stevenroose> I just ran into another strange error for rust-bitcoindrpc: I have a hex script from bitcoind. If I parse the hex to bytes and use bitcoin::consensus::encode::deserialize() with this byte slice, I get an error: 17:16 < stevenroose> BitcoinSerialization(Io(Custom { kind: UnexpectedEof, error: StringError("failed to fill whole buffer") })) 17:17 < stevenroose> But, when I use serde_json::from_str(&format!(r#""{}"", the_hex)), it parses just fine. 17:17 < stevenroose> Shouldn't those two be equivalent? 17:27 < stevenroose> andytoshi: is it possible that for consensus::decode, for script there is a varint expected in the beginning, while for serde::deserialize with hex, it's just the plain bytes? 17:28 < stevenroose> I'm confused, because the first approach (that fails for scripts), works for Transactions. But yeah a Transaction certainly doesn't start with a VarInt 17:34 < stevenroose> I solved it by using Script::from, but still, I'm confused that Script::from and consensus::encode::deserialize is not equivalent while for txs it is. I'm pretty sure it's the varint thing. 17:54 < andytoshi> there is no "equivalent of Script::from" for transactions 17:55 < andytoshi> serde deserialization and consensus deserialization are completely unrelated 17:55 < andytoshi> and Script::from isn't related to either of them, that's basically just a cast 18:35 < stevenroose> well, let me phrase it as follows then, I'd expect the consensus serialization of a script be the serialized script bytes and I'd expect the serde serialization be the hexadecimal form of this 18:41 < andytoshi> the serde serialization ruoghly matches core RPC 18:41 < andytoshi> except in cases where that doesn't make sense or where core has changed but i haven't found out yet 18:42 < andytoshi> and the core RPC does not ever match the consensus serialization. in particular, core RPC never length-prefixes scripts