< 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
< 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
< 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.
< 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
< 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.)
< 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"
< 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
< 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
< 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.
< 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)
< 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