< pierre_rochard>
Does each wallet in vpwallets have a unique identifier?
< kallewoof>
I had no idea nodes randomly rebroadcasted other people's transactions. Double spending is the only solution then. (Another case for RBF default on)
< sipa>
kallewoof: some sites do
< sipa>
though in general, nodes don't
< sipa>
there is nothing to prevent them to, though
< sipa>
and i think we'd be better off if there was some mempool synchronization that levelled the field
< kallewoof>
Just see no reason for them to do it.
< kallewoof>
Mempool synchronization? Like what?
< phantomcircuit>
sipa, there are nodes that rebroadcast transactions seemingly on a timer
< gmaxwell>
kallewoof: bitcoin core doesn't rebroadcast third party txn, but random bozos do, because they think they're helping in some cases, or because they want to pump up mempool stats. or god knows why
< phantomcircuit>
either way, transactions do not expire
< kallewoof>
gmaxwell: Ohh, okay. Thanks! (I should be on bitcointalk more often I guess)
< phantomcircuit>
kallewoof, i'd generally advise against that unless you filter for pre 2014
< kallewoof>
phantomcircuit: I very rarely visit it, but it seems like it has a lot of in-depth discussion.
< meshcollider>
kallewoof: so much rubbish too though unfortunately
< kallewoof>
meshcollider: That's unfortunate.
< sipa>
kallewoof: i think i stopped frequenting bitcointalk in 2012 maybe
< sipa>
or 2013
< gmaxwell>
it's no worse than the mailing list now.
< gmaxwell>
actually, I think it's better. There are a lot of dull and repetative posts on both, but BCT more promptly gets replies directing people to the last 20 times the material was discussed.
< kallewoof>
Heh
< Provoostenator>
sipa: so both the minimum fee required to get in the mempool and to bump transactions are both set by minrelayfee, but because there's also an MB limit to the mempool per node, that determines the effective minimum for the former?
< sipa>
Provoostenator: run getmempoolinfo
< sipa>
if your mempool is full, it will report a nonzero minrelayfee
< sipa>
any time a transaction is kicked out of the mempool, the new relay fee is raised to the fee of what was kicked out
< sipa>
and then it decays slowly back to 0
< Provoostenator>
Ok, so it's more than an emergent property from the fact that low fees are kicked out.
< sipa>
the goal is to have it carefully actually track the lowest acceptable feerate for your mempool
< sipa>
which doesn't work if the mempool is always empty ;)
< Provoostenator>
If people change their mempool size to something not standard, doesn't that create a fingerprinting opportunity?
< sipa>
yup
< sipa>
nodes even communicate their approximate minimum feerate to each other
< Provoostenator>
sipa: I'm doing a fresh make clean and make now to see if I can reproduce the test error. I did that yesterday as well, but I wonder how reproducable it is.
< sipa>
Provoostenator: also wipe your test cache
< sipa>
(test/cache directory)
< Provoostenator>
Ah, why doesn't make clean do that?
< sipa>
because make clean removes the results of make
< sipa>
the test cache isn't produced by make
< Provoostenator>
make nuke?
< sipa>
PR's welcome :p
< Provoostenator>
I can try. Do have an objection to make clean doing this? Or should it be another command? I can't see why anyone would possibly want to keep the test cache around after running make clean.
< sipa>
cfields: opinions? ^
< sipa>
Provoostenator: did removing the cache help?
< sipa>
if that's the case, that's unexpected on its own
< Provoostenator>
sipa: my machine is not that fast; I'll tell you in 15 minutes or so :-)
< Provoostenator>
But I'd that's safe to assume.
< Provoostenator>
Oh ok, so the cache is supposed to be wiped? I'll see ifI can break that.
< Provoostenator>
I wish Github emails would should show the comment someone replied to, so it's easier to tell what "fixed" refers to. I'll stalk them.
< sipa>
no, wiping the cache _should not_ matter for this
< sipa>
i'm just saying that before jumping to conclusions, you should try to reproduce with an empty cache
< Provoostenator>
That's what I meant. I'll try if wiping helps, but it shouldn't. Make is running as we speak.
< sipa>
install ccache
< Provoostenator>
(I've learned not to assume stuff :-)
< sipa>
no need to recompile from scratch every time you switch branches
< Provoostenator>
Generally I don't recompile everything. In this case I just wanted to make sure everything was clean and it wasn't some build problem.
< Provoostenator>
I'll try ccache
< sipa>
if ccache is installed, configure will automatically detect and use it
< Provoostenator>
Any good tools that can leverage other machines (e.g. EC2 nodes) to speed op compilation?
< sipa>
distcc i guess, but i never really looked into that
< sipa>
it's fast enough on an octacore machine :)
< bitcoin-git>
bitcoin/master 07c4838 Matt Corallo: Always return true if AppInitMain got to the end...
< bitcoin-git>
bitcoin/master d48ab83 Wladimir J. van der Laan: Merge #11831: Always return true if AppInitMain got to the end...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11831: Always return true if AppInitMain got to the end (master...2017-12-startup-exit-return-code-race) https://github.com/bitcoin/bitcoin/pull/11831
< Provoostenator>
p2p_full_blocktests failing on me with AssertionError: 1513072096.035577 <= 1513072096.086564
< Provoostenator>
Slightly differtent numbers is another run: 1513070202.4765592 <= 1513070202.517996
< wumpus>
uhoh
< Provoostenator>
(on the segwit branch, I'll try master as well)
< wumpus>
Provoostenator: do you get it on master too?
< Provoostenator>
wumpus: yes, just did
< terrence>
I want to develop a wallet, how can I get the lowest level api, or interface? instead of existing wrapped apis
< wumpus>
terrence: the lowest level would be to implement transaction serialization, deserialization, signing, as well as keeping the balance and unspent state up to date with the current status of the block chain yourself
< promag>
wumpus: not sure if that is what he means
< promag>
terrence: do you know bitcoind rpc interface?
< wumpus>
promag: lol, let's leave that to them instead of arguing about it between us
< promag>
heh, "existing wrapped apis" I guess he is talking about some client library or web api.. dunno... *flys away*
< promag>
wumpus: should replace in Assert with annotation in #11515?
< terrence>
promag: exactly, I'm new to blockchain, but I'm fascinated by blockchain
< wumpus>
althoug in principle the assert is redundant when the annotation is there, but it doesn't hurt to have it so I don't find it worth a long discussion
< wumpus>
better to be overcomplete here
< promag>
terrence: then join #bitcoin instead
< promag>
wumpus: I agree, if asserts can be removed when annotations are in place
< wumpus>
promag: it's somewhat complicated because not all compilers check the annotations
< promag>
so that's a +1 for assert
< terrence>
promag: I did, seems no one active in there
< promag>
terrence: try #bitcoin-dev
< wumpus>
#bitcoin is the most busy channel in the bitcoin community, if no one is active there you're just at the wrong time
< bitcoin-git>
[bitcoin] laanwj closed pull request #11354: Coins DB: Improve handling of FRESH child with non-DIRTY parent in CCoinsViewCa… (master...fix/batch-write-clean-parent-fresh-child) https://github.com/bitcoin/bitcoin/pull/11354
< wumpus>
so many things to do and so little time/energy
< promag>
wumpus: are you talking about 234 open PR's? :p
< wumpus>
for ex.
< fanquake>
The amount of stuff I see wumpus star on GH he must have about 5 side projects on the go
< wumpus>
that's... about right :)
< fanquake>
Plenty todo with graphics cards and their drivers/related software.
< promag>
ah I guess you don't have kids
< promag>
wumpus: "I think both ways should be supported for the foreseeable future, no need to deprecate anything right now" why keep legacy? in 3 releases it should not be there IMO
< wumpus>
because we don't want to break people's software just because
< wumpus>
the current way apparently works for everyone well. I kind of hate RPC PRs that break the interface just because the author likes some convention better.
< wumpus>
I personally would prefer using arrays as well there but that doesn't mean that all previously written software that uses createrawtransaction shoudl break
< wumpus>
it's just an alternative way of specifying the same data
< promag>
I don't think overloading is that great
< wumpus>
fine, I'll just NACK the whole change then
< promag>
heh
< wumpus>
keep the users in mind please
< promag>
in these cases I tend to prefer new calls instead of overloading
< wumpus>
FWIW in principle it is already possible to specify the order of outputs, but only if the client-side JSON library can emit ordered dictionaries. Python's can do this when you use Collections.OrderedDict() instead of a dictionary. The server-side (univalue) won't reorder dictionaries. But using an array is conforming to the spec instead of 'it happens to work'.
< Provoostenator>
I forgot that I used ./configure --enable-debug. The weird test functional errors I described above when I remove that (followed by make clean && make). They issues come back when I set --enable-debug again.
< wumpus>
Provoostenator: that's very strange
< Provoostenator>
They also run a lot slower with debug enabled, so that might be related.
< wumpus>
--enable-debug does make locking a lot slower, so if it's some kind of race condition, it could be triggered by that
< wumpus>
right.
< Provoostenator>
I'll run again with jnewbery's latest commits you just merged
< promag>
wumpus: nice, are you going to add the test or mind I do?
< bitcoin-git>
bitcoin/master 93a34cf Matt Corallo: Make DisconnectBlock unaware of where undo data resides on disk
< bitcoin-git>
bitcoin/master 50701ba Matt Corallo: Move txindex/undo data disk location stuff out of ConnectBlock
< bitcoin-git>
bitcoin/master e104f0f Matt Corallo: Move block writing out of AcceptBlock
< bitcoin-git>
[bitcoin] laanwj closed pull request #10279: Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces (master...2016-12-cconsensus) https://github.com/bitcoin/bitcoin/pull/10279
< bitcoin-git>
bitcoin/master a720b92 practicalswift: Remove includes in .cpp files for things the corresponding .h file already included
< bitcoin-git>
bitcoin/master 5d132e8 Wladimir J. van der Laan: Merge #10574: Remove includes in .cpp files for things the corresponding .h file already included...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10574: Remove includes in .cpp files for things the corresponding .h file already included (master...redundant) https://github.com/bitcoin/bitcoin/pull/10574
< pierre_rochard>
Does each wallet in vpwallets have a unique identifier? The class has GetName “for logging/debugging purposes” and there is the wallet’s vector index, not sure that I can rely on either of these
< promag>
don't use the index
< promag>
btw, what is the purpose?
< pierre_rochard>
accounting in multi-wallet world - which addresses belong to which wallet
< promag>
a wallet index can change
< promag>
and a wallet name too, if you do rename the wallet
< promag>
there is no embedded unique id in the wallet yet and don't know if there will be one
< pierre_rochard>
ah so is the wallet name the file name? like wallet.dat?
< promag>
yes
< pierre_rochard>
If there won’t be an embedded unique ID then wallet name will have to suffice
< pierre_rochard>
Thank you!
< promag>
don't recall if it is the filename or filepath though
< BlueMatt>
mostly cause it would help me re-implement/rebase #10692 in a cleaner way
< gribble>
https://github.com/bitcoin/bitcoin/issues/10692 | Make mapBlockIndex and chainActive and all CBlockIndex*es const outside of validation/CChainState by TheBlueMatt · Pull Request #10692 · bitcoin/bitcoin · GitHub
< BlueMatt>
I think it has enough concept ack to merit that....promag, care to rebase?
< BlueMatt>
I'll commit to reviewing it quick, and yelling at people to get it merged in a day or three
< Randolf>
Guest89357: There are many active folks here, but the discussions are usually focused on the development of the various facets of the Bitcoin project.
< Guest89357>
Ok
< Guest89357>
well
< Guest89357>
I have a problem related to an old bitcoin core client
< Guest89357>
I don't suppose you guys could help me out with it?
< Randolf>
Guest89357: For support, the #bitcoin channel is probably your best bet.
< wumpus>
better to ask in #bitcoin, this is not a support but a development channel, read the topic please
< Guest89357>
Ok
< Guest89357>
sorry for bothering, will check that channel out!
< promag>
BlueMatt: ok then
< promag>
BlueMatt: later tonight (utc+0 here) I can do it
< BlueMatt>
k, thanks
< ryanofsky>
pierre_rochard, wallet files do have embedded identifiers, search for "get_fileid" in the code
< ryanofsky>
but for your case, i think you probably better off using wallet filename, so users can understand & choose the id
< Provoostenator>
I just got a new machine, so it's a good opportunity to see if any dependencies are missing in the docs...
< Provoostenator>
Having some issues with make deploy not showing the icons.
< Provoostenator>
Fixed by reboot, nvm.
< BlueMatt>
hmm, re: #11873 I'm curious if anyone would maintain it or if it'd just die compared to travis where we at least theoretically work to fix failures
< * BlueMatt>
likes it pre-segwit-wallet, sorry sipa :p
< sipa>
?
< BlueMatt>
as in I'd like to see segwit wallet built on 11854, given it was partially the result of my review comments :p
< sipa>
oh, no opinion there
< sipa>
i'll gladly rebase if it's merged first
< wumpus>
BlueMatt: yes I think it's basically good to go, there was some discussion about where to put the MSVC build system that I didn't read in detail yet
< bitcoin-git>
bitcoin/master 9c8eca7 Russell Yanofsky: Split up key and script metadata for better type safety...
< bitcoin-git>
bitcoin/master 2214954 Wladimir J. van der Laan: Merge #11854: Split up key and script metadata for better type safety...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11854: Split up key and script metadata for better type safety (master...pr/scriptmet) https://github.com/bitcoin/bitcoin/pull/11854
< BlueMatt>
sipa: segwit wallet needs rebase :p
< sipa>
BlueMatt: already on it
< BlueMatt>
jonasschnelli: do you mind rebasing #11281 before review? Its kind confusing when some code added in intermediary commits is likely to be removed during rebase
< BlueMatt>
jonasschnelli: yes my comment was in response to gmaxwell's comment
< jonasschnelli>
BlueMatt: overlooked that comment. Thanks
< cfields>
BlueMatt: woohoo @ #10279!
< gribble>
https://github.com/bitcoin/bitcoin/issues/10279 | Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces by TheBlueMatt · Pull Request #10279 · bitcoin/bitcoin · GitHub
< BlueMatt>
cfields: heh, lol, yea
< BlueMatt>
next is #10692, but want to rebase on #11041 first
< cfields>
BlueMatt: that was much easier to review than I anticipated. Sorry for just getting to it.
< gribble>
https://github.com/bitcoin/bitcoin/issues/10692 | Make mapBlockIndex and chainActive and all CBlockIndex*es const outside of validation/CChainState by TheBlueMatt · Pull Request #10692 · bitcoin/bitcoin · GitHub
< jnewbery>
Provoostenator: Your p2p-fullblocktest.py failures are due to timeouts. The assert message isn't very helpful but if you look down the stack you'll see that it's a timeout
< jnewbery>
most likely because the re-org test at the end of p2p-fullblocktest.py isn't completing within the required 60 seconds
< meshcollider>
jnewbery: is there anything wrong with modifying bitcoin.conf in run_test() or should that only be done in setup_chain() ?
< jnewbery>
meshcollider: by default, the test_framework will start your nodes in self.setup_nodes(), which is called *before* run_test() begins. That means if you don't restart your bitcoin nodes, then they won't see any changes in bitcoin.conf that you make in run_test()
< jnewbery>
If you're stop-starting nodes and expect them to pick up changes in bitcoin.conf, then I see no problem with changing it in run_test().
< jnewbery>
You can get the datadir with the datadir variable in TestNode
< jonasschnelli>
Travis lacks a couple of PRs behind... I wonder if we once have that situation continues, all it requires is a new PR / PR push every 2hs.