< bitcoin-git>
bitcoin/master a2be3b6 Jim Posen: [net] Ignore getheaders requests for very old side blocks...
< bitcoin-git>
bitcoin/master eff4bd8 Jim Posen: [test] P2P functional test for certain fingerprinting protections
< bitcoin-git>
bitcoin/master fef65c4 Wladimir J. van der Laan: Merge #11113: [net] Ignore getheaders requests for very old side blocks...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11113: [net] Ignore getheaders requests for very old side blocks (master...net-getheaders-fingerprint) https://github.com/bitcoin/bitcoin/pull/11113
< meshcollider>
wumpus: yes indeed, I'm just wondering whether there is any point in adding a list of `available` wallets inside the walletdir to the `listwallets` RPC
< promag>
wumpus what is the real use case for that?
< wumpus>
promag: for listing available wallets? would be nice in the GUI at least
< wumpus>
otherwise peopel have to remember the names
< wumpus>
which is okay for the first version or whatever, but in the long run would be nice to select from a list instead
< wumpus>
there's no urgency in having it though
< promag>
But the app is configured with the wallets, and there is no way to create wallets
< meshcollider>
because the only clean-ish way I can think of to find wallets in the walletdir is looking for .dat extensions right?
< meshcollider>
promag dynamic loading/unloading of wallets will be coming soon right?
< wumpus>
check for berkeleydb databases
< wumpus>
(requiring .dat naming is fine with me too, but not all .dats are bdb databases unfortuantely)
< promag>
I feel that's not the right path
< promag>
not all berkeleydb files are wallets
< wumpus>
in the wallet directory they can be assumed to be
< wumpus>
but if you want to add an additional check on loading, fine
< wumpus>
there's some keys that are only in wallets...
< wumpus>
(like the wallet version)
< wumpus>
I'm more afraid of users copying valid wallets from other forks though :(
< wumpus>
so if we want to add more robustness to wallet loading, yeah, we'd have to consider that...
< promag>
I would open the wallet, keep it open, but not load the transactions
< wumpus>
I mean I *don't* think we need listing available wallets yet
< promag>
listwallets change in a different PR will make your PR faster to review and merge meshcollider
< wumpus>
we need to enforce some naming convention on wallets in that case (we don't even require .dat at the moment) as well as make sure wallets are somehow tagged as bitcoin wallet
< wumpus>
e.g. by having a key in them that identifies them as being such
< promag>
*.wlt :troll:
< meshcollider>
Yep its more complicated than i initially thought, seperating it out now
< wumpus>
promag: if you want to go that way it's better to go full out and use .bitcoinwallet - to rule out overlap with forks etc
< wumpus>
and altcoins
< wumpus>
this is a discussion topic when the wallet format is changed
< promag>
I was kidding :P but maybe .bitcoin-core-wallet
< wumpus>
from berkeleydb to something custom, for example
< wumpus>
we certainly don't want to stick with .dat then
< promag>
well, I think a good implementation will open the whatever-file-is and use/validate the content
< wumpus>
I'm all for being more robust when actually opening wallets
< wumpus>
but when scanning for available wallets please don't get bdb involved
< wumpus>
if you need to look at magics etc, a quick read-only scan should be enough
< promag>
listing an available but invalid wallet is stupid?
< wumpus>
but rare!
< promag>
ok then
< wumpus>
opening with berkeleydb is heavy
< promag>
why? does it load everything?
< wumpus>
also involves potential writing, you don't want the program to write to files it's not told to touch
< wumpus>
yes
< wumpus>
it does various things
< promag>
ok, I rest
< meshcollider>
hah i dont think i can checkout a new branch while building the current one
< meshcollider>
ill have to use my tablet instead
< wumpus>
meshcollider: you can use git worktrees
< wumpus>
and check out different branches in different directories
< meshcollider>
ooh really? That's cool, I've never even heard of that being possible before
< meshcollider>
I'll look it up
< wumpus>
it's awesome, especially with large projects like linux where you really don't want to have multiple full clones
< meshcollider>
Yeah :D
< promag>
yes, thank god sipa introduced that to me a couple of months ago
< promag>
wumpus: easy one #10941, just improves test suite
< wumpus>
it also helps for some things to do out-of-tree builds, though mostly to keep you git tree clean, and be able to build for different architectures from one source tree - it doesn't allow you to switch the branch while building
< promag_>
wumpus: regarding the eye icon, are there designers contributing? or are the used icons open source?
< wumpus>
what's wrong with the eye icon we alread have?
< wumpus>
(I edited th4e post)
< promag_>
oh there is an eye icon already
< wumpus>
if you want a new icon you'd have to find an icon that has the correct license (ideally MIT or public design) or an artist that wants to create such an icon under the appropriate license
< wumpus>
jonasschnelli designed most of the current ones
< Chris_Stewart_5>
I'm generating various standard tx types (p2pk,p2pkh,multisig) etc and then running them through the interpreter to assert our interpreter/wallet code base are consistent
< Chris_Stewart_5>
When I'm generating a std::vector<CKey> this bug appears, but does not appear when I generate a single CKey
< Chris_Stewart_5>
arubi: Thanks by the way
< arubi>
oh cheers
< wumpus>
right, next step would be to figure out why it returns the zero key. I'm happy secp256k1 catches this at least.
< Chris_Stewart_5>
wumpus: Agreed! It is weird because if I try to explicitly call .MakeNewKey(true) (again) before I convert it to a pubkey secp256k1 gives this error
< wumpus>
yes I was still in the process of trying to convert that key to raw bytes - a google would have been faster in this case :)
< Chris_Stewart_5>
do you see something inherently wrong with it?
< jnewbery>
meshcollider: sorry - missed the discussion earlier. I think updating listwallets to list available wallets would definitely be a useful feature, but it's by no means necessary for #11466.
< Chris_Stewart_5>
wumpus: For what it is worth it is unrelated to anyting in core. I wasn't capturing a variable correctly in a lambda
< promag>
Right, I just think there is no strong use case for that
< promag>
I kind of like findwallets because it can return "invalid" wallets where as listwallets is returning valid and loaded wallets
< promag>
at the moment listwallet can return available "invalid" wallet that cannot be loaded
< promag>
btw, do you think we should have the inverse of -experimentalrpc=?
< promag>
so 0.15 introduced listwallets but to use it it should be enabled like so
< promag>
sorry, **the inverse of -deprecaterpc**
< promag>
therefore all experimental rpc can change
< jnewbery>
The use case is being able to find and load wallets dynamically at run-time. If you have any concept feedback on that, the PR is 10740
< jnewbery>
re: -experimentalrpc - I don't think that's necessary. Release notes for multiwallet stated 'Note that while multi-wallet is now fully supported, the RPC multi-wallet interface should be considered unstable for version 0.15.0, and there may backwards-incompatible changes in future versions.
< promag>
ok and ok
< promag>
wumpus: you deleted the comment in #11476?
< bitcoin-git>
bitcoin/master 619bb05 MarcoFalke: Squashed 'src/univalue/' changes from 16a1f7f6e..fe805ea74...
< bitcoin-git>
bitcoin/master faaeeb0 MarcoFalke: Bump univalue and fix json formatting in tests...
< bitcoin-git>
bitcoin/master 8928093 Wladimir J. van der Laan: Merge #11420: Bump univalue subtree and fix json formatting in tests...
< wumpus>
if you get any linker errors while building master, you probably need to clean your tree after #11420 (it seems that some changes to univalue are not detected by the build system)
< Chris_Stewart_5>
I'll dig more -- it is probably something stupid I am doing else where. I just wanted to confirm produce signature has the capability before I go deeper
< morcos>
I'm just trying to catch up on old review by looking at what was merged.. In #11113 , what is the use case of responding to these strange getheaders requests with no locator at all? Or at the very least shouldn't we only respond if the hashStop is on our main chain
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #11487: Check that new headers are not a descendant of an invalid block (master...2017-10-acceptblock-validity-check) https://github.com/bitcoin/bitcoin/pull/11487
< bitcoin-git>
[bitcoin] C0deAi opened pull request #11488: Codeai fixes: remove dead code, prevent possible division by zero. (master...codeai-fixes) https://github.com/bitcoin/bitcoin/pull/11488