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