12018-12-01T00:29:27  *** intcat has quit IRC
  22018-12-01T00:52:24  *** Tralfaz has quit IRC
  32018-12-01T00:58:46  *** michaelsdunn1 has joined #bitcoin-core-dev
  42018-12-01T01:13:29  *** phwalkr has quit IRC
  52018-12-01T01:29:37  <meshcollider> And so is #14733
  62018-12-01T01:29:39  <gribble> https://github.com/bitcoin/bitcoin/issues/14733 | P2P: Make peer timeout configurable, speed up very slow test and ensure correct code path tested. by zallarak · Pull Request #14733 · bitcoin/bitcoin · GitHub
  72018-12-01T01:30:52  *** IGHOR has quit IRC
  82018-12-01T01:35:47  *** IGHOR has joined #bitcoin-core-dev
  92018-12-01T01:40:02  *** rh0nj has quit IRC
 102018-12-01T01:41:07  *** rh0nj has joined #bitcoin-core-dev
 112018-12-01T01:43:32  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 122018-12-01T01:57:30  *** aba102 has joined #bitcoin-core-dev
 132018-12-01T01:57:47  *** promag has quit IRC
 142018-12-01T02:00:53  *** aba102 has quit IRC
 152018-12-01T02:03:14  *** AaronvanW has quit IRC
 162018-12-01T02:04:56  *** Chris_Stewart_5 has quit IRC
 172018-12-01T02:09:18  *** dviola has quit IRC
 182018-12-01T02:10:02  *** harrymm has quit IRC
 192018-12-01T02:27:34  *** _cryptodesktop_i has joined #bitcoin-core-dev
 202018-12-01T02:42:01  *** AaronvanW has joined #bitcoin-core-dev
 212018-12-01T02:42:14  *** AaronvanW has quit IRC
 222018-12-01T02:48:03  *** harrymm has joined #bitcoin-core-dev
 232018-12-01T02:49:52  *** michaelsdunn1 has quit IRC
 242018-12-01T03:01:36  *** _cryptodesktop_i has quit IRC
 252018-12-01T03:06:46  *** shesek has quit IRC
 262018-12-01T03:07:14  *** shesek has joined #bitcoin-core-dev
 272018-12-01T03:07:14  *** shesek has joined #bitcoin-core-dev
 282018-12-01T03:14:31  *** rhavar has quit IRC
 292018-12-01T03:14:47  *** shesek has quit IRC
 302018-12-01T03:15:35  *** shesek has joined #bitcoin-core-dev
 312018-12-01T03:20:53  *** shesek has quit IRC
 322018-12-01T03:21:51  *** shesek has joined #bitcoin-core-dev
 332018-12-01T03:24:44  *** shesek has quit IRC
 342018-12-01T03:25:48  *** shesek has joined #bitcoin-core-dev
 352018-12-01T03:25:48  *** shesek has joined #bitcoin-core-dev
 362018-12-01T03:26:43  *** zallarak has quit IRC
 372018-12-01T03:31:34  *** Murch has quit IRC
 382018-12-01T03:53:21  *** zallarak has joined #bitcoin-core-dev
 392018-12-01T04:02:20  *** shesek has quit IRC
 402018-12-01T04:03:16  *** rhavar has joined #bitcoin-core-dev
 412018-12-01T04:03:56  *** shesek has joined #bitcoin-core-dev
 422018-12-01T04:17:38  *** Emcy has quit IRC
 432018-12-01T04:17:47  *** Emcy_ has joined #bitcoin-core-dev
 442018-12-01T04:18:12  *** bitcoin-git has joined #bitcoin-core-dev
 452018-12-01T04:18:12  <bitcoin-git> [bitcoin] fanquake opened pull request #14853: depends: latest rapidcheck, enable property based tests on Travis (master...latest-rapidcheck) https://github.com/bitcoin/bitcoin/pull/14853
 462018-12-01T04:18:12  *** bitcoin-git has left #bitcoin-core-dev
 472018-12-01T04:18:48  <fanquake> Chris_Stewart_5 hopefully 14853 unblocks your progress in 14430
 482018-12-01T04:57:07  *** wxss has quit IRC
 492018-12-01T04:57:08  *** wxss_ has joined #bitcoin-core-dev
 502018-12-01T05:00:23  *** sleepyblooshy12 has joined #bitcoin-core-dev
 512018-12-01T05:00:25  <fanquake> Apparently travis can't open .zip files.. ?
 522018-12-01T05:00:41  *** sleepyblooshy12 has quit IRC
 532018-12-01T05:08:57  *** Evel-Knievel has quit IRC
 542018-12-01T05:09:16  *** Evel-Knievel has joined #bitcoin-core-dev
 552018-12-01T05:18:24  *** shesek has quit IRC
 562018-12-01T05:19:13  *** shesek has joined #bitcoin-core-dev
 572018-12-01T05:21:01  *** rh0nj has quit IRC
 582018-12-01T05:22:06  *** rh0nj has joined #bitcoin-core-dev
 592018-12-01T05:22:12  *** shesek has quit IRC
 602018-12-01T05:25:07  *** shesek has joined #bitcoin-core-dev
 612018-12-01T05:25:07  *** shesek has joined #bitcoin-core-dev
 622018-12-01T05:27:14  <gmaxwell> sipa: mind giving #14841 a review?
 632018-12-01T05:27:16  <gribble> https://github.com/bitcoin/bitcoin/issues/14841 | consensus: Move CheckBlock() call to critical section by hebasto · Pull Request #14841 · bitcoin/bitcoin · GitHub
 642018-12-01T05:28:41  *** shesek has quit IRC
 652018-12-01T05:29:08  *** shesek has joined #bitcoin-core-dev
 662018-12-01T05:29:08  *** shesek has joined #bitcoin-core-dev
 672018-12-01T05:38:42  *** zallarak has quit IRC
 682018-12-01T07:30:42  <NicolasDorier> gmaxwell, sipa, aj, we talked before yestersday about the "least worst" way to have UTXO Set snapshot and how it would be cool if, as part of the core release, a utxo snapshot hash could be included which contributors can sign against.
 692018-12-01T07:30:43  <NicolasDorier> I understand that this can be tricky to do it at core level, so I did it on BTCPay own repos, with proper documentation on this link: https://github.com/btcpayserver/btcpayserver-docker/tree/master/contrib/FastSync
 702018-12-01T07:30:43  <NicolasDorier> I tried to explain the downsides and documented the process about how people can verify those UTXO Set by themselves if they have another trusted node somewhere else.
 712018-12-01T07:30:43  <NicolasDorier> I also documented how to sign against it.
 722018-12-01T07:30:43  <NicolasDorier> I know how much you dislike the idea, but this still solve a problem and can be used responsibly. Please, if you have time, review this doc and let me know if I need to add additional warning or documentation. (or if you feel like to add your signature! :))
 732018-12-01T07:43:47  *** hgfjkgh has joined #bitcoin-core-dev
 742018-12-01T07:44:46  <hgfjkgh> hello how are you
 752018-12-01T08:00:38  *** indistylo has joined #bitcoin-core-dev
 762018-12-01T08:00:44  *** murchandamus has joined #bitcoin-core-dev
 772018-12-01T08:03:30  *** shesek has quit IRC
 782018-12-01T08:04:45  *** shesek has joined #bitcoin-core-dev
 792018-12-01T08:04:45  *** shesek has joined #bitcoin-core-dev
 802018-12-01T08:11:48  *** spinza has quit IRC
 812018-12-01T08:14:54  *** luke-jr has quit IRC
 822018-12-01T08:20:20  *** luke-jr has joined #bitcoin-core-dev
 832018-12-01T08:26:34  <gmaxwell> NicolasDorier: This is how decenteralization dies, not with a bang but a wimper.  Having a 300 block back snapshot effectively guarentees that any review process will be worthless.
 842018-12-01T08:30:26  *** spinza has joined #bitcoin-core-dev
 852018-12-01T08:36:27  <aj> NicolasDorier: oh, i was thinking that was part of a "btc-in-a-box" releases, not core ones
 862018-12-01T08:37:48  <sipa> NicolasDorier: if you need that frequent snapshots, i think you shouldn't use a full node; the security is an illusion, they're effectively trusting just you
 872018-12-01T08:38:56  <aj> sipa: the idea wasn't to be that frequent, i thought -- you'd only do the snapshot every 6 months or so, it'd just be that "recent" to make it easy to calculate
 882018-12-01T08:39:08  <gmaxwell> 300 block snapshots effectively means that the node is not fast enough to catch up after a bit of an outage.
 892018-12-01T08:39:40  <sipa> aj: yes, that would be much more reasonable, and be compatible with a public audit
 902018-12-01T08:39:51  <gmaxwell> which is what you have in ethereum,-- if you fall behind you have to re-quick-sync.
 912018-12-01T08:40:42  <provoostenator> I'd much rather see something along the lines of #9483 but using neutrino filters, and then catching up with full blocks in the background over time.
 922018-12-01T08:40:45  <gribble> https://github.com/bitcoin/bitcoin/issues/9483 | Complete hybrid full block SPV mode by jonasschnelli · Pull Request #9483 · bitcoin/bitcoin · GitHub
 932018-12-01T08:40:52  *** albypaul has joined #bitcoin-core-dev
 942018-12-01T08:41:10  <gmaxwell> provoostenator: there is no reason to use neutrino filters for the sorts of use case contemplated here, AFAIK.
 952018-12-01T08:41:28  <provoostenator> The idea is spin up the node as quickly as possible with as little trust as possible.
 962018-12-01T08:41:34  <gmaxwell> provoostenator: in this application you are processing payments. There will be no payments to you before to started in the first place, so no need to go far back in history.
 972018-12-01T08:41:49  <luke-jr> is it time to make a wiki page reflecting devs' opinions on block size/weight reduction softforks? ;p
 982018-12-01T08:42:04  <albypaul> is there a way to change the difficulty of bitcoin core if you are mining off you're own computer just a question i need to ask.
 992018-12-01T08:42:15  <luke-jr> albypaul: #bitcoin
1002018-12-01T08:42:16  <sipa> albypaul: use regtest mode
1012018-12-01T08:42:30  <gmaxwell> provoostenator: and so if you start near the current tip, you just need to use an average of 14kbit/sec to watch for your payments, no filters required.
1022018-12-01T08:42:31  <provoostenator> Right, without history you can just check whats in a block and trust proof-of-work for new payments, until you've verify all history.
1032018-12-01T08:42:31  <luke-jr> (unless you really mean testing purposes)
1042018-12-01T08:42:48  <gmaxwell> provoostenator: yup.
1052018-12-01T08:43:05  <albypaul> none testing
1062018-12-01T08:43:26  <luke-jr> albypaul: if you're not testing, then ask in #bitcoin to learn why you can't
1072018-12-01T08:43:40  *** TrisHoar24 has joined #bitcoin-core-dev
1082018-12-01T08:43:49  <albypaul> thank you luke
1092018-12-01T08:44:02  *** TrisHoar24 has quit IRC
1102018-12-01T08:45:21  *** albypaul has quit IRC
1112018-12-01T08:46:20  <provoostenator> So I wonder what the first step is for anyone who wants to tackle this (sync headers to tip, accept new blocks based on PoW check, then sync blocks retroactively).
1122018-12-01T08:46:21  *** shesek has quit IRC
1132018-12-01T08:47:14  <gmaxwell> provoostenator: jonasschnelli previously implemented much of it
1142018-12-01T08:47:21  *** shesek has joined #bitcoin-core-dev
1152018-12-01T08:47:34  <provoostenator> Yes, and that PR is in limbo, partially because it was too big and needed splitting.
1162018-12-01T08:47:44  *** shesek has joined #bitcoin-core-dev
1172018-12-01T08:48:11  <aj> luke-jr: i think more info about effects of block weight limits would be good. i guess you're thinking of the argument along the lines that 17% pa increase in network speed means 400kB/block if the 250GB of block data is the limiting factor?
1182018-12-01T08:48:50  <luke-jr> aj: the current blockchain size is too big, so we probably need to stick to 300k as ~17% of the last reasonable blockchain size
1192018-12-01T08:49:07  <luke-jr> aj: but an opinions page could present multiple opinions ofc
1202018-12-01T08:49:33  <luke-jr> (reasonable meaning, when we had a safe level of users running full nodes of their own)
1212018-12-01T08:55:16  *** shesek has quit IRC
1222018-12-01T08:55:41  <gmaxwell> luke-jr: I don't think thats a realistic answer. besides, 2days increase is already too much... and 17%pa doesn't really reflect the available hardware.
1232018-12-01T08:56:08  <gmaxwell> I don't believe e.g. the things cited for btcpay (cheap vpses, rpis) are speeding up at 17%pa.
1242018-12-01T08:57:04  <aj> luke-jr: i'd find the reasoning more interesting; like what's "too big" mean? initial sync time for sure, but is there a point when the utxo set is "too big" too (i mean, it's only 50M atm, which doesn't come close to a utxo for every person and company eg), etc?
1252018-12-01T08:57:16  *** shesek has joined #bitcoin-core-dev
1262018-12-01T08:57:16  *** shesek has joined #bitcoin-core-dev
1272018-12-01T08:57:16  <gmaxwell> We've had pretty extensive descriptions of things we can do to fast start,  from SPV start so you can get paid immediately with spv security, to UTXOassumevalid.  We just don't have enough people right now who feel qualified to move the protocol ball forward.
1282018-12-01T08:57:35  <gmaxwell> aj: 50M!?! 2500M you mean...
1292018-12-01T08:57:44  <gmaxwell> oh maybe 50 million entries.
1302018-12-01T08:58:03  <aj> yeah, entries, not bytes
1312018-12-01T08:58:57  <luke-jr> gmaxwell: what do you mean? we need to go lower? :|
1322018-12-01T08:59:10  <provoostenator> gmaxmell it sounds like SPV start has the biggest bang for developer & review buck
1332018-12-01T08:59:19  <provoostenator> *w
1342018-12-01T08:59:51  <luke-jr> SPV start isn't really a solution to an indefinitely growing IBD time
1352018-12-01T08:59:59  *** shesek has quit IRC
1362018-12-01T09:00:09  <luke-jr> although maybe it would make the current chain size more tolerable to users
1372018-12-01T09:00:20  <gmaxwell> luke-jr: thing is that a "x day sync time" is a total non-issue for many users so long as they can send and recieve payments right away.
1382018-12-01T09:00:24  *** indistylo has quit IRC
1392018-12-01T09:00:35  *** shesek has joined #bitcoin-core-dev
1402018-12-01T09:00:35  *** shesek has joined #bitcoin-core-dev
1412018-12-01T09:00:37  <gmaxwell> so it would immediately take things from unusable to "okay" for a large class of users.
1422018-12-01T09:00:42  <luke-jr> gmaxwell: and can use Netflix in the meantime :/
1432018-12-01T09:00:45  <provoostenator> Exactly. Initial experience matters.
1442018-12-01T09:01:17  <gmaxwell> luke-jr: yes, esp if its in the background we could reasonably rate limit the sync.
1452018-12-01T09:01:17  <provoostenator> Once people are hooked, they'll accept slower sync :-)
1462018-12-01T09:01:24  <luke-jr> gmaxwell: but if 17% is too much, going based on the current blockchain size might just put us back at 300k anyway :<
1472018-12-01T09:01:57  <gmaxwell> I think it just isn't so simple. 17% is perhaps too little for top end deployment, but it's probably too much for bottom end deployment.
1482018-12-01T09:02:25  <gmaxwell> the fact is that the competition is "use paypal" or "use bitpay", and those don't take much resources and don't grow at 17% per year.
1492018-12-01T09:02:48  <luke-jr> people choosing paypal doesn't harm Bitcoin's security, though
1502018-12-01T09:02:51  <gmaxwell> And so low end SBC hardware or VPSes will continue to target low end usage, which will work with centeralized bitcoin alternatives.
1512018-12-01T09:03:21  <gmaxwell> luke-jr: well it does when to compete with paypal others make centeralized bitcoin solutions.
1522018-12-01T09:04:15  <luke-jr> I must be misunderstanding you somehow.
1532018-12-01T09:04:18  *** shesek has quit IRC
1542018-12-01T09:04:43  <provoostenator> I took a stap at rebasing something that I thought was a prerequisite for SPV sync #13937, but a) this was not easy, and b) I'm still not sure if it really is a prerequisite.
1552018-12-01T09:04:45  <gribble> https://github.com/bitcoin/bitcoin/issues/13937 | Track best-possible-headers (TheBlueMatt) by Sjors · Pull Request #13937 · bitcoin/bitcoin · GitHub
1562018-12-01T09:05:05  *** shesek has joined #bitcoin-core-dev
1572018-12-01T09:05:05  *** shesek has joined #bitcoin-core-dev
1582018-12-01T09:05:16  <luke-jr> provoostenator: it's probably one possible approach to the end goal
1592018-12-01T09:05:25  <luke-jr> with some useful side effects
1602018-12-01T09:05:45  <provoostenator> So I'm trying to figure what to tell anyone who wants to work on this problem, what would be something manageable.
1612018-12-01T09:05:55  <gmaxwell> luke-jr: even if you don't care about compeating with paypal, other people in the bitcoin ecosystem do. And they'll make tradeoffs as required to do so, and drag the ecosystem in that direction,  especially if people who don't so much care about paypal ignore the requirements.
1622018-12-01T09:06:26  <gmaxwell> provoostenator: I can't give you advice right now because I've lost track of that work, but I'll make an effort in the next day to catch up on it.
1632018-12-01T09:06:29  <provoostenator> It touches a lot of very critical code which just takes time to understand, so it may simply be something that can only be done with lots and lots of time and dedication.
1642018-12-01T09:06:53  <luke-jr> gmaxwell: ah, like moving economic activity to centralised off-chain solutions?
1652018-12-01T09:07:39  <provoostenator> gmaxwell: thanks, no rush at all
1662018-12-01T09:07:49  *** shesek has quit IRC
1672018-12-01T09:07:51  <gmaxwell> luke-jr: worse, really bad ones, rather than like.. more thoughtfully created ones.
1682018-12-01T09:08:00  <gmaxwell> and then also advertise them as decenteralized. :P
1692018-12-01T09:08:14  <luke-jr> well, if they move to altcoins, that's not so much Bitcoin's problem..
1702018-12-01T09:08:31  <luke-jr> hence why I'd like to see a certain altcoin survive some forking mess
1712018-12-01T09:09:01  <sipa> luke-jr: if chasing people away to alternatives is a solution, then 0 kb block size limit is ideal.
1722018-12-01T09:09:05  <gmaxwell> :P
1732018-12-01T09:09:41  <gmaxwell> in any case, I feel like this is a tangent, my point was that it pays to be considerate of a wider class of usecases than you would naturally care about, because we also want the participation of those people.
1742018-12-01T09:09:49  *** shesek has joined #bitcoin-core-dev
1752018-12-01T09:09:54  <luke-jr> sipa: well, chasing away centralising people would only be a means to a goal (keeping Bitcoin itself secure)
1762018-12-01T09:10:00  <gmaxwell> A luke-jr only currency would not have any scaling problems, at all... and that would be a problem for it. :P
1772018-12-01T09:10:08  <luke-jr> 0k block size kinda throws the baby out with the bathwater
1782018-12-01T09:10:40  <sipa> luke-jr: there are no "centralized" and "decentralized" people; there are people who care more about decentralization than others, but very few have it as an absolute requirement
1792018-12-01T09:10:59  <gmaxwell> luke-jr: it's not really that anyone (well not manyone) wants a centeralized solution.  They want something like cheap instant payments now, and centeralized is perhaps just how they know how to get it.
1802018-12-01T09:11:04  <sipa> if the only thing that works is centralized, it will be what most, if not everyone, uses
1812018-12-01T09:11:24  <luke-jr> gmaxwell: hopefully Lightning helps with that
1822018-12-01T09:11:28  <gmaxwell> Absolutely.
1832018-12-01T09:11:52  <provoostenator> And there's people who care about decentralalization just as much but don't fully appreciate the risks, especially the more subtle problems.
1842018-12-01T09:11:53  <gmaxwell> But thats also just one thing in a broader spectrum of improvements.
1852018-12-01T09:11:58  *** shesek has quit IRC
1862018-12-01T09:13:01  *** shesek has joined #bitcoin-core-dev
1872018-12-01T09:13:26  <gmaxwell> And NicolasDorier's use case is _tremendously_ important.  I feel like we've had this backwards.  btcpay was needed in 2011, desperately needed in 2012... and for lack of it, the supporting infrastructure has not become strong in the ways that btcpay needs it to be strong.
1882018-12-01T09:13:59  <gmaxwell> instead, most parties were using a hosted centeralized solution.
1892018-12-01T09:14:01  *** fanquake has quit IRC
1902018-12-01T09:14:26  <luke-jr> eh, I don't think smaller blocks is at odds with BTCPay - it sounds like it would even help
1912018-12-01T09:15:10  <luke-jr> especially considering BitPay apparently doing stupid things with extra sweep transactions
1922018-12-01T09:15:24  <provoostenator> I think gmaxwell meant things like SPV sync with "supporting infrastructure"
1932018-12-01T09:15:35  <gmaxwell> It would have, sure. Though it's not the point I was trying to make I think that the whole blocksize discussion would have gone very differently if the ecosystem was using btcpay and not bitpay a few years ago.
1942018-12-01T09:15:45  <gmaxwell> provoostenator: right.
1952018-12-01T09:16:16  <gmaxwell> And faster sync, and UTXO assume valid, and better backup, and god knows whatever problems we'll encounter if people really start processing their own payments under live fire at scale.
1962018-12-01T09:16:27  <gmaxwell> (and, perhaps, lightning)
1972018-12-01T09:16:49  <luke-jr> I don't think these approaches needs to be exclusionary to others (like smaller blocks)
1982018-12-01T09:17:08  <luke-jr> blockchain size just happens to be the one irreversible factor, so IMO somewhat of a priority
1992018-12-01T09:17:30  <gmaxwell> and not only did that harm users (though it seems not too much, save for a few merchants that got blacklisted) and some dumb political consequences like bitpay having way too much influence for their level of sanity... it has resulted in weaker ecosystem.
2002018-12-01T09:18:12  <gmaxwell> luke-jr: it's not an irreversable factor. At least in terms of initial time, I think it's substantially addressed by UTXOassumevalid.
2012018-12-01T09:18:23  <provoostenator> It also created a vicious circle where a shitty user experience means merchants don't see a lot of BTC revenue, so they're not inclined to look for competitors.
2022018-12-01T09:18:43  <gmaxwell> Because then you have to ask what growth rate allows keeping the last year of blocks at the same sync time, and the answer is much much larger.
2032018-12-01T09:18:52  <provoostenator> That will fix itself though if the deplatforming continuous and the alternatives get increasingly better.
2042018-12-01T09:19:45  <luke-jr> gmaxwell: UTXOassumevalid is no longer a full node security level if it means what it sounds like
2052018-12-01T09:20:18  <gmaxwell> luke-jr: I believe it has the same security model that users get right now.
2062018-12-01T09:20:24  <sipa> luke-jr: if it isn't, then running a full node you haven't implemented yourself isn't either
2072018-12-01T09:20:25  <luke-jr> provoostenator: my dedicated server provider accepts bitcoin via BitPay, and I just use PayPal nowadays instead because BitPay screwed up one too many times
2082018-12-01T09:20:59  <luke-jr> sipa: you *can* audit full node code. If people rely on UTXOassumevalid, they *can't* audit the hash
2092018-12-01T09:21:17  <sipa> sure they can; run a node with utxoassumevalid disabled
2102018-12-01T09:21:20  <provoostenator> luke-jr: my dedicated pizza provider accepts bitcoin via BitPay, and I generally finish my pizza before it's confirmed, depsite all the error messages and RBF fud.
2112018-12-01T09:21:24  <luke-jr> sipa: then they're not relying on it
2122018-12-01T09:21:45  <gmaxwell> luke-jr: basically the user's software knows about a utxo state as of some height 6-12 months ago. And if the best chain is that chain, they'll skip validating and assume it valid.  Now, it _could_ be invalid BUT the software could have a subtle one character backdoor burried it it too-- we endeavor to use public review to prevent both cases.
2132018-12-01T09:22:04  <sipa> luke-jr: i believe more people will recalculate the utxo hash than there are people capable of reviewing the source code
2142018-12-01T09:22:21  <sipa> (given sufficiently accessible processes around it etc)
2152018-12-01T09:22:35  <gmaxwell> luke-jr: you audit it be running without, (e.g. on a faster system) or using an old node you had before. Or trusting any of many other people who do review it to catch issues and sound an alarm you'll hear, same as with the software in general.
2162018-12-01T09:23:17  <gmaxwell> sipa: that appears to be the case for the current assumevalid vs changes to crypto code. The latter almost no one review, and AV pull requests get a bunch of people checking them.
2172018-12-01T09:23:18  <provoostenator> So this UTXOassumevalid would use a much older block than we do with assumevalid?
2182018-12-01T09:23:19  <sipa> rolling utxo hashes would make this much simpler, as you could at basically no cost let every node its utxo hash at every block and log it
2192018-12-01T09:23:47  <gmaxwell> provoostenator: somewhat older because of a pratical issue of managing the snapshots.
2202018-12-01T09:23:58  <gmaxwell> sipa: which is why that idea was created. :)
2212018-12-01T09:24:09  <gmaxwell> (at least as far as I'm concerned)
2222018-12-01T09:24:17  <sipa> gmaxwell: i know.
2232018-12-01T09:24:18  *** shesek has quit IRC
2242018-12-01T09:25:01  <gmaxwell> provoostenator: basically if you have an UAV of height X then you need to sync from peers with that snapshot or otherwise full sync... and it takes space to store them, so they can only be so frequent.
2252018-12-01T09:25:12  <provoostenator> You're putting the full snap shot in the binary, right? Not a hash and relying on P2P.
2262018-12-01T09:25:21  <gmaxwell> provoostenator: it's reasonable to expect nodes to keep the last two or something, but not dozens of them.
2272018-12-01T09:25:21  <sipa> no, relay over p2p
2282018-12-01T09:25:36  <gmaxwell> provoostenator: over P2P, otherwise its too hard to distribute the software without extensive centeralization.
2292018-12-01T09:25:36  *** shesek has joined #bitcoin-core-dev
2302018-12-01T09:25:54  <sipa> if we can relay blocks over P2P, we can definitely do the same with a utxo set (which is smaller than the blockchain!)
2312018-12-01T09:25:57  <gmaxwell> And ideally we'd split up the data so that the peers you fetch it from don't have to have the whole thing on any single peer.
2322018-12-01T09:26:10  *** EagleTM has joined #bitcoin-core-dev
2332018-12-01T09:26:14  <provoostenator> Right, that's gigabytes. Would be easier with the accumulator.
2342018-12-01T09:26:25  *** shesek has quit IRC
2352018-12-01T09:27:09  <sipa> provoostenator: well in a hypothetical future where the utxo set is replaced with an accumulator, and txn contain inclusion proofs... there is no need for a utxo set anymore
2362018-12-01T09:27:19  <gmaxwell> so for example, we could have each peer keep 1/8th of the last two snapshots, so even ignoring compression, the overhead is 1/4 the size of the utxo set.  Any release just refers to the most recent one.
2372018-12-01T09:27:39  <sipa> you'd just download the accumulator (which based on the technology could be a few megabytes, a few kilobytes, or even just a few bytes)
2382018-12-01T09:27:40  <provoostenator> sipa: but you could still still use an assume valid accumulator state in the same vain
2392018-12-01T09:27:58  <gmaxwell> unfortunately basically all those schemes shoot bandwidth or CPU through the roof, which it's not like we have either of those in surpluse. :)
2402018-12-01T09:28:36  *** shesek has joined #bitcoin-core-dev
2412018-12-01T09:28:54  *** bitcoin-git has joined #bitcoin-core-dev
2422018-12-01T09:28:55  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/011c42c5bd17...5ab5341d1356
2432018-12-01T09:28:55  <bitcoin-git> bitcoin/master c5ed6e7 Hennadii Stepanov: Move CheckBlock() call to critical section...
2442018-12-01T09:28:56  <bitcoin-git> bitcoin/master 5ab5341 Wladimir J. van der Laan: Merge #14841: consensus: Move CheckBlock() call to critical section...
2452018-12-01T09:28:56  *** bitcoin-git has left #bitcoin-core-dev
2462018-12-01T09:29:28  <gmaxwell> provoostenator: yes, that just saves the 2.5gb or whatever utxo set download. Which would be nice.. but we're orders of magnitude away from that being our biggest concern now.
2472018-12-01T09:29:35  <provoostenator> ^ quite possibly the scariest commit name one can thing of
2482018-12-01T09:29:48  <sipa> how so?
2492018-12-01T09:29:57  *** bitcoin-git has joined #bitcoin-core-dev
2502018-12-01T09:29:57  <bitcoin-git> [bitcoin] laanwj closed pull request #14841: consensus: Move CheckBlock() call to critical section (master...20181129-checkblock-mutex) https://github.com/bitcoin/bitcoin/pull/14841
2512018-12-01T09:29:57  *** bitcoin-git has left #bitcoin-core-dev
2522018-12-01T09:30:06  <provoostenator> It has the words consensus, check (block) and critical.
2532018-12-01T09:30:49  <gmaxwell> fortunately it just moves a lock.
2542018-12-01T09:31:00  <wumpus> that's good, maybe it will prompt some people to pay attention :)
2552018-12-01T09:31:10  <sipa> ha
2562018-12-01T09:31:10  <gmaxwell> not riskless, at all, no code change really is.
2572018-12-01T09:31:32  <gmaxwell> I feel a lot more confortable about that change than the unpatched code!  (who needs locks!)
2582018-12-01T09:32:26  <provoostenator> Speaking of baby steps to SPV sync: #13930 documentation change just got blessed by bluematt (who wrote the original comment that I based this on)
2592018-12-01T09:32:28  <gribble> https://github.com/bitcoin/bitcoin/issues/13930 | Better explain GetAncestor check for m_failed_blocks in AcceptBlockHeader by Sjors · Pull Request #13930 · bitcoin/bitcoin · GitHub
2602018-12-01T09:34:28  *** CodeBlue1776 has quit IRC
2612018-12-01T09:36:09  <gmaxwell> [back to UTXOAV] we even have some nice designs that get you a cool property that with an 8way split you can sync off _any_ 8 peers, they don't need to be particular peers that have the parts you want.... so no issues with some attacker DOS attacking one slice to prevent sync.
2622018-12-01T09:36:30  *** CodeBlue1776 has joined #bitcoin-core-dev
2632018-12-01T09:37:25  <provoostenator> Thanks sounds pretty cool, looking forward to read about it.
2642018-12-01T09:37:56  <gmaxwell> well, you might have to build it if you want to read about it. :)
2652018-12-01T09:40:39  * provoostenator hides
2662018-12-01T09:42:08  *** shesek has quit IRC
2672018-12-01T09:43:03  *** shesek has joined #bitcoin-core-dev
2682018-12-01T09:43:03  *** shesek has joined #bitcoin-core-dev
2692018-12-01T09:44:46  *** justanotheruser has quit IRC
2702018-12-01T09:48:06  *** shesek has quit IRC
2712018-12-01T09:48:35  *** shesek has joined #bitcoin-core-dev
2722018-12-01T09:55:58  *** cubancorona has quit IRC
2732018-12-01T09:56:18  *** cubancorona has joined #bitcoin-core-dev
2742018-12-01T10:00:38  *** e4xit has joined #bitcoin-core-dev
2752018-12-01T10:00:46  *** justanotheruser has joined #bitcoin-core-dev
2762018-12-01T10:04:32  *** kexkey has quit IRC
2772018-12-01T10:19:23  *** e4xit has quit IRC
2782018-12-01T10:24:31  *** rhavar has quit IRC
2792018-12-01T10:25:36  *** phwalkr has joined #bitcoin-core-dev
2802018-12-01T10:29:51  *** hgfjkgh has quit IRC
2812018-12-01T10:32:38  *** shesek has quit IRC
2822018-12-01T10:33:16  *** shesek has joined #bitcoin-core-dev
2832018-12-01T10:33:16  *** shesek has joined #bitcoin-core-dev
2842018-12-01T10:36:16  *** e4xit has joined #bitcoin-core-dev
2852018-12-01T10:36:28  *** shesek has quit IRC
2862018-12-01T10:38:19  *** shesek has joined #bitcoin-core-dev
2872018-12-01T10:57:06  *** shesek has quit IRC
2882018-12-01T10:57:33  *** spinza has quit IRC
2892018-12-01T10:59:02  *** shesek has joined #bitcoin-core-dev
2902018-12-01T11:07:47  *** spinza has joined #bitcoin-core-dev
2912018-12-01T11:08:59  *** shesek has quit IRC
2922018-12-01T11:09:25  *** shesek has joined #bitcoin-core-dev
2932018-12-01T11:11:57  *** laurentmt has joined #bitcoin-core-dev
2942018-12-01T11:18:48  *** e4xit has quit IRC
2952018-12-01T11:20:28  *** laurentmt has quit IRC
2962018-12-01T11:25:08  *** bitcoin-git has joined #bitcoin-core-dev
2972018-12-01T11:25:08  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/5ab5341d1356...ed12fd83ca79
2982018-12-01T11:25:09  <bitcoin-git> bitcoin/master fe1ff50 Chun Kuan Lee: Hide spendable label if priveate key is disabled
2992018-12-01T11:25:09  <bitcoin-git> bitcoin/master 82d6c5a Chun Kuan Lee: gui: Show watch-only eye instead of HD disabled
3002018-12-01T11:25:10  <bitcoin-git> bitcoin/master ed12fd8 Wladimir J. van der Laan: Merge #13966: gui: When private key is disabled, only show watch-only balance...
3012018-12-01T11:25:10  *** bitcoin-git has left #bitcoin-core-dev
3022018-12-01T11:25:42  *** bitcoin-git has joined #bitcoin-core-dev
3032018-12-01T11:25:42  <bitcoin-git> [bitcoin] laanwj closed pull request #13966: gui: When private key is disabled, only show watch-only balance (master...ui-disable-privkey) https://github.com/bitcoin/bitcoin/pull/13966
3042018-12-01T11:25:42  *** bitcoin-git has left #bitcoin-core-dev
3052018-12-01T11:40:48  *** Guyver2 has joined #bitcoin-core-dev
3062018-12-01T11:50:04  <NicolasDorier> gmaxwell: Unsure I understand "This is how decenteralization dies, not with a bang but a wimper.  Having a 300 block back snapshot effectively guarentees that any review process will be worthless.". I think I will do such snapshot only once every 6 months. It is only important for new nodes. And people can verify by themselves if they have their another full node they trust somewhere else.
3072018-12-01T11:50:38  *** shesek has quit IRC
3082018-12-01T11:50:58  <NicolasDorier> I tried to explain the dangers in the README, let me know if I missed something
3092018-12-01T11:57:34  *** shesek has joined #bitcoin-core-dev
3102018-12-01T11:57:34  *** indistylo has joined #bitcoin-core-dev
3112018-12-01T11:57:34  *** shesek has quit IRC
3122018-12-01T11:57:34  *** shesek has joined #bitcoin-core-dev
3132018-12-01T12:00:46  *** shesek has quit IRC
3142018-12-01T12:01:29  *** shesek has joined #bitcoin-core-dev
3152018-12-01T12:07:41  *** CodeBlue1776 has quit IRC
3162018-12-01T12:07:58  *** indistylo has quit IRC
3172018-12-01T12:08:01  *** CodeBlue1776 has joined #bitcoin-core-dev
3182018-12-01T12:21:01  *** rh0nj has quit IRC
3192018-12-01T12:22:07  *** rh0nj has joined #bitcoin-core-dev
3202018-12-01T12:24:33  *** rex4539 has quit IRC
3212018-12-01T12:27:04  *** shesek has quit IRC
3222018-12-01T12:27:05  *** Victorsueca has quit IRC
3232018-12-01T12:27:06  *** e4xit has joined #bitcoin-core-dev
3242018-12-01T12:27:49  *** shesek has joined #bitcoin-core-dev
3252018-12-01T12:27:49  *** shesek has joined #bitcoin-core-dev
3262018-12-01T12:28:14  *** Victorsueca has joined #bitcoin-core-dev
3272018-12-01T12:36:28  *** belcher has quit IRC
3282018-12-01T12:54:07  *** shesek has quit IRC
3292018-12-01T12:55:15  *** shesek has joined #bitcoin-core-dev
3302018-12-01T12:55:15  *** shesek has joined #bitcoin-core-dev
3312018-12-01T13:13:21  *** shesek has quit IRC
3322018-12-01T13:17:42  *** shesek has joined #bitcoin-core-dev
3332018-12-01T13:17:42  *** shesek has joined #bitcoin-core-dev
3342018-12-01T13:21:43  *** indistylo has joined #bitcoin-core-dev
3352018-12-01T13:23:17  *** kempc has joined #bitcoin-core-dev
3362018-12-01T13:23:27  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3372018-12-01T14:00:36  *** fabianfabian has joined #bitcoin-core-dev
3382018-12-01T14:26:53  <Chris_Stewart_5> Is fanquake on github also fanquake in here? I forget. To reproduce failures on builds with different envs is the path of least resistant just using some sort of VM? Is there docs on that in our github?
3392018-12-01T14:28:31  <Chris_Stewart_5> basically reproducing https://github.com/bitcoin/bitcoin/pull/14853
3402018-12-01T14:30:37  *** rex4539 has joined #bitcoin-core-dev
3412018-12-01T14:55:38  *** shesek has quit IRC
3422018-12-01T14:56:09  *** shesek has joined #bitcoin-core-dev
3432018-12-01T15:00:51  *** shesek has quit IRC
3442018-12-01T15:02:00  *** shesek has joined #bitcoin-core-dev
3452018-12-01T15:16:18  *** Chris_Stewart_5 has quit IRC
3462018-12-01T15:24:04  *** Guyver2_ has joined #bitcoin-core-dev
3472018-12-01T15:25:52  *** Guyver2 has quit IRC
3482018-12-01T15:34:03  *** shesek has quit IRC
3492018-12-01T15:36:20  *** shesek has joined #bitcoin-core-dev
3502018-12-01T15:37:10  *** shesek has joined #bitcoin-core-dev
3512018-12-01T15:37:10  *** shesek has joined #bitcoin-core-dev
3522018-12-01T15:49:24  *** shesek has quit IRC
3532018-12-01T15:49:55  *** shesek has joined #bitcoin-core-dev
3542018-12-01T15:49:55  *** shesek has joined #bitcoin-core-dev
3552018-12-01T15:50:25  *** zallarak has joined #bitcoin-core-dev
3562018-12-01T15:50:29  *** shesek has quit IRC
3572018-12-01T15:51:32  *** shesek has joined #bitcoin-core-dev
3582018-12-01T15:51:32  *** shesek has joined #bitcoin-core-dev
3592018-12-01T15:52:15  *** shesek has quit IRC
3602018-12-01T15:52:41  *** shesek has joined #bitcoin-core-dev
3612018-12-01T15:55:46  *** shesek has quit IRC
3622018-12-01T15:57:15  *** shesek has joined #bitcoin-core-dev
3632018-12-01T16:00:20  *** shesek has quit IRC
3642018-12-01T16:03:08  *** shesek has joined #bitcoin-core-dev
3652018-12-01T16:03:08  *** shesek has joined #bitcoin-core-dev
3662018-12-01T16:08:06  *** luke-jr has quit IRC
3672018-12-01T16:10:10  *** AaronvanW has joined #bitcoin-core-dev
3682018-12-01T16:15:52  *** luke-jr has joined #bitcoin-core-dev
3692018-12-01T16:37:49  *** shesek has quit IRC
3702018-12-01T16:38:07  *** indistylo has quit IRC
3712018-12-01T16:41:29  *** promag has joined #bitcoin-core-dev
3722018-12-01T16:44:50  *** shesek has joined #bitcoin-core-dev
3732018-12-01T16:44:50  *** shesek has joined #bitcoin-core-dev
3742018-12-01T16:45:14  *** shesek has quit IRC
3752018-12-01T16:50:44  *** shesek has joined #bitcoin-core-dev
3762018-12-01T16:54:44  *** cubancorona has quit IRC
3772018-12-01T16:57:06  *** shesek has quit IRC
3782018-12-01T16:59:06  *** shesek has joined #bitcoin-core-dev
3792018-12-01T16:59:06  *** shesek has joined #bitcoin-core-dev
3802018-12-01T17:03:11  *** promag has quit IRC
3812018-12-01T17:08:46  *** spinza has quit IRC
3822018-12-01T17:09:14  *** shesek has quit IRC
3832018-12-01T17:09:49  *** shesek has joined #bitcoin-core-dev
3842018-12-01T17:13:35  *** shesek has quit IRC
3852018-12-01T17:14:22  *** shesek has joined #bitcoin-core-dev
3862018-12-01T17:14:22  *** shesek has joined #bitcoin-core-dev
3872018-12-01T17:18:15  *** jhfrontz has quit IRC
3882018-12-01T17:25:49  *** harrigan has quit IRC
3892018-12-01T17:26:03  *** harrigan has joined #bitcoin-core-dev
3902018-12-01T17:31:54  *** spinza has joined #bitcoin-core-dev
3912018-12-01T17:32:14  *** bitcoin-git has joined #bitcoin-core-dev
3922018-12-01T17:32:14  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to 0.17: https://github.com/bitcoin/bitcoin/compare/924cf794e1f4...3362a95be360
3932018-12-01T17:32:15  <bitcoin-git> bitcoin/0.17 fcdea8a Andrew Chow: Drop the unnecessary UTXO based on the UTXOs present, not on earlier wallet things...
3942018-12-01T17:32:15  <bitcoin-git> bitcoin/0.17 fcefc68 Andrew Chow: Convert non-witness UTXOs to witness if witness sig created...
3952018-12-01T17:32:16  <bitcoin-git> bitcoin/0.17 3362a95 MarcoFalke: Merge #14196: [0.17][psbt] always drop the unnecessary utxo and convert non-witness utxo to witness when necessary...
3962018-12-01T17:32:16  *** bitcoin-git has left #bitcoin-core-dev
3972018-12-01T17:46:39  *** Guyver2_ is now known as Guyver2
3982018-12-01T17:53:17  *** Guyver2 has quit IRC
3992018-12-01T17:54:00  *** Guyver2 has joined #bitcoin-core-dev
4002018-12-01T18:05:09  *** shesek has quit IRC
4012018-12-01T18:05:40  *** shesek has joined #bitcoin-core-dev
4022018-12-01T18:10:42  *** zautomata has joined #bitcoin-core-dev
4032018-12-01T18:12:23  *** zautomata has quit IRC
4042018-12-01T18:12:23  *** zautomata has joined #bitcoin-core-dev
4052018-12-01T18:14:09  <sipa> NicolasDorier: it seems people misunderstood your document then
4062018-12-01T18:15:24  <sipa> NicolasDorier: but i'm still worried about a lack of review procedure... what prevents you from signing a snapshot every day?
4072018-12-01T18:15:42  <sipa> the more frequently you do it, the better the user experience will be
4082018-12-01T18:19:07  *** rhavar has joined #bitcoin-core-dev
4092018-12-01T18:33:42  *** _flow_ has quit IRC
4102018-12-01T18:36:51  <harding> NicolasDorier: you might get a clearer and less controversial security model by using SPV for BTCPay and having it connect to a single trusted node.  That way people can run BTCPay on low-power hardware and the people who want to do personal full verification can connect to their own node from BTCPay.  The people who don't care about doing full verification can just connect to someone else's node to use BTCPay, and you can have a
4112018-12-01T18:36:51  <harding> warning on one of BTCPay's pages telling them that they're trusting the operator of the node at 1.2.3.4 to choose the best chain for them.
4122018-12-01T18:47:18  *** shesek has quit IRC
4132018-12-01T18:48:37  *** _flow_ has joined #bitcoin-core-dev
4142018-12-01T18:50:34  *** shesek has joined #bitcoin-core-dev
4152018-12-01T18:50:35  *** shesek has quit IRC
4162018-12-01T18:50:35  *** shesek has joined #bitcoin-core-dev
4172018-12-01T19:00:15  <harding> NicolasDorier: oh, another nice advantage of that approach would be on moderately-powerful hardware you could start in trust-third-party SPV mode for almost-immediate usability of BTCPay.  At the same time, you could start a local full node and let it start syncing.  When the local node has synced after a day, a week, or even a month, BTCPay can seemlessly switch over to using that to eliminate trust on outside nodes.
4182018-12-01T19:00:34  *** fabianfabian has quit IRC
4192018-12-01T19:04:14  *** fabianfabian has joined #bitcoin-core-dev
4202018-12-01T19:07:04  *** zallarak has quit IRC
4212018-12-01T19:21:11  *** Guyver2_ has joined #bitcoin-core-dev
4222018-12-01T19:24:04  *** Guyver2 has quit IRC
4232018-12-01T19:52:09  *** FiatJustitia has joined #bitcoin-core-dev
4242018-12-01T19:58:44  *** Aaronvan_ has joined #bitcoin-core-dev
4252018-12-01T20:01:40  *** AaronvanW has quit IRC
4262018-12-01T20:02:08  *** Guyver2__ has joined #bitcoin-core-dev
4272018-12-01T20:04:52  *** Guyver2_ has quit IRC
4282018-12-01T20:09:17  *** FiatJustitia has quit IRC
4292018-12-01T20:16:02  *** rh0nj has quit IRC
4302018-12-01T20:17:08  *** rh0nj has joined #bitcoin-core-dev
4312018-12-01T20:30:29  *** Guyver2__ has quit IRC
4322018-12-01T20:34:57  *** prova has joined #bitcoin-core-dev
4332018-12-01T20:40:25  *** zallarak has joined #bitcoin-core-dev
4342018-12-01T20:43:36  *** prova has quit IRC
4352018-12-01T20:44:51  *** kempc has quit IRC
4362018-12-01T20:45:25  *** zallarak has quit IRC
4372018-12-01T20:52:39  *** wxss_ has quit IRC
4382018-12-01T20:52:39  *** so has quit IRC
4392018-12-01T20:53:13  *** Aaronvan_ has quit IRC
4402018-12-01T20:54:20  *** ghost43 has quit IRC
4412018-12-01T20:54:34  *** wxss has joined #bitcoin-core-dev
4422018-12-01T20:54:34  *** ghost43 has joined #bitcoin-core-dev
4432018-12-01T21:03:53  *** AaronvanW has joined #bitcoin-core-dev
4442018-12-01T21:08:19  *** AaronvanW has quit IRC
4452018-12-01T21:10:09  *** Eagle[TM] has joined #bitcoin-core-dev
4462018-12-01T21:11:52  *** EagleTM has quit IRC
4472018-12-01T21:12:46  *** benjamin8 has joined #bitcoin-core-dev
4482018-12-01T21:13:13  *** benjamin8 has quit IRC
4492018-12-01T21:20:47  *** so has joined #bitcoin-core-dev
4502018-12-01T21:31:59  *** Iahweh has joined #bitcoin-core-dev
4512018-12-01T21:34:45  *** Iahweh has left #bitcoin-core-dev
4522018-12-01T21:58:14  *** shesek has quit IRC
4532018-12-01T21:58:45  *** shesek has joined #bitcoin-core-dev
4542018-12-01T22:04:41  *** AaronvanW has joined #bitcoin-core-dev
4552018-12-01T22:09:04  *** AaronvanW has quit IRC
4562018-12-01T22:15:04  *** phwalkr has quit IRC
4572018-12-01T22:21:00  *** hebasto has joined #bitcoin-core-dev
4582018-12-01T22:23:08  *** CodeBlue1776 has quit IRC
4592018-12-01T22:24:10  *** CodeBlue1776 has joined #bitcoin-core-dev
4602018-12-01T22:26:41  *** phwalkr has joined #bitcoin-core-dev
4612018-12-01T22:26:58  <phantomcircuit> interesting, i have a vm where select() calls are regularly being interrupted by signals on master
4622018-12-01T22:27:17  <phantomcircuit> hmm let me double chec that isn't master actually
4632018-12-01T22:41:22  *** AaronvanW has joined #bitcoin-core-dev
4642018-12-01T22:45:08  *** spinza has quit IRC
4652018-12-01T22:45:34  <phantomcircuit> indeed it is
4662018-12-01T22:55:15  *** spinza has joined #bitcoin-core-dev
4672018-12-01T23:06:18  *** shesek has quit IRC
4682018-12-01T23:06:46  *** shesek has joined #bitcoin-core-dev
4692018-12-01T23:06:46  *** shesek has joined #bitcoin-core-dev
4702018-12-01T23:15:50  <esotericnonsense> if you do have a utxo snapshot, the idea should be that the period is sufficiently long that an alarm can be sounded if the snapshot isn't actually correct.
4712018-12-01T23:16:15  <esotericnonsense> i'm not sure if this is just an assumed obvious point in the previous discussion (i think that's what gmax is trying to get at with the review period).
4722018-12-01T23:16:46  <esotericnonsense> if you have something super short then you have to have automated "alarms" and some way of disseminating very very quickly 'oh hey the snapshot in software XYZ is nonsense'.
4732018-12-01T23:18:31  <esotericnonsense> it's not about 'decentralization' vs 'centralization' at all. a utxo snapshot in some repository somewhere is a 100% centralized source of truth regardless of whether it is the genesis block or 1 block ago. but if it's very very long ago then people have time to talk about it and warn users away from using bad software.
4742018-12-01T23:19:01  <gmaxwell> esotericnonsense: and if your have automated alarms then you have to worry about the automation being compromised.
4752018-12-01T23:19:23  <esotericnonsense> yes. e.g. externally someone can eclipse attack the nodes used for the checks.
4762018-12-01T23:19:53  <esotericnonsense> sorry, I think I wasn't clear enough, a short period is useless and shouldn't ever be used.
4772018-12-01T23:20:20  <esotericnonsense> the costs outweigh the benefits in most cases I would think for anything shorter than _at least_ a few weeks in the current ecosystem but probably months or morw.
4782018-12-01T23:20:23  <esotericnonsense> more*
4792018-12-01T23:22:00  <gmaxwell> Another way I look at short tims is this: Say given your hardware and sync time tolerance, you want a snapshot no less than X blocks back.  This also means that if you're down for more than X blocks, you'll want to snapshot instead of catch up, becuase your tolerance for downtime is not going to be better than your tolerance for initial sync (and probably a lot worse).
4802018-12-01T23:22:46  <gmaxwell> this is the factor that has resulted in the norm in ethereum that if your node has fallen behind, you resync it. ... maybe it fell behind because it was too slow, because your link was down, or because miners decided to break the rules. ... in all cases, "fixed by resync".
4812018-12-01T23:23:28  <gmaxwell> I'm told that at least one exchange has their ethereum nodes do that automatically if they fall behind some block explorer they poll.
4822018-12-01T23:36:09  *** phwalkr has quit IRC
4832018-12-01T23:36:17  *** ap4lmtree has quit IRC
4842018-12-01T23:36:43  *** ap4lmtree has joined #bitcoin-core-dev
4852018-12-01T23:40:31  *** bitcoin-git has joined #bitcoin-core-dev
4862018-12-01T23:40:32  <bitcoin-git> [bitcoin] hebasto opened pull request #14854: qt: Cleanup SplashScreen class (master...20181201-cleanup-splashscreen) https://github.com/bitcoin/bitcoin/pull/14854
4872018-12-01T23:40:32  *** bitcoin-git has left #bitcoin-core-dev