--- Day changed Sat Jan 21 2017
00:06 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
00:08 -!- moli_ [~molly@unaffiliated/molly] has quit [Client Quit]     
00:09 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
00:16 -!- wofiis [mint@gateway/vpn/mullvad/x-qinqsftskyixbnfo] has quit [Quit: Leaving]     
00:22 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has joined #bitcoin-core-dev     
00:35 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
01:02 -!- Netmage [~Netmage@p5B0A5402.dip0.t-ipconnect.de] has quit [Remote host closed the connection]     
01:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
01:06 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
01:30 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
01:42 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]     
01:43 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev     
01:43 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
01:44 -!- waxwing [~waxwing@14.174.32.23] has quit [Ping timeout: 240 seconds]     
02:03 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit []     
02:40 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-roicwuxkobfqtvzp] has joined #bitcoin-core-dev     
02:53 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
02:54 -!- whphhg [~whphhg@unaffiliated/whphhg] has quit [Quit: WeeChat 1.7]     
02:55 -!- whphhg [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev     
02:55 -!- str4d [~str4d@31.131.246.13] has joined #bitcoin-core-dev     
02:59 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 240 seconds]     
03:00 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
03:24 -!- waxwing [~waxwing@14.174.32.23] has joined #bitcoin-core-dev     
03:29 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Quit: Soligor]     
03:31 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
03:33 -!- str4d [~str4d@31.131.246.13] has quit [Ping timeout: 255 seconds]     
03:42 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke]     
03:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:52 -!- afk11 [~user@unaffiliated/afk11] has joined #bitcoin-core-dev     
03:55 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 258 seconds]     
03:59 -!- Alina-malina [~Alina-mal@37.157.216.129] has joined #bitcoin-core-dev     
04:08 -!- Alina-malina [~Alina-mal@37.157.216.129] has quit [Ping timeout: 255 seconds]     
04:09 -!- Netmage [~Netmage@p5B0A5402.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
04:11 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
04:14 -!- Alina-malina [~Alina-mal@37.157.216.129] has joined #bitcoin-core-dev     
04:48 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 256 seconds]     
04:59 -!- Alina-malina [~Alina-mal@37.157.216.129] has quit [Changing host]     
04:59 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
05:15 -!- cryptapus_afk [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev     
05:15 -!- cryptapus_afk [~cryptapus@jupiter.osmus.org] has quit [Changing host]     
05:15 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
05:30 -!- gluytium [U2FsdGVkX1@ma.sdf.org] has joined #bitcoin-core-dev     
05:30 -!- BCBot_ [~BCBot@46.101.246.115] has quit [Remote host closed the connection]     
05:31 -!- BCBot [~BCBot@46.101.246.115] has joined #bitcoin-core-dev     
05:38 -!- afk11 [~user@unaffiliated/afk11] has quit [Ping timeout: 255 seconds]     
05:45 -!- afk11 [~user@2a02:a210:301:7980:b1e4:3905:dd7e:dee8] has joined #bitcoin-core-dev     
06:07 -!- cannon-c is now known as cannon-c_AFK     
06:17 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
06:17 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 276 seconds]     
06:53 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev     
07:00 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
07:00 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
07:31 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
07:38 -!- waxwing [~waxwing@14.174.32.23] has quit [Ping timeout: 240 seconds]     
07:39 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 276 seconds]     
07:42 -!- cdecker [~cdecker@mail.snyke.net] has quit [Remote host closed the connection]     
07:42 -!- cdecker [~cdecker@mail.snyke.net] has joined #bitcoin-core-dev     
08:22 -!- cdecker [~cdecker@mail.snyke.net] has quit [Quit: ZNC - http://znc.in]     
08:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
08:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
08:30 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
08:32 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 264 seconds]     
08:33 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
08:33 -!- _mn3monic [~guido@176.9.68.68] has quit [Ping timeout: 272 seconds]     
08:36 -!- _mn3monic [~guido@176.9.68.68] has joined #bitcoin-core-dev     
08:46 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
09:30 -!- Soligor_ [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
09:33 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 245 seconds]     
09:59 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]     
10:00 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev     
10:02 -!- Soligor_ is now known as Soligor     
10:21 -!- waxwing [~waxwing@14.174.32.23] has joined #bitcoin-core-dev     
10:29 < gmaxwell> should UpdatePreferredDownload be checking ffeeler?
10:36 < BlueMatt> probably?
10:37 < BlueMatt> I'm hugely concerned about current fee estimation algorithms - they have effectively put floors on what they will return, when things an order of magnitude or less fee will easily get confirmed :(
10:38 < gmaxwell> huh?
10:38 < BlueMatt> eg currently, because no one creates txn with things less than 50 sat/byte, no fee estimation will ever return anything less than that
10:39 < BlueMatt> but things with 10 often easily get confirmed after 6 or 10 blocks (now, though that can vary to a full day sometimes)
10:41 -!- whphhg [~whphhg@unaffiliated/whphhg] has quit [Quit: Leaving]     
10:42 -!- whphhg [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev     
10:43 < BlueMatt> eg i just tested a tx with 0.1 sat/byte fee, and it had issues propagating, but was even still confirmed in 5 blocks
10:43 < BlueMatt> but every fee estimation anywhere returns >50 sat/byte
10:45 < sipa> 0.1 sat/byte? you mean 25 sat for a full transaction?
10:45 < sipa> are you sure you're not off by an order of magnitude or 2?
10:45 < BlueMatt> https://btc.com/1b4c848a30a73c805b36ec19142b9407fb74ffe9e41000ee87fadea8c6f582b5
10:45 < BlueMatt> yes, 25 sat for the whole thing
10:46 < gmaxwell> 1s/b is absurdly low, I don't think having a floor around that point is a problem.
10:46 < gmaxwell> we do need to have a meaningful relay floor to prevent DOS attacks.
10:46 < BlueMatt> sure, 1s/b whatever, but the floor is currently like 50
10:46 < BlueMatt> i'm not complaining about relay issues, i dont care it wasnt relayed
10:47 < BlueMatt> the issue is that all fee estimation stuff is currently off by an order of magnitude
10:50 < BlueMatt> ironically the only one i could find that has reasonable recommendations is by a miner: https://btc.com/stats/unconfirmed-tx
10:51 < BlueMatt> (ofc its looking at mempool state, which is also kinda shit, but...)
10:54 < gmaxwell> mempool state is great, if you're getting it from a miner.
10:54 < TD-Linux> shouldn't overpaying be easy to verify by running the estimator against historical data?
10:54 < BlueMatt> gmaxwell: well, fair
10:54 < gmaxwell> (thus have no issues with non-standard txn, and no its complete)
10:55 < gmaxwell> er know
10:55 < gmaxwell> part of the challenge is miners that @#$@# set their blocksize to less than the maximum... hard for an estimator to know if the block wasn't full because there wasn't supply or because the size was artifically restricted.
10:56 < BlueMatt> TD-Linux: current algorithms are all of the "look at what we had already seen on the public network get into a block to avoid any trickery by miners" variety....the problem is these algorithms tend to have no way to correct downwards if everyone is using them
10:56 < BlueMatt> gmaxwell: yea, and lots of shit that pays 0.1 sat/byte that gets mined :p
10:59 < gmaxwell> BlueMatt: lots of things that get pushed through miner priority interfaces and pays god knows what gets mined.
10:59 < BlueMatt> yea, that too
11:00 < BlueMatt> I dont have a solution, just noting that things are currently Fucked (tm)
11:00 < gmaxwell> which is why you can't simply use the existance of low fee txn getting mined as a measurement of anything. You need to use things not getting mined as your measurement. :)
11:01 < BlueMatt> lol, yes, thank you, I'm well aware of restrictions, but also noting things like mempools on many public nodes being <1MB and miners who post their mempool having the same thing is pretty strong supporting evidence of things being Fucked
11:02 < TD-Linux> BlueMatt, I don't see why they can't correct downward. they would just be delayed one block
11:02 < TD-Linux> err nevermind I see.
11:02 < BlueMatt> TD-Linux: well /someone/ has to be generating such transactions for that to happen, and in sufficient volume
11:02 < sipa> i nominate BlueMatt to do the low fee tx creation job
11:03 < BlueMatt> lol, i nominate petertodd...doesnt he already?
11:04 < gmaxwell> we might want to consider renaming the commandline arguments for minimum relay fee... so as to throw off settings people set back during the flood attacks before there was mempool limiting that have just been forgotten.
11:04 < BlueMatt> yea, i was wondering about that
11:04 < gmaxwell> petertodd does create low fee txn, IIRC the openstransactions stuff produces 1s/b transactions and just RBFs them until they get mined.
11:04 < BlueMatt> yup     
11:05 < BlueMatt> yea, I'm now wondering how much of this comes from stuff failing to relay quickly due to shit like that
11:06 < TD-Linux> does anyone collect public historical mempool data?
11:06 < gmaxwell> what does public mean there?
11:07 < TD-Linux> posted publicly
11:08 < sipa> i sort of do
11:09 < gmaxwell> there are some websites with stats but they're all (?) borken because they're all (?) running the aformentioned adjusted settings.
11:09 < petertodd> gmaxwell: opentimestamps starts with the lowest fee bitcoin core will accept with default settings, and increments it by the minimum fee necessary to relay a replacement each time
11:09 < BlueMatt> or displaying miles of garbage that has been floating around for months :(
11:10 < gmaxwell> BlueMatt: that would be an improvement... 
11:11 < gmaxwell> well people aren't using charting interfaces that make sense. Megabytes of mempool is a worthless metric... should be 300 all the time, short of expiration.
11:11 < petertodd> gmaxwell: any miner with a mature mempool significantly greater than 1MB will likely be mining replacement OTS transactions rather than the first ones broadcast, assuming propagation is reasonably reliable anyway
11:11 < BlueMatt> gmaxwell: yea, its no where near that much of the time, however
11:12 < BlueMatt> petertodd: i think the propagation assumption is very weak :/
11:13 < petertodd> BlueMatt: last I checked the logs, usualy the OTS tx that actually gets mined is after multiple attempts, IIRC ~5 or so
11:13 < BlueMatt> petertodd: do you have stats on the propagation prior to that point?
11:14 < petertodd> BlueMatt: point is, after that many attempts, it's likely that at least one will have gotten through
11:15 < gmaxwell> BlueMatt: well if you want to write a PR that renames the minrelayfee option... I'd test and ACK it.
11:16 < BlueMatt> yea, ok, willdo
11:16 < petertodd> BlueMatt: after # of replacements before a OTS tx gets mined is 11
11:18 < petertodd> BlueMatt: *average #
11:19 < BlueMatt> petertodd: yea, I'm curious about propagation
11:19 < BlueMatt> ping me next time it runs
11:20 < petertodd> BlueMatt: it's a fully automated thing that's constantly running...
11:20 < BlueMatt> well whats the current txid/feerate?
11:20 < petertodd> BlueMatt: in 44s I'll give you a txid...
11:21 < petertodd> BlueMatt: oh, wait, no a bit longer than that... gotta wait for a block
11:22 < petertodd> BlueMatt: after a timestamp is confirmed, it waits a minimum timeout interval, then sends a timestamp tx the next time a block is found; after that every block found results in the fees being bumped
11:24 < BlueMatt> k     
11:27 -!- wvr [~wvr@116.red-88-8-192.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
11:33 < petertodd> BlueMatt: just checked my logs, looks like 50% of the time where multiple replacements happen, the last replacement to be sent is the one that gets mined
11:34 < petertodd> BlueMatt: so I'd say that's pretty suggestive evidence that about 50% of the hashing power is mining opt-in RBF
11:34 < petertodd> here's a recently sent txid, the start of a new replacement chain: 2adceebdd5149b9f6c27764f7a619e69487e55ac37bee2d6f492067585b23f0e
11:34 < BlueMatt> hmm, or at least a big chunk (eg btcc and bitfury, i assume)
11:36 < BlueMatt> in any case, regarding ignoring opt-in rbf for fee calculation, i suppose it might make sense if we only use it for high-confirmation requests (eg 3/10 confirmations)
11:36 < gmaxwell> well it's really easy to see who does and doesn't... the ones that don't (e.g. viabtc) collect a lot less in fees.
11:36 < BlueMatt> but it certainly will have an impact on our 95% threshold
11:38 < petertodd> BlueMatt: https://0bin.net/paste/zzWuyYFWyZdkufmh#Y8Zwe0qb684VrruOQC8ZbQ2ovgqE3XLXoe-Ca+w4xn0 <- look for yourself; that's all the replacement chain ends since september
11:57 < morcos> BlueMatt: take a deep breath!  this is actually one thing fee estimatation does pretty well
11:57 < morcos> (oops, didn't catch up all the way on backlog)
11:57 < morcos> the reason we don't get estimates that low is the threshold is set very high and we don't have estimates for greater than 25 blocks
11:58 < BlueMatt> im aware
11:58 < BlueMatt> but that doesnt explain why estimates are currently in the 50s, and not the 10s
11:59 < morcos> it does explain, the estimate is answering the question of i want a 95% chance of being filled in my target
11:59 < morcos> 10s will not get you filled withing 25 blocks wiht 95% chance
11:59 < BlueMatt> yes, see later discussion, i believe that is in part due to propagation issues
12:00 < morcos> 10 sat very recently has had a 75% of being confirmed in 16 blocks and over a longer time period a 75% chance of being confirmed in 32 blocks
12:00 < morcos> for 95% chance you have to go up to a whole day
12:00 < morcos> thats not due to propagation issues i doubt
12:01 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
12:01 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
12:01 < morcos> i think pretty much everyone would propagate > 10s byte
12:01 < morcos> thats due to blocks being mostly full of stuff that pay more than that
12:01 < morcos> as mentioned, recently it has come down
12:01 < BlueMatt> im not convinced...many blocks being generated now are not full because there arent txn to include if you make 8 outbound connections
12:02 < BlueMatt> on some of my public non-listening nodes they do not have 1MB of txn in their mempool
12:02 < BlueMatt> (and havent all day)
12:03 < morcos> i'd bet you just happen to be looking at lull in transaction backlog
12:04 < BlueMatt> these nodes have been online for months
12:04 < morcos> if it stays like this for a week... estimates will come down
12:04 < BlueMatt> thats possible, but also concerning
12:04 < morcos> yes, i'm saying a few days ago.. your mempool had more expensive txs in it
12:04 < BlueMatt> 10 sat very recently has had a 75% of being confirmed in 16 blocks
12:04 < BlueMatt> what is your "very recently"?
12:05 < morcos> checking..  normal fee esitmation has a half life of about 2.5 days
12:06 < morcos> i have a node with short term and long term estimates
12:06 < morcos> the short term estimate has halflife of 6 hours
12:07 < morcos> sigh.. just realized it crashed 2 days ago...  so that number was from 2 days ago
12:07 < BlueMatt> ahh, grrr
12:09 < morcos> it is true that the existing algorithm doesn't respond very quickly to changes in conditions
12:09 < morcos> anyway.. i have to run now.. i'll restart that node
12:09 < morcos> and we can discuss in more detail later..  but i have TONS of historical data on this...
12:10 -!- Netmage [~Netmage@p5B0A5402.dip0.t-ipconnect.de] has quit [Quit: Leaving]     
12:10 < morcos> the most important thing to actually let people place lower fee txs would be to have a way to say something like i want a 75% change of being confirmed in the next 6 hours
12:10 < morcos> in otherwords be able to decrease confidence and increase target
12:10 < morcos> then you'll get much lower estimates
12:11 < BlueMatt> yes, I super think we should set lower confidence thresholds for people who ask about 20 blocks
12:12 < BlueMatt> i mean if you're asking about 20 blocks I'd hope you understand its +/- 100 at that point
12:12 < morcos> agree entirely
12:12 < morcos> and its easy to do combo stuff
12:13 < morcos> ok well they want 20 blocks lets give them a 50% chance its within 20, but a 90% chance its within 40
12:13 < morcos> i mean you just ask both questions and give the max
12:13 < BlueMatt> yea     
12:13 < BlueMatt> i mean that sounds like a uselessly complicated api
12:14 < BlueMatt> (how many people will actually use that?) but maybe
12:14 < morcos> well yeah i'm assuming that the default will be that happens behind the scenes
12:14 < morcos> but that if for some reason you don't like whatever magic core is doing, then you can ask the direct questions
12:14 < BlueMatt> sure, ok
12:15 < morcos> anwyay, lets discuss later...
12:15 < morcos> got to run
12:38 -!- protomar [~protomar@109.232.227.133] has joined #bitcoin-core-dev     
12:55 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 258 seconds]     
13:07 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
13:27 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 240 seconds]     
13:31 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye]     
13:40 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
13:53 -!- waxwing [~waxwing@14.174.32.23] has quit [Ping timeout: 240 seconds]     
14:01 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]     
14:02 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev     
14:16 -!- cdecker [~cdecker@mail.snyke.net] has joined #bitcoin-core-dev     
14:19 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 260 seconds]     
14:23 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
14:27 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 252 seconds]     
14:28 < morcos> BlueMatt: I have another node that has been consistently running that keeps estimates out to 1000 blocks but only at the default decay...
14:29 < morcos> For now it has enough data to accurately report lower fee rates..  but you are right actually that there are very few txs down there.. and so if no one is asking about those less quick confirmations.. (b/c we don't give them a way to) 
14:30 < morcos> then no one will places txs at those lower feerates and we may eventually not have any data points
14:31 < morcos> so probably we should provide that opportunity sooner rather than later..   i wrote the code over a year ago.. but it was a bit complicated and i didn't want to worry about tryng to get it reviewed
14:32 < morcos> anyway, here is some data..   # blocks target:   95% threshold (current default)   ,  75% target (maybe what we could give)
14:33 < morcos> 16: 60000 , 4600
14:35 < morcos> 32: 40000, 4600
14:36 < morcos> 64: 10000, 2500 (can't get lower due to lack of data)
14:37 < morcos> 128: 4600, 2500
14:38 < morcos> My guess is things less than 10000 (10 sat/byte) have a problem reaching the very high thresholds b/c there are probably some miners with minrelayfee set at 10  
14:39 < morcos> for good measure
14:40 < morcos> 8: 65000, 15000
14:46 -!- protomar [~protomar@109.232.227.133] has quit [Quit: Leaving]     
15:12 -!- JackH [~laptop@79-73-188-131.dynamic.dsl.as9105.com] has quit [Remote host closed the connection]     
15:30 < BlueMatt> morcos: units???
15:32 < gmaxwell> So I have a question-- would we ever want to have support for trusted feerate information? e.g. to be used when your own estimator doesn't have enough data, or such that it only decreases your estimates?
15:33 < BlueMatt> if we have bumpfee........maybe
15:33 < BlueMatt> i mean its not like all other wallets dont have to....
15:47 < luke-jr> if you mean alert-style signed-by-someone, I think it would need to be outside the reference codebase probably, unless we want to change the policy on such things altogether
15:47 < luke-jr> unless perhaps it'd be signed by the miners themselves
15:53 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
15:59 < gmaxwell> luke-jr: I mean something you could configure, which wouldn't have a default.  "Get fee estimates from key XYZ"
15:59 < gmaxwell> (or really, multisig withnessscripthash)
16:22 < luke-jr> we already have something similar for block explorers; but it'd need a URI, not just a key - otherwise nothing will get relayed far
16:23 < luke-jr> it occurs to me the revalidation we do when a pre-segwit node upgrades to segwit, is really something we ought to be doing for every softfork :x
16:25 < gmaxwell> we do? :(
16:25 < gmaxwell> I hope we're not directing people to centeralized block explorers. :(
16:26 < gmaxwell> luke-jr: yes, it is. But it was more important for segwit becuase we needed to actually fetch the witness data.
16:27 < luke-jr> gmaxwell: there is no default, and the example is example.com
16:27 < gmaxwell> where is this?
16:28 < luke-jr> Settings->Options->Display->Third party transaction URLs
16:28 < gmaxwell> in that case I'm not so worried about the defaults but the idea that you can trust basically any of these websites. I've not seen a single block explorer which has never displayed massively incorrect data at one time or another. Not to mention that the 'balances' model that they all use is a misleading presentation of the system. :(
16:31 < luke-jr> for better or worse, it's been there for a while
16:37 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:34fc:b297:8b6b:bce8] has quit [Ping timeout: 255 seconds]     
16:37 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev     
16:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []     
16:53 -!- waxwing [~waxwing@14.174.32.23] has joined #bitcoin-core-dev     
17:08 -!- harrymm [~wayne@191.96.49.87] has quit [Quit: Leaving.]     
17:09 -!- harrymm [~wayne@191.96.49.105] has joined #bitcoin-core-dev     
17:15 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev     
17:18 < morcos> gmaxwell: The aspect of that that I thought about was the ability to do some sort of sanity checking...  Like are you paying more than the median fee from the last 10 blocks? But I'm unclear on how worth it it would be...
17:18 < morcos> I think that type of sanity checking could be useful for catching when our fee estimation mihgt not be performing at it's best
17:19 < morcos> In reality, if you've had your node up and running long enough that you saw a block more than 10 mins after you started... you ought to be able ot at least do something not insane
17:34 -!- bajdev [~bajdev3@cpe-75-181-62-137.carolina.res.rr.com] has joined #bitcoin-core-dev     
17:42 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
17:45 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
17:58 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
18:00 -!- bajdev1 [~bajdev3@cpe-75-181-62-137.carolina.res.rr.com] has joined #bitcoin-core-dev     
18:01 -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-core-dev     
18:02 -!- bajdev [~bajdev3@cpe-75-181-62-137.carolina.res.rr.com] has quit [Ping timeout: 264 seconds]     
18:04 -!- bajdev1 [~bajdev3@cpe-75-181-62-137.carolina.res.rr.com] has quit [Client Quit]     
18:07 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-roicwuxkobfqtvzp] has quit [Quit: Connection closed for inactivity]     
18:16 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Ping timeout: 245 seconds]     
18:24 -!- handlex [~handlex@2804:14c:658f:4dc7:89dc:a3f1:27e3:ad8e] has joined #bitcoin-core-dev     
18:37 -!- handlex [~handlex@2804:14c:658f:4dc7:89dc:a3f1:27e3:ad8e] has quit [Quit: handlex]     
18:40 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Read error: Connection reset by peer]     
18:40 -!- pavel_ [~paveljani@79.98.72.176] has joined #bitcoin-core-dev     
18:54 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke]     
18:55 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev     
19:08 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]     
19:13 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Quit: .]     
19:45 -!- cryptapus is now known as cryptapus_afk     
20:01 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Ping timeout: 255 seconds]     
20:08 -!- chris2000 [~chris2000@p5082A50D.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
20:11 -!- chris200_ [~chris2000@p5082A8DB.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds]     
20:14 -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-core-dev     
20:34 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 245 seconds]     
20:57 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
20:58 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
20:59 -!- baldur [~baldur@pool-100-2-139-91.nycmny.fios.verizon.net] has quit [Ping timeout: 256 seconds]     
21:00 -!- dermoth [~thomas@201-77.162.dsl.aei.ca] has quit [Read error: Connection reset by peer]     
21:01 -!- dermoth [~thomas@201-77.162.dsl.aei.ca] has joined #bitcoin-core-dev     
21:11 -!- baldur [~baldur@209.95.50.136] has joined #bitcoin-core-dev     
21:33 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Quit: Leaving.]     
21:37 -!- cannon-c_AFK is now known as cannon-c     
23:24 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
23:26 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
23:27 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
23:32 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 240 seconds]     
23:37 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
23:38 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev