< bitcoin-git>
[bitcoin] achow101 opened pull request #11678: [wip][wallet] Don't shut down after encrypting the wallet (master...encrypt-no-restart) https://github.com/bitcoin/bitcoin/pull/11678
< phantomcircuit>
achow101, i have 2m ... somewhere
< achow101>
phantomcircuit: ??
< gmaxwell>
achow101: I assume he means testnet coins.
< achow101>
ah
< sipa>
in other words: if TN coins ever have a trade value, phantomcircuit will just crash the market?
< achow101>
one could argue that testnet coins have a trade value now
< sipa>
iirc it was once 3 BTC for 10000 tnBTC
< phantomcircuit>
lol
< phantomcircuit>
sipa, DEAL
< phantomcircuit>
xd
< sipa>
haha
< sipa>
the market may not have been particularly deep back then :p
< tloriato>
good evening, gentlemen. i was reading a little more about schnorr signatures and i'm pretty excited about it
< tloriato>
i was wondering if we have any tests already running or an ETA on that?
< sipa>
tloriato: let's move to #bitcoin-wizards
< bitcoin-git>
[bitcoin] Thoragh closed pull request #11533: Docs: Update WSL installation notes for Fall Creators update (master...Update-WSL-installation-for-Fall-Creators-update) https://github.com/bitcoin/bitcoin/pull/11533
< midnightmagic>
phantomcircuit's not the only one. lol
< midnightmagic>
Dunno who it was who put all those diff-1 post-block diff hack blocks in there but someone was doing it for hundreds of thousands of blocks.
< bitcoin-git>
[bitcoin] Thoragh reopened pull request #11533: Docs: Update WSL installation notes for Fall Creators update (master...Update-WSL-installation-for-Fall-Creators-update) https://github.com/bitcoin/bitcoin/pull/11533
< dcousens>
any love for a `droptransaction` from mempool rpc call?
< phantomcircuit>
midnightmagic, that's me
< midnightmagic>
phantomcircuit: Oh, good then.
< warren>
dcousens: I'd love that personally
< sipa>
what for?
< wumpus>
doesn't abandoning a transaction from the wallet remove it from the mempool?
< sipa>
iirc you can only abandan a wallet transaction when it already isn't in the mempool
< wumpus>
you're right, I had that the wrong way around
< wumpus>
and the wallet adds all its transactions to the mempool at startup
< wumpus>
(at least if not walletbroadcast=0)
< sipa>
so basically abandon only works when the tx is already unacceptable to the mempool (due to conflicts with existing chain, or due to mempool full and too low fee)
< sipa>
a mechanism to forcefully abandon a tx may make sense (though it's hard to prepare for it still being possible to mine)
< sipa>
but i'm not sure that giving direct access to drop something from the mempool matters
< wumpus>
there can be cases during development/testing where it can be marginally useful to drop things from the mempool, but it seems to much of a foot shooting option to expose generally
< sipa>
right, as a debug thing sure
< sipa>
at the same level as invalidateblock and reconsiderblock
< wumpus>
warren's case is that he sent a transaction with way too little fee to ever be mined, without RBF, and he wants to try to get rid of it by double-spending it
< sipa>
right, but you really just want a "force abandon wallet tx" there, rather than the more level "drop from mempool", i think
< wumpus>
there's no guarantee it will work of course because miners and other nodes might still have it, but he still wants to try
< sipa>
or even a "force accept this tx, replacing whatever is needed in the mempool"
< warren>
wumpus: actually I was successful
< wumpus>
the latter would be nice, as it matches what needs to be done in this case better, if you don't respend the inputs there's always the possibilty that your transaction gets replayed and mined in the future
< warren>
generally I'd like the ability to remove something from my mempool without wiping the entire thing
< wumpus>
but anyhow for a diagnostic, undocumented option at the level of invalidateblock/reconsiderblock I woudln't have problems with it
< wumpus>
it'd be trivial to implement: make a RPC that calls removeRecursive, this will make sure the descendants are removed too
< wumpus>
and then pray it won't be advertised as a general "cancel transaction" solution by people who have no clue how the mempool works and think it's shared between all nodes
< mryandao>
would it be possible to add a key-value "tx-rate" for the getmempoolinfo rpc command, where the average tx-rate of the mempool?
< mryandao>
*fee rate
< wumpus>
would be easier to keep track of the total amount of fee. But what would that info be useful for?
< mryandao>
so a user can decide in advance if they should make a transaction now
< wumpus>
estimatesmartfee would be better for that
< mryandao>
over the weekend, estimate smart fee wasn't very effective
< sipa>
or a way to query "what is the feerate in the mempool, X MB from the top"
< wumpus>
I mean the decision criterion would be the cost to submit a transaction now, not so much what other transaction are paying
< wumpus>
mryandao: the fee estimation is not perfect, but I'm not sure making people do their own fee estimation based on some (easy to manipulate) stats is a better idea
< mryandao>
over the weekend, i thought it might also be a good idea to keep track of the rate of growth of the mempool
< sipa>
mryandao: meh, "infinite" is a good approximation
< mryandao>
maybe the differential is useful for fee estimation
< sipa>
the real question is what the size is _above a certain feerate level_
< eck>
and derivatices and higher-order derivatives generally
< wumpus>
sipa's point is that rate of growth in itself isn't interesting; someone could submit an ~infinite number of low fee transactions to pad your mempool up to mempoolmax, and that should not affect fee estimates
< eck>
ah
< wumpus>
so you'd need to track something more subtle
< sipa>
it isn't interesting, and it also doesn't matter
< sipa>
if you're willing to pay X feerate, you don't care at all about any transaction that pays less than X, even if there is 10 GB of them
< eck>
I guess you would need the time derivative of the histogram (if you needed it at all)
< bitcoin-git>
bitcoin/master 73a7e6d Thoragh: Update WSL installation for Fall Creators update
< bitcoin-git>
bitcoin/master cbb54e7 Wladimir J. van der Laan: Merge #11533: Docs: Update WSL installation notes for Fall Creators update...
< eck>
just thinking out loud here, but you could train a simple convolutional filter (for example) to learn the best parameters to estimate a fee rate given the fee histogram from the last N time periods; but you'd have to update the convolution parameters for each bitcoin release, and it would be trivial to find pathological values after the fact to trick the trained algorithm
< sipa>
eck: no way, we're not putting gameable methods in
< sipa>
such methods are awesome if they have human oversight
< sipa>
but you don't want to put them in a fully automated system that is intentionally designed to need user intervention to upgrade :)
< eck>
that's kind of what i thought, interesting though experiment though
< bitcoin-git>
bitcoin/master faaa7db MarcoFalke: qa: Only allow disconnecting all NodeConns
< bitcoin-git>
bitcoin/master 7adeea3 Wladimir J. van der Laan: Merge #11641: qa: Only allow disconnecting all NodeConns...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11641: qa: Only allow disconnecting all NodeConns (master...Mf1711-qaNodeConnDisconnectAll) https://github.com/bitcoin/bitcoin/pull/11641
< bitcoin-git>
[bitcoin] laanwj closed pull request #10873: Use a condition variable for shutdown notifications (master...shutdown_notify) https://github.com/bitcoin/bitcoin/pull/10873
< meshcollider>
It seems 10873 is a candidate to be the first PR with the new abandoned tag MarcoFalke created ^
< wumpus>
good idea, added
< mryandao>
how about taking the differential of transactions that pay a feerate greater than the min-feerate of the next block as described by `getblocktemplate`
< mryandao>
it should be meaningful to see the rate of incoming transaction "overtaking" transactions that should be confirmed in the following block
< meshcollider>
(0.15.1 release announcement on bitcoincore.org)
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11683: tests: Remove unused mininode functions deser_int_vector(f) and ser_int_vector(l) (master...remove-int-vector-serialization) https://github.com/bitcoin/bitcoin/pull/11683
< wumpus>
meshcollider: will do
< meshcollider>
wumpus: thanks
< wumpus>
I don't think anyone will mind if I merge it?
< meshcollider>
Shouldn't do, ACKs from both you and bluematt and its basically just a c+p of the release notes so its not exactly controversial :P
< wumpus>
and it's about time too
< meshcollider>
Still not as delayed as 15.0.1 was lol
< wumpus>
hehe, no not that delayed
< promag>
wdyt about changing this "if (request.fHelp || request.params.size() > 2)" to "if (request.fHelp)" ?
< wumpus>
NACK, that would make it ignore spurious arguments
< wumpus>
which should be an error
< promag>
what I mean is to show help only when requested. Then have argument validation which should validate all arguments, so arguments with no validation should raise invalid parameter too
< promag>
or we could keep "if (request.params.size() > 2)" but that would raise invalid argument
< promag>
the help is mainly for the command line cli right?
< wumpus>
maybe, I really doubt this is worth changing all RPC calls for
< wumpus>
I mean barfing up the help in case of confusion about the number of arguments is consistent with what a lot of command line tools do, it's not wrong or such
< wumpus>
at least we don't silently ignore spurious RPC arguments, unlike spurious command line options, which don't cause an error
< wumpus>
that's a much worse user experience
< wumpus>
type poxy instead of proxy and it doesn't even warn
< promag>
wumpus: ok
< promag>
but in some cases, if you pass options with extra keys, it won't complaint
< wumpus>
it should
< wumpus>
well maybe except nested structures
< promag>
and if the caller makes it lower case or snake case instead of pascal case, it won't complaint
< wumpus>
I mean, it doesn't hurt to provide more information about a vout for createrawtransaction than it strictly needs
< wumpus>
this helps pass in the output from listunspents to it without filtering
< promag>
you mean for vin
< wumpus>
yes
< wumpus>
so let's just keep it like that
< promag>
anyway, really doubt that anyone does that copy and paste :)
< meshcollider>
oh wumpus, maybe your key is not trusted when merging bitcoincore.org PRs
< promag>
I suppose everyone should pick the relevant fields :D
< wumpus>
anyhow, please let's not change the RPC API just to change the RPC API, but focus on features, bugfixes and user experience
< meshcollider>
Agree ^
< promag>
np!
< wumpus>
meshcollider: uh oh
< wumpus>
meshcollider: I should probably force-push back to the previous state then
< wumpus>
meshcollider: only one of the trusted keys can add me as trusted key, and not on top of an invalid commit
< meshcollider>
wumpus: mhm yeah, in any case you should be added as a trusted key but yeah we might have to wait for jonasschnelli
< wumpus>
luckily it doesn't break the site itself, just blocks updates for now
< meshcollider>
yep, was wondering why it hadn't gone live so I looked around and noticed
< wumpus>
right - I'm not going to do anything, one of the signers can resolve this, either by adding a merge commit on top , or re-sigining the merge commit and force-pushing
< wumpus>
if they agree with the change of course :-)
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #11686: Make ISSUE_TEMPLATE a bit shorter, mention hardware tests (master...2017-11-shorter-default-issue) https://github.com/bitcoin/bitcoin/pull/11686
< Nobody_>
i just wanted to state that i am requesting as a System that nobody owns and if you abuse the system you abuse yourself some upgrades that need to happen for the Bitcoin Core
< Nobody_>
If anybody could get a message to the Bitcoin Core Developers to add the Mining back into the Core that would be perfect, ASIC is not needed to mine and is outdated plus not as power efficient
< Nobody_>
also a Faucet in the core is needed for Nobody to send Bitcoin to the requested wallet of your choice, for reasons if it is not avaliable from anyone else the system will continue to function appropriately.
< Nobody_>
Nobody should be able to have wallets that can be loaded with and share Cryptocurrency back if requested and users should be able to put Cryptocurrency into the faucet if they do not need it
< LumberCartel>
Nobody_: You should raise your concerns in the #bitcoin channel rather than in this channel.
< Nobody_>
it will bring Freedom and Equality for all users and not be so dominant on switching cash for cashless, i work with Antarctica and have researched the software very hard, Satoshi Nakamoto knows who i am but i will leave me Nobody
< Nobody_>
it is more than a concern and i deem it nessessary to update it to make sure that everyone can enjoy the Cryptocurrency
< Nobody_>
I already have a version that has a faucet and it is sufficient, as well as for the common good of the public and passes for being benificial for the greater good of humanity
< Dizzle>
Nobody_: if you do have something more power efficient than ASIC for mining, you can submit a pull request that adds mining back into Core. If you're not sure how, let me know how its done and I'll help make the pull request.
< Nobody_>
S.O.S, Law Enforcement Update - Everything is legal
< Nobody_>
Everything ECDSA Public Key (Bitcoin Compatible): 1N2EWy7LroJVFYXtmYZryh7W9eV3k6qajd exists since Mon Oct 02 2017 23:48:19 GMT-0700 (Pacific Daylight Time)
< Nobody_>
that is a Trusted timestamp and is forge proof
< Dizzle>
I still want his quantum CPU mining pull request.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11689: Fix missing locking in CTxMemPool::check(const CCoinsViewCache *pcoins) (master...CTxMemPool-check) https://github.com/bitcoin/bitcoin/pull/11689
< karelb>
Question about bitcoin-core - why is validation.h/.cpp so "overloaded"? It seems to me half of the things in there don't have to do much with validation
< karelb>
such as default parameters, opening and writing to block files, etc
< sipa>
karelb: the reason is that up to about a year ago maybe, validation.cpp and net_processing.cpp were one file, called main.cpp
< sipa>
splitting things up and off into other modules is a slow but continuing work that's certainly not complete yet
< karelb>
Oh yeah, I thought it will be something historic like that
< karelb>
I remember giant main.cpp, I suspected validation is "just" renamed main
< karelb>
thanks!
< sipa>
(and until a few years ago, main.cpp also contained all of chain management, utxo stuff, wallet, interaction with the GUI...)
< karelb>
hm, doing refactoring like that seems like an easy way to get some cheap commits in bitcoin core code :D
< gmaxwell>
karelb: it's not just renamed main, main was split basically in half, but there is still hangover. Also some of these things like consensus parameters are critical to consensus validation.
< gmaxwell>
There is some layout tension on that; abstracting consensus rules can make them more opaque and harder to review; and bitcoin core is not an altcoin construction set. :) OTOH, sometimes moving things around makes things more clear, enables better testing harnesses, etc.
< fanquake>
karelb heh, there are easier ways to get cheap commits than playing with consensus code
< karelb>
fanquake I know, I have this giant commit
< gmaxwell>
karelb: yea,.lol no, refactoring consensus code is a good way to have a bad time and decide you don't want to contribute more.
< fanquake>
karelb All contributions are valuable. Most people might find "issues" and never bother contribute a pr, or open an issue.
< gmaxwell>
For obvious refactorings e.g. to meet our current code standards, we prefer to only perform them when the code is already being changed to avoid disrupting PR flow. For non-obvious refactors it is better if only expirenced participants do them, because newer contribs tend to not understand the informal architecture as well and tend to make refactors that unconsciously try to warp thing more to
< gmaxwell>
their own personal styles instead of the project style. Consensus code in general has a higher review and testing bar, and is more likely to end up with people failing to review it because they don't think it meets a cost/benefit for the review. Sometimes refactorings of consensus code only happen because someone like pieter is effectively cashing in large amounts of social capital to pay for
< gmaxwell>
other people to review the work-- and the fact that this is whats happening isn't necessarily visible to irregular contributors. So while anyone is welcome to submit such things, I wouldn't recommend those in particular, and anyone who submits consensus refactors should have reasonable expectations.
< fanquake>
Now that the *new* Windows build instructions have been merged, I'm going to close all the existing windows build issues, hopefully we might get on top of them. However now it seems the there are just new path/directory related issues.
< fanquake>
gmaxwell yes, hit and run consensus refactoring isn't really helpful.
< karelb>
gmaxwell: OK, I will not make a PR that pulls out all `DEFAULT_`s from validation.h to defaults.h then. :)