< BlueMatt>
we sign git merges, and all is good on master, but we have two commits in the 0.12 branch that are unsigned
< BlueMatt>
(they are just copies of signed commits, but are themselves unsigned)
< BlueMatt>
gmaxwell: wut
< BlueMatt>
if whoever was confused by the original comments is concerned, its a very minor policy violation...something we never really clarified as policy anyway
< jonasschnelli>
BlueMatt: I guess many non-merge commits are unsigned? But right, this was during a time where I only signed merge commits and not my own PR commits.
< jonasschnelli>
As example: 44fef99e666e85caa7616765412d7becf97ab673 and fab83476acf4a1eaeb5d6c3fe6195b9ff80b193c are also unsigned (aprox same timeregion)
< BlueMatt>
jonasschnelli: the two i listed above /are/ merge commits
< BlueMatt>
well, are commits which were merged without a merge commits
< BlueMatt>
aside from those two, all other commits on the 0.12 branch are signed
< baldur>
the debug log is throwing some errors for me? 2016-02-07 08:49:50 ERROR: AcceptToMemoryPool: rejecting replacement 070e4b88f6b188a37f862c9a7c9a1aff7285fcaefe329b8f55522106fd0bc0de; new feerate 0.00040349 BTC/kB <= old feerate 0.00046111 BTC/kB
< btcdrak>
replacements must have a higher fee
< baldur>
2016-02-19 00:19:28 ERROR: AcceptToMemoryPoolWorker: CheckInputs: 945624be07514b307d27a37df67d4c7e2e67c9f76bdce64532cdcca8c74248d3, non-mandatory-script-verify-flag (Non-canonical signature: S value is unnecessarily high) (code 64)
< btcdrak>
baldur: this is correct. but you should ask these questions in #bitcoin
< baldur>
sorry, sure will do, just relatively new to see so many error messages in the debug log
< BlueMatt>
jonasschnelli: everything before "No parent of 82bcf405f6db1d55b684a1f63a4aabad376cdad7 was signed with a trusted key!" is just informational - it lists every change to contrib/verify-commits first
< btcdrak>
I wonder if these should not be prefixed as "ERROR" rather "REJECTED"
< BlueMatt>
jonasschnelli: after that, it tells you that 82bcf405f6db1d55b684a1f63a4aabad376cdad7 was properly signed, but neither of its parents were
< BlueMatt>
jonasschnelli: do we still support qt4?
< jonasschnelli>
BlueMatt: yes. But we don't fix UI issues... kind of legacy support.
< jonasschnelli>
We strongly recommend Qt5.
< jonasschnelli>
Qt4 will probably be dropped soon
< wumpus>
"soon" as in a few major versions haha
< BlueMatt>
jonasschnelli: hmm...ubuntu doesnt like it
< wumpus>
but yes, qt4 is legacy, don't use it for new builds
< BlueMatt>
checking for QT... no
< BlueMatt>
checking for QT... no
< BlueMatt>
configure: WARNING: Qt dependencies not found; bitcoin-qt frontend will not be built
< BlueMatt>
except nothing wrt qt has changed
< jonasschnelli>
Hmm... it should detect qt4... did you try --with.gui=qt4
< wumpus>
but unlike the change from, say, Python2 to Python3, Qt4 to Qt5 wasn't controversial at all, so there is an EOL
< BlueMatt>
ugh, its remote build...pita to just test something
< wumpus>
not intentional, but you'll have to force it with --with-gui=qt4
< BlueMatt>
ok
< wumpus>
still not sure why, hope cfields will take a look at it some time :)
< jonasschnelli>
BlueMatt: after executing `verify-commits.sh`, I get the changes in contrib/verify-commits, and then (after pressing q) a list of commits. Do I need to provide a src directory when executing: verify-commits.sh?
< jonasschnelli>
verify-commits.sh only reports two commits in my case
< jonasschnelli>
075faaebf2e534265ff8aca015eaf03a8a156f32 and 2f601d215da1683ae99ab9973219044c32fa2093
< BlueMatt>
huh?
< GitHub53>
[bitcoin] jonasschnelli opened pull request #7586: [Qt] fix for building against LibreSSL (master...2016/02/fix_openssl_libressl) https://github.com/bitcoin/bitcoin/pull/7586
< GitHub199>
[bitcoin] AliceWonderMiscreations opened pull request #7588: Sample RPM spec file for Bitcoin 0.12.0 (master...master) https://github.com/bitcoin/bitcoin/pull/7588
< GitHub162>
[bitcoin] jonathancross opened pull request #7589: Improving wording related to required Boost library requirement (master...patch-2) https://github.com/bitcoin/bitcoin/pull/7589
< GitHub160>
[bitcoin] jonathancross opened pull request #7590: Improving wording related to Boost library requirements [updated] (master...patch-3) https://github.com/bitcoin/bitcoin/pull/7590
< GitHub23>
[bitcoin] jonathancross closed pull request #7589: Improving wording related to Boost library requirements (master...patch-2) https://github.com/bitcoin/bitcoin/pull/7589
< gmaxwell>
hm nothing in listtransactions seems to show when a sent tx is abandoned.
< gmaxwell>
other than that trusted is false.
< sipa>
define abandoned?
< gmaxwell>
having been throbbed by the abandontransaction rpc.
< sipa>
ah.
< morcos>
gmaxwell: that was all left for later improvements because it was a battle to get abandontransaction included at the last second anyway!
< GitHub99>
[bitcoin] laanwj opened pull request #7592: mempool: Reduce ERROR logging for mempool rejects (master...2016_02_mempool_error_spam) https://github.com/bitcoin/bitcoin/pull/7592
< morcos>
warren et al: i'm going to continue my musings on system effects of the limited mempool
< morcos>
so i was thinking what you were about randomization of expiration delays or something.. but perhaps being in sync isn't the problem. perhaps being out of sync might be a problem.
< morcos>
(and again there may be no problem)
< morcos>
i've been trying to debug a particular issue where a node connected to 7 peers uploaded 250MB of tx data in one hour
< morcos>
haven't quite gathered why this burst would happen at one particular time, but it occurred to me that if your peers are all mempool limited
< morcos>
(or most of them)
< morcos>
and there is traffic flow like that on the network that reaches you somehow
< morcos>
you'll end up having to upload it N times for each of your N peers since they are rejecting it all, they will never inv it back to you
< morcos>
of course they might receive it from someone else and thus have it recentrejects...
< morcos>
so i don't know.. but 250MB in one hour is sligthly disturbing to me especially with so few peers
< Luke-Jr>
morcos: after more thought, it seems to me priority should be added back to mempool
< morcos>
Luke-Jr: You know that Suhas and I TRIED to do that and met a lot of resistance
< Luke-Jr>
morcos: resistance from whom?
< morcos>
sdaftuar_ even coded it up
< morcos>
It was discussed on the PR and in IRC
< morcos>
At this point I think that ship has sailed
< morcos>
By priority being added to the mempool you really mean free transactions even if the mempool is full right?
< Luke-Jr>
more or less
< Luke-Jr>
I had gotten the impression you guys abandoned it, not that it was resisted
< morcos>
We abandoned it because it was resisted
< morcos>
I was torn personally about whether keeping priority was worth it or not
< morcos>
But it seemed if we were keeping it for now
< morcos>
we should have it work mostly consistently
< morcos>
Thats why the two of us went to the trouble to make it work right
< morcos>
But it seemed like an uphill battle
< morcos>
And that in my mind pushed the weight of the evidence in favor of well lets just clean it out then
< morcos>
I hate this half supported state that it exists in
< Luke-Jr>
well, the current state isn't too bad, but the reason I think it makes sense to add back to mempool is that there is *no* economically-rational decision there at all
< gmaxwell>
I thik full support would require effectively keeping two mempool limits, a priority oriented limit and a fee oriented limit. The extra index would be no big deal, but the rest?
< morcos>
gmaxwell: that was all coded up
< morcos>
there was a PR for it
< morcos>
perhaps not the most elegant implementation, but it was efficient and worked right (well modulo the fact hat it never got much testing)
< morcos>
i think sturles might even be using it
< gmaxwell>
I don't think this addresses the potential issue morcos is talking about above though.
< morcos>
but i don't understand the comment about no economically rational decision?
< Luke-Jr>
morcos: relay nodes don't get the fees anyway
< Luke-Jr>
their *only* interest in relaying transactions, is the well-functioning of the network
< morcos>
yes but why relay things that miners aren't going to care about? you should relay things that miners are going to mine
< Luke-Jr>
and priority makes far more sense there than feerate
< Luke-Jr>
why relay anything at all?
< morcos>
i don't see why there is an inherent benefit into relaying old rich peoples coins as opposed to relaying txs that will get mined
< gmaxwell>
^
< gmaxwell>
Having multiple mechenisms has a lot going for it, but priority over feerate? no.
< Luke-Jr>
gmaxwell: I'm saying priority is a better metric, not that it should be exclusively used
< Luke-Jr>
morcos: miners can only mine what is relayed
< morcos>
Also a priority limit doesn't work like a fee limit in the case of eviction.
< Luke-Jr>
morcos: ?
< morcos>
It appears to me that to protect against DOS with priority txs you HAVE to have the rate limiter
< gmaxwell>
Luke-Jr: thats magical thinking, if there is ever a problem of miners not getting relayed whatever they want, they'll simply spin up a few nodes (perhaps even sybil attack) and the issue is gone.
< petertodd>
gmaxwell: and the code to do that already exists in my full-rbf fork
< gmaxwell>
Aside: is it a known issue that bitcoin-cli will get disconnected during a rescan for importprivkey?
< morcos>
Luke-Jr: Also the idea that there is a min fee to get relayed, but then things can be prioritized differently is not a bad model
< Luke-Jr>
morcos: I agree, it's not bad. But there's not much rationale to removing priority in mempool IMO
< paveljanik>
gmaxwell, "yes" - see -rpcclienttimeout
< gmaxwell>
Luke-Jr: as a wallet/user priority makes it harder in theory to get predictable behavior out of the system for everyone. Instead of "pay more for faster service" you get "uh, how old are your coins? how much space/profit are miners giving up for priority recently?"
< petertodd>
gmaxwell: just wait'll people extend coinjoin w/ pay-for-priority...
< Luke-Jr>
gmaxwell: ironically, as things work out, priority is for low priority transactions
< morcos>
We tend to try to do too much. Priority isn't bad per se. But it is a lot of code that becomes difficult to maintain especially complicating thinking about attack scenarios with mempool limits or bandwidth DoS.
< morcos>
And we don't really imagine it serves that much of benefit to justify all that.
< morcos>
Let's concentrate our efforts on more important things.
< Luke-Jr>
the evidence suggests priority is important
< gmaxwell>
Luke-Jr: indeed, but it still makes the behavior less predictable for other users. "I'm paying more than all those txn, why am I not getting in."
< Luke-Jr>
(perhaps less so for the mempool, but it seems logical to support there)
< morcos>
Probably would have taken me half as long to do the huge speedup to block assembly if i wasn't trying to keep priority working. That time could have been better spent doing other things. We probably could have had ancestor package mining for 0.12
< petertodd>
also, tx fees are becoming quite important to miners - e.g. average block right now has about 1% revenue in fees, which is a very significant % of your profit margin if you're a pool - that'll double soon at the halving, and probably even more than that due to tx pressure
< morcos>
I'm confused. What evidence suggests its important? (priority)
< Luke-Jr>
morcos: 5% of transactions being mined via priority
< morcos>
Luke-Jr: My calculations were 1%
< morcos>
And that doesn't mean its important
< petertodd>
Luke-Jr: even 5% is nothing in the grand scheme of things - what wallets take priority into account?
< Luke-Jr>
also inability to de-stick stuff
< morcos>
What's to say that anything would have been harmed if those 1% had to pay a small fee
< Luke-Jr>
morcos: there is no way to do that yet
< Luke-Jr>
RBF is not complete
< petertodd>
Luke-Jr: what would make it 'complete'?
< Luke-Jr>
those 1% would simply be stuck indefinitely
< Luke-Jr>
petertodd: the ability for people to actually bump fees
< gmaxwell>
Luke-Jr: even without rbf there is expiration now.
< petertodd>
Luke-Jr: as in, wallet support?
< Luke-Jr>
petertodd: yes
< morcos>
Yes, so lets concentrate our time on fixing that! And again ancestor package mining (formerly known as CPFP) can be used to unstick stuff
< petertodd>
Luke-Jr: that's coming, and will probably be ready by the time priority actually gets removed from Core
< morcos>
Luke-Jr: those 1% wouldn't have been placed without fee if we didn't have priority
< Luke-Jr>
morcos: I gave up trying to implement CPFP on top of 0.12
< Luke-Jr>
morcos: yes, which means they'd be stuck 'forever'
< morcos>
If you put literally ANY fee > than the minimum on your transaction, it has a very high probability of making it in a block within a week
< morcos>
if your fee is less than 1014 satoshis per kB you'll get caught up in the spam
< morcos>
otherwise you're in
< Luke-Jr>
and if you don't, you're out… with no recourse.
< gmaxwell>
Luke-Jr: please stop saying forever.
< gmaxwell>
it's just not true.
< sipa>
morcos: how hard is CPFP/ancestor package mining to implement now?
< Luke-Jr>
gmaxwell: it's true given the current state of things, with priority removed.
< morcos>
sipa: its done
< gmaxwell>
Luke-Jr: they expire.
< morcos>
just being tested and cleaned up
< Luke-Jr>
morcos: is it?
< morcos>
sdaftuar_ wrote it
< Luke-Jr>
gmaxwell: not in a way that users can take advantage of
< petertodd>
what users actually are relying on txs that take a day or two to confirm anyway? where's the feedback from users saying they actually do this?
< gmaxwell>
Luke-Jr: also a signficant amount of transactions would take months to meet the minimum priority criteria anyways, it's not magic pixie dust.
< Luke-Jr>
gmaxwell: anything not micro-tx would be <1 week
< Luke-Jr>
morcos: CPFP is inherently stateful.
< petertodd>
if anything, having txs that take a week to get mined, but do get eventually mined, seems *more* misleading and dangerous than those txs not getting mined
< gmaxwell>
Luke-Jr: 0.01 BTC, which is a couple bucks, from just created in a 1kb transaction... takes a long time.
< gmaxwell>
petertodd: the fact that it's poorly handled by wallets is not good.
< Luke-Jr>
morcos: for example, if the parent gets mined on its own, the child shouldn't include its data in its feerate/priority
< petertodd>
gmaxwell: indeed, but such wallets need to get fixed - having those txs simply being dropped is probably less likely to lead to losses in many cases where the user thinks the tx failed and won't go through
< morcos>
Luke-Jr: you mean block assembly is stateful or maintaining state in the mempool. both are true. mempool state is already done with descendants, its easy to do with ancestors too. the one downside is that there is a slight hit to block propagation, hopefully unmeasurable though
< Luke-Jr>
morcos: I mean as we add transactions to the template, the cached data becomes invalid
< morcos>
Luke-Jr: yes in block assembly that state has to be updated, but so far the bench marks show it being actually ever so slightly faster, but basicaly about 7ms to assemble a block
< morcos>
its a copy of the data that is updated
< morcos>
its faster b/c in block assembly you no longer have to check for orphans. when you add a package, there are no orphan txs
< Luke-Jr>
right
< morcos>
anyway, lets not revisit adding priority to the mempool. please.
< morcos>
i think it would be reasonable to keep the modified calculation of priority as something miners can prioritize based on if we want to
< Luke-Jr>
ok, for now
< morcos>
i refactor CreateNewBlock substantially when I realized we werent' about to get rid of priority code to completely separate priority block filling and feerate block filling
< Luke-Jr>
no new CPFP PR to review yet, I guess?
< morcos>
i never pr'ed it b/c well just seemed like code for codes sake
< morcos>
but sdaftuar used it, so now i will pr that
< morcos>
not yet, but soon
< morcos>
don't worry, i'm sure there will be plenty of opportunity for feedback
< morcos>
:)
< Luke-Jr>
well, I'd like to throw it in Knots sooner rather than 0.13 ;)
< sipa>
what is Knots?
< morcos>
sure, if for some reason it doesn't get pr'ed shortly, i bet sdaftuar would be happy to point you to a branch
< morcos>
i haven't been paying too close attention
< morcos>
but i see a lot of comments out there about how people can just identify it
< morcos>
i wonder how obvious it is to everyone though that its inherited
< morcos>
sure doing 0-conf with unconfirmed parents is fraught with risk
< petertodd>
morcos: probably not that obvious, but those people will get defrauded in 10x different ways anyway
< morcos>
but i think maybe we should make the extra effort to be sure everyone is aware of how it works
< morcos>
its a bit non-intuitive
< morcos>
like a warning disclaimer or something
< petertodd>
morcos: IMO the best way to do that is make easy to use tools that use it, and let people understand that for themselves
< morcos>
well i think we did PR poorly on the feature in the first place, i don't wnat to kind of get hit with that again b/c they feel like there was a hidden way aroudn the opt'ing in aspect
< morcos>
communication solves many problems
< petertodd>
morcos: well, mycelium just added support to show rbf txs, and they did it the "right" way, even showing other examples like low fee txs
< petertodd>
morcos: the audience of people who will be writing code to deal with this is relatively small
< gmaxwell>
Luke-Jr: can you remind me the reason that we've discarded composite scores? e.g. using ancestorfeerate + log(priority)*C or feerate>x?feerate:min(x,priority*C) ? I know I've asked this before.
< Luke-Jr>
gmaxwell: I don't know that it has been discarded?