< gwillen> ... why does the test runner keep logs in files named "test_runner_₿_🏃_...", with a unicode bitcoin sign and a unicode running-man emoji
< echeveria> gwillen: to check if your filesystem supports UTF characters.
< phwalkr> Is it possible/common to build a transaction with inputs of different types? I mean, one p2sh input, one p2pkh input and so on
< echeveria> phwalkr: this is normal. more a question for #bitcoin.
< phwalkr> echeveria: Sorry about that. And thank you for answering it!
< warren> I've noticed in recent years that the download size savings of .drpm vs .rpm is only a small % these days. I wonder if something about builds containing randomization makes the delta between before and after much larger than it used to years ago. In most cases it's faster to turn off deltarpm entirely.
< Lauda> Has anyone encountered the following error during building depends for winx64 on Ubuntu 16 (0.17.1 tag)?
< Lauda> "qwin10helpers.cpp:60:37: fatal error: uiviewsettingsinterop.h: No such file or directory"
< warren> oops wrong channel sorry
< Lauda> qt 5.9.6 is where it fails if I'm reading this correctly
< luke-jr> [10:13:01] <echeveria> gwillen: to check if your filesystem supports UTF characters. <-- rather, to check that the Bitcoin Core code correctly handles the unicode
< bitcoin-git> [bitcoin] promag opened pull request #15363: http: Exit the event loop as soon as there are no active events (master...2019-01-loopexit) https://github.com/bitcoin/bitcoin/pull/15363
< promag> sdaftuar: with the above your new test runs in 3 sec
< promag> provoostenator: ping
< nsh> strange question but
< nsh> what's the minimum number of chars for a brain wallet passphrase for a btc privkey?
< nsh> ideally something that i can spell out with the pieces of a standard scrabble board
< nsh> (sorry meant to ask next-door)
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/72d34c0edc5a...d83d6079432c
< bitcoin-git> bitcoin/master 6440e61 João Barbosa: qa: Drop RPC connection if --usecli
< bitcoin-git> bitcoin/master d83d607 MarcoFalke: Merge #15350: qa: Drop RPC connection if --usecli
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15350: qa: Drop RPC connection if --usecli (master...2019-01-fixusecli) https://github.com/bitcoin/bitcoin/pull/15350
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15364: qa: Fix race in feature_notifications (master...Mf1902-qaNotifRace) https://github.com/bitcoin/bitcoin/pull/15364
< achow101> meeting?
< luke-jr> ..
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Feb 7 19:01:27 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< jnewbery> hi
< jonasschnelli> hi
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb
< achow101> hi
< gkrizek> hi
< gwillen> buenos dias
< luke-jr> wat
< jamesob> hi
< wumpus> PSA feature freeze for 0.18 is next week #14438
< gribble> https://github.com/bitcoin/bitcoin/issues/14438 | Release schedule for 0.18.0 · Issue #14438 · bitcoin/bitcoin · GitHub
< wumpus> probably makes sense to discuss what will be ready for merge this week, as that should be prioritized for review
< promag> hi
< moneyball> hi - no proposedtopics from the week
< wumpus> moneyball: thanks
< instagibbs> hi
< dongcarl> #14856 has had lots of review
< wumpus> #topic 0.18 last-minute features
< gribble> https://github.com/bitcoin/bitcoin/issues/14856 | net: remove more CConnman globals (theuni) by dongcarl · Pull Request #14856 · bitcoin/bitcoin · GitHub
< jtimon> hi
< wumpus> dongcarl: that's not a feature tho
< * dongcarl> ducks
< dongcarl> true
< wumpus> so there's some feature PRs both in the 0.18.0 tag and high priority for review
< wumpus> I guess most are related to the wallet
< wumpus> and the importmulti descriptor imports
< wumpus> oh ofc that's wallet too :<
< luke-jr> XD
< achow101> it would be nice for that to be merged. and blank wallets
< wumpus> so yes, wallet, what will be ready for merge this week? maybe you can weigh in meshcollider?
< wumpus> i see #15153 has a tested ACK
< gribble> https://github.com/bitcoin/bitcoin/issues/15153 | gui: Add Open Wallet menu by promag · Pull Request #15153 · bitcoin/bitcoin · GitHub
< wumpus> #15226 too
< gribble> https://github.com/bitcoin/bitcoin/issues/15226 | Allow creating blank (empty) wallets (alternative) by achow101 · Pull Request #15226 · bitcoin/bitcoin · GitHub
< wumpus> so I suppose they can be merged soon
< wumpus> #14491 even seems ready for merge
< phantomcircuit> hi
< gribble> https://github.com/bitcoin/bitcoin/issues/14491 | Allow descriptor imports with importmulti by MeshCollider · Pull Request #14491 · bitcoin/bitcoin · GitHub
< wumpus> #action review last-minute wallet feature PRs for 0.18
< promag> if 15153 goes then #15195 and #15204 should probably go too - but these are simpler
< gribble> https://github.com/bitcoin/bitcoin/issues/15195 | gui: Add Close Wallet action by promag · Pull Request #15195 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/15204 | gui: Add Open External Wallet action by promag · Pull Request #15204 · bitcoin/bitcoin · GitHub
< wumpus> that's a lot for one week
< wumpus> but we'll see I guess...
< wumpus> any other topics?
< gmaxwell> (Hi)
< wumpus> (hi!)
< luke-jr> should I close https://github.com/bitcoin-core/bitcoincore.org/pull/637, or do we still want to do something for that?
< wumpus> #topic Advisory and full disclosure for CVE-2018-20587 on bitcoincore.org
< meshcollider> hi
< wumpus> looks like the PR is somewhat controversial
< gmaxwell> that seems weird to me.
< gmaxwell> it's an absurdly narrow corner case, not some major concern. it should get release notes.
< luke-jr> well, there's no fix in Core, so release notes don't really make sense
< luke-jr> some docs were updated tho
< wumpus> I tend to agree with harding though "I'm a fan of updating the documentation in the Bitcoin Core docs/ directory and putting something into the release notes instead of publishing a long blog post that basically says that using a computer not under your exclusive control is unsafe"
< sipa> hi!
< gmaxwell> requires an attacker on your local host, which 99.99999% of the time means you are boned anyways.
< * jonasschnelli> does also agree with harding
< luke-jr> gmaxwell: the attacker could be another unprivileged user
< gmaxwell> and it's also a 'vulnerablity' that is shared by virtually every other piece of software with an rpc on a non-privledged port.
< wumpus> gmaxwell: especially for the kind of environments that users that don't know this run
< luke-jr> (FWIW, #15223 is the doc/ updates)
< gribble> https://github.com/bitcoin/bitcoin/issues/15223 | Doc: add information about security to the JSON-RPC doc by harding · Pull Request #15223 · bitcoin/bitcoin · GitHub
< wumpus> e.g. if you're on windows and run everything as the same user anyhow then someone can just as well install a keylogger
< gmaxwell> luke-jr: yes but almost all the time multiuser OSes are vulnerable to one priv esc vuln or another.
< luke-jr> gmaxwell: not really, many things fail if they can't bind
< luke-jr> (I haven't had any negative reports from the fix in Knots, maybe I should PR that)
< gmaxwell> luke-jr: failing if you don't bind doesn't actually eliminate the vulnerablity here, just makes you more likely to notice (esp after you're screwed).
< gmaxwell> (and 'more' but not by much)
< luke-jr> gmaxwell: if you don't notice prior to the attack, at most they can get the walletpassphrase, which isn't a big problem if the wallet file is inaccessible
< wumpus> using a unix socket would eliminate the vulnerability but I think we've been through this
< gmaxwell> A real fix would be mutual auth and or using a unix domain socket.
< luke-jr> (with a bind=>failure fix)
< luke-jr> gmaxwell: I'm not sure most JSON-RPC libraries can support those
< wumpus> which would be nice, but I don't think there's anything new to discuss in that regard, there's still the libevent server crap
< wumpus> +http
< gmaxwell> luke-jr: the way you'd do the attack is start a process that binds in a tight loop until it gets it. then when it gets it it listens for a walletpassphrase then shuts off. What the user will is is that their daemon crashed, and they'll restart it before digging through the logs with almost certanty.
< bitcoin-git> [bitcoin] MeshCollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d83d6079432c...1933e38c1a08
< bitcoin-git> bitcoin/master 5952838 Sjors Provoost: [rpc] util: add deriveaddresses method
< bitcoin-git> bitcoin/master 1933e38 MeshCollider: Merge #14667: Add deriveaddresses RPC util method
< gmaxwell> luke-jr: indeed, which is another point that essentially everything off a privleged port is similarly 'vulnerable'.
< bitcoin-git> [bitcoin] MeshCollider merged pull request #14667: Add deriveaddresses RPC util method (master...2018/11/deriveaddress) https://github.com/bitcoin/bitcoin/pull/14667
< luke-jr> annoyingly, most OSs doesn't make it practical to reserve ports [privileged or otherwise] for specific users :/
< luke-jr> anyway, main question is do we want to do some blog post alerting people to this? or just leave it at a doc/ probably nobody will notice?
< wumpus> it's possible on linux with iptables IIRC buut I'm not sure we really want to go into that rabbit hole for documentation
< gmaxwell> the blog post also won't be noticed, plus I'm concerned that its crying wolf -- increasing the profile of minutia.
< wumpus> I'm also worried of that.
< wumpus> most people will be able to do exactly nothing with this advisory
< luke-jr> wumpus: it is?
< gmaxwell> Like we don't have a blog post warning you about following links or whatever, which is a much greater risk to users than this.
< wumpus> luke-jr: yes, there's a uid filter
< luke-jr> okay, sounds like I should just close the PR then and leave it at that
< wumpus> at least there was back in the day I was still interested in using user ids for separation instead of VMs
< gmaxwell> If we really wanted a blog post ... maybe instead we should have a blog post about bitcoin wallet security best practices, and this port thing could be mentioned somewhere in it. that would make sense. But alerting on this? I don't think so.
< luke-jr> wumpus: but that can't block binding afaik? I guess if nobody can connect it's effectively the same..
< wumpus> ok, any other topics?
< sipa> short topic: descriptor checksums
< wumpus> #topic Descriptor checksums (sipa)
< sipa> so, this was discussed in the wallet meeting 1 or 2 weeks ago
< sipa> the idea is that if descriptors are going to be used as import, and to generate addresses, we probably want to protect against typos (or due to length more commonly, copy-paste errors)
< sipa> and things like keypaths and public keys are quite vulnerable to that
< wumpus> makes sense
< luke-jr> I think it might be annoying to have to calculate checksums if you enter a keypath by hand..?
< jonasschnelli> it may be optional
< sipa> i have a PR almost ready to add these (will submit today), but since deriveaddress was just merged, i think it would make sense to have these in 0.18 (as it'd otherwise an incompatible change later; scantxoutset doesn't really require checksums)
< jtimon> oh, there's a wallet meeting?
< luke-jr> jtimon: same time Friday, every other week
< jtimon> thanks
< sipa> i'm just bringing it up as a heads up here; obviously if review doesn't let us get it in 0.18, so be it
< luke-jr> sipa: will they be optional?
< sipa> luke-jr: for RPCs where mistakes aren't critical, yes
< wumpus> it is very last minute considering there's many other wallet PRs that are tagged 0.18, but sure it'd be nice
< luke-jr> and can you (eg) have checksums on the keys, but not the paths?
< sipa> no, you'd need a tool or RPC to recompute the checksum
< luke-jr> :/
< sipa> my thinking is that for most things where you're just "playing" with them, they're optional
< achow101> luke-jr: keys would still be checksummed becaused of base58
< meshcollider> sipa: how large of a PR is it?
< sipa> meshcollider: not big, very localized
< meshcollider> thats good, I think we could get it in then
< wumpus> good, at least it won't interfere with the others then
< sipa> but when importing (which isn't merged yet), the checksum would be mandatory (or there could be a flag to disable that, if people like that...)
< meshcollider> is it based on #14491 then?
< achow101> I think there should be a flag to make them optional
< gribble> https://github.com/bitcoin/bitcoin/issues/14491 | Allow descriptor imports with importmulti by MeshCollider · Pull Request #14491 · bitcoin/bitcoin · GitHub
< jonasschnelli> skipping the checksum on RPC level is probably acceptable
< sipa> meshcollider: no, but it'd be a one-line change to integrate
< meshcollider> awesome
< luke-jr> almost certainly the response to mandatory checksum will probably be to just calculate it :x
< luke-jr> probably enough to just make sure if it is present and doesn't match, it fails
< sipa> luke-jr: that's perhaps true... but it's the best we can do
< sipa> end topic
< gwillen> we should avoid ever creating / displaying one without a checksum ourselves
< sipa> gwillen: yes, my PR adds the checksum in the text serialization code; it's optional just in the parser
< gwillen> :+1:
< sipa> (no point in discussing this here; will open the PR as soon as a few tests are fixed)
< wumpus> more topics?
< jl2012> hi
< jonasschnelli> I have just a little reminder...
< jl2012> #13360
< gribble> https://github.com/bitcoin/bitcoin/issues/13360 | [Policy] Reject SIGHASH_SINGLE with output out of bound by jl2012 · Pull Request #13360 · bitcoin/bitcoin · GitHub
< jonasschnelli> we should finally add older wallet tests
< jonasschnelli> with growing states (blank wallets, disable private key, hd non hd)
< jonasschnelli> I mean function tests that test stuff with wallets from older bitcoin core versions
< wumpus> #topic old wallet tests
< jonasschnelli> Or we will certainly break stuff in the near future
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15365: wallet: Add lock annotation for mapAddressBook (master...Mf1902-LockAnnotmapAddressBook) https://github.com/bitcoin/bitcoin/pull/15365
< jonasschnelli> I think MarcoFalke once made an issue: #14536
< gribble> https://github.com/bitcoin/bitcoin/issues/14536 | functional test with ancient wallet.dat (upgrade test) · Issue #14536 · bitcoin/bitcoin · GitHub
< jonasschnelli> So if someone is interested to write some tests against older wallets and eventually just use static older wallet files,.... your welcome
< jonasschnelli> The other route would be compiling older Bitcoin Core versions and use that as base for file interoperability tests (including levelDb upgrades, etc.)
< jonasschnelli> sorry,... I meant chainstate database upgrade (not levelDB upgrades)
< luke-jr> jonasschnelli: that complicates testing, which might be fine for extended tests, but I think wallet tests would be better as an "always run"
< MarcoFalke> The wallet file could be added to https://github.com/bitcoin-core/qa-assets in case core-repo-bloat is a concern
< jnewbery> Sjors has a PR for using older versions in testing: #12134
< gribble> https://github.com/bitcoin/bitcoin/issues/12134 | Build previous releases and run functional tests by Sjors · Pull Request #12134 · bitcoin/bitcoin · GitHub
< luke-jr> I wouldn't think a simple old wallet would be that large
< jonasschnelli> Probably,... but a couple of older wallet.dats in as test statics would not be completely wrong IMO
< jnewbery> I think it's a nice idea, but the instability of the interfaces and testing framework means it'll be quite an effort to maintain going forward
< luke-jr> I guess an ideal test would make an old wallet, load it in a new version, do stuff, then make sure the old version still works
< luke-jr> but that's getting complex
< jonasschnelli> I don't care where they are stored but we should finally add tests
< jnewbery> I think the idea of having old wallet files in the tests is more maintainable
< jonasschnelli> luke-jr: thats another tests that would certenly required to compile older version of Core
< wumpus> I'm not too happy with the idea of adding wallet.dat's to the repository
< MarcoFalke> wumpus: seen my reply above?
< wumpus> MarcoFalke: no I missed that, :+1: to that
< jonasschnelli> wumpus: we could rename them to static.dump *duck*
< gwillen> one could manually construct wallet.dats without keypool for testing, yeah? So they don't need to be very large?
< gwillen> unless that itself would break or fail to test important stuff.
< MarcoFalke> I don't think there is anything to discuss here. It just needs someone to create some wallet.dats and write the test
< jonasschnelli> jup. agree
< jtimon> since this is for testing, can't we just download older versions from https://github.com/bitcoin/bitcoin/releases ?
< wumpus> yes-
< jonasschnelli> that's why I labeled it as "reminder".
< MarcoFalke> heh
< jonasschnelli> Create blank wallets will be merged soon
< luke-jr> jonasschnelli: or have it available anyway
< luke-jr> wumpus: what about Python maps of key/values that get shoved in a BDB db manually? :P
< jonasschnelli> luke-jr: thats not authentic enough IMO
< MarcoFalke> Jup, we really need a wallet.dat before every feature-bump in Bitcoin Core
< jtimon> well, that would still be better than nothing, I guess
< wumpus> any more topics?
< jl2012> I'd like to have some concept ACK and review for #13360, which makes out-of-bound SIGHASH_SINGLE non-standard.
< gribble> https://github.com/bitcoin/bitcoin/issues/13360 | [Policy] Reject SIGHASH_SINGLE with output out of bound by jl2012 · Pull Request #13360 · bitcoin/bitcoin · GitHub
< jl2012> this could become a softfork someday
< wumpus> #topic out-of-bound SIGHASH_SINGLE (jl2012)
< luke-jr> jl2012: ltns. What's the benefit though?
< jl2012> luke-jr: to avoid losing money by accident
< luke-jr> ah, so it's more for local sendrawtx than for relaying
< jl2012> in legacy script, signing with out-of-bound SINGLE is almost like revealing your private key
< luke-jr> (I'm not sure it makes sense to do a softfork for that reason though)
< luke-jr> it's like absurd fee
< jl2012> fee is a feature, but this thing is clearly a bug
< luke-jr> jl2012: IIRC, it has been proposed to use it, in the past
< wumpus> I'm also not sure it makes sense to do a softfork for this, if you're afraid of users doing this then it indeed makes sense to add it on submitrawtransaction
< luke-jr> I believe the feature in that case, was that the signature was smaller than a normal one
< luke-jr> (the goal was to clean dust UTXOs)
< jl2012> how smaller? It's still 72 bytes or so
< wumpus> I mean there's tons of ways to lose money with raw transactions, it is user friendly to try to protect this on RPC, but I'm not sure it merits changing the consensus rules... but that's just me
< luke-jr> or maybe it was compressability? I'm not sure
< jl2012> you can use SIGHASH_NONE for donating dust
< luke-jr> wumpus: +1
< gmaxwell> achow101: I don't think there should be a flag to make them optional, instead just have a command that adds/fixes them.
< gmaxwell> achow101: so then you're not peppering every interface with a flag, and also don't run into people just setting the flag all the time "because thats how you do it"
< luke-jr> gmaxwell: I think yuo had suggested some "privkey gets compromised" dust cleaning thing - was that this?
< gmaxwell> luke-jr: sorry, missing the context
< jl2012> luke-jr: I guess you mean that's cheaper to validate, as you don't need to hash it
< luke-jr> gmaxwell: [19:50:00] <jl2012> I'd like to have some concept ACK and review for #13360, which makes out-of-bound SIGHASH_SINGLE non-standard.
< gribble> https://github.com/bitcoin/bitcoin/issues/13360 | [Policy] Reject SIGHASH_SINGLE with output out of bound by jl2012 · Pull Request #13360 · bitcoin/bitcoin · GitHub
< jl2012> but using ANYONECANPAY|NONE would not be too bad
< gmaxwell> I think we should get rid of sighash single, not to protect users (the UI does that), but because it's a constant hazard in consensus rules.
< wumpus> get rid of SIGHASH_SINGLE completely?
< gmaxwell> Twice now I've gone through some horror of thinking some interaction of consensus rules/ecdsa would make all funds trivially stealable but only to be saved by dumb luck.
< gmaxwell> no, the bug.
< gmaxwell> Single itself is fine, sorry-- but the single bug is a hazard.
< gmaxwell> it's also not actually useful.
< gmaxwell> Nor used.
< luke-jr> gmaxwell: a few years ago, you had a way to reduce block space used in dust cleanup, but in a way that compromised the privkey - was that related to this?
< gmaxwell> luke-jr: It just used a nonce with an usually small nonce. Using the single bug didn't make the txn any smaller.
< luke-jr> k
< gmaxwell> (though may have made them somewhat more gzippable, but not more compressable with a format aware compressor)
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Feb 7 20:00:40 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< gwillen> achow101: friendly poke on #13932 :-)
< gribble> https://github.com/bitcoin/bitcoin/issues/13932 | Additional utility RPCs for PSBT by achow101 · Pull Request #13932 · bitcoin/bitcoin · GitHub
< luke-jr> anyway, sounds like the policy change is a clear concept ACK, and softfork is at least something to consider later
< gmaxwell> An example, of one of the times I went through some horror. It's trivial to forge an ECDSA signature of the hash '0' with any pubkey... I realized this when I was AFK and thought single signed 0 instead of 1... if it did, every coin would have been stealable.
< gmaxwell> also, I think we already 'ruled' on the single bug being useful or not-- we didn't keep it in segwit.
< achow101> gwillen: what needs to be done on it?
< jl2012> gmaxwell: well, it's still in segwit, just not in a replayable style
< luke-jr> gmaxwell: saved by a bit ;)
< jl2012> in BIP143, out-of-bound SINGLE is treated like NONE
< gmaxwell> Right, it only signs that transaction.
< gmaxwell> And if by some cosmic wtf someone comes up with some application for it, it could always be introduced in a new script version.
< luke-jr> (yay script versions)
< gwillen> achow101: I left a few comments but I'd consider them nits -- should I be poking reviewers instead?
< gmaxwell> as far as concrete benefits beyond simplifying security analysis... it's one less case for a sighashcache to handle. (which I think was 95% of what caused it to come up)
< gwillen> achow101: or who do you think would ultimately be merging it?
< achow101> gwillen: right now it's waiting on reviewers
< achow101> i don't think there is much I can do
< gwillen> ok, I guess I can hassle people to review at the wallet meeting tomorrow
< gwillen> do take a look at my comments?
< achow101> sure
< wumpus> probably a good idea!s
< jl2012> gmaxwell: I don't think the SINGLE bug would affect sighash caching? If it is out-of-bound, it's always out-of-bound for the same input
< kanzure> late hi
< meshcollider> kanzure: you missed the whole meeting :p
< kanzure> time zones..
< gmaxwell> jl2012: right, but it's still an extra case to branch on that has to be tested.
< jl2012> gmaxwell: the trick to make smaller signature is using R = G^0.5 ?
< benthecarman> Hey, so I am making a PR to add an option to give the user the ability to have commands run after Bitcoin Core is finished starting up, the idea is so someone could have things like lnd or electrum-personal-server automatically run when Bitcoin Core starts. Is this something desirable to add or could it be too unsafe?
< gmaxwell> jl2012: yes, it makes r serialize 10 bytes smaller.
< gmaxwell> benthecarman: that doesn't seem crazy (or at least not any more crazy than the 'notify' commands... But why not just start lnd or eps at the same time-- presumably they'll just keep trying to reconnect, no?
< jl2012> so G is clearly not a random choice. Who choose that and why?
< jl2012> it seems not answered
< benthecarman> gmaxwell: my thinking was that you don't need to add all those to your automatic startup or have to run anything extra and bitcoin core can set it up for you
< sipa> jl2012: there is a very old bct thread about that, from someone who contacted certicom about the origins of the curve
< gmaxwell> jl2012: it's not, (AFAIK, I'm the one who discovered that it isn't...) but it's largely irrelevant. e.g. its trivial to prove that any 'weak' point makes all points weak.
< gmaxwell> jl2012: I can tell you how I discovered it, which is suggestive as to how it might have been selected that way.
< gmaxwell> jl2012: We had theorized that libsecp256k1's generator was was the output of some hash, but had no luck at finding a match (somee standards had hashes of the designers kids dates of birth or similar for choosing g)... In unrelated work on libsecp256k1 we wanted an easily generated NUMS point for blinding some operations in libsecp256k1... so like take a dumb string or a hash and treat it as a
< gmaxwell> point. Then it seemed useful to perform some operation on it to randomize the bits. The only operation you can do with just a single point and nothing is double it... which does a pretty good job of making the resulting values look 'random'.
< gmaxwell> jl2012: so I thought maybe the designer of this curve had taken a hash as a point and doubled it... so I havled G and found a surprisingly small value.
< gmaxwell> FWIW secp224k1 uses the same constant.
< jl2012> oh, btw, I have a related idea: in the new schnorr sig checking, if the signature size is 32 bytes, we check if it is the correct private key. This should be the cheapest way to donate dust
< gmaxwell> I had that thought too, fwiw.-- during the above disussion, but ISTM it's such a corner case that I dunno if it's worth doing.
< bitcoin-git> [bitcoin] benthecarman opened pull request #15367: feature: Added ability for users to add a startup command (master...startup_commands) https://github.com/bitcoin/bitcoin/pull/15367
< jl2012> if we will have some kind of EC MATH opcodes in the future, there is probably not much marginal cost to support this
< bitcoin-git> [bitcoin] laanwj pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/1933e38c1a08...9127bd7abaf8
< bitcoin-git> bitcoin/master a1b25e1 John Newbery: [wallet] Refactor ProcessImport()
< bitcoin-git> bitcoin/master 4cac0dd John Newbery: [wallet] Add ProcessImportLegacy()
< bitcoin-git> bitcoin/master d2b381c John Newbery: [wallet] Refactor ProcessImport() to call ProcessImportLegacy()
< instagibbs> \o/
< instagibbs> Only a couple PRs away from running master again :P
< bitcoin-git> [bitcoin] laanwj merged pull request #14491: Allow descriptor imports with importmulti (master...201810_importmulti_desc_2) https://github.com/bitcoin/bitcoin/pull/14491
< achow101> \o/
< bitcoin-git> [bitcoin] sipa opened pull request #15368: Descriptor checksums (master...201902_descsum) https://github.com/bitcoin/bitcoin/pull/15368