< meshcollider> there we go, travis is happy once again
< sipa> \o/
< Machine_Ex98> Hi all
< meshcollider> There's no support for BIP 39 in core currently is there
< sipa> no
< meshcollider> #11085 is adding ability to set a new HD seed using a WIF private key, would there be any reason not to take that further and allow setting a 512 bit seed or even mnemonic itself?
< gmaxwell> meshcollider: bip39 is a bad spec, disavowed by some of its authors even. Among other issues it has no facilities for versioning, which is a critical flaw.
< meshcollider> mhm true, but its pretty widely supported in hardware wallets and online wallets for backups so even if we didn't add mnemonic support itself, wouldn't it be useful to be able to set any seed for an HD wallet if you wanted to? Not just using a WIF private key?
< gmaxwell> doesn't make any sense.
< gmaxwell> you can import indivigual keys
< gmaxwell> but just having the same seed wouldn't result in the same derrived keys
< gmaxwell> unless the feature set and style were exactly the same.
< gmaxwell> The whole idea of compatibly imported keys is wrongheaded-- at least in a world where all wallets don't have exactly the same functionality-- and can result in funds loss.
< meshcollider> I mean, most support bip 32, 39 and 44, so if you imported the 512 bit seed generated from a mnemonic from bip 39, using bip 32 to generate master key, you'd have all the same keys?
< meshcollider> as long as they support the same seed -> master key in bip32 and tree structure in bip44
< gmaxwell> Which we will not, because it's insecure if key export is possible.
< meshcollider> not sure what you mean sorry?
< gmaxwell> and again, not actually compatible because.. unversioned.. how do you know if the key is using segwit or not.. p2sh or not.
< meshcollider> key export is possible currently with dumpwallet?
< gmaxwell> meshcollider: bip 44 forces public derrivation, if you give someone one private key and they find out your extended public key they can derrive all your private keys.
< gmaxwell> BIP44 basically violates bip32 by applying public derrivation to all cases, it should only be used in cases where export is not permitted; which is plausable for hardware wallets.
< meshcollider> ohhh you mean no to adding bip 44 support, not importing arbitrary seeds
< meshcollider> Yeah good point, fair enough then it would be pretty useless 👍
< meshcollider> I was only thinking about the security of importing the seed, not about bip44 itself hence my confusion
< gmaxwell> at some point we might support wallets which have export disabled, e.g. wallets with a public derrivation of whatever path, but it should be seperate.
< gmaxwell> with multiwallet thats more reasonable.
< bitcoin-git> [bitcoin] jamesob opened pull request #11293: Deduplicate CMerkleBlock construction code, add test coverage (master...dedup-cmerkleblock) https://github.com/bitcoin/bitcoin/pull/11293
< aleph_null> what is the latency in the FIBRE network?
< aleph_null> in practical, every day scenarios
< gmaxwell> aleph_null: a couple milliseconds over the best path distances 95% of the time.
< bane5000> Hey guys, was thinking about running a bitcoin core p2p only headless server on debian. Just had a couple of questions regarding the online documentation... first of all, do you recommend running this as root? Would it be wiser to run the daemon as a separate user/group?
< bane5000> Also, I know how to operate a firewall, with that being said, does the p2p function require upnp? Would i be safe to turn it off and just forward incoming connections on port 8333 (or whichever port it is) to the server?
< bane5000> Thanks guys :)
< sipa> bane5000: no need to run as root, forwarding 8333 is perfectly fine but you'll need to configure your external ip address (-externalip=IP on cmdline, or externalip=IP in bitcoin.conf)
< bane5000> sipa: Fantastic! I appreciate the information. Also, upon compilation, i just issue ./configure --disable-wallet (if i remember correctly?)
< MarcoFalke> where is gribble? pls revive
< sipa> nanotube: ^
< nanotube> sipa: it looks like gribble is banned from here
< nanotube> * #bitcoin-core-dev Banlist: Thu Aug 17 15:16:57 2017 *!*gribble@unaffiliated/nanotube/bot/gribble sipa!~pw@unaffiliated/sipa1024
< sipa> oh, yes!
< nanotube> was it thrashing?
< sipa> it was responding with extremely large lag (minutes or more), making it more distracting than helpful
< nanotube> ah
< nanotube> it seems it's working speedily presently
< sipa> good
< nanotube> i'll tell him to join back in once the ban's off. :)