< rusty>
sipa: trying to find where the relayfeerate changes, other than manual configuration...
< sipa>
rusty: it doesn't
< rusty>
sipa: ah, right. Indeed, I agree that nodes should be scaling their min output level by feerate. But as long as they propagate that's a v1.1 problem.
< sipa>
rusty: maybe for DoS reasons it should be changed at some point, but even then i can't imagine that happens in core without making sure it's certain to be consistently higher than actual feerates
< bitcoin-git>
bitcoin/master ca8549d Gregory Maxwell: Always drop the least preferred HB peer when adding a new one....
< bitcoin-git>
bitcoin/master 407d923 Pieter Wuille: Merge #9199: Always drop the least preferred HB peer when adding a new one....
< bitcoin-git>
[bitcoin] sipa closed pull request #9199: Always drop the least preferred HB peer when adding a new one. (master...remove_high_bandwidth_zombies) https://github.com/bitcoin/bitcoin/pull/9199
< rusty>
gmaxwell: it's your fault I now have 'while sleep 10; do bitcoin-cli getblocktemplate | awk '/"fee"/ { FEES += $2 } /"height"/ { HEIGHT = $2 } END { print HEIGHT,FEES }'; done' running in a terminal here, BTW.
< sipa>
rusty: i have a patch that builds a max-size block, removes the included transactions from the mempool, then builds another max-size block, etc
< sipa>
rusty: and then store the min feerate of each of those built blocks
< bitcoin358>
quick question, at what point does a .13 node start dropping tx from mem pool
< bitcoin358>
assuming default mem pool size of 300mb, when that is reached, what happens?
< gmaxwell>
the lowest feerate transaction is dropped.
< bitcoin358>
thanks greg
< gmaxwell>
and the fee filter is increased to tell peers to stop sending transactions with feerates below that-- until there is room again.
< bitcoin358>
so as a counterpoint
< bitcoin358>
is there any decent way to tell how many mempools still have your transaction in them
< bitcoin358>
basically i'm thinking of a business case where you are sending coins to someone, but it doesn't confirm, and the mempool explodes, and they request that you resend
< gmaxwell>
No. 'how many' isn't particularly important either, what is important is being in the mempools of miners.
< bitcoin358>
is there a decent way to get a feel for what % of the network or mining pools have still in their mempool, so as to alleviate the risk of double payment
< gmaxwell>
Then you resend and conflict with the original transaction, it would _never_ be safe to repay without conflicting, regardless of what some mempool in a forrest of nodes is doing.
< bitcoin358>
I hear you
< bitcoin358>
what about, in the event, that you have chained unconfirmed inputs
< gmaxwell>
A miner could happily include any valid transaction they liked... and some miners have APIs to pay them out of band to poke fees into their blocks.
< bitcoin358>
so customer A wants a manual resend, you do a doublespend with a bigger fee
< gmaxwell>
bitcoin358: add more fees later in the chain and enjoy giving them to miners running Bitcoin Core, since it will happily notice those fees later in the chain.
< bitcoin358>
but customer B also received coins that came after A, and are relying on his inputs
< bitcoin358>
right so
< bitcoin358>
I am actually trying to do just that, right now!
< bitcoin358>
however, the issue is I run into the 64 error, mempool chain too long
< bitcoin358>
I have actually been taking advantage of CPFP the last 48 hours with great success
< bitcoin358>
but I have this one monster transaction I received and I am trying to get it confirmed by spending it forward with a higher fee, and I get the 64 error
< gmaxwell>
welp, --- error means what it says, nodes won't handle more than depth 25 for that fee analysis. You can't add more fees on a chain that deep until part of it confirms.
< bitcoin358>
dang
< gmaxwell>
is there change on a shorter part of the chain you could potentially add fee via?
< bitcoin358>
I think so but unfortunately I'm not the node operator, I just received a payment from them
< gmaxwell>
e.g. A -> B -> D, D' D -> E -> f ... but D' is still unspent early in the chain?
< bitcoin358>
I was hoping I could bump their whole cluster of transactions by being generous on my own but yeah
< bitcoin358>
they are running .11.... and causing all sorts of problems
< gmaxwell>
you could if not for the depth limit, unfortunately there had to be a cutoff there to avoid the CPFP analysis taking unbounded cpu.
< bitcoin358>
i hear you 100%, oh well
< bitcoin358>
hopefully the mempool subsides tomorrow on the holiday and we get a little relief
< gmaxwell>
well a luckly run of blocks will happen at some point and clear things out.
< bitcoin358>
*fingers crossed* lol
< bitcoin358>
I have like 1.5 BTC from this guy stuck in limbo because he paid $2 on a 25 kb transaction ..
< bitcoin358>
CPFP is working great otherwise
< bitcoin358>
:)
< Lightsword>
bitcoin358, if you get stuck for too long I can probably mine it for you
< gmaxwell>
yea, I've seen a fair amount of it.
< bitcoin358>
thanks man, I will ping you if it doesn't clear in the next day or so
< bitcoin358>
I would honestly be down to pay $10 or whatever but the issue is probably that the entire chain it's relying on is maybe ... 100kb? who knows
< gmaxwell>
bitcoin358: if you're running modern (0.13+) bitcoind it's easy to find out.
< bitcoin358>
I am going to try to raw transact the first one to myself with a higher fee
< bitcoin358>
my math seems to suggest if I want it to confirm in 1-2 blocks I need to pay about 0.0392
< bitcoin358>
is that math right
< bitcoin358>
56kb paying 7 satoshi/byte
< Lightsword>
0b34a5f31f6bc1ecad957a3af2a927b454992b565a8786c21e8d7f9e7743a6d1 looks like
< gmaxwell>
21inc's estimator is saying, about 70 to get in 2 blocks-- though there are at least a few miners that don't CPFP. so.. it would be longer than two blocks perhaps. Nothing you can do about that.
< bitcoin358>
ah right, glossed over there's 6 zeros here so you're right
< bitcoin358>
70 satoshi
< bitcoin358>
.039 btc alright
< bitcoin358>
I'm going to yolo it
< bitcoin358>
and tell this dude to upgrade his node and stop making 25 kb transactions
< gmaxwell>
Lightsword: yea, I get a count of 25 on that one.
< bitcoin358>
weird okay so
< bitcoin358>
I just did a rawtx spending the one that's 56kb that only has 2 ancestors
< gmaxwell>
bitcoin358: (in case you're watching logs) if you do nag the author of this chain of unconfirmed txn, they should really be encouraged to sendmany. This whole graph of unconfirmed txn could have been reduced down to a fraction of its size as a single sendmany.
< fanquake>
Just experienced #9212, running master on mainnet
< paveljanik>
Looks like more people need fork to eat the dinner today. My son just gave me one to eat the desert...
< Victorsueca>
y u no spoon?
< gmaxwell>
Can some people other than me run #9188 and report testing results (ideally on testnet) just so I'm not the only person who has tested it...