< bitcoin-git>
[bitcoin] jtimon opened pull request #10859: RPC: gettxout: Slightly improve doc and tests (master...b15-rpc-gettxout-mempool) https://github.com/bitcoin/bitcoin/pull/10859
< Guest38971>
lets say I wanted my node to support bip148. What do I need to configure in order to allow this? I am currently running bitcoin core 0.14.2 am I just ammending a line of code into the config file? I just need a reference if possible or is it advised to just wait for a release from bitcoin core?. I do not know if this is the proper channel for this so I apologize in advance. Thank you very much for the help.
< sipa>
Bitcoin Core at this point does not support BIP148
< sipa>
There are forks of the codebase that do.
< Guest38971>
Understood my question was hypethical. My main concern is if I am running my node how can I test BIP148 suppost. I found a link that allows me to download bitcoin core with BIP148 support, but I did not know if this was trustworthy. Thank you
< sipa>
wumpus: how about a --sha256= option, which now defaults to basic, but can be changed to auto or a specific implementatio
< sipa>
?
< wumpus>
sipa: if you want to go that way, it needs to be future-proof to be able to add more sha algorithms in the future and select multiple, I guess
< wumpus>
that's why I proposed a a generic 'experimental assembly' flag, which is not so specific
< wumpus>
but sure, that makes sense
< cfields>
sipa: i think that's good to have either way. If nothing else, it makes benchmarking/comparing easier.
< sipa>
cfields: agree
< gmaxwell>
more complex is genreally less good because it's costly to test all the options. --enable-expiremental-asm is also what we did in libsecp (and FWIW! how arm still is!)
< sipa>
gmaxwell: there are other advantages... like being able to run the tests and benchmarks on different hash function impls even if it's not the best available on your platform
< wumpus>
that doesn't need a compile time option
< wumpus>
e.g. bench could just cycle through all available sha algorithms
< sipa>
agree, like your branch did
< wumpus>
or some run-time override, if you want to do the other tests / a chain sync with it
< wumpus>
but maybe that's overkill to add an option for such a rare scenario
< wumpus>
but at least the tests should test all the possibilities (that run on the platform) I guess
< sipa>
wumpus: by --sha256 i meant a runtime option
< wumpus>
for basic sanity testing, not for running all tests
< bitcoin-git>
[bitcoin] corebob opened pull request #10863: Fix leaking a socket handle if call to SetSocketNonBlocking failed (master...20170718-fix-leak-1) https://github.com/bitcoin/bitcoin/pull/10863
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10864: Avoid redundant redeclaration of GetWarnings(const string&) (master...GetWarnings-in-warnings.h) https://github.com/bitcoin/bitcoin/pull/10864
< bitcoin-git>
[bitcoin] corebob closed pull request #10863: Fix leaking a socket handle if call to SetSocketNonBlocking failed (master...20170718-fix-leak-1) https://github.com/bitcoin/bitcoin/pull/10863
< bitcoin-git>
[bitcoin] corebob opened pull request #10865: Move CloseSocket out of SetSocketNonBlocking in netbase.cpp (master...20170718-refactor-1) https://github.com/bitcoin/bitcoin/pull/10865
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10866: Add mutex requirement for AddToCompactExtraTransactions(…) (master...lock-requirement-for-AddToCompactExtraTransactions) https://github.com/bitcoin/bitcoin/pull/10866
< wumpus>
I think the rest tagged for 0.15 qualifies as bug-fix, not feature
< wumpus>
BlueMatt: #10784 needs rebase btw
< gribble>
https://github.com/bitcoin/bitcoin/issues/10784 | Do not allow users to get keys from keypool without reserving them by TheBlueMatt · Pull Request #10784 · bitcoin/bitcoin · GitHub
< BlueMatt>
wumpus: concept ack on 10571, I'm happy to see it merged now and I'll postumously ack it later today
< wumpus>
just found a bug in 10571
< BlueMatt>
heh, ok, nevermind, then
< BlueMatt>
no harm in pushing to 16 imo, no?
< wumpus>
a very minor one though just an error message
< BlueMatt>
up to you, we have a few weeks bugfix window anyway
< wumpus>
well it would be a waste with so many utacks, this is a trivial fix, will wait for achow101
< wumpus>
#10784 does need mention in release notes I guess
< gribble>
https://github.com/bitcoin/bitcoin/issues/10784 | Do not allow users to get keys from keypool without reserving them by TheBlueMatt · Pull Request #10784 · bitcoin/bitcoin · GitHub
< BlueMatt>
indeed
< * wumpus>
wishes people would do that immediately instead of leaving it until the end
< bitcoin-git>
bitcoin/master cf82a9e Matt Corallo: Do not allow users to get keys from keypool without reserving them...
< bitcoin-git>
bitcoin/master 9e8d6a3 Wladimir J. van der Laan: Merge #10784: Do not allow users to get keys from keypool without reserving them...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10784: Do not allow users to get keys from keypool without reserving them (master...2017-07-keep-change) https://github.com/bitcoin/bitcoin/pull/10784
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #10867: Allow only a single -usewallet argument (master...2017/07/multiwallet_bitcoincli) https://github.com/bitcoin/bitcoin/pull/10867
< jonasschnelli>
Hmm... isn't the whole wallet endpoint URI encoding really required if we only allow "CHARS_ALPHA_NUM + ".-_"" for wallet filenames?!
< jonasschnelli>
I guess it's not. Ping ryanofsky
< cfields>
jonasschnelli: i wondered about that as well. I tried (unsuccessfully) to get wallets containing sneaky characters to load, and it failed as expected (though sometimes with a segfault that needs to be fixed). I fail to see why it's necessary
< cfields>
jonasschnelli: i assumed it was for more robust usage in the future
< jonasschnelli>
cfields: yes. That makes sense.
< cfields>
jonasschnelli: well that theory is based on absolutely nothing :)
< jonasschnelli>
Indeed
< ryanofsky>
url encoding was suggested when there were still wallet ids. if you want to check for CHARS_ALPHA_NUM in bitcoin-cli instead of percent encoding, that seems fine, though a little more fragile (because maybe we will allow another class of characters in bitcoind and bitcoin-cli will break)
< sipa>
i'd rather leave it this way
< morcos>
wumpus: #10817 is not really a bug fix, but its ready for merge and adds a couple strings
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #10870: [Qt] Use wallet 0 in rpc console if running with multiple wallets (master...2017/07/qt_mw) https://github.com/bitcoin/bitcoin/pull/10870
< jtimon>
perhaps you can help. communication is hard
< goatpig>
jtimon: you to provide the outpoint with the address?
< goatpig>
want*
< jtimon>
it seems I missunderstood this comment "The checksum should not contain any salted data. Otherwise with 30bits of non-cryptographic checksum one can easily calculate a TxID that is valid for more than one Network"
< jtimon>
he means that since it's only 30 bits of checksum, with 2^15 tries you can create a collision that is valid for more than 1 network.
< bitcoin-git>
[bitcoin] achow101 opened pull request #10871: Handle getinfo in bitcoin-cli w/ -getinfo (revival of #8843) (master...cli-getinfo) https://github.com/bitcoin/bitcoin/pull/10871
< bitcoin-git>
[bitcoin] eklitzke opened pull request #10872: Docs: Syntax highlight shell commands in the building notes (master...hilite) https://github.com/bitcoin/bitcoin/pull/10872
< bitcoin-git>
[bitcoin] eklitzke opened pull request #10873: Use a condition variable for shutdown notifications (master...shutdown_notify) https://github.com/bitcoin/bitcoin/pull/10873