--- Day changed Sat Nov 17 2018
01:02 < stevenroose> Perhaps we should think about what we want the Address type to be..
01:03 < stevenroose> IMHO, they shouldn't be anything more than a representation of what we know now as an "address". I.e. a standardized string that we can send to.
01:03 < stevenroose> In that sense, the enum-based type we have now is fine; we should actually even drop p2pk. (current impl strings that as a p2pkh)
01:06 <+andytoshi> i do want a way to produce p2pk addresses similarly to how core does (though maybe this is actually useless because everyone will interpret it as a p2pkh?)
01:06 < stevenroose> If we want a type that can represent any scriptpubkey and also help wallets sign for it, I don't think that's necessarily what an address should do.
01:06 <+andytoshi> agreed. that's a job for descriptors
01:06 < sipa> andytoshi: bitcoin core doesn't support p2pk addresses
01:07 < sipa> it can spend from them, but there is no corresponding CTxDestination for them
01:07 < sipa> similar to multisig
01:08 <+andytoshi> oh, i see
01:08 <+andytoshi> i was abotu to say "so, if i call `validateaddress` (or `getaddressinfo` i guess) on an address that corresponds to a p2pk output, it will give me a p2pkh-looking address"
01:08 <+andytoshi> but core doesn't distinguish between different address formats like that does it
01:08 <+andytoshi> it just knows "i can spend with this private key"
01:09 < sipa> well, you can't call validateaddress on a P2PK output because there is no way to construct an input for the RPC to do that :)
01:09 <+andytoshi> sipa: so, the original reason that we have p2pk support in rust-bitcoin was that there was some guy on #bitcoin with a bunch of p2pk outputs that he couldn't use because electrum had upgraded out from under him and dropped support
01:09 <+andytoshi> and i told him to import the wallet into core somehow
01:09 < sipa> you could give it a P2SH wrapped P2PK output, but then it would say it's a p2sh address, which wraps a pubkey
01:09 <+andytoshi> and i thought, rust-bitcoin should be able to do this too
01:09 < sipa> sure, spending from p2pk sounds totally plausible, but that doesn't mean you need an address for it, i think?
01:10 < sipa> or will you also have an 'address' for raw multisig?
01:10 <+andytoshi> i think my confusion is because if you call `decoderawtransaction` on a tx with a p2pk output, it will show an "address"
01:10 <+andytoshi> which it also does for raw multisig, now that i think about (well, a list of "addresses")
01:11 < sipa> it will do that, but that's a historic mistake
01:12 < stevenroose> is it because it just shows an address per pubkey associated?
01:12 <+andytoshi> hmmm. so maybe we should drop that entirely from rust-bitcoin
01:12 <+andytoshi> and drop p2pk entirely from our Address type
01:12 < sipa> it conflates addresses (things which correspond to a unique sPK) with key identifiers (hash160 of pubkey, represented in base58, to 'refer' to a particular key)
01:12 < stevenroose> in the "an address is just the hash of a pubkey" spirit
01:12 < sipa> right, this dates from a time when P2PKH was the only address type
01:12 <+andytoshi> because currently we literally cannot round-trip addresses to scriptpubkeys and back because of this
01:12 < sipa> so P2PKH addresses were used anywhere to identify pubkeys
01:13 <+andytoshi> which i consider a failure of rust-bitcoin, but i thought it was necessary for core compatibility
01:13 < stevenroose> andytoshi: if we drop p2pk support for Address, we could roundtrip, right?
01:13 <+andytoshi> stevenroose: yep
01:13 <+andytoshi> and further, if we supported output descriptors, we could still support the necessary data structures for wallets to use p2pk outputs
01:14 < sipa> if you call decoderawtransaction on a raw multisig output it will give you the list of public keys involved... each represented as a P2PKH address :'(
01:14 <+andytoshi> heh, yep .. so, we don't do that, but only because we don't really support raw multisig in any reasonable way in rust-bitcoin
01:15 < stevenroose> > if we supported output descriptors => that's very much planned, right?
01:15 <+andytoshi> stevenroose: sorta ... the miniscript crate will have support for output descriptors, plus miniscript, plus a solver and a bunch of other stuff
01:15 <+andytoshi> in the last week i've started thinking that we want a simpler version of descriptors in rust-bitcoin
01:16 <+andytoshi> that can support the address types that we currently try to support with the Address struct (which currently we're having a ton of trouble with because it's unclear what this type is supposed to represent)
01:16 <+andytoshi> so then Address would become basically a serialization type for a few specific scriptpubkey templates, and descriptors would be used if people wanted to attach EC keys and stuff to those
01:17 <+andytoshi> and you could map Descriptor -> Address but not the other way around .... and miniscript will also have a Descriptor type but it'll be pretty-much unrelated (except that it will also admit an Address representation)
01:18 < sipa> andytoshi: in core you can expand a Descriptor to sPKs
01:18 < stevenroose> sounds good
01:18 < sipa> and you can 'extract' an address from an sPK (which may fail)
01:18 <+andytoshi> yeah, i think that's what we want in rust-bitcoin too
01:19 <+andytoshi> we current support "extracting" an address from spks i think .. or at least, there was a proposal for that recently and then i complained that it would force us to release a new major version every time we added address types .. but i think that's OK, there won't be any more new address types now that we have segwit
01:22 < sipa> in core the internal representation for an address is a variant containing either a P2PKH hash, P2SH hash, P2WPKH hash, P2WSH hash, "unknown witness" version + payload, and nothing (for cases where no corresponding address exists)
01:23 < sipa> which means the internal representation actually would break if a new witness type is introduced, but its serialization (the string form) is stable
01:23 <+andytoshi> cool. that's exactly what we have i think (though the different segwit things are encapsulated a bit more in the rust-bech32 typse, and also we support p2pk for apparent-confused reasons)
01:24 <+andytoshi> sipa: one ongoing frustration we've had is that if you have an EC pubkey (or a bitcoin EC pubkey, which also has a compressedness flag), you can't get an address from that because it has no associated network
01:24 <+andytoshi> so we have this weird situation where in Bitcoin a privkey has a network (needed for WIF serialization), a pubkey does not, a descriptor does not, but an address does
01:24 <+andytoshi> which means that some "obviously possible" conversions, e.g. pubkey -> p2pkh address, are not actually possible without extra information
01:25 < sipa> andytoshi: right, in a library setting I guess you always need to work with tuples (network, pubkey) and (network, descriptor)
01:25 <+andytoshi> yeah :/. i guess core gets around this because any running bitcoind always has a specific network it cares about
01:26 < sipa> yes, the network type is a global :p (i know, that's cheating)
01:26 <+andytoshi> ok. i'm glad i'm not crazy :P but i was hoping you'd have an obvious clean solution
01:26 < sgeisler> I'd imagine the workflow to be sPK -> Descriptor ->  Option<Address> (where Descriptors can be anything) or sPK -> Option<Descriptor> ->  Address (where Descriptors can't be raw/addr). The latter seems more useful to me since the Descriptor could be used to construct PSBTs.
01:26 < sipa> i think it may be easier to actually always treat the network as being passed around along with things... even together with WIF and addresses
01:27 <+andytoshi> hmm, that's not a bad idea
01:27 < sipa> instead of seeing the network as being implied by WIF or address, you see it as external information being passed along (because generally you know due to external context what it is anyway)... and then there is just one valid encoding for the address
01:27 < sipa> so parsing an address string would take a network type as input as well, and it would fail if the address's prefix doesn't match that network
01:28 <+andytoshi> right
01:28 <+andytoshi> hmm
01:28 < sgeisler> but if the network isn't part of Address we can't impl Display for it :/
01:28 <+andytoshi> the rust ecosystem have some more-or-less standard deserialization/serialization libraries which make it somewhat unergonomic to pass around context like that
01:28 < stevenroose> andytoshi: how about pk.to_wif(network)
01:28 <+andytoshi> oh, yeah, and the Display/Debug stuff
01:29 < stevenroose> just like pubkey.to_p2pkh(network)?
01:29 < gmaxwell> You should keep the possibility of things like stealth addresses in mind.
01:29 < sipa> andytoshi: so don't treat them as serialization :)
01:29 < gmaxwell> You shouldn't generally assume that you can go back from a scriptpubkey to an address...
01:29 <+andytoshi> gmaxwell: we can't do that now so we don't do it now :)
01:30 <+andytoshi> gmaxwell:  i generally treat addresses as a pile of crappy inconsistently-specified special cases. future work is centered on descriptors
01:31 <+andytoshi> sipa: yeah, ok, sure .. but sgeisler makes a good point that if we can't implement Display for Addresses then we lose the ability to println them conveniently, which sucks
01:31 < stevenroose> well, I'm off to bed. I'll read up tomorrow
01:31 <+andytoshi> i guess we could insist that users println a (Network, Address) tuple
01:31 < sipa> andytoshi: that's what i was going to suggest :)
01:31 < sipa> printing a type that encapsulates an address and a network
01:32 < sgeisler> Is that possible? Can I impl a foreign trait for a tuple of local structs?
01:32 < sgeisler> or ist that tuple treated as foreign too and so it's forbidden?
01:32 <+andytoshi> sgeisler: lemme check
01:34 <+andytoshi> sgeisler: grrr, no, the tuple is considered foregin
01:34 <+andytoshi> that's stupid
01:34 <+andytoshi> so, we can define a named type which encapsulates an address and a network
01:35 <+andytoshi> but then like, what good is the address type by itself :)
01:35 <+andytoshi> i guess it's "a thing you can get from a public key or a descriptor"
01:36 <+andytoshi> I think we should just stick with more-or-less our current design ... Address has a network in it, you can go Address -> spk or (Descriptor, Network) -> spk or (PublicKey, Network) -> spk ... and you can (fallibly) go (spk, Network) -> Address
01:37 <+andytoshi> i don't feel very strongly about PrivateKey, honestly i think that's a crappy type because anyone handling private keys should probably be writing their own code to deal with them safely, but I guess we want to expose some way to do WIF de/serialization
01:38 < sipa> andytoshi: do you support private descriptors?
01:38 <+andytoshi> sipa: sooorta
01:38 <+andytoshi> my miniscript library has a descriptor type which is abstracted over a PublicKey type
01:38 <+andytoshi> and you could define a PublicKey type which was actually a private key :P
01:38 <+andytoshi> but i think i need to re-think the API to make that less confusing
01:38 < sipa> right
01:38 <+andytoshi> or at least rename PublicKey to Key
01:39 <+andytoshi> it also has a translate() method where you give it a closure that can map between different Key types, and it'll convert between different Descriptor types by converting every key
01:40 < sipa> in my implementation the key type is fixed, but the parser will go from string type to descriptor + list of private keys
01:41 < sipa> and there is a serializer which takes a descriptor plus private keys, and puts them in place where possible
01:41 < sipa> i think in a from-scratch design, that's literally the only place where i'd support serializing private keys - always in the context of how it will be used
01:42 <+andytoshi> in my implementation you give it a Key type which needs to support stringification/destringification, and it uses that to parse/serialize
01:42 <+andytoshi> IIRC for signing you pass it a callback which takes a PublicKey and sighash and tries to produce a signature on that
01:42 <+andytoshi> but i've gone back and forth on a sensible API for that a lot and haven't settled on one
01:43 <+andytoshi> i like that "i'd only support serializing private keys in the context of how it will be used" (although descriptors are not quite a complete solution cuz they don't encode which network to use them on ;))
01:43 < sipa> ah, yes, in core signing is separate from descriptors... but in a from-scratch design i would probably make it part of it
01:44 <+andytoshi> but unfortunately we've gotta support WIF
02:11 < ariard> BlueMatt: right, added shutdown_pubkey into KeyStorage::PrivMode
02:13 < gmaxwell> isn't supporting WIF just as simple as supporting different encodings of descriptors?
02:13 < gmaxwell> like WIF is just shorthand for a descriptor.
02:14 < sipa> i don't think that corresponds to actual usage
02:14 < sipa> as you can use a WIF key regardless of how the pubkey is used
02:15 < sipa> (also, the text form of descriptors supports WIF right now in core, you can say "sh(wpk(WIFKEY))" to refer to the P2SH-P2WPKH scriptPubKey of that key's public form, together with the private key to spend it)
02:17 < gmaxwell> hm? what would "support WIF" even mean, except treat it like a descriptor with the same key material?
02:18 <+andytoshi> if you had a descriptor with only a single key, and you augmented that with network information, you could WIF-encode it in some sense, though there is no sensible decoding
02:18 < sipa> gmaxwell: my point is that a WIF is only conveying a key, and not whether it's to be used in PKH or WPKH or some multisig setting or whatever
02:19 < sipa> while a descriptor is specific to its usage
02:20 < sipa> so a WIF as part of a descriptor makes sense, but I don't think treating WIF as a shorthand notation for any particular type of descriptor does
02:20 < gmaxwell> well you can't 'support' (e.g. import) the WIF without some kind of implied descriptor.
02:21 < sgeisler> isn't that what combo(KEY) is for?
02:21 <+andytoshi> my understanding is that core basically imports every single-key descriptor it has support for
02:21 < sipa> core doesn't import descriptors at all (yet)
02:21 <+andytoshi> i don't want to support that behavior in rust-bitcoin
02:22 < sipa> gmaxwell: for example you could have a tool that takes a PSBT (which already includes keypath and script information) and a WIF private key, and signs it - regardless of how that key is used
02:23 < sipa> andytoshi: i would hope not :D
02:25 < sipa> gmaxwell: agree that for importing you always need some (implied or not) descriptor along with the key, but that's not the only thing keys are useful for
02:36 < gmaxwell> fair enough
11:44 < stevenroose> andytoshi: what's wrong with instead of wanting to do tuples/combinator types (network + x), just define a method that takes a network?  WIF imo is just a way to format a private key in the context of a network.  So PrivateKey::to_wif(&self, Network) seems fine.  Just like PrivateKey::from_wif(&str) -> (PrivateKey, Network)
11:45 < stevenroose> For an address, I'd keep the network, as the Address type is a Rustification of the address string.
11:45 < stevenroose> Why do you need the network in these cases? (Descriptor, Network) -> spk & (PublicKey, Network) -> spk
13:32 <+andytoshi> stevenroose: i think i meant to write -> Address there
13:33 <+andytoshi> and yeah, sure, we colud pull Network out of Private key and require user provide it when doing WIF de/serialization, because i don't really want serialization to be very ergonomic anyway, plus as i mentioned i don't understand the purpose of the type anyway
13:34 <+andytoshi> but it's weird, you've got two "serialization" flags on a private key ... network and compressedness ... and one of them needs to stay in the type but the other one doesn't
14:54 < stevenroose> hmm, think some messages didn't arrive; could also have serialize and serialize_uncompressed
14:54 < stevenroose> (compressed is default, right?)
14:54 < stevenroose> dongcarl: you mind if I try working on your 2018-9-pubkey-wrapper branch a bit?
15:00 <+andytoshi> stevenroose: no, a compressed secret key really is a different thing from an uncompressed secret key
15:00 <+andytoshi> they correspond to different addresses, they are not interchangeable
15:01 <+andytoshi> (the same is true for network bytes btw, but since these don't appear on the blockchain there is a lot of software that is super sloppy about these)
15:27 < stevenroose> andytoshi: but that depends on how you see things, no?
15:27 < stevenroose> why should a "private key correspond to an address" necessarily?  the decision compressed/uncompressed only actually happens when you create the address
15:36 < stevenroose> an example reasoning for that is that most software projects will either always use compressed or uncompressed keys
15:37 < gnusha> irc logs http://gnusha.org/rust-bitcoin/
15:37 < stevenroose> so they really don't need to keep that extra metadata around in all their types. they can just have a global variable that they pass the moment it's needed, like for address creation
15:37 < stevenroose> gnusha: awesome!
15:38 < kanzure> if you have old irssi-formatted irc logs then i can backpopulate that archive
15:43 <+andytoshi> stevenroose: the compressed/uncompressed distinction happens whenever you want to encode an EC key on the blockchain
15:43 <+andytoshi> as for "why should a private key correspond to an address", what else would it correspond to?
15:45 < stevenroose> nothing in particular. you can use it to crate a p2pk scriptPubKey, an p2pkh address, a p2sh address, a p2wpkh address, make it part of a p2sh multisig scriptPubKey, a p2wsh multisig scriptPubKey
15:47 <+andytoshi> heh, you need compressedness for literally everything you just listed
15:51 < stevenroose> Well, that was a response to what should a private key correspond to.  No strong opinions, though, just thinking.  Wrote it up here: https://github.com/rust-bitcoin/rust-bitcoin/pull/194
15:52 < stevenroose> I don't think the address example makes any less sense: https://github.com/rust-bitcoin/rust-bitcoin/pull/194/files#diff-7769ce7612a45cca417dce18a5aa6a50R32
15:53 <+andytoshi> oh, goodness, IIRC we had an API like this long in the past and it was so freeking annoying passing network flags around everywhere
15:54 <+andytoshi> and users would have to provide them in some sort of config file even though they were implied by multiple other things, because otherwise the ordering got complicated
15:55 <+andytoshi> also why would we even have PrivateKey and PublicKey types in rust-bitcoin if they're just wrapping the types from rust-secp
15:55 <+andytoshi> i think this API is extremely unergonomic. users are forced to carry around this aux data literally every time they want to use an EC key
15:56 < stevenroose> Hmm, I don't really see why. I mean isn't almost any application doing only one network at a time and can just default to either compressed or uncompressed?
15:57 < stevenroose> You need to have that aux available either at key construction or at address construction fwiw.
15:57 <+andytoshi> so, the liquid functionaries are never working with less than two networks
15:57 <+andytoshi> and i have zero interest in hardcoding `true` in 6 billion places because some API author didn't want to store a boolean
15:58 < stevenroose> well, if compressed is very much the default, an Address::p2pkh_uncompressed is easy
15:58 <+andytoshi> if you have an uncompressed secret key you cannot get an uncompressed public key
15:58 <+andytoshi> or vice versa
15:58 <+andytoshi> we are not implementing an API where that is permitted and produces nonsense
15:58 <+andytoshi> please
15:59 < stevenroose> fwiw, don't the liquid functionaries use rust-elements and rust-bitcoin for both network? so they do one network per library basically
15:59 <+andytoshi> yes, ok, so they'd have to hardcode twice as many constants
16:00 < stevenroose> that's not true, you have to pass that data also when you create the privkey/pubkey struct
16:00 < stevenroose> so it's basically just doing it in another place
16:00 <+andytoshi> you mean instead of getting it from users' addresses i have to force them to redundantly put it in some config file, and then deal with inconsistencies?
16:00 < stevenroose> your argument is that you have to drag that context around from the one place to the other, but I'm saying in the first place it's irrelevant, so it's just moving to the other place
16:00 <+andytoshi> or i hardcode it somewhere and recompile every time the network changes?
16:01 <+andytoshi> this context is not irrelevant, it is literally part of the key and is needed for basically every use of the key
16:01 <+andytoshi> and if you remove it then it can become mangled or become inconsistent, users need to figure out a story for where they're going to store/infer the extra context, etc
16:04 <+andytoshi> i would sooner delete the PrivateKey type entirely than i would remove the compressedness
16:04 <+andytoshi> and i'm not really sold on removing the network flag either
16:05 < stevenroose> in all fairness, like this, I'd also just remove the both types, use the secp structs and have util::wif::encode_wif and util::wif::decode_wif
16:06 < stevenroose> I'm not saying this design is better, I don't have that much experience building large applications using this either.  Just seems weird that a private key, in essense just any random 32-byte string, is having a network and compressedness attached
16:06 <+andytoshi> ok, i can almost get behind that
16:06 <+andytoshi> my next question is, what key type would go into descriptors then
16:06 <+andytoshi> a (secp::PublicKey, bool) tuple?
16:06 < stevenroose> for which the compressedness if only used to pass into the pubkey struct later
16:07 < stevenroose> well, one big question is: how frequently used are uncompressed keys?
16:07 <+andytoshi> infrequently enough that i'm willing to make people type _uncompressed in a bunch of places to use them
16:07 < stevenroose> if it's really niche, having _uncompressed everywhere just for the awkward user would be fine
16:07 <+andytoshi> yeah
16:08 <+andytoshi> but i _don't_ want to have a type structure exported where people can accidentally lose track of compressedness
16:08 < stevenroose> would it be possible to have descriptors also explicitly indicate compressedness?
16:08 < stevenroose> or would that become very verbose?
16:08 <+andytoshi> i think we're going to need to have a PrivateKey type and a PublicKey type that include compressedness, but we can probably get away with just using them to instantiate a Descriptor<T> type
16:09 <+andytoshi> stevenroose: they already do
16:09 <+andytoshi> you cannot de/serialize a descriptor without the compressedness of its keys (using the 'standard' WIF/hex encoding of private/public keys that wallets use)
16:09 <+andytoshi> this is literally why we're having this discussion .. because we needed types for PSBT that wouldn't lose this info
16:11 <+andytoshi> so, i'd be willing to have a `pub struct PublicKey { key: secp256k1::PublicKey; compressed: bool; }` with nothing implemented on them except the de/serialization support that descriptors need, and make users manually construct these types when they need them
16:11 <+andytoshi> and also be willing to require users provide a Network when serializing private keys and descriptors
16:11 <+andytoshi> and when converting to Addresses
16:13 <+andytoshi> it'd be cool to have no Privatekey/PublicKey and just work with (secp256k1::SecretKey, bool) tuples, but rust doesn't let us add methods to those
16:13 < stevenroose> I was thinking of a CompressedPublicKey type but that also doesn't work
16:14 < stevenroose> need to have a unified type for a method signature, right?
16:14 <+andytoshi> yeah, annoyingly you sometimes need both at once
16:14 <+andytoshi> yeah
16:14 <+andytoshi> you can parameterize over different kinds of keys
16:14 <+andytoshi> so we could have both
16:14 <+andytoshi> but if you had a multisig output that had both compressed and uncompressed keys in it, you'd need some sort of Descriptor type that could support that
16:15 < stevenroose> who came up with this idea of optional compression in the first place :D
16:15 <+andytoshi> lol
16:15 <+andytoshi> openssl
16:15 <+andytoshi> actually no.
16:15 <+andytoshi> it was in the secp256k1 standard
16:15 <+andytoshi> in 2001
16:16 < stevenroose> did they cite any reason for which one would use uncompressed keys? other than tx malleability attacks of some sort?
16:16 < stevenroose> performance?
16:16 <+andytoshi> yes, there is a dramatic time/memory tradeoff
16:17 <+andytoshi> err, time/storage
16:17 <+andytoshi> you need to decompress a key to validate a signature, which requires a field sqrt
16:18 <+andytoshi> ah, it was actually 2000, not 2001 .. i couldn't find the doc but djb rehosted it https://safecurves.cr.yp.to/www.secg.org/SEC2-Ver-1.0.pdf
16:19 <+andytoshi> lol some of these curves are hilarious, sect113r1 etc ... those didn't make it to v2 i'm pretty sure
16:20 < stevenroose> those kind of "papers"/documents are so strange to me :D
16:21 < stevenroose> but RSA primes are even stranger I guess; "hey guys we found some super nice numbers, check them out!"
16:21 <+andytoshi> they don't give a justification for having compressed public keys .. which is kinda interesting, in those days people cared about signing perf but basically nothing else
16:21 <+andytoshi> so you'd think they'd have just stuck with a single compact public key format
16:22 <+andytoshi> as that has no effect on signing at all
16:24 < stevenroose> academics will never miss an opportunity to casually mention that you could easily half any of their metric, even if no industry use :D
16:26 <+andytoshi> heh, well, secg was mostly certicom, which had smartcards deployed all over the place
16:31 < stevenroose> hmm, so I came to my coworking to install Qubes OS on an Intel MUC I had lying around but I can't find a USB stick :/
16:32 <+andytoshi> perhaps if you yelled "what a shitty coworking space, nobody has a usb stick" ;)
16:36 < stevenroose> it's saturday, I'm alone here. Plus it is actually a shitty coworking space, I'm usually alone with some (non-software) architects here :/
16:36 < stevenroose> The perks of living in a small town
16:38 <+andytoshi> heh. i'm in a random coffee shop and there are several other software people here
16:41 < stevenroose> places are different I guess
16:55  * esotericnonsense is sitting in london hackspace which is currently in the process of refurbishment so quite empty
16:56 < esotericnonsense> if i'm outside i generally go to the pub to work because the food is better and it's cheaper, not many software people there. :P
16:56 < esotericnonsense> also usually more comfortable than coffee shops.
16:57 <+andytoshi> esotericnonsense: i also do that, though i went out this morning at 8AM, which is a bit early for the pub :)
16:57 < esotericnonsense> i enjoy watching the clientele change during the day
16:58 < esotericnonsense> like, during working hours, lunchtime ramping up is quite fun
16:58 < esotericnonsense> 10am - oh it's me, hardcore alcoholics, and pensioners
16:58 < esotericnonsense> 12pm - city workers
16:58 < esotericnonsense> 2pm is 10am again. :p
16:58 <+andytoshi> lolol
17:02 <+andytoshi> i could maybe do that at a pub that i never go to
17:03 <+andytoshi> but if i recognized regulars, i wouldn't be able to resist talking to people (maybe this is less acceptable in the UK) and i'd never get anything done
17:03 < esotericnonsense> london is pretty anonymous i think just cause it's so massive? i dunno
17:03 < esotericnonsense> it's pretty uncommon to see the same person twice on a train commute
17:04 < esotericnonsense> i recognise staff in places I go to often, that's about it, perhaps I'm just buried though
17:04 <+andytoshi> oh wow, i constantly see the same people around town, people say hi to me in the grocery store and stuff
17:05 < esotericnonsense> it's weird how it works because if I go to my hometown it's pretty likely I'll bump in to someone
17:06 <+andytoshi> i live in austin, which supposedly has a couple million people, but the downtown core area feels kinda like a small town (though i guess it's much more crowded, there -are- a lot of anonymous people surrounding the folks that i know)
17:07 < stevenroose> yeah living in a town that doesn't speak your language makes those things a bit harder too :D though I do recognize people and say hi etc all the time, but more than hi gets challenging
17:08 < stevenroose> unless it's related to the task at hand.. ordering food, selecting vegetables, ..
17:11 <+andytoshi> i'd have a super hard time of that
17:12 < stevenroose> Ok so I took out wif to util::wif and now it's really just secp wrappers.  I could drop them now.  For descriptors a simple PublicKeyWithCompressedness(pub secp256k1::PublicKey, pub bool) would be sufficient in that case, no?
17:12 < stevenroose> I mean I'm still not convinced it makes sense per se, though :D
17:12 < stevenroose> Just trying to see how it feels.
17:13 < stevenroose> being able to drop the secp context for serialization would certainly make that a lot more ergonomic.
17:17 <+andytoshi> yeah, we will be able to in the next rust-secp version. probably by end of next week
17:17 <+andytoshi> so, i would prefer `PublicKeyWithCompressedness` just be called bitcoin::PublicKey :P
17:18 < stevenroose> yeah that's fair enough I think, would otherwise also get very messy with deserializing
17:28 < stevenroose> hehe, I guess I did quite a circular change by now
17:28 < stevenroose> I actually like having bitcoin::PrivateKey even though it's an empty type
17:29 < stevenroose> makes it easier if there would be upstream api changes f.e.
17:29 <+andytoshi> i continue to think that bitcoin::PrivateKey should have the compressedness flag
17:30 < stevenroose> I currently did it with a `.to_public_key()` and `to_public_key_uncompressed()`, which seemed fair.
17:30 <+andytoshi> no it doesn't
17:30 <+andytoshi> a compressed private key can't become an uncompressed public key
17:31 <+andytoshi> or vice-versa
17:31 <+andytoshi> no wallet software allows that to happen
17:31 < stevenroose> a compressed private key doesn't exist afaik..
17:31 < stevenroose> you mean "a private key that is supposed to be used to create a compressed public key when generating an address"?
17:31 < stevenroose> :p
17:32 <+andytoshi> i mean a private key with the "compressed" flag not set
17:32 <+andytoshi> one that corresponds to a compressed public key, yes
17:32 <+andytoshi> uncompressed*
17:32 <+andytoshi> core has a notion of compressed/uncompressed private keys
17:33 <+andytoshi> so does electrum
17:34 <+andytoshi> icboc does not support uncompressed keys, its keys are all compressed
17:35 <+andytoshi> ledger wallet app appears to have some global option to switch between uncompressed and compressed keys
17:35 <+andytoshi> perhaps you could name a wallet that has ever existed which did not make this distinction?
17:39 < stevenroose> don't think I can, don't know much about wallet internals. how do wallets that are fully bip32 count?
17:40 <+andytoshi> typically they only support compressed keys
17:40 <+andytoshi> but e.g. ledger can be run in an "uncompressed key" mode (maybe this requires recompiling from source, i'm not sure)
17:40 <+andytoshi> bip32 doesn't make any reference to compressedness IIRC
17:40 < stevenroose> I guess they do xpriv -> path -> key -> address
17:41 <+andytoshi> but in bitcoin,  EC keypairs have a compressedness bit associated with them, you cannot reference either half of the pair without knowing its compressedness
17:41 < stevenroose> fwiw Core has CKey which is basically everything together
17:41 < stevenroose>     static const unsigned int PRIVATE_KEY_SIZE            = 279;
17:41 < stevenroose> hey
17:41 < stevenroose> why don't we have pubkey and keypair?
17:42 < stevenroose> :D
17:42 <+andytoshi> hmmm
17:42 <+andytoshi> it's useful sometimes to refer to the private key by itself
17:43 <+andytoshi> and if you wanted to deserialize a private key to a keypair (which would be the only thing you could do), this would involve a key derivation which is horribly expensive
17:43 < stevenroose> yeah was thinking the same
17:43 < stevenroose> even though you don't necessarily have to store the pubkey non-lazily to call it a keypair
17:43 < stevenroose> but yeah I agree it would make less sense to not have the pubkey there always
17:45 <+andytoshi> well, rust makes lazy storage a bit unergonomic
17:45 <+andytoshi> because you'd have to mutate an internal field to cache it
17:54 < stevenroose> Don't give the PR too much value, will overthink things for a while.
17:54 <+andytoshi> hehe, sounds good
18:10 < dongcarl> andytoshi: could you put this up as a log? http://gnusha.org/rust-bitcoin/
18:10 < dongcarl> kanzure helped set it up
18:13 <+andytoshi> sure
18:13 -!- mode/#rust-bitcoin [+o andytoshi] by ChanServ
18:14 -!- andytoshi changed the topic of #rust-bitcoin to: Rust-Bitcoin Libraries Discussion. Artisinal Bitcoin for the rest of us. Do NOT have private conversations on the FreeNode network! | https://github.com/rust-bitcoin | Logs at http://gnusha.org/rust-bitcoin/
22:45 < dongcarl> stevenroose: I don't mind, but what's missing right now?
22:46 < dongcarl> ariard: if you have old irssi-formatted irc logs kanzure can backpopulate the gnusha archive
23:04 < ariard> kanzure: hey thanks for setting this up, I've old irssi-formatted logs from july, how do I transfer them to you ?
23:36 < sipa> stevenroose: CKey is just a 32-byte secret + compressedness flag
23:37 < sipa> stevenroose: there is also CPrivKey which is a private key in OpenSSL DER serialization (which contains pubkey, private, but also the curve parameters; that's the 279 byte thing)
23:37 < sipa> but CPrivKey is only used for backward compatibility with old wallet file formats
23:47 < kanzure> ariard: send me a link. use dropbox. upload to a file server. whatever.