< GitHub81>
[bitcoin] gmaxwell closed pull request #7100: Replace setInventoryKnown with a rolling bloom filter. (master...known_bloom) https://github.com/bitcoin/bitcoin/pull/7100
< GitHub159>
[bitcoin] gmaxwell closed pull request #7037: Move the blocknotify callback ahead of peer announcement. (master...notify_early) https://github.com/bitcoin/bitcoin/pull/7037
< Luke-Jr>
dcousens: there is no consensus, when reasonable dissent remains.
< dcousens>
Luke-Jr: well, this is a policy based thing isn't it?
< Luke-Jr>
dcousens: yes, it doesn't strictly *need* consensus. Just saying.
< dcousens>
and my point was, at least the impression from those IRC logs, was, that reasonable dissent didn't exist beyond your concerns
< gmaxwell>
Luke-Jr: lets try to be productive and figure out something that works for everyone.
< dcousens>
(not to down play your concerns at all, fwiw)
< Luke-Jr>
dcousens: "reasonable dissent didn't exist beyond reasonable dissent" does not make sense.
< Luke-Jr>
gmaxwell: I see no benefit whatsoever to changing the default policy in a way that is clearly harmful to Bitcoin.
< gmaxwell>
Luke-Jr: right now with the mempool behavior, inserting priority back into the process has an astronomical performance hit that directly drives people shortcutting validation. That fact remains, as does the fact that priority is useful too.
< dcousens>
well, I'm not in the position to say whether it was reasonable or not,
< gmaxwell>
Luke-Jr: slow block generation is clearly harmful to Bitcoin, in a way which I think is worse than loss of priority.
< Luke-Jr>
gmaxwell: that fact does not remain. The CNB rewrite fixed it.
< Luke-Jr>
gmaxwell: priority no longer has any significant performance penalty
< gmaxwell>
Luke-Jr: I thought you were also trying to undo the only compute priority at mempool entry change too?
< Luke-Jr>
gmaxwell: that also is insignificant, but less concerning (other than the fact that it requires miners to apply code patches to fix)
< Luke-Jr>
(I mean, fixing that also would not have a notable performance penalty)
< gmaxwell>
Luke-Jr: 'accurate' priority requires traversing every free transaction in the mempool to build the block, even if only a few are included.
< gmaxwell>
Luke-Jr: what is your view of the argument that priority is effectively only available to very few users; because most people don't have a stack of year old txouts stiting around?
< jgarzik>
how many tx per day get confirmed solely due to priority - measure field use
< Luke-Jr>
gmaxwell: "Bitcoin only works for users with lots of bitcoins during spam attacks" is much better than "Bitcoin doesn't work during spam attacks period"
< gmaxwell>
Luke-Jr: okay, I hadn't seen that PR. it might change my opinion. I think if we can prevent there from being bad performance or memory usage effects we should preserve it.
< Luke-Jr>
it adds a dobule + unsigned int per mempooltx
< Luke-Jr>
double*
< gmaxwell>
Luke-Jr: Thus far, spending one or two _cents_ for an ordinary sized transaction has been more than enough to get it past all the spam attacks that I've looked at.
< gmaxwell>
so I think the "doesn't work" is hyperbole, especially with the belief that most users simply don't have access to priority in the way that you or I do.
< dcousens>
Luke-Jr: "doesn't work"? just add a higher fee?
< Luke-Jr>
jgarzik: gmaxwell: that is the same kind of argument for skipping validation. the rate of attempted bogus blocks is zero, so why check them?
< Luke-Jr>
dcousens: many people cannot add higher fees yet
< dcousens>
Luke-Jr: why not?
< Luke-Jr>
maybe in some post-RBF-wallet world, priority can safely be removed
< gmaxwell>
Luke-Jr: I don't think it is; because the kind of harm caused is different. If there is no priority than no one has a strong assumption that there will be priority.
< dcousens>
Luke-Jr: isn't that we're moving towards?
< Luke-Jr>
dcousens: yes, but we're not there.
< gmaxwell>
Luke-Jr: good argument. So you would point out that priority can rescue transactions which would otherwise be massively delayed absent the ability to revise their fees.
< gmaxwell>
This sounds like something we could actually check. like how many transactions in blocks now (even ones cherry picked to be not-spam) would have been priority eligible at all; or would become eligible within 24-36 hours.
< dcousens>
gmaxwell: indeed
< dcousens>
morcos: ? :P
< gmaxwell>
pfft; morcos is not our stats monkey. :)
< dcousens>
haha
< Luke-Jr>
we have a stats monkey? :o
< gmaxwell>
(except for his own PRs :) )
< gmaxwell>
No, but perhaps we should.
< gmaxwell>
but where will we get the suit?
< gmaxwell>
in any case, I think if we can make an objective case that it has a use for people other than me and you, and we can prefer a performance hit.. then great. It would considerable extra work to maintain the functionality. (though this is my view; and wumpus is not around to kick my ass for it right now)
< gmaxwell>
But if either of these things are not true; then we might have to swallow the pill.
< Luke-Jr>
gmaxwell: I was not able to fully parse your longest line.
< gmaxwell>
it would be worth performing extra work to maintain priority if the above two conditions (can do it without breaking performance; can show that it would be helpful for existing users under hypothetical attack conditions)
< tulip>
I'm not sure I've seen any wallet software which actually takes priority into account when making a transaction.
< Luke-Jr>
tulip: it doesn't need to
< Luke-Jr>
and at least my Bitcoin LJR wallet does (although I understand 0.12 won't)
< dcousens>
Luke-Jr: I think tulip's point is, if the wallet doesn't account for it, then, likely, it'll probably just assume it needs to pay a higher fee under attack conditions anyway
< Luke-Jr>
dcousens: there are no wallets that correctly figure the right fee :/
< dcousens>
Luke-Jr: what is the "right" fee?
< dcousens>
its just something high enough, right?
< Luke-Jr>
dcousens: more or less
< dcousens>
well, the wallets I use usually have a 4c fee
< Luke-Jr>
dcousens: most wallets just assume it's some fixed rate per kB, and can't take spam conditions into account at all
< dcousens>
and I've never had an issue
< dcousens>
Luke-Jr: eh, the ones I use `estimatefee`
< Luke-Jr>
dcousens: this is tangent
< dcousens>
agreed
< * Luke-Jr>
ponders if there's any way to parallelize git bisect
< tulip>
Luke-Jr: I think at least one popular wallet has a proxy for Bitcoin Cores estimatefee built in.
< Luke-Jr>
estimatefee is not accurate during spam attacks
< tulip>
then I suppose no wallet estimates fees correctly.
< gmaxwell>
If an attack begins, the estimate may have been too low (though you need to overestimate if you are unable to replace); and then maybe priority saves you.
< dcousens>
gmaxwell: so maybe we need a mempool reactive estimatefee?
< Luke-Jr>
dcousens: that won't work if the spam starts after you send
< Luke-Jr>
RBF is the only way to really fix this
< gmaxwell>
estimatefee is mempool reactive, but it can't predict the future.
< dcousens>
seems we were answering two different questions, I'm talking about: "what should my fee be right now"
< dcousens>
you're talking about "what should my fee be to ensure no matter what happens, I get in the next block"
< dcousens>
the latter isn't possible in market, so, the most you can do is "right now" + RBF
< Luke-Jr>
dcousens: s/next block/next day/ or even next week
< Luke-Jr>
"what should my fee be right now" makes no sense alone
< dcousens>
"given the mempool"
< Luke-Jr>
still
< dcousens>
obviously your mempool is also subjective
< Luke-Jr>
you need a *goal*
< dcousens>
why?
< Luke-Jr>
because without a goal, there is no "should be" at all
< Luke-Jr>
might as well just do no fee, and wait for some generous miner to pick it up
< dcousens>
Luke-Jr: but you can't really reason about anything other than competing with other txs for the current block
< dcousens>
if you say my goal is "within 3 blocks", its irrelevant
< Luke-Jr>
…
< dcousens>
its still always going to be within "the next block"
< Luke-Jr>
sounds like you just defined your goal as "next block"
< dcousens>
IMHO, that can be the only role of a fee
< Luke-Jr>
…
< aj>
dcousens: "one of the next dozen blocks" is perfectly reasonable. if you want to parse that as "the next block, or else the next block, or else the next block, ..." i guess that's equivalent...
< dcousens>
"one of the next dozen blocks", but thats implying you can predict the future
< dcousens>
which is to say, at some point, if not the next, the market is going to be less competetive
< gmaxwell>
dcousens: the point is that you could target 6 blocks, then twelve blocks of higher paying spam suddenly show up.
< dcousens>
gmaxwell: thats my point, saying I target 6 blocks makes no sense IMHO
< aj>
dcousens: if a block is found in 2 minutes, there'll be less competition than for a block that's found after 1h30m
< dcousens>
because, all that really matters is whats competeting for a block right now
< gmaxwell>
dcousens: even if you target _now_ the next second 12 blocks worth of spam shows up.
< dcousens>
gmaxwell: exactly
< gmaxwell>
The estimator measures that competition retrospectively.
< dcousens>
gmaxwell: which is why "right now" + RBF is the only solution
< dcousens>
having a target other than "right now" is implying you can predict the future
< gmaxwell>
it doesn't just say "how do I get N blocks into the pool" it says "transactions paying this much too how long?"
< gmaxwell>
s/too/took/
< gmaxwell>
You can predict the future if the future is like the past; which is usually true.
< gmaxwell>
But you can't predict the black swans.
< dcousens>
gmaxwell: until something like a spam attack happens
< dcousens>
which is exactly why we're talking about this
< dcousens>
and hence, if we're talking about how to 'correctly' estimate a fee, then, "right now" + RBF is your only true best chance
< gmaxwell>
In any case, luke believes that priority is actually a useful backstop. It's certantly something that is hard for attacks to abuse, at least.
< gmaxwell>
dcousens: even N blocks + RBF is fine. N blocks, assuming nothing changes; and RBF for those times when it does.
< gmaxwell>
(keep in mind that mining is a posson process; as is new transaction entry. N blocks really does make sense statistically)
< dcousens>
gmaxwell: only if transaction priority/age matters
< gmaxwell>
No.
< gmaxwell>
Paying for block N, N>0 is making a bet on the rate of block finding and/or the rate of new transactions showing up.
< dcousens>
if 6 blocks have even competition, aka, the mempool is consistently full, they'll just continually skim the top of the pile, if you fail to make it over that threshold, no matter what your prediction was originally, you won't make it in?
< dcousens>
N blocks only makes sense if the system wasn't changing after your entry?
< gmaxwell>
Thats why the estimator is based on past performance.
< dcousens>
gmaxwell: which is why its a prediction, and not necessarily a 'correct' estimate :)
< gmaxwell>
You can look at it as the question, because of variance in tx entry and block findinging; mining goes deeper into the mempool with declining probablity the deeper it goes.
< Luke-Jr>
dcousens: right now, to get the next block, you need a fee like 0.88 mBTC; but if you're okay with up to 25 blocks, 0.01 mBTC is probably fine
< gmaxwell>
Yes, and thats where the RBF and CPFP come in. They let you use a prediction without grave outcomes.
< Luke-Jr>
and these are just small numbers
< Luke-Jr>
it makes a lot more sense to target 1, 144 (24 hours), or 1008 (1 week) blocks
< Luke-Jr>
IMO
< Luke-Jr>
the difference is fees needed for those is likely to be even more pronounced
< gmaxwell>
well 1008 is unfortunately incompatible with current mempool policy but I hope we improve that in the future. (e.g. be being able to save the mempool to disk)
< Luke-Jr>
yes, I'm just saying ideally
< gmaxwell>
(and by changing the 72 hour timeout to 1week for RBF transactions)
< Luke-Jr>
also once there's RBF for continually re-estimating fees needed, estimates can be a lot less accurate
< Luke-Jr>
can afford to be*
< gmaxwell>
As I've pointed out before, if the load has a cycle with period Q, then you cannot make efficient use of the system without at least Q worth of storage... and there clearly is a weekly cycle in load.
< Luke-Jr>
1 GB of storage just for the mempool, with 1 MB blocks.. :x
< Luke-Jr>
maybe I should be trying to solve this in my mempool work
< Luke-Jr>
s/solve/make this reasonably possible without RAM/
< gmaxwell>
well I think thats not really a big deal; mempool shouldn't be in ram.
< Luke-Jr>
right.. that's what I mean
< dcousens>
gmaxwell: the rational miner algorithm is just: mempoolTxs.sort(byFee).takeAtMost(marketDerivedN) (with size in there somewhere), therefore, if you want to get in the blockchain, you just need to be in that cut, why would a miner care about how long a transaction has been waiting for?
< Luke-Jr>
maybe I should restart my mempool changes, and this time move it to disk in the proces
< gmaxwell>
dcousens: it doesn't. But reality cares. More time means greater odds that there were a number of fast blocks that cleared out the backlog.
< gmaxwell>
(faster than new high fee tx arrived)
< dcousens>
gmaxwell: assuming a constant tx rate
< gmaxwell>
e.g. you want to get in within 25 blocks, what you end up paying would put you (say) 4 blocks deep in the mempool, but given new tx coming in, it was 12 blocks out before miners got lucky enough that you were in the top $blocksize.
< dcousens>
which still puts it as a prediction, versus just persistently watching the pool and instead competeting the entire time (no guarantee still, obv, but, its probably the most 'correct')
< gmaxwell>
or 12 blocks out before the rate of tx coming in hit a slump, or a mixture of the two.
< gmaxwell>
yes, indeed. well replacements have a cost with RBF... as you must increment by at least the entry amount.
< gmaxwell>
and you lose privacy when you use it.
< gmaxwell>
(it identifies your change)
< dcousens>
what's the privacy lost?
< dcousens>
nvm
< gmaxwell>
so I think being somewhat forward looking still make sense even with RBF.
< dcousens>
gmaxwell: indeed, its probably your best bet
< dcousens>
uh, a good bet*
< dcousens>
but you're best bet would be alternative
< dcousens>
but obviously it'll probably cost you more etc
< gmaxwell>
I mean, many things are possible including the possiblity of having an totally different unconfirmed transaction market mechenism. Like some server over tor that people connect to and do a great big auction to agree on fees and make a great big coinjoin to subit to the miners as a unit. :P
< dcousens>
haha, that'll be the day
< dcousens>
and yeah, the coinjoin would subvert the orthogonal issue of privacy loss during RBF
< dcousens>
at least, the loss of privacy to the network
< gmaxwell>
also the fact that you'd agree on .. right.
< gmaxwell>
I mean, this is effectively what joinmarket is... well joinmarket is the MVP version of that.
< aj>
gmaxwell: oh, wow, a bitcoin user's union putting the screws into the Big Business of corporate mining!
< gmaxwell>
aj: the word is "buyers cartel"
< dcousens>
haha
< aj>
gmaxwell: maybe in the literature, but that's not how you market it man!
< gmaxwell>
my earliest posts on bitcoin talk were worrying about mining cartels driving up fee prices, then I realized buyers cartels were possible too and worried less about that. :P
< gmaxwell>
an interesting thing you can do is do the bidding for fees and then round robin distribute them to transactions, so that the miners just see N transactions which each page the average feerate, and can't cherrypick the higer paying bidders.
< GitHub195>
[bitcoin] posita opened pull request #7152: Add missing automake package to deb-based UNIX install instructions. (master...posita/fix-doc-build-unix) https://github.com/bitcoin/bitcoin/pull/7152
< GitHub77>
[bitcoin] jonasschnelli closed pull request #6997: Don't use hard-coded AllowFree, as this is usually far too low. (master...no-default-free-priority) https://github.com/bitcoin/bitcoin/pull/6997
< GitHub147>
bitcoin/master b171c69 Michael Ford: [doc] Update OS X build notes for new qt5 configure...
< GitHub147>
bitcoin/master 4a63f94 Jonas Schnelli: Merge pull request #7040...
< GitHub44>
[bitcoin] jonasschnelli closed pull request #7040: [doc] Update OS X build notes for new qt5 configure (master...patch-4) https://github.com/bitcoin/bitcoin/pull/7040
< GitHub36>
bitcoin/master 74d0f90 Matt Corallo: Add method to remove a tx from CCoinsViewCache if it is unchanged
< GitHub36>
bitcoin/master b2e74bd Matt Corallo: Get the set of now-uncacheable-txn from CTxMemPool::TrimToSize
< GitHub36>
bitcoin/master 677aa3d Matt Corallo: Discard txn cache entries that were loaded for removed mempool txn
< GitHub195>
[bitcoin] laanwj closed pull request #6872: Remove UTXO cache entries when the tx they were added for is removed/does not enter mempool (master...limitucache) https://github.com/bitcoin/bitcoin/pull/6872
< jonasschnelli>
the current icon looks like a biniki, which is nice,.. but...
< wumpus>
yes I kinda like the current one
< gmaxwell>
It's one of those mcdonalds ghosts.
< wumpus>
I agree it may be more sensible to you know, put the logo there, but I don't know :-)
< gmaxwell>
hehe.
< jonasschnelli>
i think only wumpus and gavinandresen can change it
< jonasschnelli>
but no strong opinion... I juts think it looks "unfinished".
< paveljanik>
yay, we can change it weekly or per event - like google does with its logo 8)
< wumpus>
which is somehwo appropriate
< paveljanik>
lets scale the logo for today 8)
< wumpus>
it IS far from finished :-)
< jonasschnelli>
hah.. that true.
< gmaxwell>
"What do you mean you want bigger blocks? Cant you already see the pixels? they're super chunky now!"
< wumpus>
paveljanik: haha before you know you get requests to change the logo to a smaller denomination because that would sell more bitcoins *ducks*
< wumpus>
it doesn't get blockier than this
< gmaxwell>
"no no, bitcoin is deflationary; the logo must get smaller over time."
< wumpus>
that 1024x1024 logo is so subpixel-perfectly round, there's no blocks and no block chain in it!
< wumpus>
it also has no decentralization
< gmaxwell>
well a couple seconds in gimp and it can be as decentered as you want.
< wumpus>
but just moving the center is not decentralization!
< gmaxwell>
You can also _erase_ the center!
< wumpus>
ah yes a hole in the middle like some coins do have
< wumpus>
also used to happen someties with the 1 and 2 euro coins which consist of two materials, where the center dropped out
< wumpus>
not sure if symbolic
< paveljanik>
our 50CZK (~2EUR) coin is still like this...
< Luke-Jr>
just make it a QR code with a HD wallet seed that has 1 BTC in it, and see how long people take to notice
< Luke-Jr>
<.<
< Luke-Jr>
of course, since I just said that here, there's probably 10 people writing bots to automatically check it..
< wumpus>
right, from now on everyone checks our images very carefully for hidden QR codes and steganography
< gmaxwell>
I've probably mentioned it before; but there was some troll group ("GNAA") that started contributing illustrations to wikipedia that secretly coded "GNAA" in them. I knew about them all over the place, but the illustrationwere so useful we just let them keep on doing it.
< Luke-Jr>
lol
< Luke-Jr>
gmaxwell: someone checked they weren't copyrighted by other, right?
< gmaxwell>
Luke-Jr: yea, we were pretty sure they were drawing them.
< GitHub125>
[bitcoin] petertodd opened pull request #7155: Remove old replace-by-fee tests (master...2015-12-remove-old-rbf-tests) https://github.com/bitcoin/bitcoin/pull/7155
< sipa>
wumpus: there is some annoying github logic if you just clone
< wumpus>
sipa: hm?
< sipa>
wumpus: as it will keep showing here and in all existing forks that jgarzik/univalue is upstream
< sipa>
or is that the intention?
< wumpus>
that's the intent
< sipa>
ok, no problem then
< wumpus>
I've updated the description for it "ork for bitcoin changes to univalue, upstream is https://github.com/jgarzik/univalue" my idea is that it's similar to the leveldb one
< sipa>
ok
< wumpus>
but I agree on the annoying logic, there's AFAIK no way to 'unparent' a project so that it is no longer seen as a subsidiary fork
< sipa>
it is
< sipa>
you can move the repo to another project
< sipa>
which is what i should have done for secp
< sipa>
instead i just deleted & recreated
< gmaxwell>
speaking of secp256k1, you need to blank your personal repo again.
< sipa>
uh
< gmaxwell>
sipa: force push the master branch of mine onto yours, you overwrote it.
< btcdrak>
wumpus: alternatively jgarzik could push his repo to the bitcoin org
< btcdrak>
*transfer
< wumpus>
btcdrak: right
< wumpus>
btcdrak: although in this specific case I'd prefer not to, part of the reason of splitting off subtrees is that they can have their own maintenance, it's just that in this case we want this patch in for 0.12 ASAP so have to act on our own a bit
< btcdrak>
wumpus: fair, but it would be better to have a few maintainers (ie people with push access) to repositories we rely on.
< btcdrak>
I see there's only 1 PR left in the 0.12 milestone! \o/
< wumpus>
yep the univalue is the last critical one
< MarcoFalke>
wumpus, #14 didn't get merged because unit tests fail?
< wumpus>
so I'm not sure where you get that reasoning from, no one is saying that in the pull either
< wumpus>
strange, I see bitcoin's travis does report that
< wumpus>
cannot reproduce it locally
< wumpus>
MarcoFalke: I guess I know the problem, the new test files added aren't part of Makefile.am's listing, and univalue's travis build doesn't do a 'make dist'
< wumpus>
(would be better to have a proper error in the tests that a file is missing instead of having to divine it from an assertion message)
< GitHub11>
bitcoin/master db6047d Peter Todd: Take the training wheels off anti-fee-sniping...
< GitHub9>
[bitcoin] laanwj closed pull request #6216: Take the training wheels off anti-fee-sniping (master...take-training-wheels-off-fee-sniping) https://github.com/bitcoin/bitcoin/pull/6216
< GitHub11>
bitcoin/master 83f06ca Wladimir J. van der Laan: Merge pull request #6216...
< morcos>
gmaxwell: re load of cycle Q: i don't think you really need to store Q's worth of txs b/c you only need to store the backlog. it seems somewhat unlikely that your load is going to present the entire weeks worth of tx's in the first 10 mins.
< morcos>
i don't know what the right answer is and it's possibly more than the existing back log capacity which is less than 1 day
< morcos>
Luke-Jr: agree with you that estimates for 1 to 25 are kind of useless. i wrote code to modify the fee estimator to "efficiently" calculate up to 1008 while maintaining backwards compatibilty and still providing 1 through 25, but it was a tad complicated, and i was discouraged myself from reviewing it for correctness, so never published it.
< sipa>
1 to 25 what?
< morcos>
the target number of blocks
< sipa>
i miss context
< sipa>
ah, fee estimation?
< morcos>
wumpus: 7062 should be tagged with 0.12 as well. i suppose its really a bug fix, and sdaftuar is going to add another commit to affect ATMP later today
< wumpus>
ok
< morcos>
sipa: yes, Luke-Jr was saying those are all small numbers and asking about 1, 144, and 1008 would be more meaningful
< morcos>
I agree that some sort of doubling is more useful 1,2,4,8 ... 1024
< sipa>
agree
< morcos>
i can't imagine needing to distinguish between 17 and 18
< morcos>
nor is possible
< morcos>
perhaps i should just get rid of the bakcwards compatibility, and i think the code will be significantly cleaner
< morcos>
but seems like it would be nice to take advantage of your old fee_estimates.dat
< morcos>
what's the right way to convert that. build the converstion code into bitcoind or a standalone utility
< sipa>
inside bitcoind is certainly simpler
< morcos>
yeah just won't get used otherwise
< morcos>
luckly it has version information. thanks gavin!
< GitHub117>
bitcoin/master 02354c9 Luke Dashjr: Constrain rpcport default values to a single location in code
< GitHub117>
bitcoin/master df2ced5 Wladimir J. van der Laan: Merge pull request #7128...
< GitHub83>
[bitcoin] laanwj closed pull request #7128: Constrain rpcport default values to a single location in code (master...const_rpcport) https://github.com/bitcoin/bitcoin/pull/7128
< MarcoFalke>
wumpus, translation missing for $ grep -r "Choose data directory on startup (default: %u" src/
< MarcoFalke>
?
< MarcoFalke>
Can't find it in bitcoin/master nor transifex
< wumpus>
MarcoFalke: oh shit
< wumpus>
MarcoFalke: when moving the option translations to qt, it was forgotten to change _ to tr()
< wumpus>
now all those translations are lost
< MarcoFalke>
trasifex saves them?
< wumpus>
it removes them once they're out of the english (reference) translation
< wumpus>
they are still in old git but getting them back in transifex is not trivial
< btcdrak>
wow, today has been a bullrun on PR merges!
< sipa>
almost there
< btcdrak>
sdaftaur: #6312 has been rebased,
< morcos>
sipa: i have some questions about #6312
< morcos>
in thinking about how to store height and time txs are valid at
< morcos>
are we going to be ok with passing output height/time arguments through CheckLockTime to LockTime to get populated?
< morcos>
The int64_t that LockTime returns is useless as far as I can tell, it should just be a bool
< phantomcircuit>
morcos, there are way too many knobs for that stuff
< morcos>
phantomcircuit: how do you mean?
< sipa>
hmm, i thought it was used for determining time until confirmation
< phantomcircuit>
i was going through and trying to change mining knobs yesterday and had to go and read the source to make sense of them
< sipa>
but the semantics are a bit weird; you need to call twice, once with zero time and once with zero height to get actual data
< morcos>
sipa: i didn't double check that it wasn't used anywhere but how could it be. you have a height and which you could be valid and a time, its only returning one
< morcos>
phantomcircuit: i'm not talking about knobs, i'm talking about caching calculations to save time on reorgs and mining
< sipa>
if that is not the case, reverting to just a bool seems appropriate
< morcos>
which knobs were you turning
< phantomcircuit>
ok im talking about what you said like 3 hours ago :)
< morcos>
sipa: that's secondary to my question though of is it ok to pass in output arguments?
< phantomcircuit>
the priority space things
< morcos>
phantomcircuit: ok, agreed there
< sipa>
morcos: will look at the code in a few days, other things now first
< morcos>
sipa: we don't need to change that for #6312 to merge, but i just want to have some idea that we'll be able to solve the performance degradation
< morcos>
since i think solving it should hold up releasing #6312 based code in a point release
< morcos>
sipa: ok sure
< morcos>
releasing BIP68 soft fork i mean
< morcos>
phantomcircuit: checkout sdaftuars 4th commit in 7062. it just makes me happy!
< morcos>
sigh.. i guess the return value of LockTime is used for GUI and tests.. doesn't seem very valuable to me though since it's just one of the possible times you could be waiting for
< sipa>
maybe it should return a pair instead
< sipa>
with height and time both
< morcos>
yeah, thats' what i'd like to get out of it, except only the BIP68 valid height and time
< morcos>
we already have the locktime handy
< morcos>
i hope this isn't a really stupid question, but the code in the GUI that shows how long a locked transaciton is "open" for
< morcos>
how does one get a locked transacion in the wallet in the first place?
< MarcoFalke>
reindex
< morcos>
so it'll be temporarily locked while the chain catches up?