< promag> it'd be nice to label all pulls that "fix something"
< promag> see pulls listed in #15575 description, only common label is "wallet"
< gribble> https://github.com/bitcoin/bitcoin/issues/15575 | 0.17: Backport 15297 by promag · Pull Request #15575 · bitcoin/bitcoin · GitHub
< promag> add label or place them in some gh project
< fanquake> promag you keep adding new backports to that :p, the labels can't keep up
< promag> what I mean is that, for instance, #11911 could have a "backport candidate" label or something like that
< gribble> https://github.com/bitcoin/bitcoin/issues/11911 | Free BerkeleyEnvironment instances when not in use by ryanofsky · Pull Request #11911 · bitcoin/bitcoin · GitHub
< promag> it's not a new feature, it's kind of fix
< fanquake> promag right, ok
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15587: wallet: Remove GetLegacyBalance (master...1903-walletRemoveLegacyBal) https://github.com/bitcoin/bitcoin/pull/15587
< gwillen> sipa: when you get a moment, can you explain to me a bit more about your most recent comment on #15508
< gribble> https://github.com/bitcoin/bitcoin/issues/15508 | Refactor analyzepsbt for use outside RPC code by gwillen · Pull Request #15508 · bitcoin/bitcoin · GitHub
< gwillen> i.e. specifically why it is that mempool code needs to care about potential insanely-signature-happy transactions, but we don't need to worry that we might have to deal with one here?
< gwillen> Is it that there is some reason one would not be possible, or just that such a transaction is so abusive that we never expect to see one in a non-adversarial context in practice?
< sipa> gwillen: in the mempool crazy things are possible, because they're constructed by third parties
< sipa> the size estimation code in analyzepsbt obviously only works for transactions that fully consist of inputs we at least understand
< sipa> those crazy sigoo-limited transactions are not we're able to sign for regardless
< gmaxwell> currently.
< sipa> gmaxwell: can you imagine any where that isn't the case?
< sipa> miniscript doesn't include anything where sigop cost would dominate either
< gmaxwell> for sigops cost to dominate there needs to be reused signatures?
< sipa> yes, by a factor 3x
< sipa> and that is ignoring pubkey sizes
< gmaxwell> okay, then no, I don't.
< gmaxwell> (sorry, the currently was a thoughtless comment)
< gmaxwell> and I hope in the future any sigops limits we do are just achieved via weight adjustment... (or at worst per txin limits...)
< sipa> gmaxwell: weight adjustment is painful, as it means you can't compute weight without knowing utxos being spent
< sipa> but otherwise i agree, i hope that going forward we can get rid of the two distinct resource limits
< gmaxwell> sipa: with segwit you don't need to know the utxo, redeemscript is present in the transaction itself, always.
< gmaxwell> though perhaps we sould make the version explicit in the transaction itself in future script versions!
< gmaxwell> (for this reason!)
< MarcoFalke> promag: fanquake: The gitian build takes about 12h for master and about 12h per pull (if it is in the same loop run). So the worst case for two pulls (assuming two loops are run for two pulls, because for example the second pull was labelled after the first one started) is 48 hours wait time.
< sipa> gmaxwell: but you can't know from the spending tx what segwit version it is
< sipa> say, there could be a p2wpkh spend that looks like a p2wsh
< sipa> and with future witness versions this may become even harder
< gmaxwell> we could fix that in future versions.
< sipa> i don't think so
< fanquake> MarcoFalke thanks
< gmaxwell> luke-jr solve this problem for us.
< gmaxwell> :P
< * sipa> likes a rule that the sigop cost of a spend can't exceed its witness size
< gmaxwell> We could fix it with a softfork that makes some classes of otherwise valid v1 scripts invalid.
< gmaxwell> sipa: the idea of data stuffing (or never being able to have expensive opcodes) makes me sad.
< gmaxwell> Esp with taproot where many features can mostly exist as threats more than reality.
< gmaxwell> It would be reasonable to have absurdly expensive opcodes (e.g. like pairings), which are virtually never executed.
< sipa> yeah, when there are opcodes that have a (much) higher cpu cost per byte than things we currently have, that approach isn't viable
< gmaxwell> I dunno if pairings are there yet, but its at least plausable to me that they are.
< gmaxwell> certantly if we use checksig as the standard of acceptable cpu/byte they are.
< gmaxwell> as they're >10x worse.
< gwillen> sipa: ok thanks that makes sense to me
< sipa> gmaxwell: p2p/storage update that RLE encodes big zeroes in witness elements; then have a rule that every OP_PAIRING must be followed by a push of 100 zero bytes :)
< gwillen> at that point you've pretty much turned it into size plus ops, you could just make the representation of each opcode equal in size to its op cost ;-)
< gmaxwell> this did occure to me, but unlike you I had the good taste to not mention it. :P
< fanquake> MarcoFalke what is the meaning of the egg
< echeveria> be thankful we can validate unconfirmed transactions at all
< echeveria> in ethereum you can't validate transactions really until they're in a block.
< gmaxwell> it's not an accident...
< gmaxwell> like, we've shot down and reformed proposals that make that harder.
< bitcoin-git> [bitcoin] achow101 opened pull request #15588: Log the actual wallet file version and no longer publicly expose the "version" record (master...rm-wallet-nfileversion) https://github.com/bitcoin/bitcoin/pull/15588
< fanquake> dongcarl what are you doing your testing with guix on? I've been running 0.16.0 with QEMU on macOS
< fanquake> Currently looking at setting up a alpine/guix docker container for building etc.
< dongcarl> fanquake: I’ve been doing it on my Arch machine... I haven’t tested nested containers yet unfortunately but you should give it a go and see if it works
< dongcarl> Your normal OS is macOS I presume?
< fanquake> Yea, running 10.14.x at the moment
< wumpus> promag: it'd be nice to label all pulls that "fix something" -> this is what the "bug" label is for, in principle
< wumpus> I don't think PRs get labeled with that in practice, but it was the idea
< wumpus> but I fully agree it would be useful when you want to wade through the zillions refactoring PRs and find those that actually solve problems
< aj> wumpus: maybe rename the label to "bugfix" then?
< wumpus> bahh
< wumpus> I mean, that would work less well for issues, but I don't think discussing names is very useful in any case
< aj> wumpus: *shrug* it just never would've occurred to me to search PR's for label:bug
< kallewoof> alternatively, we tag up the refactor PRs and you do "-label:refactor"
< kallewoof> that could probably use an additional "is:pr"..
< wumpus> but that gets features/documentation and all other categories as well, but ok good point
< luke-jr> [03:24:13] <gmaxwell> though perhaps we sould make the version explicit in the transaction itself in future script versions! <-- like the witness v1 draft I did in ~2017? :P
< luke-jr> (although I came away from that thinking it needed a substantial redesign)
< dta_> chat
< dta_> bip16?
< bitcoin-git> [bitcoin] Sjors closed pull request #15567: Make OutputType consistent with Descriptor and return it (master...2019/03/descriptor-output-type) https://github.com/bitcoin/bitcoin/pull/15567
< newbie2019258_> Hi guys, I got error message when I tried to use the /share/rpcauthrpcauth.py ANY help please?
< wumpus> which error message ?
< newbie2019258_> python ./rpcauth.py berlin2019RpcUser ---> File "/usr/lib/python2.7/hmac.py", line 50, in <lambda> self.digest_cons = lambda d='': digestmod.new(d) AttributeError: 'str' object has no attribute 'new'
< wumpus> try 'python3' instead of 'python'
< newbie2019258_> YES! Perfect, thank you, working!!!
< wumpus> great!
< wumpus> to ask, was there any documentation that you followed that made you use 'python'?
< wumpus> if so that needs to be corrected
< newbie2019258_> I searched a lot of on the web. But unfortunately I don't fund any "normal" documentation about this.
< newbie2019258_> Example: This topic also "unanswered" ---> https://bitcointalk.to/index.php?topic=4946696.0
< wumpus> i think the best place to search for or ask usage questions is the bitcoin stack overflow (https://bitcoin.stackexchange.com/)
< wumpus> the script is prefixed with "#!/usr/bin/env python3" so it should find the correct python interpreter if you execute the script without specifying one
< newbie2019258_> Yes, thank you, unfortunately I missed to check the shebang of the script.
< Sentineo> is verify-commits.py broken? It jus returns "origin/master was not signed with a trusted key!". Not saying which key is to blame.
< newbie2019258_> One more question please: After I added the rpcauth=... line into the config file (bitcoin.conf) how to need activate/accept, I mean maybe need to reload some service(s) or something like that? (I want to use the PHP wrapper to manage bitcoind over RPC)
< wumpus> Sentineo: gpg --refresh-keys might help
< wumpus> Sentineo: oh, it's broken here too
< wumpus> sipa's key 0xAC6626172E00A82CFFAE8972A636E97631F767E0 has expired and trying to refresh it gives me "gpg: keyserver refresh failed: No data" :shrug:
< bitcoin-git> [bitcoin] practicalswift opened pull request #15589: lint: Teach lint-whitespace.sh to detect missing newline at end of file (master...lint-newline-at-eof) https://github.com/bitcoin/bitcoin/pull/15589
< wumpus> oh no more linting PRs
< wumpus> can we stop doing that please ... :(
< gmaxwell> might be a better use of time to tell people how to set color.diff.whitespace in their local git configs.
< wumpus> I don't care about EOL at the end of files and other micro-aesthetic obsessions
< wumpus> this is getting out of hand, has been for a while, maybe it's time to set a requirement that every PR fixes a reported problem
< gmaxwell> \O/
< Sentineo> is verify-commits.py broken? It jus returns "origin/master was not signed with a trusted key!". Not saying which key is to blame.
< luke-jr> gmaxwell: isn't color.diff.whitespace the default?
< Sentineo> hm sorry for pasting it again, exidentaly
< wumpus> Sentineo you're repeating yourself
< wumpus> ohh okay
< bitcoin-git> [bitcoin] practicalswift closed pull request #15589: tests: Teach lint-whitespace.sh to detect missing newline at end of file (master...lint-newline-at-eof) https://github.com/bitcoin/bitcoin/pull/15589
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/c3b1cb958f7c...8e1704c01537
< bitcoin-git> bitcoin/master a4d0fd0 fanquake: doc: correct analysepsbt rpc doc
< bitcoin-git> bitcoin/master 335931d fanquake: rpc: return a number for estimated_feerate in analyzepsbt
< bitcoin-git> bitcoin/master 8e1704c Wladimir J. van der Laan: Merge #15559: doc: correct analyzepsbt rpc doc
< bitcoin-git> [bitcoin] laanwj merged pull request #15559: doc: correct analyzepsbt rpc doc (master...fixup-analysepsbt-rpc-doc) https://github.com/bitcoin/bitcoin/pull/15559
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/021a9ad6f19b...2edd0c40c34b
< bitcoin-git> bitcoin/0.18 20fd64f fanquake: doc: correct analysepsbt rpc doc
< bitcoin-git> bitcoin/0.18 2edd0c4 fanquake: rpc: return a number for estimated_feerate in analyzepsbt
< wumpus> re: #15583 yes I feel really strongly about not ignoring errors, it has given me so much pain...
< gribble> https://github.com/bitcoin/bitcoin/issues/15583 | wallet: Ignore recursive_directory_iterator errors in ListWalletDir by promag · Pull Request #15583 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] Sjors opened pull request #15590: Descriptor: add GetAddressType() -> base58 / bech32 (master...2019/03/descriptor-address-type) https://github.com/bitcoin/bitcoin/pull/15590
< dongcarl> fanquake: it would seem that all you need is docker --privileged to be able to nest. Lemme know if you encounter any problems.
< fanquake> dongcarl Thanks, I've seen similar in some mailing list discussions. I don't think it should be too hard to get setup.
< dongcarl> If you’re trying it out for the first time, I’d suggest using the install script and enabling binary downloads for packages. Otherwise you’ll be building the whole world from scratch
< fanquake> :o
< dongcarl> Haha yeah, very desirable for bootstrappability, but somewhat less so if you’re just trying things out haha
< dongcarl> You’ll be prompted for it when you run the install script I believe
< fanquake> Yea no worries, I'll keep a look out
< promag> ryanofsky: I'm checking removing read access etc on walletdir and on each wallet file
< promag> ryanofsky: I don't think it results in an infinite loop
< MarcoFalke> Sentineo: It seems so. Please file an issue about that
< MarcoFalke> Interesting that it took so long for someone to find out
< MarcoFalke> Or instead of filing an issue, ping sipa to upload his unexpired key
< MarcoFalke> hmm sub 4096R/C4EB3A28 2017-02-27 [expires: 2022-02-26]
< MarcoFalke> ugh, gpg hides expired keys
< MarcoFalke> gpg --list-options show-unusable-subkeys --list-key --fingerprint --fingerprint 4E669320
< bitcoin-git> [bitcoin] pajasevi opened pull request #15594: Changed Czech translation of the word "blockchain" (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15594
< bitcoin-git> [bitcoin] promag closed pull request #14826: Avoid expanding descriptor scriptPubKeys (master...2018-11-faster-descriptor-expand) https://github.com/bitcoin/bitcoin/pull/14826
< bitcoin-git> [bitcoin] laanwj closed pull request #15594: Changed Czech translation of the word "blockchain" (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15594
< wumpus> ahhh I hate gpg, no one understands it
< wumpus> (re #15592)
< gribble> https://github.com/bitcoin/bitcoin/issues/15592 | Bitcoin signing key by @laanwj expired on 2019-02-14 · Issue #15592 · bitcoin/bitcoin · GitHub
< wumpus> and the tons of mails I got about it
< wumpus> really, just retire the thing
< wumpus> I guess the whole expiration date thing is non-obvious but that's not my fault, I 'm only using the software, I don't deserve this
< sipa> wumpus: some people will always be confused
< luke-jr> I think someone needs to write an article going over how to use GPG
< luke-jr> it's a pain, though, because it needs to be just right :x
< wumpus> sipa: I don't really blame the people that are confused
< wumpus> luke-jr: we first have to find someone that is not confused about gpg to write it though
< wumpus> :-)
< luke-jr> the hard part is key verification :P
< wumpus> yes
< MarcoFalke> wumpus: Mind to backport #15582, so it doesn't miss rc2?
< gribble> https://github.com/bitcoin/bitcoin/issues/15582 | Fix overflow bug in analyzepsbt fee: CAmount instead of int by sipa · Pull Request #15582 · bitcoin/bitcoin · GitHub
< MarcoFalke> Should be a clean cherry-pick. I can backport it as well, but I would have to create a pull for it. Not sure if you prefer that
< wumpus> MarcoFalke: sure
< bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/2edd0c40c34b...232ef630ecd3
< bitcoin-git> bitcoin/0.18 232ef63 Pieter Wuille: Fix overflow bug in analyzepsbt fee: CAmount instead of int
< wumpus> rc2 tomorrow after the meeting?
< MarcoFalke> I'd say so
< gmaxwell> Why not now? :P
< jonasschnelli> Any idea why Draht reports conflicts multiple times? https://github.com/bitcoin/bitcoin/pull/14032#issuecomment-471980504
< jonasschnelli> Maybe MarcoFalke
< MarcoFalke> Sorry, thats a bug
< jonasschnelli> No worries and thanks for fixing MarcoFalke
< MarcoFalke> What is the git repo again that mirrors all bitcoin core github comments?
< echeveria> eg, curl -s http://data.gharchive.org/2015-01-01-{1..31}.json.gz | zgrep "github.com/bitcoin/bitcoin"
< wumpus> gmaxwell: there's still #15583 tagged
< gribble> https://github.com/bitcoin/bitcoin/issues/15583 | wallet: Log errors in ListWalletDir and IsBerkeleyBtree by promag · Pull Request #15583 · bitcoin/bitcoin · GitHub
< wumpus> otherwise, yeah I agree
< wumpus> MarcoFalke: https://github.com/zw/bitcoin-gh-meta.git is what I used but it seems it hasn't been updated in a while :(
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15595: rpc: Actually use sendmany::minconf (master...1903-rpcWalletDummySendmany) https://github.com/bitcoin/bitcoin/pull/15595
< MarcoFalke> ^ not for 0.18.0 imo
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15596: rpc: Ignore sendmany::minconf as dummy value (master...1903-rpcWalletDummySendmany_2) https://github.com/bitcoin/bitcoin/pull/15596
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #15595: rpc: Actually use sendmany::minconf (master...1903-rpcWalletDummySendmany) https://github.com/bitcoin/bitcoin/pull/15595
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #15587: wallet: Remove GetLegacyBalance (master...1903-walletRemoveLegacyBal) https://github.com/bitcoin/bitcoin/pull/15587