< wpaulino> > The replacement transaction pays an absolute fee of at least the sum paid by the original transactions.
< wpaulino> looking at bip 125, in the case of multiple replacements, is “original transactions” meant to just be the previous replacement with its descendants (if any)?
< wpaulino> double checking with the validation code, that seems to be the case. just want to make sure tho as the wording is kinda weird
< luke-jr> wpaulino: any and all transactions the new one conflicts with
< luke-jr> so if the new one has two inputs conflicting with two different and unrelated transactions, it includes both of them and all their descendents
< luke-jr> potentially conflicts could be huge, but I think there's a limit to what we process
< wpaulino> luke-jr: gotcha, thanks
< phantomcircuit> luke-jr, nope they're actually separate buffers
< phantomcircuit> somethings just happen to map to both
< luke-jr> phantomcircuit: ?
< luke-jr> oh
< luke-jr> phantomcircuit: but terminal programs don't have their own clipboards…
< luke-jr> they use the same ones every other program does
< phantomcircuit> luke-jr, actually they don't by default, they're just virtually universally configured to copy into both the "primary" and "clipboard"
< luke-jr> phantomcircuit: QClipboard doesn't even support 4 clipboards, so what you're claiming is extremely unlikely
< luke-jr> and the 3rd one is only supported on macOS
< phantomcircuit> luke-jr, see xclip
< luke-jr> bash: xclip: command not found
< luke-jr> phantomcircuit: ancient terminals nobody uses != all or normal terminals
< wumpus> luke-jr: they could go in separate files IMO
< wumpus> luke-jr: the usual qt convention seems to be one file pair = one class, which makes it easy to find where a class lives, so makes a sensible default unless you're dealing with lots of small classes
< luke-jr> fair enough
< fanquake> 4x signed sigs for v0.18.0 so far.
< bitcoin-git> [bitcoin] practicalswift opened pull request #15938: Silence GCC 7 warning "control reaches end of non-void function" (-Wreturn-type) in psbt.cpp (master...psbt-return-type-warning) https://github.com/bitcoin/bitcoin/pull/15938
< wumpus> fanquake: goign fast
< luke-jr> now if only more of them would build Knots too ;)
< wumpus> no problem, which repo/tag is that?
< luke-jr> wumpus: will announce here when tagged, thanks ☺ (probably an hour or so)
< luke-jr> hrm, Launchpad is timing out trying to get PPA download counts for Core - hopefully it will get fixed before Matt pushes 0.18 XD
< luke-jr> hmm
< luke-jr> the big "Download Bitcoin Core" button on the website links ot the non-existent win32 :/
< luke-jr> wumpus: can you fix that quickly? otherwise it may skew our goal of finding out who cares
< luke-jr> (ie, people may care that the default doesn't work, even if they don't necessarily care about win32 specifically)
< wumpus> I don't really know how to do website stuff
< wumpus> surprised anyone's default would be win32 though
< wumpus> ping @ harding
< luke-jr> probably just need to change win32exe to win64exe on line 21
< luke-jr> of _includes/templates/download.html
< wumpus> so this means *everyone* with windows was suggested the 32-bit download? ouch
< wumpus> will change
< gmaxwell> ugh
< luke-jr> wumpus: does it try to detect even? I got that link on Linux
< luke-jr> looks like it's a win32 link for everyone
< wumpus> it used to detect, maybe no more
< gmaxwell> maybe it correctly detects 64 bits on win64 but elsewhere just does 32bits?
< luke-jr> gmaxwell: i don't see any conditional logic
< luke-jr> bet it was lost with bitcoin.org -> bitcoincore.org
< wumpus> luke-jr: oh good point, I guess the bitcoin.org PR will fail because it's missing the 32-bit windows files
< luke-jr> bitcoin.org indeed has OS detection Javascript
< luke-jr> wumpus: nevermind, it'll be a while. something broke with the power64 gitian builds :/
< luke-jr> apparently a bug with Ubuntu's GCC 8 for older ppc64
< * luke-jr> ponders whether to bump up the ppc64 -mcpu, or drop to GCC 7
< wumpus> bumping the cpu sounds better, at least if it's still suppported on the TALOS
< luke-jr> yeah, it needs power7 for __float128, which glibcxx's headers assume is available
< gmaxwell> forcing down to older power probably hurts performance in any case, is anyone running this on anything less than power9?
< luke-jr> gmaxwell: awilfox was pushing for 970 (G5)
< luke-jr> gmaxwell: and ironically, it performs better on POWER9 with an older target, than if targetting power9
< wumpus> that's interesting
< wumpus> FWIW I'm surprised how good recent gcc's risc-v code generation is, it took ages to get to that level for ARM, for a long time it did kind of dumb things like juggle results between registers and memory unnecessarily
< luke-jr> it's -misel that makes the performance hit specifically
< gmaxwell> wumpus: might help that GCC is presumably the compiler the risc-v designers use, while arm was focused on their own toolchain for a long time
< wumpus> gmaxwell: yup
< gmaxwell> luke-jr: IIRC isel is some predicated execution thing? it might want branch profiling...
< wumpus> gcc is the only feasible toolchain for RISC-V at the moment, clang doesn't support everything yet for full linux rv64gc
< luke-jr> gmaxwell: well, supposedly POWER8 had it, but it performed worse, so GCC disabled it by default.. I imagine they'll end up doing the same for POWER9
< gmaxwell> Predication like features can result in big performance gains, but only when they're used on frequently executed low predictability branches, if you use it on a branch that always goes the right way on many that are rarely executed they hurt performance.... This was a super big deal on itanium.
< gmaxwell> without profiles GCC has some guesses, e.g. exceptions are rare... malloc failures seldom happen, etc.
< luke-jr> should we begin littering our code with likely()/unlikely()? :P
< wumpus> luke-jr: the performance critical parts, maybe yes, that'll also help for other platforms
< gmaxwell> Littering, probably not, but there might be a couple places where they make sense... but PGO is better from a maintance perspective!
< wumpus> although I've never seen those in c++ code, only c code
< luke-jr> PGO?
< gmaxwell> profile guided optimization.
< wumpus> e.g. MESA is littered with them (but that makes sense, almost everything in GPU drivers is perf critical that's the whole reason they exist)
< gmaxwell> I think for C++ you can't manage to likely tag all the important stuff...
< wumpus> the problem with PGO in our case might be reproducibility
< gmaxwell> luke-jr: -fprofile-generate and then run -fprofile-use.
< wumpus> yes, I also suspect it's more difficult due to more implicit behavior
< luke-jr> does PGO do cross anyway?
< gmaxwell> I believe mozilla has addressed PGO + reproducability.
< gmaxwell> but I'm not sure where that stands, in theory you should just be able to ship the profiles as side information along with the source.
< gmaxwell> in any case, might be worth benchmarking, if just to know even if its too much trouble to use.
< wumpus> right
< gmaxwell> If it gets a big speedup anywhere that might suggest likely() usage and/or refactoring to avoid confusing compiler hurestics.
< gmaxwell> (we do use builtin_expect in secp256k1, but mostly just around error handling code to get it to turn those into distant jumps)
< harding> wumpus: did you get the win32/64 thing for the website sorted out? (Sorry; I thought I tested that for the removal.)
< luke-jr> harding: looks like it
< harding> luke-jr: cool. Thanks for noticing it was broken.
< gmaxwell> achow101: awake? time for a new bitcoin release thread on bitcointalk
< gmaxwell> achow101: you snooze you loose, https://bitcointalk.org/index.php?topic=5138532.0
< luke-jr> lol
< wumpus> harding: I think so, made a minimal change to fix the broken link, suggested by luke-jr
< harding> wumpus: thanks! Sorry I missed that in the release PR.
< wumpus> no problem
< Lauda> IsBerkeleyBtree: The system cannot find the file specified D:\Disk 1\Bitcoin\blocks\wallet.dat
< Lauda> is this intended in 18?
< Lauda> Seems to go through all folders looking for wallet.dat
< luke-jr> Lauda: that looks weird
< luke-jr> maybe trying to build the wallet list?
< Lauda> follow up is remaining folders
< Lauda> well it sounds weird 'find the file specified'
< Lauda> I didn't specify anything
< wumpus> bitcoin_test is really noisy on 0.18.0 RISC-V "Error: Specified -walletdir "/tmp/test_bitcoin/1556792182_943311758/tempdir/path_does_not_exist" does not exist" a zillion times, but the tests pass OK so I suppose these are expected errors
< luke-jr> also on x86_64 IIRC
< wumpus> on master x86_64 it prints three errors, which is better, but still not ideal
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15939: gitian: Remove Windows 32 bit build (master...1904-GitianWin) https://github.com/bitcoin/bitcoin/pull/15939
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0936f35f65ad...c4560a7dfee9
< bitcoin-git> bitcoin/master 5d35ae3 Luca Venturini: Handle the result of posix_fallocate system call
< bitcoin-git> bitcoin/master c4560a7 MarcoFalke: Merge #15650: Handle the result of posix_fallocate system call
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15650: Handle the result of posix_fallocate system call (master...handle-posix-fallocate) https://github.com/bitcoin/bitcoin/pull/15650
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c4560a7dfee9...c1ba1182eb43
< bitcoin-git> bitcoin/master beb42d7 practicalswift: Silence GCC 7 warning "control reaches end of non-void function" (-Wreturn...
< bitcoin-git> bitcoin/master c1ba118 MarcoFalke: Merge #15938: refactor: Silence "control reaches end of non-void function"...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15938: refactor: Silence "control reaches end of non-void function" (-Wreturn-type) in psbt.cpp (master...psbt-return-type-warning) https://github.com/bitcoin/bitcoin/pull/15938
< bitcoin-git> [bitcoin] laanwj opened pull request #15941: doc: Add historical release notes for 0.18.0 (master...2019_05_historical_release_notes) https://github.com/bitcoin/bitcoin/pull/15941
< bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/2472733a24a9...be92be5644a7
< bitcoin-git> bitcoin/0.18 be92be5 Wladimir J. van der Laan: doc: Clean out release notes post-0.18.0
< achow101> gmaxwell: 7 am is too early for me
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c1ba1182eb43...24dfcf3a56f9
< bitcoin-git> bitcoin/master da9f1ac Wladimir J. van der Laan: doc: Add historical release notes for 0.18.0
< bitcoin-git> bitcoin/master 24dfcf3 Wladimir J. van der Laan: Merge #15941: doc: Add historical release notes for 0.18.0
< bitcoin-git> [bitcoin] laanwj merged pull request #15941: doc: Add historical release notes for 0.18.0 (master...2019_05_historical_release_notes) https://github.com/bitcoin/bitcoin/pull/15941
< hebasto> wumpus: #15940 "for 0.18.0" - typo?
< gribble> https://github.com/bitcoin/bitcoin/issues/15940 | Release schedule for 0.19.0 · Issue #15940 · bitcoin/bitcoin · GitHub
< wumpus> hebasto: yes, thanks, updated
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15942: tests: Use BOOST_CHECK_EQUAL for verbose prints on fail (master...1905-testCryptoEqual) https://github.com/bitcoin/bitcoin/pull/15942
< luke-jr> apparently GCC 8.2 is broken on PPC in other ways too so just reverting to GCC 7
< luke-jr> (has anyone checked that 8.2 isn't broken on other platforms we support?)
< luke-jr> wumpus: ^
< wumpus> no problems with it for risc-v nor x86
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #15942: tests: Use BOOST_CHECK_EQUAL for verbose prints on fail (master...1905-testCryptoEqual) https://github.com/bitcoin/bitcoin/pull/15942
< wumpus> #startmeeting
< lightningbot> Meeting started Thu May 2 19:01:08 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.
< sipa> hi
< luke-jr> hi
< kanzure> hi
< jnewbery> 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 moneyball
< sdaftuar> hi
< achow101> hi
< wumpus> congrats on release 0.18.0 everyone !
< sipa> indeed!
< jamesob> hi
< jonasschnelli> hi
< sdaftuar> \o/
< jtimon> still not sure what I did for this release exactly...but thanks, I guess :)
< wumpus> I've created an issue with the release schedule for 0.19: #15940
< gribble> https://github.com/bitcoin/bitcoin/issues/15940 | Release schedule for 0.19.0 · Issue #15940 · bitcoin/bitcoin · GitHub
< wumpus> any proposed topics? nothing on moneyball's list this week
< instagibbs> \o/
< wumpus> #topic high priority for review
< sipa> i've been busy with some other things, i'll be more active soon
< phantomcircuit> hi
< wumpus> currently on the list: #15427 #15024 #15006 #15141 #15512
< gribble> https://github.com/bitcoin/bitcoin/issues/15427 | Add support for descriptors to utxoupdatepsbt by sipa · Pull Request #15427 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/15024 | Allow specific private keys to be derived from descriptor by meshcollider · Pull Request #15024 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/15006 | Add option to create an encrypted wallet by achow101 · Pull Request #15006 · bitcoin/bitcoin · GitHub
< wumpus> sipa: good to know!
< gribble> https://github.com/bitcoin/bitcoin/issues/15512 | Add ChaCha20 encryption option (XOR) by jonasschnelli · Pull Request #15512 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/15141 | Rewrite DoS interface between validation and net_processing by sdaftuar · Pull Request #15141 · bitcoin/bitcoin · GitHub
< wumpus> anything to add/remove?
< jonasschnelli> If you want progress on the p2p encryption, review the ChaCha20 stuff in #15512 (</ad>)
< gribble> https://github.com/bitcoin/bitcoin/issues/15512 | Add ChaCha20 encryption option (XOR) by jonasschnelli · Pull Request #15512 · bitcoin/bitcoin · GitHub
< wumpus> right!
< sipa> jonasschnelli: will do, promise
< jonasschnelli> thanks
< jamesob> psa: going to be putting up the first of the assumeutxo-related PRs in the next few days; if you're interested and haven't reviewed the general proposal you can do so here: https://github.com/jamesob/assumeutxo-docs/pull/1
< wumpus> jamesob: yes, some context is always useful
< wumpus> any other topics? (or, more to discuss about assumeutxo)
< jamesob> not on my end, though happy to chat about assumeutxo if anyone has questions
< wumpus> okay
< wumpus> a short meeting then, I guess
< jonasschnelli> new record
< jnewbery> short meetings are good meetings
< wumpus> very efficient
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu May 2 19:14:00 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< MarcoFalke> Oh, I missed it
< sipa> MarcoFalke: you didn't miss much :p
< MarcoFalke> heh
< luke-jr> we need to have another meeting for MarcoFalke
< MarcoFalke> can I add #15870?
< gribble> https://github.com/bitcoin/bitcoin/issues/15870 | wallet: Only fail rescan when blocks have actually been pruned by MarcoFalke · Pull Request #15870 · bitcoin/bitcoin · GitHub
< MarcoFalke> to high priority?
< wumpus> MarcoFalke :sure
< MarcoFalke> cool thx
< * MarcoFalke> #end meeting for MarcoFalke
< jtimon> jamesob: reading the proposal, looks very nice
< jamesob> jtimon: cool, thanks!
< phantomcircuit> sipa, the CAddrMan Unserialize method trusts that the nSize parameter isn't corrupted, is there an upper bound for that we could set to prevent an infinite loop on disk corruption?
< sipa> phantomcircuit: the total number of entries is capped by the number and size of the buckets, so yes
< sipa> though we may want to set the limit a small factor higher to permit downgrading if the bucket layout ever changes
< phantomcircuit> sipa, line 423 in addrman.h , so it's the "new" table
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15943: tests: Fail if RPC has been added without tests (master...1905-testFailNoRpcCov) https://github.com/bitcoin/bitcoin/pull/15943
< phantomcircuit> sipa, i guess it mostly doesn't matter cause the stream will probably fault before it loops for too long
< sipa> phantomcircuit: i think there are at most 64*1024 entries in the 'new' table
< sipa> #define ADDRMAN_NEW_BUCKET_COUNT_LOG2 10
< sipa> #define ADDRMAN_BUCKET_SIZE_LOG2 6
< sipa> MarcoFalke: that sha256d64 test failing is scary
< phantomcircuit> sipa, thinking about it more i dont think it really matters cause the stream reads will just throw an exception once it's past the end of the file
< sipa> yes
< sipa> phantomcircuit: i guess the only thing to worry about is if a garbage file can cause us to allocate a ginormous amount of memory immediately
< sipa> but the normal vector serialization functions allocate incrementally to prevent that
< sipa> *deserialization
< phantomcircuit> sipa, and this is just reading integers so it cant be more than 32bits at a time
< MarcoFalke> yeah, indeed scary
< MarcoFalke> So bitcoind is using a different sha than the tests do?
< MarcoFalke> Otherwise, how could it sync
< sipa> MarcoFalke: how many times do you get the "check memcmp(...) == 0 has failed" ?
< MarcoFalke> 32
< sipa> what happens if you add a SHA256AutoDetect() call in the test?
< MarcoFalke> Same
< MarcoFalke> I guess it is already called in BasicTestingSetup()
< sipa> ok, what if you comment out the "if (have_avx2 && have_avx && enabled_avx) {" block in crpyto/sha256.cpp ?
< MarcoFalke> Same with if (true||have_avx2 && have_avx && enabled_avx) {
< sipa> what if you disable it entirely (as in: don't use avx2)
< MarcoFalke> still fails
< sipa> what if you comment out the "TransformD64_4way = sha256d64_sse41::Transform_4way" line and the "TransformD64_8way = sha256d64_avx2::Transform_8way;" line?
< * sipa> is baffled
< MarcoFalke> same
< * MarcoFalke> yes I double checked that I compiled it again
< MarcoFalke> 2019-05-02T21:37:33Z Using the 'standard' SHA256 implementation
< sipa> sense, it makes none.
< luke-jr> NSA disagrees
< sipa> can you add an assert inside the avx2/sse4 implementations to make sure they're not invoked?
< MarcoFalke> I think it calls TransformD64
< MarcoFalke> and Transform
< MarcoFalke> sha256_sse4::Transform and Transform_8way have an assert(false)
< sipa> what if you set TransformD64 to TransformD64Wrapper<sha256::Transform> (and make SHA256AutoDetect a no-op)?
< sipa> in the initializer
< MarcoFalke> still fails
< luke-jr> MarcoFalke: what GCC version?
< MarcoFalke> $ gcc --version === gcc (GCC) 9.0.1 20190312 (Red Hat 9.0.1-0.10)
< luke-jr> hrm, I'd guess probably not the issue, but it might indicate GCC has been playing with memory stuff? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273
< luke-jr> might be worth recompiling with GCC 7 just to see if it's compiler-dependent
< MarcoFalke> Someone else reported it with fedora 29, which has gcc8?
< MarcoFalke> But I will try with clang
< MarcoFalke> Might take a while since 32 bit only gives me 2gb of ram
< sipa> MarcoFalke: does compiling with ubsan or asan give any interesting results
< sipa> ?
< MarcoFalke> rip ram
< MarcoFalke> will have results in an hour earliest
< luke-jr> MarcoFalke: since this is a not-very-likely cause, I'd suggest continuing to troubleshoot with sipa while it builds
< luke-jr> although I guess rebuilding with sanitizers are going to take just as long :x
< luke-jr> I would be surprised if asan supported x86_32 since it requires so much virtual memory space
< MarcoFalke> So just to confirm this should be the call stack?
< MarcoFalke> SHA256D64 calls Transform?
< sipa> yeah, that looks right
< sipa> it calls TransformD64, which is a function pointer to a wrapper function that invokes Transform
< MarcoFalke> ok, building on clang with sanitizers = address,undefined
< phantomcircuit> so apparently GetTimeMillis() can throw an exception, which isn't handled like anywhere
< sipa> phantomcircuit: define 'can'
< phantomcircuit> actually it can't nvm
< phantomcircuit> sorry
< phantomcircuit> boost::gregorian::date can but not with the constants we use
< MarcoFalke> So it passes with clang and address sanitizer
< MarcoFalke> !?
< gribble> (misc help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
< sipa> MarcoFalke: gcc 9 bug?
< * MarcoFalke> off
< MarcoFalke> Maybe.
< MarcoFalke> Could also be 8
< MarcoFalke> Will update the issue tomorrow
< luke-jr> hopefully not 8, as we just shipped built with 8 :x
< MarcoFalke> luke-jr: The issue is there since 0.17.1
< MarcoFalke> So yes, likely also gcc 8
< luke-jr> :|
< booyah> on limited memory maybe just run in valgrind, if you have memory problems? (though always few false positives)
< sipa> MarcoFalke: i can reproduce
< * luke-jr> looks forward to the day he can do these gitian builds on ppc64