< bitcoin-git>
[bitcoin] luke-jr opened pull request #10745: Be consistent in using "opt_into_rbf" parameter for Opt-In RBF (master...opt_in_rbf-param) https://github.com/bitcoin/bitcoin/pull/10745
< bitcoin-git>
[bitcoin] jnewbery opened pull request #10747: [rpc] fix verbose argument for getblock in bitcoin-cli (master...fix_getblock_verbose_argument) https://github.com/bitcoin/bitcoin/pull/10747
< earlz>
Is there a know minimum gcc version for compiling Bitcoin Core?
< sipa>
4.8
< bitcoin-git>
[bitcoin] instagibbs opened pull request #10750: [wallet] Change bumpfee totalFee option to feeRate option (master...bumpfeerate) https://github.com/bitcoin/bitcoin/pull/10750
< morcos>
instagibbs: Just wanted to jot down some of the thoughts on future improvements to bumpfee
< morcos>
So right now bumpfee doesn't let you bump a tx which has any of its outputs spent by other mempool txs (i.e. has any descendants)
< morcos>
I think there are several reasons for this
< morcos>
One you might unintentionally pay way more in fee than you were expecting b/c you're paying for a lot of descendants
< instagibbs>
yes, rhavar brought this up on the mailing list recently
< instagibbs>
someone does a mega-sweep on top, even low fee, and you can pay lots
< morcos>
Two is the tricky issue of you aren't sure which transaction is actually going to get confirmed, the original or the replacement
< morcos>
So if your replacement isn't doing something pretty smart, you may now end up in a confused state as to whether your descendant payees should be repaid and making sure they are repaid using conflicting in puts so you don't end up double paying them
< morcos>
We should probably write up a plan for the next step in improving bumpfee functionality
< morcos>
I think the ability to bump a chain of txs where all the descendant txs are also yours ought to be feasible as a next step
< morcos>
Bumping a tx which someone else has spent seems riskier.. Perhaps if there are no new inputs added in the original chain and you have enough original change, then you could pay all their payees for them?
< instagibbs>
Are you saying the local logic cares that downstream someone double-counted payments?
< morcos>
Not exactly.. But I'm saying we don't want to design our wallet software such that in an ecosystem of people using it, they end up actually double paying other people b/c they aren't properly conflicting inputs on double spends
< morcos>
I think this also touches on why it's tricky to add new inputs on just the simple case of bumping your own tx
< sipa>
morcos, instagibbs: i wonder if an alternative to deal with rhavar's problem is to keep a counter in every tx "bytes_replaced", which accumulates any time a replacement happens through acceptance of a tx (both for rbf or eviction reasons)... and then you're required to pay that number times the relay margibal feerate
< instagibbs>
I'm not grokking tbh, I might need specific examples of what's wrong here
< sipa>
the requirement of strictly larger fee on replacement is not actually necessary to make the economics work out
< morcos>
sipa: hmmmm.... i'm not sure that's completely correct
< sipa>
the requirement is that 1) mining the new tx is economically better for miners and 2) the new tx pays for the relay of all previous txn it caused to be evicted
< morcos>
it seems to me there is a relationship between the min relay rate and the min rate which is accepted in a block, which is dictated by the size of the mempool and the decay of the mempool min fee
< morcos>
it is a slightly broken relationship to be sure
< morcos>
but i dont' think we have enough confidence that the min relay fee alone is sufficient to prevent spam that we should sort of allow "downgrading" the fees paid as long as your are still over the cumulative bytes times min relay
< instagibbs>
morcos, can you give me an example of problematic behavior which doesnt just boil down to "don't do unconfirmed chaining on top of bip125 transaction"?
< instagibbs>
s/behavior/example
< morcos>
sipa: certainly it's also not clear that would be in the best interest of miners
< morcos>
instagibbs: let me think for a min
< sipa>
morcos: i what way wouldn't it?
< morcos>
sipa: hmm.. i suppose only if blocks aren't full (hopeful smiley face)
< morcos>
but no, not even exactly that
< morcos>
if the feerates in question are all above average, then miners have lost right?
< morcos>
you could replace 10200 bytes of something paying 100 sat/B with 200 bytes of something paying 201 sat/B in your example right?
< morcos>
if the feerate at the bottom of a block ever drops below 100 sat/B then miners lost out didn't they?
< morcos>
instagibbs: ok back to your questions. i think i said two things, the second was that your previous idea of adding inputs to bumpfee might have issues
< morcos>
i think i agree that it should not have issues
< instagibbs>
it'se self-invalidating
< morcos>
although i think we'll need to carefully examine the code for handling conflicts and make sure we're not making any edge cases worse
< morcos>
but i agree we should be able to make it work
< instagibbs>
i think for descendants in mempool, the two easiest cases to think about: 1) all yours 2) none of yours
< morcos>
yes, so i think we can handle 1.
< sipa>
morcos: right, ok, i'm assuming a more rational market than currently exists, i guess
< morcos>
i think we can handle any cases that aren't 1 (including mix of yours and not yours) as long as no inputs that aren't yours are added
< morcos>
volatile != irrational does it?
< morcos>
instagibbs: but i agree we should separate those into two separate cases... and handling all yours first seems easier
< sipa>
morcos: i'm assuming near infinite demand at various fee rate levels
< sipa>
reality is much more complicated, i agree
< rhavar>
There's minor privacy implications of doing that automatically, you clearly identify which descendants are yours
< morcos>
rhavar: you mean of only having the ability to do it when all are yours?
< rhavar>
yeah
< rhavar>
(although I'm just jumping in this conversation a bit late, as I got some pings on slack i was being mentioned). But you're talking about automatically resigning and resending invalidated descendants?
< morcos>
yeah, i mean we could do both steps, but you will still be able to differentiate b/c if any of the descendant txs added inputs, those will be identified as being your descendant txs
< instagibbs>
rhavar, no just simple bump case
< rhavar>
oh, never mind then
< morcos>
rhavar: well just replacing the whole chain with a single tx that pays all the necessary payees and conflicts all the txs which pull in new in-chain inputs
< rhavar>
That's not often a sane thing to do, as the fee rates will differ
< morcos>
instagibbs: i suppose if you look at it the way i just stated it, then it doesn't matter to break it in two cases... you just wont be able to do it if any of the non-you descendnats add inputs (assuming no mixed txs)
< morcos>
and now we have to start looking at stuff in a per wallet world
< morcos>
from you has to mean from this wallet
< morcos>
which raises an interesting point... if you have wallets which overlap with other wallets, then you can run into problems conflicting only part of a tx
< morcos>
did people envision overlapping wallets?
< BlueMatt>
lol, morcos writes out "smiley face"
< instagibbs>
can you rephrase "just wont be able to do it if any of the non-you descendnats add inputs (assuming no mixed txs)" (so sorry, lots of terminology)
< morcos>
instagibbs: mixed tx = tx which spends some of your inputs and some of someone elses (can't remember exactly what we call those)
< instagibbs>
ok that cannot be replaced because we don't know fees?
< morcos>
instagibbs: that's not what i meant, but maybe i'm looking at it backwards
< morcos>
yeah i was looking at it backwards
< morcos>
what i was trying to avoid is making it so you accidentally have two pays to the same payee get confirmed that spend different inputs
< instagibbs>
that's a check feebumper does, fwiw :P
< morcos>
we do that in our own wallet by making sure we conflict at least one of the inputs between the two txs
< morcos>
so now i'm back to your original division and thinking we should distinguish between a chain of only our txs and a chain which includes someone elses child spends
< morcos>
it's just going to be a bit unexpected if they see their child spend evicted and they won't know their payee has been paid (if thats what we do by bumping the package)
< rhavar>
Is it really even worth while to support chains? :P
< morcos>
so lets just forget about that (at least for now) and only bump chains of ourself
< morcos>
support bumping them or support them? unfortunately supporting them is a long lost cause, but i do think that is still valuable
< morcos>
supporting bumpng them makes a lot of sense b/c you can save money by consolidating
< rhavar>
support bumping them. There's a lot of edge cases, like the descendant having a lower fee rate
< rhavar>
which you might not want to consolidate
< * BlueMatt>
still votes for "you cant bump if there are not-yours descendants, without a force flag, which is mostly-unsupported"
< BlueMatt>
and if there are "your" descendants, we should probably only support bumping at the bottom of the chain
< BlueMatt>
should also probably support explicit cpfp, which handles some other cases, too
< morcos>
BlueMatt: the advantage of not bumping at the bottom is you can consolidate
< morcos>
you can always choose to bump at the bottom
< BlueMatt>
well ok, but that seems like a rather separate thing, no?
< BlueMatt>
auto-merging transactions sounds like very surprising behavior for "bumpfee"
< morcos>
but yeah having a smart algo that determines whether CPFP or bump or CPFP by bumping the bottom is the best choice would be nice
< sipa>
i wonder if we should just have a set of outputs that require being paid, and just have RPCs that change that set, where every change just results in a new RBF doing the whole thing
< sipa>
and stop seeing unconfirmed transactions as transactions
< BlueMatt>
that sounds like reasonable behavior...for users who only need limited privacy
< BlueMatt>
but it sounds like a separate set of RPCs?
< morcos>
i think that at the Bitcoin Core level it's always going to be a highly advanced application, and its better not to abstract away too much about how it actually works
< morcos>
Let higher level software build on top of it that type of functionality
< sipa>
BlueMatt: yeah, it'd need to be separate... and not compatible with any receiver that wants a txid ahead of time etc
< sipa>
what do you mean with limited privacy?
< morcos>
Of course if the wallet software was separate, we could just have both
< sipa>
morcos: right, perhaps this is more something for a new wallet rather than an add-on to the existing one
< BlueMatt>
sipa: well my biggest concern with auto-merging in bumpfee is that you have people who manually selected inputs or created raw txn and all of a sudden those txn change structure massively
< sipa>
it just seems so much easier to reason about
< BlueMatt>
potentially merging outputs that they wanted to keep "separate"
< sipa>
well this wouldn't support self-selecting inputs...
< BlueMatt>
it doesnt, but Core does
< rhavar>
If merging was desired, wouldn't it be better to have done that in the first place when sending the 2nd transaction?
< BlueMatt>
in the future maybe want to push people to multiwallet, but thats far away
< sipa>
yeah, my suggestion isn't really on topic in this discussion
< morcos>
BlueMatt: I think bumpfee could take a list of txs to merge, and then could by default merge descendants of those txs, but take an option to not include descendants. In all cases, all txs must be from you. That ought to be pretty intuitive and cover all possibilites.
< sipa>
but all the reasoning about CPFP and bumping and chains of transactions makes my head hurt
< sipa>
and i think there is a possible way of how things could have worked if not for legacy, that is much easier
< BlueMatt>
morcos: maybe we should rename it "dothings" if it grows to do all kinds of magic :p
< morcos>
if blocks were bigger and came every 10 secs instead of every 10 mins, we wouldn't really have these problems
< BlueMatt>
lol
< rhavar>
I'm actually a huge fan of bumpfee taking a *list* of transactions to fee bump (and consolidate them) .. but i think all the descendant stuff is way too insanely annoying
< BlueMatt>
bitcoin also wouldnt function, but thats a separate issue
< instagibbs>
getting back to my original thing: absolute fee argument is brittle if we want to do anything dynamic with our replacements
< morcos>
instagibbs: dynamic?
< instagibbs>
maybe it can just get the fee wanted, but perhaps grab too many inputs in order to pay
< instagibbs>
adding inputs for example
< rhavar>
because if you're a high volume sender, you probably don't have a single transaction to bump ... but have a list of them
< instagibbs>
I was really hoping to avoid doing insane loops guessing how many outputs to select
< BlueMatt>
hmm, well maybe I take that back, maybe a list of txids is ok and not too huge
< morcos>
instagibbs: ah, i see
< rhavar>
the main difficulty i guess is that you'll have now multiple change addresses
< rhavar>
but that should be easy to prune
< morcos>
instagibbs: i would recommend just adding a new option which is payTxFeeRate
< morcos>
I think if you wait until my PR's that use coin control get merged, it'll be trivial to add that to bumpfee
< instagibbs>
and disable anything nice when using totalFee? :P
< morcos>
No
< morcos>
Hmm
< instagibbs>
or just be ok grabbing too many inputs
< * BlueMatt>
-> airport
< instagibbs>
and shove the excess fee into a change output?
< instagibbs>
(thinking along lines of using effective value)
< morcos>
In what cases do we grab extra inputs?
< morcos>
Only when we have no change or it's not big enough?
< morcos>
s/do/will/
< instagibbs>
no change or not enough yeah
< instagibbs>
otherwise no reason to
< BlueMatt>
morcos: in any case, I kinda like the "multiple txn to bump and auto-merge" option now that I think of it...but still think we should just go with only supporting bottom chunks of chains by default, cause thats almost always what you want to do anyways (ie cpfp, effectively)
< rhavar>
and i don't think it has any fragile and annoying logic
< morcos>
BlueMatt: For starters you can do that by bumping the bottom tx yourself... I think if you have a chain, you'll probably save more by consolidating
< morcos>
instagibbs: Yeah I think that gets tricky. It's actually going to get a bit tricky even without thinking about totalFee, I think.
< BlueMatt>
morcos: yes, agreed, but you can only support consoladating at the bottom of the chain
< BlueMatt>
if you want to consolodate mid-chain, things might break, and thats less of our issue
< morcos>
Why don't you just get it to work right only in the event that it is using automatic fee calculation or a txconfirmtarget was passed in
< morcos>
Supporting it in the totalFee case (if possible) can be later.
< morcos>
Adding a payTxFeeRate is orthogonal and as simple as above.
< instagibbs>
morcos, if we don't have that constraint, should be a fairly simple effective value selection, no?
< instagibbs>
well, we have to decide how much we want to grab, just has to be enough to pay for fee delta... if you get exact match no change, otherwise make change.
< instagibbs>
Fair enough, was just hoping it was a useless arg to have less code
< morcos>
instagibbs: don't have what constraint? that it has to work with totalFee?
< instagibbs>
Yeah. Previously it's dead-easy because you just adjust the change.
< rhavar>
or if you don't mind rabbit-holes, the "create transaction" stuff could be extended with an array of set of transaction inputs in which at least 1 must be picked
< rhavar>
and then all that logic can be reused
< rhavar>
the part that gets messy is that you need to make sure your new transaction not only conflicts with the transaction you're fee bumping -- but all previous fee bumps too
< rhavar>
so you can avoid that by only adding new inputs (at the cost of worse coin selection)
< instagibbs>
oh please, not that rabbit hole
< sipa>
instagibbs: BnB isn't hard to give a constraint "only accept combinations which include at least one input of each of these previous transactions
< instagibbs>
right nothing in principle is wrong, just the versioning thing
< instagibbs>
it's obviously correct, just hard
< morcos>
instagibbs: yeah to that point, i'd argue we should concentrate on the BnB and effective value logic first
< instagibbs>
our functionary stack uses a version of that logic to not doublespend
< morcos>
adding inputs to bumpfee sounds nice but very non-critical and might as well only do it once on top of the new coin selection logic
< instagibbs>
morcos, agreed, I was building a speculative PR on top of achow's
< instagibbs>
I'm supporting BnB as trojan horse to get effective value in (kidding, sorta)
< gmaxwell>
instagibbs: you keep complaining about EV but it doesn't seem like anyone is working to fix the bloat concern!
< instagibbs>
gmaxwell, hopefully it doesn't cause bloat for bumpfee!
< instagibbs>
:)
< instagibbs>
not trying to be flippant, you can just take negative EV outputs anyways
< gmaxwell>
it's not clear to me that being willing to take negative ev outputs is sufficient to be as de-bloating as the current stuff, maybe it is.
< gmaxwell>
rhavar: the easiest thing to do is always conflict all the earlier inputs, then you don't have to worry about failing to conflict an earlier bump. It's also better for privacy.
< gmaxwell>
BlueMatt: we can't really do the multiple txn bump and auto-merge without segwit, I think. Handling malleability is too gnarly.
< rhavar>
it's not clearly better for privacy, if the new coin selection result avoided creating change (and thus the means to cluster your wallet further)
< rhavar>
hmm never mind, i'm stupid
< instagibbs>
gmaxwell, would simulations suffice? What kind of data are people looking for?
< gmaxwell>
instagibbs: simulations would sufficice in my view. Basically just a clear argument that the new procedure won't tend to select fewer inputs than the old one.
< morcos>
gmaxwell: I'm all for putting together a simulation. But at the end of the day, I think we're going to have to wing it a bit. It's almost by definition going to put together fewer inputs.
< morcos>
We're doing stupid things now by spending uneconomical inputs
< morcos>
To fix that and prevent utxo bloat getting worse takes a more involved solution I think
< morcos>
Being smarter about what size outputs we create is one starting point
< morcos>
But the key is also being willing to purposefully pick multiple small outputs to consolidate sometimes
< morcos>
The tricky thing is when to do that
< morcos>
But I think if we start on this right after 0.15, we ought to be able to get it all done. BnB, effective value, better output creation and smart consolodiation
< morcos>
Whether we'll be 100% convinced its at least as good as before, I don't think thats going to be easy... But as long as it's not a COMPLETE disaster, we can refine it over a couple of releases.
< morcos>
Simulations are just so hard when we don't have a good sense of what the user population looks like.
< instagibbs>
morcos, you can at least compare apples to apples, which might be useful
< morcos>
Depends on what an apple is I guess
< morcos>
but like i said, i'm all for tryingsimulations out
< gmaxwell>
morcos: I don't think that is acceptable-- you don't even know what the magitude of the change is. And yes, but definition it will use fewer inputs: thats the problem. It's not like we haven't made this kind of mistake before, and it had a tremendously negative and lasting effect.
< morcos>
gmaxwell: what do you propose as an alternative?
< morcos>
my argument is that TX A which consolidates the UTXO more but contains an input with negative effective value is not clearly superior to TX B which is identical but does not contain the negative effective value input
< gmaxwell>
There isn't an alernative. We need to simulate and make compensating changes and adjust things until we have good reason to believe there won't be a seriously bad effect.
< morcos>
Simulate how?
< gmaxwell>
I disagree, especially considering that we will make UTXO which immediately have negative effective value, that sequence alone basically guarentees runaway utxo growth (I just don't know the runaway constant)
< morcos>
gmaxwell: well the "especially .." is the part i think we need to address first
< morcos>
the problems i have with simulation is they tend to simulate over a single large wallet making and receiving a series of txs
< morcos>
I don't know if there is any reason to believe that this has the same net utxo affect as an ecosystem of wallets (many probably much smaller) all making/receiving txs to each other
< gmaxwell>
If it were addressed first I would worry somewhat less. Similarly, if we had some mechenism to sweep up utxo even when they have low or slightly negative EV then there would be less cause for concern. We know that pruning unnecessary inputs caused phenominal UTXO set inflation, avoiding low EV inputs seems to me like it would do the same.
< morcos>
without understanding some structure of how tx flows look, we're at risk of producing useless results
< gmaxwell>
morcos: well murch's simulation had traces of real payment in, payment out amounts.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10752: Use quoted form when including primitives/transaction.h (master...transaction-h) https://github.com/bitcoin/bitcoin/pull/10752
< morcos>
did you read my whole spiel.. i thought we should do those other things as well
< gmaxwell>
morcos: I think it is still a big step forward to say that in at least one realistic situation the changes don't produce UTXO runaway.
< morcos>
but it's actually easier to build those other things properly on top of an effective value framework
< rhavar>
Has anyone suggested raising the "is dust" check to something more sane?
< gmaxwell>
I'm not saying they should be done, I'm saying that they must be done. And that we must have at least _some_ measurement that suggests that it won't go nuts. It doesn't have to be perfect.
< instagibbs>
rhavar, yep
< rhavar>
the current dust threshold is ludicrously low
< instagibbs>
rhavar, the BnB branch does just that, to minimize review surface, but generally raising it is a goal too
< sipa>
rhavar: using effectively output value effectively does that
< gmaxwell>
I think rhavar is talking about something different instagibbs, sipa.
< morcos>
rhavar: yeah, changing dust levels is a bit annoying, but changing the levels at which we'll create dust is a no-brainer!
< rhavar>
i'm talking about is standard
< gmaxwell>
rhavar is talking about what the network allows people to do.
< sipa>
oh
< instagibbs>
oh, then no
< rhavar>
not the coin selection itself
< gmaxwell>
rhavar: I think we should get rid of it, unfortunately it's ineffective since some large miners bypass it.
< sipa>
no sane coin selection strategy should produce anything near the current dust threshold
< rhavar>
some miners do bypass it, but it's still quite effective as a network policy
< morcos>
gmaxwell: i agree to the extent that we shouldn't raise it, but getting rid of it seems risky. it's at least somewhat of an impediment to other implementations creating stupidly small utxos
< sipa>
but there are quite a few not-so-sane coin selection algorithms out there...
< rhavar>
it stops a lot of fee attacks
< gmaxwell>
morcos: perhaps.
< rhavar>
I saw a service that recently (3 month ago?) got spammed with 3000 sat (?) outputs and ended up needing to spend over a bitcoin to clean it up
< gmaxwell>
rhavar: I don't think it does, you can reliably get txn mined that violate it.
< rhavar>
if they could've spammed with 1 sat outputs, it would've been a lot more effective
< rhavar>
and at a certain point people wouldn't even bother trying to clean it up
< rhavar>
which leads to permanent bloat
< gmaxwell>
Really the weighting in segwit is intended to be a better way of dealing with this stuff-- make the fees on creating those outputs that never get spent higher.
< rhavar>
Unless you imagine a future where spending dust has <= 0 weight :P
< gmaxwell>
I think on the order of 30% of hashpower doesn't enforce it, so I think really the only effect it has is that ignorant/lazy wallet authors get forced by relay policy to avoid creating dust, where otherwise they might not care.
< rhavar>
it's also reasonably effective at stopping spammers (who are trying to attack a specific wallet, not the network itself)
< rhavar>
they send to 1 peer who rejects it, so they use a higher amount
< gmaxwell>
rhavar: why? are they just too stupid to give their txn directly to antpool?
< rhavar>
probably
< gmaxwell>
(or whomever else is bypassing at the moment)
< gmaxwell>
fair but kind of a fragile justification.
< rhavar>
not sure how they even construct the spam, tbh. it's possible they just use a wallet (like core?) that rejects it immediately
< rhavar>
they probably aren't aware of that some miners don't enforce
< rhavar>
it's a pretty big attack vector though, i'm not sure a sane way to deal with it
< rhavar>
having wallets not spend uneconomical outputs might reduce the amounts of attacks though (as they know they can't harm someone by doing it)
< rhavar>
if i know you're using a wallet that spends the uneconomical dust, i'm a lot more likely to create it in the first place
< gmaxwell>
rhavar: segwit substantially deals with it, because it moves fees from spending outputs to creating them. (not as much as I'd like, but there are constraints on how far you can go with that)
< rhavar>
yeah i'm aware =)
< instagibbs>
he wants infinite discount :P
< gmaxwell>
And having wallets be sensible about not spending insanely uneconomical dust would be good.
< rhavar>
instagibbs: nah, i want a constant negative weight for each byte you remove from the utxo :P
< gmaxwell>
Yea, infinite discount has problems, alas... byte bloat goes up hyperbolically with the discount. Signature costs are much less of a concern than utxo but only finitely so. :)
< gmaxwell>
negative weight is even more problematic than infinite discount.
< gmaxwell>
:(
< sipa>
just surcharge for outputs
< rhavar>
unless you join the dark size and embrace almost unbounded size blocks 8)
< rhavar>
(they'd still be bounded to the size of the utxo or something lolz)
< gmaxwell>
because then you can pad up outputs then produce a yottabyte block. which then in practice you end up with multiple constraints and intractable fee estimation.
< rhavar>
I wonder how harmful it really would be if someone mined a 1GB block that also removed 1GB from the utxo :P
< sipa>
short-term, terrible
< sipa>
long-term, great
< rhavar>
as it'd kind of be a "one off" style block, as it's obviously not sustainable
< sipa>
if we as a community feel that such a UTXO reduction is necessary, the proper way would be aim for a softfork that does that, not with a massive block
< morcos>
the biggest problem with too big a discount is that fees are still sometimes effectively nil, so you can preload the utxo now for "freeish"
< rhavar>
I just meant that if you came up with a weighting scheme that made it possible
< sipa>
rhavar: ah, i see
< gmaxwell>
rhavar: the problem is that the block would get orphaned because it would take forever to propagate. It would blow up all fast propagation methods (or to avoid blowing them up we'd have to uncap relay of txn, which would make the network DOS vulnerable).
< rhavar>
fair point
< morcos>
but i'm with gmaxwell, segwit didn't go quite far enough, and if we ever do have a HF, we should definitely go a bit further.
< gmaxwell>
rhavar: so in practice miners would impose a second limit, which would often be the operable limit, and now efficient fee computation becomes intractable, because you don't know what limit you're competing for when you make the transaction. ... plus all the above just degrades network stability.
< gmaxwell>
yea, with a HF we could go a bit further than segwit. E.g. counting the txin:vout data like witness data.
< gmaxwell>
I still don't think a factor much beyond 4 is well advised, but there are some other accounting changes that would be reasonable along these lines.
< morcos>
BlueMatt has a pAtent on that though, even more problematic than segwit pAtents
< gmaxwell>
lol
< rhavar>
I can't imagine it actually causing a problem with fee estimation. If one of the limits was just an extreme thing that was sustainably being able to hit (due to it requiring continual utxo decrease) fee estimation could just ignore it
< rhavar>
although multiple limits is nasty for transaction selection :(
< rhavar>
that wasn't* able to be continually hit
< gmaxwell>
At least when I've played through these things, it seems to work out such that both limits should always be near getting hit the reason is that if the one limit isn't being hit, miners should pat their blocks creating UTXO to charge up to allow larger blocks later.
< gmaxwell>
In general I think anything where it can go negative immediately leads to non-trivial stratigies for income maximization.
< morcos>
gmaxwell: one easy change we could still make for 0.15 is if we think the amount you should be willing to discard entirely (just move to fees) should be higher than the DustThreshold
< rhavar>
Imagine you had a weight of: -2 for each byte removed from the utxo. 1 weight for each byte in the transaction. And 100 weight for each byte added to the utxo. Say you have two limits: block weight limit of 1e6 and block size limit of 100MB
< morcos>
I like these changes that can be made without redoing coin selection.
< rhavar>
it'd be impossible for the block size limit to be hit frequently
< morcos>
It would be easy to add a new calculation. GetDiscardRate = max(dustrate, min(discardrate, estimatesmartfee(1000)))
< morcos>
then if we configured discardrate default to something > 1 sat/Byte .
< morcos>
i'm the king of adding new rate variables though
< morcos>
say it was 5 sat/byte
< morcos>
at $3000 bitcoin, i think that means if you create an output thats less than 8 cents (or a bit smaller for segwit) that you'll just throw it away, and instead of redoing coin selection, you'll just add it to fee
< morcos>
you guys say sane wallets shouldn't create anything close to the dust threshold, but i think that number, which is just 5x dust would be hard to convince people is good idea
< rhavar>
what's the alternative though? redoing coin selection?
< morcos>
taking the min with estimatesmartfee(1000) though helps avoid it becoming bad if BTC denominated fees
< morcos>
drop
< morcos>
rhavar: the problem with coin selection, is you don't know if you actually could get a better result
< rhavar>
with "redoing coin selection" i mean it would contain the same logic about omitting change
< instagibbs>
the coin selection could pick a similar sized set and get to keep the change, instead of dump it
< morcos>
i suppose when we redo coin selection you'll first aim for at least min_desired_change (which is now a CENT and we aim for it exactly, but screw that, just at least)
< rhavar>
yeah, i think it's strictly better or equal (from a fee perspective, not privacy)
< morcos>
if you can't get to min_desired_change, then you'll throw everything you have in there and just take what you get, and if its less than discard (right now just dust) just throw away change
< gmaxwell>
morcos: I'm fine with discarding more. One way we could answer your concenr is making it configurable. Then people who want it different could adjust it.
< morcos>
i'll write it up.. it's small
< gmaxwell>
morcos: you could use the BNB hurestic: you can throw away up to the cost of creating and spending the change output.
< morcos>
gmaxwell: but then you're throwing it away twice
< rhavar>
"spending the change output" how does it know the cost of spending the output? At what fee rate does it use?
< gmaxwell>
morcos: I don't get the 'throwing it away twice'?
< BlueMatt>
lol, morcos' troll game is strong today
< instagibbs>
We should never be keeping change that doesn't hit that threshold, the real Q is larger but still not great.
< Murch>
gmaxwell: One of the Trezor guys did some more experiments this weekend and found that he got better results by allowing a smaller window of just the change output size
< morcos>
well you've already done the coin selection and fee calculation to pay for the change, and now you're also throwing away the change output itself,so you are potentially overpaying the newly needed fee by double the cost of creating the change
< BlueMatt>
gmaxwell: what am I being dense about? how does merging txn during a bump cause issues w/ malleability? shouldnt it go the other way if anything?
< BlueMatt>
or are you suggesting we should explicitly not support chains in your wallet without segwit (which is true)
< gmaxwell>
morcos: ah okay, don't do that.
< gmaxwell>
BlueMatt: because you don't know what will get confirmed, will the orignal or the bump get confirmed? So what you should do is make two transactions: a child and a bump. sign both, announce the child if the bump loses. (and apply this recursively for more spends)
< gmaxwell>
BlueMatt: as soon as malleability enters the picture you can't do this anymore; and you're stuck hoping the user stays online and reenters their keys so you can resign when a malleation happens.
< BlueMatt>
what do you care if the child gets confirmed?
< BlueMatt>
great! you've saved the attempted-bump in fees?
< BlueMatt>
now the user is a bit confused, and may need to bump the child again, but thats ok
< morcos>
i'm confused now too. i agree we should not attach a child to a bumper or bumpee. but what is wrong bumping something that already has a child if the bump is the merge of the parent and child?
< morcos>
if the bump loses, i don't think you've done too much harm to the child have you?
< gmaxwell>
When you create a _new_ child or a _new_ bump that adds outputs, you must also make children of all the existing ones.
< gmaxwell>
Perhaps I'm talking about something a bit more broad than bluematt.
< BlueMatt>
I believe you are talking about a very full-featured bumpfee, much more than I am thinking?
< BlueMatt>
Though I missed some of the above discussion, just waiting for them to reopen the airport after they closed it due to weather :(
< rhavar>
I think it's pretty sane to support the case of fee bumping a list of transactions, where all of them have no children.
< BlueMatt>
would those then get merged, or no?
< rhavar>
yeah
< BlueMatt>
yea, I agree, but I dont think thats an issue pre-segwit
< rhavar>
yeah, i don't see how malleability matters at all
< rhavar>
(at least if nothing has descendants)
< gmaxwell>
it doesn't matter if nothing has decendants. But BlueMatt was talking about decendants, unless I've misunderstood.
< * BlueMatt>
is kinda missing how it matters in any case, but I'm probably missing some crazy-full-featured feebump scenario that gmaxwell is thinking about
< BlueMatt>
i was, but I'm still confused
< rhavar>
if there's descendants, there's some super annoying cases. But i don't think anyone is ever going to do that, so i don't think it's worth worrying about
< rhavar>
i think it's only worth considering bumping shit without descendants, and i don't think bumping a list of them at once adds much more complexity :D
< gmaxwell>
BlueMatt: If you allow decendants comes up. You pay A then you bump A. Then you go to pay B, if you're going to chainbumb you now need to compute and sign three transactions A->B, A'->B and AB.
< gmaxwell>
BlueMatt: and you can keep applying this for any number of chains and bumps and its all great. until you consider malleability. E.g. maybe A gets mined but in malleated form, and now your payment to B is invalidated until you restart the wallet and enter your phassphrase.
< gmaxwell>
rhavar: I think without malleability there is no big deal on the bumps, just takes some code. I also think greenaddress does bumps with decendants.
< BlueMatt>
well that has nothing to do with bumping
< BlueMatt>
thats just the general-case spending-unconfirmed
< BlueMatt>
and I dont see why you need to sign A'->B, you're just merging?
< morcos>
i think what we are talking about is a tx with descendants (or multiple txs each with descendants) and then bumpfee bumping all of them at once
< morcos>
the thing we already don't allow, which i agree we should not change, is adding a child to a tx that is a bumper or has been bumped
< morcos>
i don't see any issue with bumping a tx with children (presumably if the children are all yours) as long as you also pay all their outputs as well
< gmaxwell>
morcos: no, it's a problem with making a child of a transaction that has a bump.
< morcos>
ok agreed
< gmaxwell>
you can bump something that has a child without any big complexity, but you can't produce a child of anything that has been bumped.