< morcos>
wumpus: MarkoFalke: what is the intended purpose of mintxfee? I was just looking back at the changes where Marco introduced GetRequiredFee, which was maybe a step in the right direction, but maybe not the proper fix.
< morcos>
Perhaps I also changed this in my estimateSmartFee PR, but i don't think so, anyway, minTxFee is not actually a minTxFee
< morcos>
it only serves as that if you are not using fee estimation or fee estimation can not return a result
< morcos>
I'm asking this because I think we should change the default value that gets used if fee estimation can't give you an answer. As rusty was pointing out in bitcoin-dev, 1000 sat/KB is just too small
< morcos>
And since this number is rarely used, i think its fine if its significantly higher, say at least 10000 sat/KB. But then I think all of the comments in the QT code are misleading, because you might often be paying a fee less than this and not depending on priority
< morcos>
Anwyay, super annoying since these are probably all translation strings, so maybe we can't fix the UI confusion for 0.12. But I still think its worth bumping the default, you don't want to fall back to 1000 sat/KB before yoru fee estimates warm up
< GitHub141>
bitcoin/master 5246180 Suhas Daftuar: Mark blocks with too many sigops as failed
< GitHub141>
bitcoin/master a10a792 Wladimir J. van der Laan: Merge pull request #7217...
< GitHub105>
[bitcoin] laanwj closed pull request #7217: Mark blocks with too many sigops as failed (master...fix-sigops-rejection) https://github.com/bitcoin/bitcoin/pull/7217
< GitHub58>
bitcoin/0.12 e08b7cb Suhas Daftuar: Mark blocks with too many sigops as failed...
< MarcoFalke>
morcos, I agree 1000 sat/KB is too low. About your question: GetRequiredFee() returns whatever is higher: the minRelayTxFee (which is needed due to the mempool) or the mintxfee (which is what the user may have set in his settings)
< MarcoFalke>
Personally I don't use fee estimates and my .conf has a hardcoded mintxfee which just fits my time-cost-tradeoff just fine.
< MarcoFalke>
I was planning to writeup about the "hard" fees in the release notes but if you are planning to change the notion of mintxfee, please let me know
< MarcoFalke>
wumpus, anything holding back 7193 ?
< wumpus>
MarcoFalke: huh, "pruning" is kind of ambigious in this context
< wumpus>
test looks good to me though
< MarcoFalke>
Should have been merged as part of the pull that introduced "pruning"
< wumpus>
let's not call it pruning please
< wumpus>
so #7193 fixes the test so that it actually tests what it purports to test
< wumpus>
what do you mean with "pruning must fail on 0.12"?
< wumpus>
*this test* must fail on 0.12?
< wumpus>
and succeed on master?
< MarcoFalke>
It must fail where trimming was not yet implemented
< MarcoFalke>
It must pass when (and after) trimming was implemented
< wumpus>
right - the test, not the process itself
< wumpus>
ok then I understand, thanks ;)
< MarcoFalke>
oops, was a typo in my comment
< morcos>
MarcoFalke: If you want to use a preset fee, then why do you use mintxfee and not paytxfee?
< morcos>
I guess my point was what is the intended use of mintxfee? it seems to function now mostly as the fall back default. it does not appear to serve as a min otherwise? but i'm not sure i'd fully thought through all the different fee configurations
< wumpus>
I'm not entirely sure either
< btcdrak>
oh finally some life
< btcdrak>
was really quiet here this morning :)
< MarcoFalke>
morcos, paytxfee can be set via settxfee
< MarcoFalke>
If you happen to settxfee too low, you might want a fall back
< MarcoFalke>
That's what I was guessing why it was there, but your concern is valid
< MarcoFalke>
so mintxfee is the "hardcoded" minimum whereas paytxfee is your "dynamic choice"
< morcos>
MarcoFalke: yeah ok , so thats a bit what i was afraid of
< morcos>
for someone like you, you would not want mintxfee to be set to say 20000 satoshis
< morcos>
because you would want the freedom to choose below that sometimes
< morcos>
but for someone using fee estimation, they'd probably rather it fall back to something that pays a bit too much rather than the other way aroud. as it only gets used very rarely
< morcos>
I mean luckily it is command line settable also
< morcos>
so no reason to obsesses on it now, and just pick something that is more sensible than 1000
< GitHub179>
bitcoin/0.12 333e1ea MarcoFalke: Bump copyright headers to 2015...
< jtimon>
wumpus I'm still on vacation and kind of waiting on #7091 before continuing with the "document-with-words-and-pictures" I promised to some people, but...what is the "right time for refactors and moveonlies"? I really don't want to miss it for the consensus encapsulation moveonly again
< jtimon>
it was supposed to be after major version forks, right? or is it after the major released is actually done (to avoid interfering with backports)?
< morcos>
wumpus: are you completely opposed to adding a new command line argument for 0.12. -defaulttxfeeifnoestimate (or something)
< morcos>
I think it makes a lot of sense for this to be a different value than -mintxfee
< morcos>
and then we can actually make fee estimate generated fees respect -mintxfee (which they currently don't)
< morcos>
I would then advocate that there is no need to change -mintxfee right now, we can leave it at 1000, but should someone desire to never ever send fees that low, they can bump that number
< morcos>
and it'll prevent them from doing so, regardless of how they pick their fees
< morcos>
-defaulttxfeeifnoestimate will only come into play if you're trying to use estimates and you can't
< morcos>
(uh not exactly, if you're trying to use estimates and you can't get an estimate for the value you are asking for, it'll make sure you pay at least that much)
< maaku>
we shouldn't be pulling numbers out of a hat for fees, mintxfee or defaulttxfeeifnoestimate or otherwise
< morcos>
so if for example you try to estimatefee 1, and it can only give you an answer for 2 and says its 25000 satoshis, but the default is 40000, then it'll make you pay 40000 in that case
< morcos>
but if you asked for 2, and got 25000 at 2, then thats fine
< morcos>
maaku: if you have no estimates (on startup) you have to pull numbers from a hat
< maaku>
morcos: or you can disable transaction creation until the fee estimator is primed
< MarcoFalke>
morcos, I'd be fine with setting mintxfee to 5000 or 10000 and mention in the release notes that ppl can change it.
< morcos>
my point is this is a relatively rare occurence, but makes much more sense to have it do something sane, than ridiculous (right now it defaults to mintxfee in all the cases i mentioned)
< maaku>
although hopefully soon we will have the consensus changes needed to prime estimation on startup
< morcos>
MarcoFalke: I think what I proposed makes a lot more sense, because it seems to me peole might say, you know what, i odn't care what fee estimation says i always want to pay at least X
< MarcoFalke>
And also adjust the GUI to show the GetRequiredFee() for estimates, in case it does not yet do this
< aj>
morcos: it'd seem more user-friendly to actually say "i don't know what fee you need to get into the next block" in that case
< morcos>
so giving them a way to do that with -mintxfee is valuable
< maaku>
morcos: defaulttxfeeifnoestimate seems just as crazy
< morcos>
aj: its not just gui, if you just do sendtoaddress() from RPC, you don't get a chance for feedback, what does it default to
< morcos>
and even in the gui, what should it default to if it doesn't know
< morcos>
maaku: why is that crazy
< aj>
morcos: RPC can give an error back :)
< maaku>
morcos: it's another number that could be just as wrong, with either too high a fee (users get angry) or too low a fee (users get stuck)
< morcos>
what we've done is moved from a regime where we always hard code a default fee to a regime where we use a fee by fee estimation the vast majority of the time, except when its impossible to
< morcos>
and then we should have a sane default
< maaku>
better to just give an error, or in the GUI a window to enter a manual fee
< morcos>
you guys, fee estimation is not that perfect
< morcos>
you can't just depend on it always giving you the right answer, bitcoind/-qt needs to be workable if feeestimation isn't working
< morcos>
for instance what you are describing would be impossible on regtest or testnet which often don't have any estimates
< aj>
morcos: it would make sense being able to explicitly set a fee for the transaction (whether GUI or RPC/cmdline), but otherwise having fee estimation always working would be a better goal...
< morcos>
its a much bigger change to eliminate fall back to default (and a worse change). i'm just trying to make it fall back to a more sane default. and i think its better to do that with a new variable, rather than misuse mintxfee
< morcos>
aj: that is the goal
< morcos>
but if its not working some small % of the time, then what should you do?
< MarcoFalke>
morcos, can you elaborate again what the difference in UX is in regard to defaulttxfeeifnoestimate vs mintxfee
< MarcoFalke>
What is "misuse"?
< MarcoFalke>
The default is: "Estimate the fee to get into <n> blocks, where <n> is user set."
< morcos>
MarcoFalke: So in the case of a user trying to use fee estimation. Right now mintxfee does not apply if fee estimation returns an answer, but if fee estimation can not return an answer for the target you are asking about, it gives you the max(any answer it did get, mintxfee).
< aj>
morcos: if i expect something to be working 100% of the time, then i want an error when it's not, not silently different behaviour. (ymmv)
< morcos>
MarcoFalke: I think the correct behavior for a user trying to use fee estimation is . If you cna't get a proper answer fee = max(answer you got, defaultfeeifnoestimate). And in all cases, the fee is maxed with mintxfee.
< morcos>
MarcoFalke: So there are 2 effective changes. It'll fall back to a more sane default and if you want to set a floor for feeestimation generated txs, you can do so now.
< morcos>
aj: So what would you like fee estimation to do if you say "estimatefee 1" and it can only give you an answer for "estimatefee 25". Silently let you send a tx expected to be confirmed in 25 blocks.
< aj>
morcos: i would like an error saying "best estimate is for 25 blocks"
< aj>
morcos: ie an error -- no transaction sent. "manual" intervention required. (well, if it's RPC it could be automated by some other script, whatever)
< morcos>
aj: there is currently no way to set the txconfirmtarget via rpc, so then you would get stuck in a position where you can't send any txs period
< MarcoFalke>
agree that the rpc error is no solution
< morcos>
sendtoaddress() is meant to just send the damn tx and do something smart for me
< aj>
morcos: (i'd rather have txconfirmtarget set as an optional parameter to sendtoaddress)
< morcos>
aj: i'm trying to patch up 0.12. we can't rework the entire way fee estimation and wallet txs work for that
< MarcoFalke>
morcos, You were right that GetRequiredFee() is ignored. (I somehow had it differently in mind)
< morcos>
i'm just trying to avoid a situation where people routinely send txs of too low fee when they just start their nodes up
< MarcoFalke>
So you'd disagree to move nFeeNeeded = std::max(nFeeNeeded, GetRequiredFee(nTxBytes)); furher down
< MarcoFalke>
(right in the line before return?)
< morcos>
MarcoFalke: I do think we should do that as long as we're not also trying to make mintxfee a sane default. as long as its a min, then we should do that. but we need a saner default
< aj>
morcos: well, i'm talking about what i /want/, not necessarily what's easy/possible :)
< morcos>
aj: well can you help us try and figure out what we should do for 0.12 instead
< morcos>
MarcoFalke: I don't think it ever respect mintxfee in the event an estimate was given. (and technically it doesn't need to respect minrelaytxfee b/c its not possible to have an estimate less than that). But yes, lets make it respect both via GetRequiredFee, but then give people a way to have a sane default, which doesn't require that all their fees be at least that default
< morcos>
These will be very minor changes. Move the GetRequiredFee and add a new commandline argument. It almost doesn't really matter if its not communicated very well b/c translations are closed or whatever. It's a default that only applies rarely.
< GitHub110>
[bitcoin] MarcoFalke opened pull request #7295: [WIP] Obey mintxfee on txconfirmtarget, Bump mintxfee (master...Mf1601-wallet-mintxfee) https://github.com/bitcoin/bitcoin/pull/7295
< MarcoFalke>
this is what I thought.
< MarcoFalke>
Haven't reviewed that closely, so it may be fatally wrong or not even compile
< morcos>
MarcoFalke: yeah but thats not what i think we shoudl do
< morcos>
THat will prevent you from sending for instance 3000 sat/KB fee txs even if fee estimation is telling you those will confirm quickly
< morcos>
I think the minimum should literally be the minimyum you ever want to send
< morcos>
I would recommend not raising the default of that
< morcos>
But the fallback value if you can't get an estimate should be larger
< morcos>
so your change to wallet.cpp stays, but we change line 2213 to nFeeNeeded = std::max(nFeeNeeded, GetArg("-fallbackfee", DEFAULT_FALLBACK_FEE)); or -defaultfeeifnoestimate or whatever you want to call it
< morcos>
line 2213 only gets execute if fee estimation is indicating to you its answer is unreliable
< morcos>
but your addition at 2221 should stay, to respect the desired minimum
< MarcoFalke>
I don't really like yet another fee arg, but what you say makes sense
< MarcoFalke>
There would be no translations for 0.12 though
< morcos>
In order to solve the pulling numbers out of a hat concern we could even just have a formula for the -fallbackfee at every release. -fallbackfee = estimatefee(2) which a 1 month decay instead of a 2.5 day decay calculated shortly before release
< morcos>
MarcoFalke: yeah, but i think the translation thing is ok, b/c users shouldn't really need to worry about setting that.
< Luke-Jr>
Frankly, we should probably replace the fee options with a %s so the same translation can be used..
< morcos>
or maybe makes more sense -fallbackfee = estimatefee(10) with a 99% threshold and a 1 month decay
< Luke-Jr>
(I might have a PR to do that, not sure)
< Luke-Jr>
morcos: 10? What is that, blocks? Way too aggressive for a fallback..
< morcos>
too fast you mean?
< Luke-Jr>
yes
< Luke-Jr>
the worst case scenario should allow for up to a month time
< morcos>
its not a minimum, its what gets used if fee estimation is broken
< morcos>
s/broken/not ready yet/
< MarcoFalke>
not a month
< Luke-Jr>
if the fee estimation is broken, it can't be block-based..
< MarcoFalke>
a day at most
< morcos>
but more importantly cant' give you an estimate for the # youre asking for
< Luke-Jr>
MarcoFalke: a week at least
< morcos>
Luke-Jr: anything more than 3 days doesnt' exist right now
< jtimon>
morcos how is defaulting to -mintxfee something ridiculous?
< morcos>
but i 100% agree we should be able to predict longer term fees
< aj>
MarcoFalke: limiting below at GetRequiredFee should be before limiting above at maxTxFee -- if you typo and set the RequiredFee crazy high, better to have it capped than not
< Luke-Jr>
morcos: but you're talking about a scenario where we *don't have estimates at all*, right?
< morcos>
i have code to push fee estimation out to a week but i never PR'ed
< Luke-Jr>
morcos: oooh, sounds useful
< morcos>
Luke-Jr: unfortunately i'm talking about both
< MarcoFalke>
jtimon, mintxfee=5000. THat will prevent you from sending for instance 3000 sat/KB fee txs even if fee estimation is telling you those will confirm quickly per morcos
< Luke-Jr>
morcos: does it by chance work with non-24/7 nodes? :D
< morcos>
Luke-Jr: We can distinguish between them though if we want to do different things in those cases
< morcos>
jtimon: because -mintxfee is often too low to be of any use whatsoever = stuck tx
< Luke-Jr>
gotta run..
< morcos>
the default if you can't get an estimate should not be stuck tx
< jtimon>
MarcoFalke: mhmm, why doesn't the code decide with min(-mintxfee, estimatedFee) instead of min(-mintxfee, estimatedFee) to solve your concern?
< jtimon>
MarcoFalke: mhmm, why doesn't the code decide with min(-mintxfee, estimatedFee) instead of max(-mintxfee, estimatedFee) to solve your concern?
< jtimon>
morcos: but -mintxfee is configurable
< morcos>
jtimon: min implies its the lowest you ever want to send regardless of what fee estimates tell you or what you accidentally choose with settxfee
< morcos>
not what you want the fall back value to be
< morcos>
it doesnt make sense to fall back to the lowest possible
< morcos>
anyway, i have to run now, now that i've gotten some of the bickering out of the way on irc, i'll submit a PR later this afternoon
< jtimon>
morcos ok, I think I get it, so what you want is max(-mintxfee, max(-defaulttxfeeifnoestimate, estimatedFee)) ?
< jtimon>
sorry, again
< jtimon>
morcos ok, I think I get it, so what you want is max(-mintxfee, min(-defaulttxfeeifnoestimate, estimatedFee)) ?
< jtimon>
I still think min(-mintxfee, estimatedFee) should is good enough though
< MarcoFalke>
good enough for 0.12.
< MarcoFalke>
We may want to do the other suggestion for 0.13 if it can't get into 12
< jtimon>
yep, we can move to max(-newoption, min(-mintxfee, estimatedFee)) later
< jtimon>
I mean, I just wanted to understand, I surredered on relay policy/acceptToMemoryPool already...
< morcos>
jtimon: what i want is max(estimatefee, -mintxfee) where estimatefee = (if tgt found: estimatefee , else: max(estimatefee, newoption))
< morcos>
currently the fee = (if tgt found: estimatefee, else: max(estimatefee, -mintxfee))
< morcos>
i will submit PR as soon as i get a chance
< jtimon>
well if estimatefee = found ? estimatedfee : maxint, then my "max(-mintxfee, min(-defaulttxfeeifnoestimate, estimatedFee))" description is equivalent
< jtimon>
but thank you for confirming that I understood you
< morcos>
your min is not correct though, there is never a min
< jtimon>
min(1, 2) == 1 ?
< morcos>
why don't you just let me write it first. :)
< morcos>
no if estimatefee does not work, it will return either 0 (if it didnt' work at all) or an estimate for a lower confirm target
< jtimon>
morcos: I just wanted to understand what you were saying, thanks. I don't plan to code, review or otherwise collaborate in anything related to relay policy/mempool acceptance in the near future, I'll just restore my previous work on jt-0.12
< jtimon>
"no if estimatefee does not work, it will return either 0 (if it didnt' work at all) or an estimate for a lower confirm target" the 0 can be changed to maxint, of course, but anyway it was just a way to say it
< morcos>
MarcoFalke: OK I created my PR. I actually changed the logic a little from what I suggested. This will not use the fallback fee if fee estimation has given you an estimate for a slightly longer confirm target. It only uses the fallback fee if it can't give you any estimates at all.
< morcos>
I think this is safest, and runs least risk of having the fallbackfee accidentally screw people by being too high
< morcos>
wumpus: I know you HATE defaults, especially ones that have to be changed over time. But I see no way around this if you want to allow txs before fee estimates are warned up. I suppose as aj suggests we could come up with a way to prevent that, but its a more invasive change.
< morcos>
I think we should come up with a rule of thumb using historical fee estimates for adjusting this default per major release. I think 20000 satoshis/KB is about what you would get for estimatefee(4) over a longer time horizon. But honestly I don't care what we use there, as long as it makes more sense than 1000. Anything between 5K-50K would be ok by me.
< morcos>
rusty: result of our discussion last night ^^^ Thanks for bringing it up!
< jtimon>
morcos, so now that you have changed the estimation to give an estimation or 0, what's wrong with chaning the zero to maxint and doing min(estimatefee, -mintxfee) without introducing any new parameter or default instead of max(-mintxfee, min(-defaulttxfeeifnoestimate, estimatedFee)) ? (not proposing that, again, just want to understand the need for a new runtime option)
< jtimon>
(apart from maybe having to update the documentation for -mintxfee)
< morcos>
i agree it could work fine with maxint, that seems unrelated to this change, gavinandresen chose the 0 error value. but i don't want to use -mintxfee because i want the fallback value to be a higher number. if you dont' have estimates you shouldn't fall back to the lowest possible value
< jtimon>
or more in words, if there's no estimate, you're doing max(-mintxfee, -defaulttxfeeifnoestimate)), why not just -mintxfee?
< jtimon>
"because i want the fallback value to be a higher number" but people can do -mintxfee=higher_number, can't they?
< jtimon>
"the lowest possible value" well, that's just part of the documentation of -mintxfee (assuming it is)
< jtimon>
documentation is easy to change
< morcos>
jtimon: yes they can, and that was originally what i wanted to do, but then it occurred to me that it makes sense to have 2 values. one of which is the minimum fee you ever want to pay, regardless of what you set with settxfee and regardless of what fee estimates tells you
< jtimon>
I guess what you don't want is being able to produce that are lower than -mintxfee, even if the estimator says it will be fine
< morcos>
and the other is what you want to pay by default if there are no fee estimates and you're trying to reduce them
< jtimon>
I guess then my question is, why is that "mininmum fee regardless of what the estimator says" necessary?
< jtimon>
isn't a default for when the estimator doesn't work enough?
< morcos>
it's probably not, but people may already use it
< morcos>
they also may use it if they are not using the estimator
< morcos>
it just seemed to big a change to completely remove what people think mintxfee does
< jtimon>
to the second point, if they don't use the estimator they would just use the single default
< morcos>
imagine someone has some external program that does their own fee estimation. And they use settxfee to tell bitcoin core what fee to pay based on that
< morcos>
they might want to be able to set a minimum, sure they could implement the minimum logic themselves
< morcos>
but it might be a change from how they are currently using it
< jtimon>
that's what I meant by adapting the documentation, right now it says "Fees (in %s/kB) smaller than this are considered zero fee for transaction creation (default: %s)"
< morcos>
yeah, well thats just completely wrong
< morcos>
but i'm not messing around with any priority related stuff, its too annoying
< jtimon>
if people think that what it does is "the minimum fee regardless of what the estimator says" we should change it one way or another
< jtimon>
who's talking about priority?
< morcos>
That's what "considered zero fee" means
< morcos>
evaluated based on priority
< morcos>
There is one more reason to keep a distinct mintxfee
< jtimon>
I see, I actually believe that was just copied from minrelaytxfee...
< jtimon>
but -mintxfee has nothing to do with priority (I may be wrong here)
< morcos>
In the future minrelaytxfee makes more sense as the relay cost. So if you want to RBF or evict, thats the increment you need to pay
< morcos>
But its not obvious that you want to be able to first place a tx for only relay cost, there may be a different mintxfee that is required
< morcos>
Anyway, i'm just trying not to get caught up in the whole mess of how people want to use mintxfee. I don't know what peole use if for, I know Marco said he used it as a safety mechanism
< jtimon>
I still don't see why two command line options (not counting minrelaytxfee) are needed
< morcos>
look at it as 3
< morcos>
min, default, max
< jtimon>
well, if we want to "fix mintxfee", maybe knowing more about "how people use it" would be interesting
< morcos>
i don't wnat to fix mintxfee. i'm not changning it. i want to give fee estimation a sane fall back value
< morcos>
an mintxfee does not seem to fit the bill, unless i change it
< jtimon>
"unless i change it" that's entirely my point
< jtimon>
but I didn't got your point about "min, default, max" either
< jtimon>
each parameter has its own default
< jtimon>
and I don't see where you are using the max
< jtimon>
anyway, never mind, I guess I will understand it in time
< jtimon>
you guys do whatever you want with this
< morcos>
i'm saying the user already has options to set: the min possible fee they want to send, the fee they will send if fee estimation doesn't work, the max possible fee they will send
< morcos>
s/has/will have/
< jtimon>
oh, ok, when you talk about "will have things" as if they were already in, it is very confusing to me
< jtimon>
oh, I guess the max is the absurd fee
< jtimon>
still, I don't see the point with the default, if you don't have estimation just use the min the user has set
< jtimon>
to me this strongly smells to "users are stupid so let's have more obscure runtime options with 'reasonable defaults" to make it harder for them to do stupid things"
< jtimon>
but is just a personal feeling, again you guys do whatever you want
< jtimon>
wumpus I'm probably leaving soon, please don't answer my previous question while I'm gone, I don't have a bouncer yet
< MarcoFalke>
botbot.me
< MarcoFalke>
will archive this channel at least
< jtimon>
MarcoFalke: yes, but it's simpler to me to just ask again than to look through the logs, at some point during the 0.13.99 I will get the "now it's the right time" answer I'm waiting for, or I'll stop asking
< morcos>
sipa: i wasn't around when the work on handling evicted txs for 0.12 went in. but what did we decide to do if you have a tx that gets evicted b/c of too low fee.
< morcos>
are those outputs then just stuck forever?
< morcos>
wumpus: sipa: i think we still need another fix for evicted txs
< morcos>
for 0.12
< morcos>
sipa's change made it so that if a tx is evicted you will not automatically respend the inputs, thats all fine and good
< morcos>
but there has to be SOME way to respend them
< morcos>
prior to this change, if you had a permanently stuck tx (say you just relayed it with way too low a fee or it got lost and its only in your mempool or whatever)
< morcos>
if you restarted your node with a higher min relay fee, then it wouldn't make it in your mempool and by the prior logic would have been conflicted and respendable
< morcos>
now its just permanently unspendable
< morcos>
ideally we'd eventually RBF these txs or soemthing, but i dont' even know what that means if its not in your mempool
< morcos>
but i think we need a way to manually be able to respend these inputs
< morcos>
we had talked back in November about adding a "forget" option, i guess that never happened?
< sipa>
morcos: they're considered respendable if there is a conflict in the chaim
< sipa>
*chain
< morcos>
sipa: ? but how would there be a conflict in the chain
< sipa>
right, we also need a way to mark an old non-confirming transaction as respendable
< morcos>
yep, its possible to manually construct and submit a double spend with createrawtransaction and that'll be accepted b/c the original is no longer in the mempool
< morcos>
but thats fairly tedious
< sipa>
agree
< morcos>
should i start by taking a look at adding a forgettransaction or something rpc call and then we can worry later about the gui implementation. i'll have to dive into the code to figure out how to represent its respendableness, unless you already know how you'd like it done
< morcos>
maybe marktransactionrespendable (which can only apply to wallet txs that arent' in your memory pool)
< sipa>
i think we can just mark a tx as conflicting with the genesis block or something :)
< gijensen>
morcos, please removing wallet transactions that aren't in the mempool is on my to-do list
< morcos>
sipa: I noticed an order of magnitude slow down in running smartfees.py . I tracked it down to your tricklenode->poisson change. I guess its not unexpected that it would cause a big slowdown on any rpc tests that require mempools to be synced?
< morcos>
I'm not sure if its really a problem. presumably its only in regtests that you would care about something like this. but smartfees.py went from 40sec to 250sec