< 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] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0de7fd36de57...407d9232ef5c
< 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
< sipa> last entry:
< sipa> 1479946521 0.00098826 0.00081403 0.00067987 0.00065261 0.00065000 0.00062687 0.00061134 0.00060031 0.00058407 0.00055922
< sipa> which means that it would take at least 5 blocks to get the feerate to get accepted down to 65sat/byte
< rusty> sipa: nice!
< rusty> So it stops when it can't make a full block?
< sipa> no, it stops at 10
< sipa> i can increase it, and probably should right now
< bitcoin-git> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/407d9232ef5c...93566e0c37c5
< bitcoin-git> bitcoin/master ec4525c Matt Corallo: Move orphan processing to ActivateBestChain...
< bitcoin-git> bitcoin/master 97e2802 Matt Corallo: Erase orphans per-transaction instead of per-block
< bitcoin-git> bitcoin/master d2b88f9 Matt Corallo: Move orphan-conflict removal from main logic into a callback...
< fubu> ;)
< * luke-jr> wonders why the splashscreen has a copyright line, but nothing indicative of the license terms
< luke-jr> any objections to adding another line "Available without royalties under a free software license" or something?
< bitcoin-git> [bitcoin] luke-jr reopened pull request #8889: Qt/ModalOverlay: Use theme tooltip colours (master...overlay_theme) https://github.com/bitcoin/bitcoin/pull/8889
< luke-jr> gmaxwell: interesting
< bitcoin358> hey guys
< 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.
< Lightsword> bitcoin358, what’s the txid?
< bitcoin358> gmaxwell: what's the command?
< bitcoin358> e5a24368c0a68f0b7f6eba48dc0824c265a67300bd486e7b98c2f246c2fb9ce3
< gmaxwell> bitcoin358: getmempoolentry <txid>
< gmaxwell> looks like the whole collection is 58276 bytes.
< bitcoin358> ohh nice
< bitcoin358> I see that :)
< bitcoin358> very cool
< bitcoin358> 495d71e30565278827e4ba0930f1ca939db9e05df2c95b39dc7a81befefb2858 this is the other one
< gmaxwell> that one isn't too deep.. says there are currently 3 ancestors.
< gmaxwell> I don't have that one locally.
< bitcoin358> right, I don't have this one locally in my node either
< bitcoin358> not sure why
< gmaxwell> something could be in its history that doesn't even meet the minrelay fee...
< gmaxwell> CPFP doesn't influence passing the minrelayfee.
< Lightsword> yeah, I get 64: too-long-mempool-chain when trying to sendrawtransaction that one
< gmaxwell> Whats a txid of one of its parents?
< 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
< bitcoin358> and when push I get same 64 error
< bitcoin358> (this one: e5a24368c0a68f0b7f6eba48dc0824c265a67300bd486e7b98c2f246c2fb9ce3)
< Lightsword> well I went ahead and manually prioritized those transactions
< gmaxwell> well it would have gone nowhere.. pastebin it?
< bitcoin358> thanks Lightsword!
< bitcoin358> http://pastebin.com/Na3KrbUJ here's the raw
< Lightsword> gmaxwell, btw you can just put ?format=hex at the end of the url on a blockchain.info transaction page to get the raw hex
< gmaxwell> yea, if it has it, but something his own node rejected...
< bitcoin358> Lightsword: I didn't know that either, thank you for heads up
< gmaxwell> Lightsword: FWIW, Piuk added that at my request in this channel a couple years ago. :)
< bitcoin358> definitely helpful feature
< Lightsword> yeah, I can’t add that to mempool due to chain being too long…but the inputs should at least get mined I think
< bitcoin358> thanks man I really appreciate it
< gmaxwell> hm. there are limits other than count...there is a limit of size of 101k... but that shouldn't be exceeded either.
< bitcoin358> alright, appreciate the help gmaxwell/lightsword
< bitcoin358> I am off to bed
< bitcoin358> happy holidays to all
< gmaxwell> bitcoin358: goodnight, hopefully you'll wake to confirmed txn.
< gmaxwell> Cheers.
< bitcoin358> gmaxwell: fingers crossed :)
< Lightsword> gmaxwell, pushed that transaction to blockchain.info https://blockchain.info/tx/4db1a95e339193ad2faac2e9d02ad59d014d88ee387ad0617885c528ff664e21
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/9212 | Assertion failed: (nSendVersion != 0), function GetSendVersion, file ./net.h, line 775. · Issue #9212 · bitcoin/bitcoin · GitHub
< paveljanik> fanquake, do you have more lines in the log before this_
< paveljanik> ?
< fanquake> paveljanik Added to the issue, pretty sure these were the preceeding lines.
< Arid> Hello, a site that double your bitcoins in 48h is a scam?
< bitcoin-git> [bitcoin] paveljanik opened pull request #9216: Doc: Fix copypasted comment (master...20161124_commentfix_banmap) https://github.com/bitcoin/bitcoin/pull/9216
< bitcoin-git> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/93566e0c37c5...db5e22e0537a
< bitcoin-git> bitcoin/master 47db075 Wladimir J. van der Laan: qt: Plug many memory leaks...
< bitcoin-git> bitcoin/master 693384e Wladimir J. van der Laan: qt: Prevent thread/memory leak on exiting RPCConsole...
< bitcoin-git> bitcoin/master e4f126a Wladimir J. van der Laan: qt: Avoid splash-screen related memory leak...
< bitcoin-git> [bitcoin] laanwj closed pull request #9190: qt: Plug many memory leaks (master...2016_11_plug_leaks) https://github.com/bitcoin/bitcoin/pull/9190
< fanquake> paveljanik re #9144. You want all instances of Result:: changed to Result: ?
< gribble> https://github.com/bitcoin/bitcoin/issues/9144 | [Trivial] Correct waitforblockheight example help text by fanquake · Pull Request #9144 · bitcoin/bitcoin · GitHub
< paveljanik> fanquake, yes please. :: looks strange.
< paveljanik> but this is supermicronit, when we are there...
< paveljanik> thank you!
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/db5e22e0537a...c98f6b3d93a2
< bitcoin-git> bitcoin/master e3c4f7e fanquake: Correct help output for waitfor RPC commands
< bitcoin-git> bitcoin/master c98f6b3 MarcoFalke: Merge #9144: [Trivial] Correct waitforblockheight example help text...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #9144: [Trivial] Correct waitforblockheight example help text (master...rpc-commands) https://github.com/bitcoin/bitcoin/pull/9144
< fanquake> Have solved the afl-fuzz issue on osx by setting AFL_NO_FORKSRV=1
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c98f6b3d93a2...bc121b0eb197
< bitcoin-git> bitcoin/master f26da35 Pavel Janík: Fix copypasted comment.
< bitcoin-git> bitcoin/master bc121b0 MarcoFalke: Merge #9216: Doc: Fix copypasted comment...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #9216: Doc: Fix copypasted comment (master...20161124_commentfix_banmap) https://github.com/bitcoin/bitcoin/pull/9216
< arevutsky> Hi. I updated bitcoind to version130100. Now I see message "Warning: unknown new rules activated (versionbit 28)". Should I do something?
< bitcoin-git> [bitcoin] laanwj opened pull request #9218: qt: Show progress overlay when clicking spinner icon (master...2016_11_overlay_when_clicking_sync_icon) https://github.com/bitcoin/bitcoin/pull/9218
< jonasschnelli> wumpus: re #9218, .. I mean additionally to the spinner option.
< gribble> https://github.com/bitcoin/bitcoin/issues/9218 | qt: Show progress overlay when clicking spinner icon by laanwj · Pull Request #9218 · bitcoin/bitcoin · GitHub
< wumpus> jonasschnelli: yes, makes sense
< 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...
< gribble> https://github.com/bitcoin/bitcoin/issues/9188 | Make orphan parent fetching ask for witnesses. by gmaxwell · Pull Request #9188 · bitcoin/bitcoin · GitHub
< gmaxwell> I'd like to see it merged soon, since I think we'll want it in a 0.13.2 backport.
< gmaxwell> wumpus: I think #9189 is ready for merge.
< gribble> https://github.com/bitcoin/bitcoin/issues/9189 | Always add default_witness_commitment with GBT client support by sipa · Pull Request #9189 · bitcoin/bitcoin · GitHub
< luke-jr> gmaxwell: could that bug be potentially forking if segwit activates? :/
< gmaxwell> 9188? no.
< gmaxwell> just would result in orphan segwit txn not propagating so well.
< luke-jr> is there any way to tell if it's working, once I have it running?
< gmaxwell> debug net will no longer show it making non-witness tx fetches towards witness peers.
< luke-jr> going to run 0.13 with this backported
< luke-jr> (minor conflict on the shadowing stuff, but no big deal just a var rename)
< luke-jr> ok, node is up
< instagibbs> can someone briefly explain the use/life cycle of CReserveKey?
< luke-jr> instagibbs: it removes it from the memory keypool immediately, but only from disk when you keep it
< instagibbs> ok thanks
< bitcoin308> hey guys just wanted to thank everyone for the help last night, the massive unconf chain / backlog finally cleared out for us :)
< gmaxwell> sictransitgloria: good to hear that!
< midnightmagic> God dammit.
< oddcomet> midnightmagic: ?
< midnightmagic> oddcomet: wrong channel. I was about to ask someone to help me remember something stupid I forgot. :(