< luke-jr>
meshcollider: it should probably be fixed
< bitcoin-git>
[bitcoin] practicalswift opened pull request #12782: Explicitly state our assumptions about LookupBlockIndex(...) return values (master...LookupBlockIndex-assumptions) https://github.com/bitcoin/bitcoin/pull/12782
< meshcollider>
luke-jr: I'm not quite sure what "fixed" means in this case though, because the interaction between locktime and the sequence numbers when mutating a transaction might not be clear
< meshcollider>
luke-jr: for example, I'm not sure that setting a locktime in the transaction should modify the sequence numbers itself, if a user is using bitcoin-tx they probably want to modify the transaction themselves rather than it doing stuff in the background
< luke-jr>
meshcollider: at the very least it should fail if you try to set it when it's ignored
< emad>
i'm looking for a working api for ethereum transaction
< CubicEarths>
emad: This is the Bitcoin development channel
< Dmitrii__>
hi friends, can some one help me with installing Bitcore Node? I have some problems with p2p module...
< sipa>
Dmitrii__: this channel is about bitcoin core, not bitcore
< Dmitrii__>
sipa: i know, but i cant find any bitcore community... can you help me find it then? :)))
< kallewoof>
Huh... trying to build windows version of bitcoin with --enable-gprof --enable-debug. It fails to compile, with `Fatal error: can't write 86 bytes to section .text of wallet/libbitcoin_wallet_a-wallet.o because: 'File too big'`. That doesn't sound too good. (Without both, it compiles though.)
< kallewoof>
Actually --enable-debug is the problem. -gprof appears to work fine. Guess that's to be expected for a cross compile...
< kallewoof>
Hum. Running test_bitcoin.exe through wine takes <2m. I wonder if the 30+ mins are in the other tests (secp256k1 / univalue)...
< kallewoof>
(^ is with --enable-gprof, too)
< Randolf>
Dmitrii__: I suspect that you're looking for the Bitcoin community: /join #bitcoin
< Dmitrii__>
Randolf: thx
< wumpus>
kallewoof: which gcc version?
< wumpus>
kallewoof: shouldn't have anything to do with cross compiling, some versions of mingw-w64 produce corrupted executables under some conditions
< wumpus>
ok, you might want to try with a different one
< kallewoof>
I'm trying to reproduce the super long runtime for make check in travis, so I'll see if I can get the one travis is using. Thanks for the hint.
< wumpus>
or even with clang - their windows support is improving every release
< kallewoof>
Nice, okay.
< wumpus>
it isn't simply the secp2565k1 exhaustive tests taking a long time?
< kallewoof>
wumpus: They take < 1 min on my machine (through wine), with --enable-gprof on.
< kallewoof>
21.8s for tests.exe and 1.1s for exhaustive_tests.exe (that sounds really fast, btw. maybe it's skipping stuff)
< wumpus>
hmm okay
< kallewoof>
Actually travis has 2 windows jobs, and it's the Win32 one that is failing. I'm gonna try that one.
< wumpus>
if it is test_bitcoin, try enabling the verbose output flag
< wumpus>
it logs time taken per test and test suite
< kallewoof>
Ah ok
< kallewoof>
s/failing/taking more than 30 mins for make check/
< wumpus>
right - makes sense to do that on the environment (travis) where the problem happens, not locally, if you can't reproduce the problem there. It's very possible that it's a problem with trusty's mingw-w64 which is ancient by now :/
< wumpus>
but some of the tests do take a long time
< bitcoin-git>
[bitcoin] practicalswift opened pull request #12784: Fix error in memory usage calculation (unintended integer division) (master...calc-error) https://github.com/bitcoin/bitcoin/pull/12784
< kallewoof>
wumpus: I wonder how hard it would be to do a gprof-enabled travis run by just pushing a PR with the yml file updated. Seems straightforward.
< kallewoof>
wumpus: Gotcha on the mingw. If it seems that's a problem maybe we can use a newer version somehow..
< wumpus>
I think we should switch gitian building to 18.04 for 0.17 (https://github.com/bitcoin/bitcoin/issues/12511), would be nice to do the same for travis, but I'm not sure that's possible
< wumpus>
are you sure you need gprof if test_bitcoin can do timings itself?
< kallewoof>
wumpus: I wanted to use it to time stuff, but ultimately it's all been running in < 10 mins so no need so far. And probably no need if the problem is in test_bitcoin
< kallewoof>
wumpus: I am crashing on QT tests though, for some reason. Perhaps because I'm running over an ssh connection with no X forwarding.
< kallewoof>
wumpus: Also not sure how travis fixes 'wine prefix for executables'. I had to edit build-aux/test-driver and manually add 'wine' before "$@" line...
< wumpus>
there's something with linux kernel executable format support that automatically redirects executing .exe's to wine
< kallewoof>
ohh ok
< wumpus>
I dn't know how that is configured, though, I remember it being the default with some ubuntu if wine is installed
< kallewoof>
wumpus: Can't imagine it makes a difference but I'll see if I can find it if I don't see the long runtime.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #12785: wallet: Set m_last_block_processed to nullptr in CWallet::SetNull() (master...m_last_block_processed-setnull) https://github.com/bitcoin/bitcoin/pull/12785
< bitcoin-git>
[bitcoin] practicalswift opened pull request #12787: rpc: Adjust ifdef to avoid unreachable code (master...unreachable-code-ifdef-ENABLE_WALLET) https://github.com/bitcoin/bitcoin/pull/12787
< bitcoin-git>
[bitcoin] kallewoof opened pull request #12788: [build] Tune wildcards for LIBSECP256K1 target (master...build-tune-libsecp256k1-wildcards) https://github.com/bitcoin/bitcoin/pull/12788
< bitcoin-git>
[bitcoin] practicalswift opened pull request #12789: Don't return a CExtPubKey filled with junk when DecodeExt{Pub,}Key is given input not passing DecodeBase58Check(...) (master...CExtKey-junk) https://github.com/bitcoin/bitcoin/pull/12789
< provoostenator>
That one along with a way to turn pruning on in the GUI, preferably at first launch, would make me more excited about 0.17 :-)
< stepa[m]>
Just read the bitcoin whitepaper, and it is so clear and concise! What are the major changes that happened since the paper was written? I believe the Merkle Tree as described is not used anymore in lieu of a Fast Merkle Tree? Are there any other major differences that make the whitepaper outdated?
< stepa[m]>
Also, is transaction pruning implemented in the full node core client by default?
< provoostenator>
stepa[m]: this is more suited for #bitcoin or bitcoin.stackexchange.com
< provoostenator>
As for your second question: pruning is not on by default.
< AndyS2>
stepa[m]: the paper just explains a few basic concepts (important ones), but the code has always done a lot more. Pruning is only an option for a few participants, because you actually need some people to have the whole blockchain to give it to pruning nodes (who can then later delete it after verifying those blocks)
< stepa[m]>
Thanks! Sorry for off-topic
< AndyS2>
Because the paper describes just a few basic things, most of what it actually talks about remained the same. but for example, the (2. transactions) part isn't entirely accurate anymore since we mostly use public key hashes as addresses nowadays, so we (often) don't include the public key of the receiver into our transaction anymore
< AndyS2>
I haven't been around very long and I'm not a dev, though, so what has been around how long is hard to know for me with certainty, stepa[m]
< stepa[m]>
Ah, interesting!
< AndyS2>
I can recommend "Mastering Bitcoin", it's freely available online or as a book. It was written in 2017, though, but it does tell you about a few things that were added later on
< AndyS2>
maybe someone can chime in on when bitcoin was changed away from IP-Addresses and other weird things to what we mostly use nowadays. I remember reading something about that a long time ago
< instagibbs>
AndyS2, this is #bitcoin talk, please move it there
< bitcoin-git>
[bitcoin] instagibbs opened pull request #12795: do not truncate .dat extension for wallets in gui (master...nowalletprune) https://github.com/bitcoin/bitcoin/pull/12795
< jnewbery>
wumpus: is contrib/testgen/gen_base58_testvectors.py still used? I can't see where the output files base58_keys_valid.json are used anywhere
< jnewbery>
ah, they were renamed in 92f1f8b3197c2ba3cf65556070509838098975a4 . Question remains: is gen_base58_testvectors.py required?
< wumpus>
I can't find any gen_base58_testvectors.py, is it supposed to be in the main repo?
< wumpus>
it was used to generate the json file for the tests, I think it's useful in case the format needs to change for some reason, or tests are to be added/removed
< wumpus>
in that regard it's similar to the generation for the script and transaction tests
< wumpus>
to be able to regenerate if e.g. if a new kind of base58-encoded data is added, the version byte is changed, etc
< wumpus>
it doesn't hurt to keep it around
< jnewbery>
ok, it's python2 only. I was going to include it in #11881, but it doesn't seem worth updating
< wumpus>
right, if you don't feel like updating it, then don't
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #12797: init: Fix help message for checkblockindex (master...Mf1803-initHelpCheckBlockIndex) https://github.com/bitcoin/bitcoin/pull/12797
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #12798: doc: Refer to witness reserved value as spec. in the BIP (master...Mf1803-docWitnessReservedValue) https://github.com/bitcoin/bitcoin/pull/12798