< wangchun>
what are ANCESTOR/DESCENDANT limits? My tx failed the test.
< sdaftuar>
wangchun: starting in 0.12, there are limits on the length of unconfirmed transaction chains. "ancestors" refers to all the unconfirmed transactions that a given transaction depends on
< sdaftuar>
wangchun: "descendants" refer to the unconfirmed transactions that depend on a given one
< sdaftuar>
these limits apply to mempool acceptance of new transactions
< sdaftuar>
default is 25/25 if i remember correctly
< wangchun>
sdaftuar: my tx has only one ancestor, but it is refused
< wangchun>
sdaftuar: which limit should I increase?
< sdaftuar>
that can't be the ancestor/descendant limits unless you manually overrode the default
< sdaftuar>
what's the exact error?
< wangchun>
too-long-mempool-chain
< sdaftuar>
oh, it could be the size of the transaction i suppose
< sdaftuar>
how big is it?
< wangchun>
sdaftuar: I was trying to send another tx which only has one vin = b28fe214a938921dcbf39146b806ab954c77f81e0b58ac4e4d8c5e9f21a308fa:0 but it has about 5000 vouts
< wangchun>
at the time I was trying to send, b28fe214a938921dcbf39146b806ab954c77f81e0b58ac4e4d8c5e9f21a308fa hasn't been confirmed
< sdaftuar>
wangchun: ok, yes i forgot to mention that in addition to limits on the number of ancestors and descendants, there are also limits on the size of a transaction including ancestors and size of a transaction including descendants
< wangchun>
I already raised standard tx size limit to 500kb
< wangchun>
so should i increase these new limits too?
< sdaftuar>
yes, you can try -limitancestorsize=500 and -limitdescendantsize=500
< sdaftuar>
those values are interpreted as kb
< sdaftuar>
and default to 101
< wangchun>
the tx itself is counted in ancestor/descendant size?
< wangchun>
ancestor or descendant?
< sdaftuar>
i would bump both to be safe
< sdaftuar>
i'm double-checking the calculation
< sdaftuar>
both numbers include the transaction itself
< sdaftuar>
so if it has one unconfirmed parent, make sure that you set -limitancestorsize to be large enough for both transactions
< wangchun>
sdaftuar: ok
< GitHub3>
[bitcoin] sdaftuar opened pull request #7367: Mention mempool chain limits in release notes (0.12...update-release-notes) https://github.com/bitcoin/bitcoin/pull/7367
< GitHub55>
[bitcoin] sdaftuar opened pull request #7368: [Tests] Eliminate race condition in mempool_packages.py (master...fix-package-test) https://github.com/bitcoin/bitcoin/pull/7368
< phantomcircuit>
wangchun, why are you trying to send 5000 vouts? that seems like a lot
< phantomcircuit>
morcos, did you work on improving the utxo caching setup to avoid clearing it on flush?
< michagogo>
.whois cfields cfields
< michagogo>
er
< michagogo>
sorry
< wangchun>
phantomcircuit: daily payout
< phantomcircuit>
wangchun, you dont have a minimum payout amount of > $1 ?
< wangchun>
phantomcircuit: our threshold is 0.001 BTC
< wangchun>
that about ¥2.51
< wangchun>
s/that/that's/
< phantomcircuit>
wangchun, not even enough to buy a candy bar :P
< adnn_>
The Classic fork will be successful. This is looking like the end.
< GitHub71>
bitcoin/master 64360f1 Wladimir J. van der Laan: Make max tip age an option instead of chainparam...
< GitHub71>
bitcoin/master 47c5ed1 Wladimir J. van der Laan: Merge pull request #7208...
< GitHub60>
[bitcoin] laanwj closed pull request #7208: Make max tip age an option instead of chainparam (master...2015_12_maxtipage) https://github.com/bitcoin/bitcoin/pull/7208
< michagogo>
wumpus: I don't suppose you have any clue why the OS X gitian build is failing so spectacularly?
< MarcoFalke>
michagogo. 0.11.2 works fine?
< michagogo>
Yep, I build 0.11.2 on this setup and 0.12.0rc1 windows and Linux are fine
< michagogo>
And fanquake also had the same failure
< GitHub177>
bitcoin/master 94bdd71 Gregory Sanders: Added help text for chainwork value
< GitHub177>
bitcoin/master ae20172 Wladimir J. van der Laan: Merge pull request #7232...
< GitHub101>
[bitcoin] laanwj closed pull request #7232: [RPC] getblock: Added help text for chainwork value (master...getblockhelp) https://github.com/bitcoin/bitcoin/pull/7232
< GitHub99>
bitcoin/0.12 351ffd8 James O'Beirne: Fix help, add RPC tests for getblockheader...
< michagogo>
wumpus: Yeah, that's not it. It's the build itself that's crashing and burning, not the signer.
< michagogo>
It looks like it might be happening at the qt stage -- deps build seems fine until that point, but then something breaks in a really weird way
< MarcoFalke>
Can you downgrade gitian-builder to something older (e.g. 29c406e1174) and test again?
< MarcoFalke>
(Needs new base images)
<@wumpus>
MarcoFalke, it's just the OSX build that is failing, if it was a base image problem wouldn't all the builds fail?
< MarcoFalke>
wumpus have you been using the latest gitian builder version for the OSX build?
<@wumpus>
michagogo: no, no clue, I had some problems with LXC myself hence https://github.com/bitcoin/bitcoin/pull/7060 , but haven't heard anyone else about it (and shouldn't be macosx specific either)
<@wumpus>
MarcoFalke, yes
<@wumpus>
but I use KVM, not LXC
< michagogo>
wumpus: fanquake was having the same issue, also using LXC, and also only on the OS X build
<@wumpus>
so yes I also have issues with LXC all the time
< michagogo>
wumpus: and also, that PR is for networking, I'm preseeding the cache as mentioned in release-process
< michagogo>
wumpus: idk, it mostly works for me, until something weird happens like this
< michagogo>
Definitely not "all the time"
<@wumpus>
the PR is not only networking, it also adds some packages that I needed
<@wumpus>
(or maybe those are only networking related, I dunno)
<@wumpus>
do you have a log of what goes wrong?
< michagogo>
ca-certificates is definitely only networking
< michagogo>
that's toget the deps over https
< michagogo>
and, er...
< michagogo>
the image should already have *python*...
< michagogo>
yeah, it's in scrollback
< michagogo>
one sec
< michagogo>
wumpus: so somehow build.log is being truncated:
< GitHub117>
bitcoin/0.12 cda064c Wladimir J. van der Laan: Merge pull request #7370...
< PRab>
FYI, I've been running 0.12RC1 and maxuploadtarget appears to be working.
< PRab>
I think thats a great improvement over the previous QOS setup I had.
< MarcoFalke>
but maxuploadtarget isn't doing qos
< PRab>
Its not, but my goal is to limit it to ~50 GB per month. I don't really care about bursts very much.
< GitHub190>
[bitcoin] sdaftuar reopened pull request #7222: [WIP] RPC: Indicate which transactions are signaling opt-in RBF (master...add-optin-info) https://github.com/bitcoin/bitcoin/pull/7222
< Luke-Jr>
can we get *explicit* ACKs on #7300? otherwise someone has to go make sure the authors actually contributed the code themselves :/
< MarcoFalke>
Luke-Jr, only sipa is missing
< MarcoFalke>
need to ping when back online
< Luke-Jr>
MarcoFalke: lots of people just posted stupid "ACK everything I contribute" which doesn't really help
< Luke-Jr>
because git doesn't track who contributed things, only who wrote them
< MarcoFalke>
They are legally responsible if they commit copyfraud, how is this our problem? Or asking the other way: How would it help us to get "explicit ACKs" in case a copyfraud is detected and legally pursued?
< Luke-Jr>
MarcoFalke: it's not copyfraud necessarily
< Luke-Jr>
MarcoFalke: what if I PR some code from your repo, for example?
< Luke-Jr>
MarcoFalke: you didn't contribute it, but you wrote it and git attributes it to you
< GitHub73>
[bitcoin] toby opened pull request #7376: Payments: Allow zero value OP_RETURN in PaymentRequests (master...zeropayments) https://github.com/bitcoin/bitcoin/pull/7376
< michagogo>
wumpus: btw, I can confirm that adding python to the os x descriptor fixes it
< lpersona>
quick question for devs as I was reviewing the 0.12 RC: has the combination of auto setting the min relay fee and RBF enabled a possible attack vector?