< Lightsword>
think we can add an option to force bump fee even if opt-in RBF was not used? often transactions will relay regardless since they wouldn’t already be in mempools
< gmaxwell>
Lightsword: ugh. forcing the creation of a transaction that we won't relay ourselves is .. a bit ugly. :(
< Lightsword>
gmaxwell, well it would make sense to allow ourselves to relay it as well
< sipa>
Lightsword: that is equivalent to implementing full RBF
< sipa>
and we're not going to make an exception for your own transaction, as that's a privacy leak
< Lightsword>
sipa, would it make sense to have it only under a force flag? I’m mainly thinking it’s better to have the bumpfee option than having to do it manually
< sipa>
i think the only reasonable way to do it is to first have someone use abandontransaction (which will only work if it's already evicted from the mempool), and then a wrapper to recreate an abandoned transaction with a higher fee (but guaranteeing that some if its inputs are spent again)
< sipa>
that way you don't need an exception for relay
< luke-jr>
gmaxwell: what if we would relay it ourselves because it's dropped out of our mempool?
< luke-jr>
sipa: must it be abandoned explicitly?
< sipa>
luke-jr: otherwise the wallet won't allow you to respend
< luke-jr>
sipa: bumpfee will?
< sipa>
luke-jr: bumpfee won't let you bump without it being bip125
< sipa>
or are you saying that bumpfee should do that, IF the result would be acceptable to our own mempool?
< luke-jr>
sipa: and if a "force" option is provided
< sipa>
that seems reasonable
< Lightsword>
the user can restart their node to force the transaction out of the mempool right?
< sipa>
if they delete mempool.dat, yes
< Lightsword>
is it possible to manually evict a transaction from the mempool by doing a negative prioritisetransaction call so it goes below the minfee needed to stay in the mempool?
< morcos>
Lightsword: I think that would only work if the mempool was full (and some other transaction came in to cause limiting)
< morcos>
however a restart combined with a negative prioritisetransaction might work
< Lightsword>
morcos, mempool is normally full with the way the limiter currently works right?
< sipa>
it won't be full shortly after a new block was found
< morcos>
it doesn't seem so recently.. and even if the network is busy it tends to not stay full b/c fee filter stops you getting cheap replacements
< Lightsword>
isn’t fee filter mostly based on feerate of recently evicted transactions?
< morcos>
sipa: i'm not around next week and #9371 or otherwise is necessary for 0.14.. could you take a look and if you agree with the approach, we could at least tag the PR 0.14 and i can give someone else repo access to carry it over the finish line
< morcos>
right now just the issue is tagged for 0.14, b/c we never agreed what type of solution we want
< sipa>
morcos: will do
< morcos>
Lightsword: yes, but the minfee which the fee filter is set to = incrementalRelayRate (same as minRelayTxFee before 0.14) + the evicted rate. in practice, this is 1000 sat/KB + 1000 sat/KB
< morcos>
therefore excluding all the garbage between 1000-2000 sat/KB which is the only way your mempool fills up
< morcos>
so until the fee rate declines below 1000 sat/KB again... your mempool tends to get less full...
< morcos>
that was at least true with 3 day time expiration... with 2 week time expiration in 0.14, your mempool might stay closer to full? depending on current tx supply
< gmaxwell>
sipa: well we could allow abandond transactions to get bumped.
< gmaxwell>
but we aren't very permissive with abandonment.
< morcos>
i think we should try as hard as possible to not ever recommend abandoning
< morcos>
not that it doens't work well
< morcos>
but i think it'll inevitably lead to people spending different outputs and having both txs confirm
< morcos>
in that sense, i kind of think Lightsword is right... if you have a "stuck" transaction and you forgot to make it opt-in RBF, it's probably better to still let you bumpfee it
< Lightsword>
I think it would be a good idea to let one broadcast as well with a force flag
< morcos>
otherwise you are going to use abandontransaction and try to do it manually and end up screwing yourself
< Lightsword>
since it’s a major useability issue
< sipa>
gmaxwell: i think what luke is suggesting is allowing /abandonable/ transactions to be bumped
< sipa>
i do think that's better... first fully abandoning them would perhaps introduce a race conditions where you respend the coins in between the abandon and the bump
< gmaxwell>
I think thats reasonable, but the set of abandonable transactions is so small as to make it hardly matter.
< sipa>
evicted from mempool is enough, no?
< morcos>
but that's basically not going to happen, unless you finagle it, and if you're going to finagle it, well why not just let you do it anyway
< morcos>
whats the downside, privacy leak?
< gmaxwell>
sipa: what morcos said.
< sipa>
is it reasonable to expect your transaction will propagate otherwise?
< sipa>
i would expect relatively similar mempool among your peers
< gmaxwell>
the major downside is that we'll end up with txn in our wallet that we don't expect to relay, which is something we kind of assume doesn't happen.
< gmaxwell>
sipa: well except peers change over time, so maybe not. or you might have a full rbf peer.
< morcos>
or you might want to construct a tx to submit in some out of band way to a miner
< gmaxwell>
yea, you might not really care about the relay at all.. just plan on extracting the hex and giving it to the antpool doublespending service (I mean free txn priority service)
< Lightsword>
sipa, I think there are enough nodes with inconsistant relay policy that you have a good chance of propagation even if your own mempool doesn’t accept the transaction, for example nodes with much more strict mempool limiting may accept it
< sipa>
i wonder if that's a temporary thing
< Lightsword>
well extreme mempool limiting is usually due to resource limitations(reducing ram usage)
< Lightsword>
I think in this case the privacy risks are far less of a risk than users messing up the feebump by trying to do it manually and using the wrong utxo’s
< gmaxwell>
well because bumpfee can only diminish change, it's already pretty limited.
< bitcoin-git>
[bitcoin] luke-jr opened pull request #9621: Define, check, and use MIN_TRANSACTION_SIZE as a const (master...cleanup_mintxsize) https://github.com/bitcoin/bitcoin/pull/9621
< bitcoin-git>
[bitcoin] kallewoof opened pull request #9622: [rpc] Bug-fix: listsinceblock should include lost transactions when parameter is a reorg'd block (master...listsinceblock-include-lost-txs) https://github.com/bitcoin/bitcoin/pull/9622
< gmaxwell>
sipa: please close 9616
< gmaxwell>
"you promised it would only be a three-line change and you delivered :)" best pull request review comment ever.
< wumpus>
yeah I'm not sure whether it makes sense to do now - a pure refactor is not a bugfix but neither is it a feature - depends on the regression risk I suppose
< BlueMatt>
so it looks like the archlinux-arm bitcoin packages are being built using a PKGBUILD different from the one published and building a modified 0.13.2 source tree
< BlueMatt>
over under on a backdoor?
< sipa>
ugh
< BlueMatt>
they're looking into it (the alarm guys)
< BlueMatt>
(thats ArchLinux-ARM)
< cfields>
jonasschnelli: crontab (to fetch sources on fallback server) wasn't running. should be fixed now, so fallback should work if sf.net 404's
< sipa>
morcos: "all i do is sendtoaddress" - "the manual CPFP transaction i created"
< bitcoin-git>
[bitcoin] jnewbery opened pull request #9624: [Trivial] fix logging typo in FlushStateToDisk() (master...TrivialTypo) https://github.com/bitcoin/bitcoin/pull/9624
< cfields>
BlueMatt: holy crap, arch packages are built by hand and uploaded?
< BlueMatt>
cfields: on regular arch, yes!
< BlueMatt>
cfields: (as in, holy crap, dont trust arch packages)
< cfields>
that's terrifying
< BlueMatt>
cfields: archlinux-arm has a build farm, apparently
< BlueMatt>
cfields: everything is, when you look closely
< cfields>
i went looking for a build log, only to come to the depressing realization :(
< cfields>
BlueMatt: looks like it's possible to me that their builder gets confused by the tag version, and doesn't end up checking out the tag
< BlueMatt>
cfields: I dont think there is a single linux distro which I would trust almost in any way at all....even the ones with build farms end up accepting sigs from any one of a million people to update the source files :/
< BlueMatt>
cfields: the binary reports "v0.13.2.0-0d719145b-dirty"
< BlueMatt>
that commit is v0.13.2
< BlueMatt>
(though dunno where the ".0" came from - is that normal for git describe?)
< cfields>
hmm
< BlueMatt>
the non-arm archlinux binary properly reports "v0.13.2"
< BlueMatt>
well, I didnt run it, just strings'd it
< cfields>
yes, i'm looking at the same now
< cfields>
ok good, well at least it's based on the right version
< bitcoin-git>
[bitcoin] morcos opened pull request #9625: Increase minimum debug.log size to 9MB after shrink. (master...shrinkless) https://github.com/bitcoin/bitcoin/pull/9625
< BlueMatt>
"based on" i mean the "-dirty" coul be anything
< BlueMatt>
but was still unable to reproduce the PKGBUILD hash claimed in the .BUILDINFO file
< cfields>
where's the .BUILDINFO coming from?
< BlueMatt>
the .pkg.tar.xz thing that is the package itself has a .BUILDINFO file in it
< cfields>
ah, thanks. grabbing
< BlueMatt>
(note that the pkgbuild_sha256sum in the non-arm archlinux packages also doesnt match, but I cant figure out what modifications might be happening before that hash is calculated)
< morcos>
gmaxwell: that -shrinkdebugfile is only defaulted on if no debug options are present, you don't think 9MB is enough then?
< gmaxwell>
morcos: I know-- my though is that I've troubleshoot people on nodes that went out of sync two weeks before, and their log was full of connect/disconnect messages. Maybe you're right that 9MB is enough. I do sort of wish critical errors went into a seperate very low volume log that was never rotated.
< morcos>
yeah i certainly don't mind doing more, was just tryign to make the patch as unobjectionable as possible
< gmaxwell>
yea, it's fine.
< jonasschnelli>
morcos: The new CWallet::IsChange() function does not work after a zapwallettx, right?
< morcos>
hmm, jonasschnelli i think your question confused me. Isn't that function old? And I'm not very familiar with zapwallettx, so not really sure what it would do?
< jonasschnelli>
morcos: I though it's a new one... I'm doing my bumpfee review pretty late. I know.. but I just had the feeling that detecting the change output based on the address book is kinda-bad
< jonasschnelli>
Though,... is change when it's _not_ in the address book. I guess bumpfee should still work after a zapwallettx
< morcos>
well as far as i can tell it doesn't really matter... the failure modes are : 1) it can't find change (or finds more than 1) and can't bump the tx or 2) it reduces another output to you instead of change, doesn't seem so bad
< jonasschnelli>
Yes. Right.
< jonasschnelli>
Have you guys already started working on the case where bumping requires new input?
< jonasschnelli>
Like when you use subtractfeefromamount
< ryanofsky>
have not done work on that
< jonasschnelli>
ryanofsky: thanks for the info. Maybe its not worth the effort..
< gmaxwell>
being able to spend bumped outputs is more important in that case... since the bumps will tie up more inputs.
< morcos>
I don't think that makes sense for combination with subtract fee from amount
< morcos>
well at least i think we should more narrowly define what we are trying to accomplish wiht subtractfeefromamount anyway..
< jonasschnelli>
morcos: If you have a single input, assume 25BTC, and you spend the 25BTC with subtract-fee-from-amount you endup with a tx without change.
< morcos>
it causes a lot of complication in the code when as far as i can tell the main use case is just send all this money over there
< jonasschnelli>
I think its a fantastic feature (subtract fee from amount).
< morcos>
yeah so the way to bump that is reduce the output in my opinion
< jonasschnelli>
From other wallet uses-cases, I know that people are trying to send-out the wallet funds with often leaving some coins behind.
< morcos>
yes, i agree thats a use case worse supporting
< morcos>
but we use it in a more general sense... which is annoying... like reducing the outputs even further to give ourselves dust change if we would have had sub-dust change... see #9343
< jonasschnelli>
Another wild thought,... we should probably reject self created transactions with absurde high fee during signrawtransaction (additional to ATM over sendrawtx)
< gmaxwell>
morcos: there are a bunch of small issues, I need to find the branch and pick them up. It mishandles locked wallets (it should reject trying to import a private key when the wallet is locked), if you ask it to import a key without a birthday it just assumes now and can cause funds loss, it's easy to cause it to rescan everything when you didn't think it would... node out of comission for hours
< gmaxwell>
...
< morcos>
right.. well nudge nudge, 0.14 is in the car with the engine running..
< BlueMatt>
gmaxwell: please at least file issues for known issues and ask to have them marked 0.14....
< gmaxwell>
sorry for whining, but I already opened an issue for one of them where I _need_ feedback before doing anything, and only morcos commented a bit. #9491
< gmaxwell>
this is not convincing me of the utility of opening more issues.
< BlueMatt>
behind on things, sorry :/
< BlueMatt>
gmaxwell: opening issues gives us all a view into how close we are to release, and also ensures we dont end up with stuff outstanding until a day before rc
< BlueMatt>
gmaxwell: there are multiple reasons to open issues
< gmaxwell>
I don't disagree with anything you are saying there. This doesn't change that if you want people opening issues, you need to respond to the issues they open. Asking if fine too, but it will be ultimately ineffective if people feel that they're wasting their time.
< BlueMatt>
sorry, somehow I had #9491 marked in my mental list of "oh, that one has an open pr for it to fix it already"
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #9626: Clean up a few CConnman cs_vNodes/CNode things (master...2017-01-remove-broken-unused-funcs) https://github.com/bitcoin/bitcoin/pull/9626
< cfields>
BlueMatt: thanks for remembering those
< BlueMatt>
can we mark #9622 as 0.14 since its a pretty big bugfix and isnt too complicated?