< * luke-jr>
ponders if 13151 should just use sendfile(2) :P
< wumpus>
luke-jr: I think that'd be the most efficient solution. But a lot more work, would need some further (OS-specific) abstractions in that case though to get the sendfile command all the way to the network layer, getting around the send buffering
< wumpus>
this was just fairly low-hanging fruit - bypassing the deserialization/serialization should already have helped
< jonasschnelli>
wumpus: 13151. yes. I have no idea why this can happen and I hope it's a local issue... though I doubt it.
< jonasschnelli>
Can you do a test on a fast SSD?
< wumpus>
all the otherresults are at least somewhat hopeful
< wumpus>
no, I don't have any SSD large tnough
< jonasschnelli>
wumpus: I could try to redo the test on a digital ocean instance.. or at least a different ssd env
< wumpus>
I'll also try on another machine when I find time (more spinning rust, though)
< fanquake>
I can test on an SSD. Were both done using bitcoincore-indexd ?
< bitcoin-git>
[bitcoin] glaksmono opened pull request #13196: [WIP] Refactoring platform-specific code in util.h/util.cpp (master...bitcoin-12697) https://github.com/bitcoin/bitcoin/pull/13196
< fanquake>
Having people grab tickets to work on is good. However I'm wondering if we should mention that opening WIP PRs means that some actual work should have been done? re #13196
< kallewoof>
fanquake: Yeah, that's a good rule I think. It will discourage others from working on the issue even if no work has been done.
< kallewoof>
I mean, having that rule will preevent discouraging ---.
< jonasschnelli>
fanquake: yes. if you can test on both hdd/ssd... that would be great.
< jonasschnelli>
maybe use wumpuses branch of the indexer
< jonasschnelli>
make sure you request blocks with witness
< fanquake>
kallewoof yep. WIP PRs should be opened when someones needs help/feedback in regards to code/design decisions.
< fanquake>
We don't need to use them as a signal for "claiming" an issue
< fanquake>
thanks jonasschnelli
< kallewoof>
fanquake: Agreed
< kallewoof>
#12265 has 1 tested ACK, 1 utACK (latest), and 1 ACK and 1 utACK (pre-squash/rebase). It's test bug-fix only, so feels mergeable but if someone would be up for reviewing that would be lovely.
< wumpus>
jonasschnelli: it can't hurt; though there's a tested ack already
< wumpus>
jonasschnelli: also we've been testing these patches on master already - I guess the useful test of doing a gitian build would be whether a gitian build still works, of course
< jonasschnelli>
I try with my build script (not sure if it can handle older branches... lets see)
< fanquake>
thanks jonass
< fanquake>
wumpus #12265 should be ready to go. John and marco have ackd cc kallewoof
< wumpus>
fanquake: only seeing that one now; yes, makes sense I think, srcdir is a misnomer as that's not where the executables end up in out of tree builds
< promag>
wumpus: occasionally I got random unicorns as well
< wumpus>
promag: me too; but I was worried because this is another large PR with lots of comments
< jnewbery>
wumpus: sorry not to answer yesterday re: #10267. My current workaround for unicorn issues is to use chrome's developer tools and use the device toolbar to view the page as mobile/tablet.
< jtimon>
probably stupid question... in https://github.com/bitcoin/bitcoin/blob/master/src/pubkey.h#L59 why are there 3 ways to indicate non-compressed and 2 ways to indicate compressed? shouldn't one for each be enough? also, should using an enum or macros or constants be more clear?
< gribble>
https://github.com/bitcoin/bitcoin/issues/10267 | New -includeconf argument for including external configuration files by kallewoof · Pull Request #10267 · bitcoin/bitcoin · GitHub
< wumpus>
jnewbery: interesting, that that works, thanks
< jtimon>
s/should/shouldn't/
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #13199: Bugfix: ensure consistency of m_failed_blocks after reconsiderblock (master...2018-05-fix-reconsider-block) https://github.com/bitcoin/bitcoin/pull/13199
< bitcoin-git>
bitcoin/master a2f678d Pieter Wuille: Bugfix: the end of a reorged chain is invalid when connect fails...
< bitcoin-git>
bitcoin/master 08c1caf Wladimir J. van der Laan: Merge #13185: Bugfix: the end of a reorged chain is invalid when connect fails...
< bitcoin-git>
[bitcoin] laanwj closed pull request #13185: Bugfix: the end of a reorged chain is invalid when connect fails (master...201805_bugfix_invalidchain_end) https://github.com/bitcoin/bitcoin/pull/13185
< vlugansky>
Hi guys! quick question: does anyone manage to add bitcoinold to decentralized exchanges?
< sipa>
vlugansky: this channel is about software development of bitcoin core
< bitcoin-git>
[bitcoin] martinus opened pull request #13202: prevents copying of in/outputs for SignSignature (master...optimize-SignSignature) https://github.com/bitcoin/bitcoin/pull/13202
< bitcoin-git>
[bitcoin] martinus closed pull request #13202: Prevent copying of in/outputs for SignSignature (master...optimize-SignSignature) https://github.com/bitcoin/bitcoin/pull/13202
< jl2012>
if I have a zero fee unconfirmed parent tx, is it possible to make it relayed/mined with CPFP? Is there any minimum fee requirement for the parent tx?
< sdaftuar>
jl2012: not currently -- transactions below 1sat/byte feerate are not accepted by default
< sdaftuar>
jl2012: and the descendant transaction can't cover the fee, the way our code is structured now