< wumpus> luke-jr: AFAIK, transactions have always been decomposed differently for different purposes. My idea re: having the GUI doing its own transaction decomposition is to keep GUI specific logic out of core code. Of course, if they end up becoming the same then it's no longer necessary to have its own.
< promag> requesting reviews in #15149 #15101 #15153 #15150
< gribble> https://github.com/bitcoin/bitcoin/issues/15149 | gui: Show current wallet name in window title by promag · Pull Request #15149 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/15101 | gui: Add WalletController by promag · Pull Request #15101 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/15153 | gui: Add Open Wallet menu by promag · Pull Request #15153 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/15150 | gui: Show wallet selector on console window if there are wallets loaded by promag · Pull Request #15150 · bitcoin/bitcoin · GitHub
< luke-jr> Running tests: random_tests from test/random_tests.cpp
< luke-jr> test/test_bitcoin -l test_suite -t "`cat test/random_tests.cpp | grep -E "(BOOST_FIXTURE_TEST_SUITE\\(|BOOST_AUTO_TEST_SUITE\\()" | cut -d '(' -f 2 | cut -d ',' -f 1 | cut -d ')' -f 1`" > test/random_tests.cpp.log 2>&1 || (cat test/random_tests.cpp.log && false)
< luke-jr> Test setup error: no test cases matching filter or all test cases were disabled
< luke-jr> any ideas? :/
< sipa> luke-jr: does random_tests.cpp define a suite called random_tests, that has at least one test case in it?
< wumpus> luke-jr: how do you get that? 'make check' on master runs the random_tests succesfully here
< promag> +1 wumpus
< promag> luke-jr: all good with test/test_bitcoin -l test_suite -t "random_tests"
< CODER82> Hi guys, at the moment virus total shows some red entries:
< CODER82> do you think those are false positives?
< CODER82> The signature is correct, looks like
< CODER82> fa1e80c5e4ecc705549a8061e5e7e0aa6b2d26967f99681b5989d9bd938d8467 bitcoin-0.17.1-win64-setup.exe
< CODER82> any clue?
< gmaxwell> if the signature is correct, you're good to go, unfortunately people maliciously submit bitcoin core as viruses to av companies and they don't give a crap about giving accurate results...
< CODER82> I see
< CODER82> I will try to get in contact with the community and see if they can help countering this
< CODER82> I've seen a few devs turned down
< CODER82> it's all false
< wumpus> virus scanners are total crap nowadays
< TokenHash> "money is a social system, therefore it's ok to integrate social management tools in Bitcoin such as 'invalidateblock' and others" is a fallacy.
< TokenHash> 1. whether money is a "social system" in the first place is at minimum a personal opinion, at maximum unsound thinking
< Isthmus> We got McAfee to fix a crypto-related virus false positive, just by askig nicely.
< Isthmus> Haven't interacted with the other antivirus companies though.
< TokenHash> 2. whether money is a social system or not, does not mean that a strictly objective system, with the goal of being as secure as possible by trust minimizing it must be contaminated with social tools integrated at the procol layer
< TokenHash> If that were the case, heck! let's integrate all the social tools! -> 'invalidateblock' 'preciousblock' 'revertchain' 'changestate' 'entervote' 'automaticupgrade' 'oldversiondeactivate' 'KYCmode' 'freezefundsdotgov' 'activatesurvaillancensa' 'blacklistactivate' 'monetarysupplychange'
< benthecarman_> Just because I use 'invalidateblock' on my own node doesn
< benthecarman_> doesn't mean the rest of the network will
< TokenHash> the coordination problem is a true safety model, but to integrate the tools just puts us closer to abuse, imo
< sipa> this discussion seems very offtopic
< benthecarman_> ^
< Isthmus> Good point.
< TokenHash> ok, leaving, I saw this topic here in the first place, but goodbye
< luke-jr> wumpus: sipa: ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/libbitcoinconsensus-0.17.1 --htmldir=/usr/share/doc/libbitcoinconsensus-0.17.1/html --libdir=/usr/lib64 --enable-asm --without-qtdbus --without-qrencode --
< luke-jr> without-miniupnpc --enable-tests --disable-wallet --disable-zmq --with-libs --disable-util-cli --disable-util-tx --disable-bench --with-daemon --without-gui --disable-ccache --disable-static --with-system-univalue
< CODER82> How do you make a payment with zero confirmation based on peer nodes relaying the transaction? Can it be done with RPC calls?
< CODER82> How do you make a payment with zero confirmation based on peer nodes relaying the transaction? Can it be done all with RPC calls?
< luke-jr> CODER82: your question doesn't really make sense, and in any case belongs in #bitcoin
< CODER82> ok