< bitcoin-git> [bitcoin] jtimon opened pull request #10427: Consensus: Introduce static GetScriptFlags (mostly MOVEONLY) (master...b15-consensus-script-flags-min) https://github.com/bitcoin/bitcoin/pull/10427
< luke-jr> ugh, it's like people refactored Core intentionally to make this rebase harder! (I know that's not the case..)
< bitcoin-git> [bitcoin] earonesty opened pull request #10428: -bip148 option (0.14...0.14) https://github.com/bitcoin/bitcoin/pull/10428
< bitcoin-git> [bitcoin] theuni opened pull request #10429: tests: fix spurious addrman test failure (master...fix-addrman-test) https://github.com/bitcoin/bitcoin/pull/10429
< SopaXorzTaker> guys, I want to propose a BIP
< SopaXorzTaker> Let's bring back the removed script opcodes, and standartize their behavior
< ajd_> have you tried the mailing list?
< SopaXorzTaker> ajd_, well, I've never had an experience with mailing lists
< SopaXorzTaker> where can it be found?
< ajd_> hold on lmgtfy
< ajd_> not sure how successful you'll be but probably not less successful than pitching it here
< SopaXorzTaker> hmm
< SopaXorzTaker> yup, found that
< SopaXorzTaker> um, what should I write?
< SopaXorzTaker> "Umm guys do u wanna look at my BIP proposal?"
< ajd_> - Posts should be technical or academic in nature.
< ajd_> - Generally encouraged: patches, notification of pull requests, BIP proposals, academic paper announcements. And discussions that follow.
< ajd_> - Generally discouraged: shower thoughts, wild speculation, jokes, +1s, non-technical bitcoin issues, rehashing settled topics without new data, moderation concerns.
< ajd_> maybe better to run the proposal past the people in #bitcoin first
< ajd_> Anyway I'm going to shut up now
< SopaXorzTaker> hmm
< SopaXorzTaker> BTW, just a core dev question
< SopaXorzTaker> do we prune old UTXOs?
< SopaXorzTaker> If not, I'd suggest keeping ones older than a parameter in on-disk cache, and allocating memory only for the new ones
< luke-jr> SopaXorzTaker: please at least understand things before making suggestions.. all UTXOs are kept primarily in an on-disk database
< sipa> SopaXorzTaker: please go away
< sipa> SopaXorzTaker: you've been told repeatedly to not make proposals about changing bitcoin here
< sipa> the UTXO question is indeed on topic, but you could do some basic research like trying to read the code and ask questions about it
< SopaXorzTaker> wait
< SopaXorzTaker> I had that misconception that UTXOs are kept in memory
< sipa> they are cached in memory
< sipa> the most recently used ones
< sipa> -dbcache controls the size of that cache
< sipa> the default since the latest release is 450 MB
< SopaXorzTaker> hm
< wumpus> also, please don't prefix any question with a "wait!" or "guys!" or "hm" line, you can just go and ask the question
< SopaXorzTaker> so I tried to oversmart the Core dev team, uh
< sipa> any idea what's going on here: https://travis-ci.org/bitcoin/bitcoin/jobs/233833539
< sipa> the win32 build repeatedly fails to test... 10 min timeout
< sipa> if i look at other PRs that succeed there, there is '790s' marker next to that line
< wumpus> seems the util test is taking very long
< sipa> i think it's the test_bitcoin
< sipa> just hasn't produced output yet
< sipa> but i don't understand how in normal (succesful) builds, there can be line that takes 790s, while not timing out
< sipa> oh, perhaps that 790s for the entire section
< wumpus> maybe it's on the edge of timing out, and usually it falls within the allotted time, but sometimes (due to VM unpredictability) it doesn't
< wumpus> travis issues are usually so hard to debug , especially intermittent ones, it's become its own kind of dread
< sipa> but with 10195 (after the latest rebase, not before) reproducibly times out there
< sipa> can we increase that 10min timeout?
< sipa> or make test_bitcoin print some dots
< sipa> oh, it wouldn't be visible even to travis, as the makefile construction doesn't connect stdout/stderr of the tests with the actual outut
< wumpus> you could increase the verbosity level, but yeah exactly
< sipa> seems that worked
< wumpus> interesting
< bitcoin-git> [bitcoin] paveljanik opened pull request #10431: Prevent shadowing the global dustRelayFee (master...20170519_policy_shadowing) https://github.com/bitcoin/bitcoin/pull/10431
< bitcoin-git> [bitcoin] plaxton opened pull request #10432: [Trivial] Add BITCOIN_FS_H endif footer in fs.h (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10432
< rafalcpp> Hello. Using your tool github-merge.py - it seems not work in some cases, e.g. it dislikes when one of the files is a symlink, is that not supported?
< rafalcpp> (Using you tool, but for another project)
< wumpus> symlinks are indeed not supported
< wumpus> (this is partially on purpose, partially because we don't know how to handle them for the treesum - but in any case it prevents symlinks from being introduced to the repository)
< rafalcpp> wumpus: perhaps like SYMLINK filename targetname? though yeah I guess we can live without symlinks :)
< wumpus> not all OSes support them anyway, and we're slightly afraid it can be used for nefarious things, but for your own project you could patch it to do something with symlinks sure
< rafalcpp> wumpus: even without the symlink, now both current and older script fails for one of PRs. It worked without problem for hundreds of merges before. Perhaps a bug in the tool, can I PM you urls/example?
< wumpus> sure
< rafalcpp> error is that Automatic merge failed. How ever, merge of that author/branch that he tries to PR, to same target/target_branch that the PR addresses, works fine (even as ff only)
< wumpus> automatic merge failed means that the merge could not be done automatically, it's usually fixed by rebasing the branch
< wumpus> hm okay
< wumpus> what it does is: GIT,'merge','-q','--commit','--no-edit','--no-ff','-m',message.encode('utf-8'),head_branch ... if that returns a non-zero exit code, you get the "Cannot be merged cleanly" error
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ea6fde3f1d26...993a1d710e7e
< bitcoin-git> bitcoin/master 2300a5e Ahmad Kazi: [Trivial] Add BITCOIN_FS_H endif footer in fs.h
< bitcoin-git> bitcoin/master 993a1d7 Wladimir J. van der Laan: Merge #10432: [Trivial] Add BITCOIN_FS_H endif footer in fs.h...
< bitcoin-git> [bitcoin] laanwj closed pull request #10432: [Trivial] Add BITCOIN_FS_H endif footer in fs.h (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10432
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/993a1d710e7e...6b99dafe4204
< bitcoin-git> bitcoin/master 6b51b0a Cory Fields: tests: fix spurious addrman test failure...
< bitcoin-git> bitcoin/master 6b99daf Wladimir J. van der Laan: Merge #10429: tests: fix spurious addrman test failure...
< bitcoin-git> [bitcoin] laanwj closed pull request #10429: tests: fix spurious addrman test failure (master...fix-addrman-test) https://github.com/bitcoin/bitcoin/pull/10429
< instagibbs> code seems simple enough, but IsInitialBlockDownload() will return true if IBD || reindex || importing blocks from disk?
< instagibbs> (asking if any sharp edges)
< wumpus> instagibbs: yes, that's the ida
< bitcoin-git> [bitcoin] jnewbery opened pull request #10433: [tests] improve tmpdir structure (master...test_runner_tmpdir) https://github.com/bitcoin/bitcoin/pull/10433
< sipa> so #10426's bogosize counts around 50 bytes per utxo (excluding the scriptPubKey)
< gribble> https://github.com/bitcoin/bitcoin/issues/10426 | Replace bytes_serialized with bogosize by sipa · Pull Request #10426 · bitcoin/bitcoin · GitHub
< sipa> disksize counts around 19 bytes per utxo
< gmaxwell> if would be more accurate if you made it work in units of nat-bytes. :P
< sipa> hahaha
< sipa> octonats
< Eliel_> I'm trying to debug a weird problem with the bitcoind wallet occasionally not unlocking after an apparently succesful walletpassphrase RPC call. The sendfrom RPC that follows the unlock errors with "Error: Please enter the wallet passphrase with walletpassphra
< Eliel_> se first."
< Eliel_> I found the debug parameter from bitcoind --help -help-debug. Which categories would make sense to activate? I think at least rpc category, but would other categories be useful?
< Eliel_> maybe lock or http categories as well?
< Chris_Stewart_5> Why would fundrawtransaction fail with 'Signing Transaction failed'? I thought fundrawtransaction does no signing?
< arubi> it does run some script with a dummy signature in the process though
< arubi> maybe the script you're redeeming is disallowed in itself
< arubi> some = the script being spent in the input
< instagibbs> Chris_Stewart_5, you likely don't know how to sign an input you included
< instagibbs> oh sorry I see you moved elsewhere, ignore...