--- Log opened Sat Dec 01 00:00:38 2018
--- Day changed Sat Dec 01 2018
00:00 -!- indistylo [~indistylo@106.51.29.204] has joined #bitcoin-core-dev
00:00 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev
00:03 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
00:04 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
00:04 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
00:04 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
00:11 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
00:14 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds]
00:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
00:26 < 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.
00:30 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
00:36 < aj> NicolasDorier: oh, i was thinking that was part of a "btc-in-a-box" releases, not core ones
00:37 < 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
00:38 < 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
00:39 < gmaxwell> 300 block snapshots effectively means that the node is not fast enough to catch up after a bit of an outage.
00:39 < sipa> aj: yes, that would be much more reasonable, and be compatible with a public audit
00:39 < gmaxwell> which is what you have in ethereum,-- if you fall behind you have to re-quick-sync.
00:40 < 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.
00:40 < gribble> https://github.com/bitcoin/bitcoin/issues/9483 | Complete hybrid full block SPV mode by jonasschnelli · Pull Request #9483 · bitcoin/bitcoin · GitHub
00:40 -!- albypaul [3aa789c0@gateway/web/freenode/ip.58.167.137.192] has joined #bitcoin-core-dev
00:41 < gmaxwell> provoostenator: there is no reason to use neutrino filters for the sorts of use case contemplated here, AFAIK.
00:41 < provoostenator> The idea is spin up the node as quickly as possible with as little trust as possible.
00:41 < 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.
00:41 < luke-jr> is it time to make a wiki page reflecting devs' opinions on block size/weight reduction softforks? ;p
00:42 < 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.
00:42 < luke-jr> albypaul: #bitcoin
00:42 < sipa> albypaul: use regtest mode
00:42 < 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.
00:42 < 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.
00:42 < luke-jr> (unless you really mean testing purposes)
00:42 < gmaxwell> provoostenator: yup.
00:43 < albypaul> none testing
00:43 < luke-jr> albypaul: if you're not testing, then ask in #bitcoin to learn why you can't
00:43 -!- TrisHoar24 [~TrisHoar@122.254.153.210] has joined #bitcoin-core-dev
00:43 < albypaul> thank you luke
00:44 -!- TrisHoar24 [~TrisHoar@122.254.153.210] has quit [Read error: Connection reset by peer]
00:45 -!- albypaul [3aa789c0@gateway/web/freenode/ip.58.167.137.192] has quit [Client Quit]
00:46 < 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).
00:46 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
00:47 < gmaxwell> provoostenator: jonasschnelli previously implemented much of it
00:47 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
00:47 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
00:47 < provoostenator> Yes, and that PR is in limbo, partially because it was too big and needed splitting.
00:47 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
00:47 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
00:47 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
00:48 < 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?
00:48 < 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
00:49 < luke-jr> aj: but an opinions page could present multiple opinions ofc
00:49 < luke-jr> (reasonable meaning, when we had a safe level of users running full nodes of their own)
00:55 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: No route to host]
00:55 < 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.
00:56 < gmaxwell> I don't believe e.g. the things cited for btcpay (cheap vpses, rpis) are speeding up at 17%pa.
00:57 < 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?
00:57 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
00:57 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
00:57 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
00:57 < 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.
00:57 < gmaxwell> aj: 50M!?! 2500M you mean...
00:57 < gmaxwell> oh maybe 50 million entries.
00:58 < aj> yeah, entries, not bytes
00:58 < luke-jr> gmaxwell: what do you mean? we need to go lower? :|
00:59 < provoostenator> gmaxmell it sounds like SPV start has the biggest bang for developer & review buck
00:59 < provoostenator> *w
00:59 < luke-jr> SPV start isn't really a solution to an indefinitely growing IBD time
00:59 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
01:00 < luke-jr> although maybe it would make the current chain size more tolerable to users
01:00 < 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.
01:00 -!- indistylo [~indistylo@106.51.29.204] has quit [Ping timeout: 250 seconds]
01:00 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
01:00 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
01:00 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
01:00 < gmaxwell> so it would immediately take things from unusable to "okay" for a large class of users.
01:00 < luke-jr> gmaxwell: and can use Netflix in the meantime :/
01:00 < provoostenator> Exactly. Initial experience matters.
01:01 < gmaxwell> luke-jr: yes, esp if its in the background we could reasonably rate limit the sync.
01:01 < provoostenator> Once people are hooked, they'll accept slower sync :-)
01:01 < luke-jr> gmaxwell: but if 17% is too much, going based on the current blockchain size might just put us back at 300k anyway :<
01:01 < 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.
01:02 < 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.
01:02 < luke-jr> people choosing paypal doesn't harm Bitcoin's security, though
01:02 < gmaxwell> And so low end SBC hardware or VPSes will continue to target low end usage, which will work with centeralized bitcoin alternatives.
01:03 < gmaxwell> luke-jr: well it does when to compete with paypal others make centeralized bitcoin solutions.
01:04 < luke-jr> I must be misunderstanding you somehow.
01:04 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
01:04 < 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.
01:04 < gribble> https://github.com/bitcoin/bitcoin/issues/13937 | Track best-possible-headers (TheBlueMatt) by Sjors · Pull Request #13937 · bitcoin/bitcoin · GitHub
01:05 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
01:05 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
01:05 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
01:05 < luke-jr> provoostenator: it's probably one possible approach to the end goal
01:05 < luke-jr> with some useful side effects
01:05 < provoostenator> So I'm trying to figure what to tell anyone who wants to work on this problem, what would be something manageable.
01:05 < 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.
01:06 < 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.
01:06 < 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. 
01:06 < luke-jr> gmaxwell: ah, like moving economic activity to centralised off-chain solutions?
01:07 < provoostenator> gmaxwell: thanks, no rush at all
01:07 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
01:07 < gmaxwell> luke-jr: worse, really bad ones, rather than like.. more thoughtfully created ones.
01:08 < gmaxwell> and then also advertise them as decenteralized. :P
01:08 < luke-jr> well, if they move to altcoins, that's not so much Bitcoin's problem..
01:08 < luke-jr> hence why I'd like to see a certain altcoin survive some forking mess
01:09 < sipa> luke-jr: if chasing people away to alternatives is a solution, then 0 kb block size limit is ideal.
01:09 < gmaxwell> :P
01:09 < 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.
01:09 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
01:09 < luke-jr> sipa: well, chasing away centralising people would only be a means to a goal (keeping Bitcoin itself secure)
01:10 < gmaxwell> A luke-jr only currency would not have any scaling problems, at all... and that would be a problem for it. :P
01:10 < luke-jr> 0k block size kinda throws the baby out with the bathwater
01:10 < 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
01:10 < 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.
01:11 < sipa> if the only thing that works is centralized, it will be what most, if not everyone, uses
01:11 < luke-jr> gmaxwell: hopefully Lightning helps with that
01:11 < gmaxwell> Absolutely.
01:11 < provoostenator> And there's people who care about decentralalization just as much but don't fully appreciate the risks, especially the more subtle problems.
01:11 < gmaxwell> But thats also just one thing in a broader spectrum of improvements.
01:11 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
01:13 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
01:13 < 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.
01:13 < gmaxwell> instead, most parties were using a hosted centeralized solution.
01:14 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit []
01:14 < luke-jr> eh, I don't think smaller blocks is at odds with BTCPay - it sounds like it would even help
01:15 < luke-jr> especially considering BitPay apparently doing stupid things with extra sweep transactions
01:15 < provoostenator> I think gmaxwell meant things like SPV sync with "supporting infrastructure"
01:15 < 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.
01:15 < gmaxwell> provoostenator: right.
01: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.
01:16 < gmaxwell> (and, perhaps, lightning)
01:16 < luke-jr> I don't think these approaches needs to be exclusionary to others (like smaller blocks)
01:17 < luke-jr> blockchain size just happens to be the one irreversible factor, so IMO somewhat of a priority
01:17 < 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.
01:18 < gmaxwell> luke-jr: it's not an irreversable factor. At least in terms of initial time, I think it's substantially addressed by UTXOassumevalid.
01:18 < 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.
01:18 < 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.
01:18 < provoostenator> That will fix itself though if the deplatforming continuous and the alternatives get increasingly better.
01:19 < luke-jr> gmaxwell: UTXOassumevalid is no longer a full node security level if it means what it sounds like
01:20 < gmaxwell> luke-jr: I believe it has the same security model that users get right now.
01:20 < sipa> luke-jr: if it isn't, then running a full node you haven't implemented yourself isn't either
01:20 < 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
01:20 < luke-jr> sipa: you *can* audit full node code. If people rely on UTXOassumevalid, they *can't* audit the hash
01:21 < sipa> sure they can; run a node with utxoassumevalid disabled
01:21 < 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.
01:21 < luke-jr> sipa: then they're not relying on it
01:21 < 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.
01:22 < sipa> luke-jr: i believe more people will recalculate the utxo hash than there are people capable of reviewing the source code
01:22 < sipa> (given sufficiently accessible processes around it etc)
01:22 < 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.
01:23 < 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.
01:23 < provoostenator> So this UTXOassumevalid would use a much older block than we do with assumevalid? 
01:23 < 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
01:23 < gmaxwell> provoostenator: somewhat older because of a pratical issue of managing the snapshots.
01:23 < gmaxwell> sipa: which is why that idea was created. :)
01:24 < gmaxwell> (at least as far as I'm concerned)
01:24 < sipa> gmaxwell: i know.
01:24 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
01:25 < 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.
01:25 < provoostenator> You're putting the full snap shot in the binary, right? Not a hash and relying on P2P. 
01:25 < gmaxwell> provoostenator: it's reasonable to expect nodes to keep the last two or something, but not dozens of them.
01:25 < sipa> no, relay over p2p
01:25 < gmaxwell> provoostenator: over P2P, otherwise its too hard to distribute the software without extensive centeralization.
01:25 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
01:25 < sipa> if we can relay blocks over P2P, we can definitely do the same with a utxo set (which is smaller than the blockchain!)
01:25 < 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.
01:26 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
01:26 < provoostenator> Right, that's gigabytes. Would be easier with the accumulator. 
01:26 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
01:27 < 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
01:27 < 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. 
01:27 < 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)
01:27 < provoostenator> sipa: but you could still still use an assume valid accumulator state in the same vain
01:27 < 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. :)
01:28 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
01:28 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-fdhatevvffyokerd] has joined #bitcoin-core-dev
01:28 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/011c42c5bd17...5ab5341d1356
01:28 < bitcoin-git> bitcoin/master c5ed6e7 Hennadii Stepanov: Move CheckBlock() call to critical section...
01:28 < bitcoin-git> bitcoin/master 5ab5341 Wladimir J. van der Laan: Merge #14841: consensus: Move CheckBlock() call to critical section...
01:28 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-fdhatevvffyokerd] has left #bitcoin-core-dev []
01:29 < 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.
01:29 < provoostenator> ^ quite possibly the scariest commit name one can thing of
01:29 < sipa> how so?
01:29 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-tqaouvjbciqnmjqu] has joined #bitcoin-core-dev
01:29 < 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
01:29 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-tqaouvjbciqnmjqu] has left #bitcoin-core-dev []
01:30 < provoostenator> It has the words consensus, check (block) and critical.
01:30 < gmaxwell> fortunately it just moves a lock.
01:31 < wumpus> that's good, maybe it will prompt some people to pay attention :)
01:31 < sipa> ha
01:31 < gmaxwell> not riskless, at all, no code change really is.
01:31 < gmaxwell> I feel a lot more confortable about that change than the unpatched code!  (who needs locks!)
01:32 < 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)
01:32 < 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
01:34 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has quit [Ping timeout: 246 seconds]
01:36 < 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.
01:36 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-dev
01:37 < provoostenator> Thanks sounds pretty cool, looking forward to read about it.
01:37 < gmaxwell> well, you might have to build it if you want to read about it. :)
01:40  * provoostenator hides
01:42 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
01:43 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
01:43 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
01:43 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
01:44 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 244 seconds]
01:48 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
01:48 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
01:55 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has quit [Remote host closed the connection]
01:56 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has joined #bitcoin-core-dev
02:00 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-core-dev
02:00 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
02:04 -!- kexkey [~kexkey@173.209.61.62] has quit [Ping timeout: 250 seconds]
02:19 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 244 seconds]
02:24 -!- rhavar [uid237883@gateway/web/irccloud.com/x-afldeaustetraitk] has quit [Quit: Connection closed for inactivity]
02:25 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
02:29 -!- hgfjkgh [67630f4f@gateway/web/freenode/ip.103.99.15.79] has quit [Quit: Page closed]
02:32 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
02:33 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
02:33 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
02:33 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
02:36 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-core-dev
02:36 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
02:38 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
02:57 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
02:57 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
02:59 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
02:59 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
02:59 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
03:07 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
03:08 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: No route to host]
03:09 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
03:11 -!- laurentmt [~Thunderbi@94.242.228.172] has joined #bitcoin-core-dev
03:18 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 245 seconds]
03:20 -!- laurentmt [~Thunderbi@94.242.228.172] has quit [Quit: laurentmt]
03:25 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-bnoexgskwliyodnn] has joined #bitcoin-core-dev
03:25 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/5ab5341d1356...ed12fd83ca79
03:25 < bitcoin-git> bitcoin/master fe1ff50 Chun Kuan Lee: Hide spendable label if priveate key is disabled
03:25 < bitcoin-git> bitcoin/master 82d6c5a Chun Kuan Lee: gui: Show watch-only eye instead of HD disabled
03:25 < bitcoin-git> bitcoin/master ed12fd8 Wladimir J. van der Laan: Merge #13966: gui: When private key is disabled, only show watch-only balance...
03:25 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-bnoexgskwliyodnn] has left #bitcoin-core-dev []
03:25 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-jfqhlirjvzkkezxd] has joined #bitcoin-core-dev
03:25 < 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
03:25 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-jfqhlirjvzkkezxd] has left #bitcoin-core-dev []
03:40 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
03:50 < 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.
03:50 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
03:50 < NicolasDorier> I tried to explain the dangers in the README, let me know if I missed something
03:57 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
03:57 -!- indistylo [~indistylo@106.51.29.204] has joined #bitcoin-core-dev
03:57 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
03:57 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
04:00 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
04:01 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
04:07 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has quit [Read error: Connection reset by peer]
04:07 -!- indistylo [~indistylo@106.51.29.204] has quit [Ping timeout: 245 seconds]
04:08 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-dev
04:21 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection]
04:22 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev
04:24 -!- rex4539 [~rex4539@ppp-2-84-161-2.home.otenet.gr] has quit [Quit: rex4539]
04:27 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
04:27 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
04:27 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-core-dev
04:27 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
04:27 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
04:27 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
04:28 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
04:36 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
04:54 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
04:55 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
04:55 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
04:55 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
05:13 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
05:17 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
05:17 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
05:17 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
05:21 -!- indistylo [~indistylo@106.51.29.204] has joined #bitcoin-core-dev
05:23 -!- kempc [1838e3ae@gateway/web/freenode/ip.24.56.227.174] has joined #bitcoin-core-dev
05:23 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:00 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has joined #bitcoin-core-dev
06:26 < 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?
06:28 < Chris_Stewart_5> basically reproducing https://github.com/bitcoin/bitcoin/pull/14853
06:30 -!- rex4539 [~rex4539@ppp-2-84-161-2.home.otenet.gr] has joined #bitcoin-core-dev
06:55 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
06:56 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
07:00 -!- shesek [~shesek@unaffiliated/shesek] has quit [Excess Flood]
07:01 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
07:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
07:24 -!- Guyver2_ [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
07:25 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds]
07:34 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
07:36 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
07:36 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
07:36 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
07:36 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: No route to host]
07:37 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
07:37 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
07:37 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
07:49 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
07:49 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
07:49 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
07:49 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
07:50 -!- zallarak [~zain@c-71-202-100-255.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
07:50 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
07:51 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
07:51 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
07:51 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
07:52 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
07:52 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
07:55 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
07:57 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
08:00 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
08:03 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
08:03 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
08:03 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
08:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 252 seconds]
08:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
08:15 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
08:37 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
08:38 -!- indistylo [~indistylo@106.51.29.204] has quit [Ping timeout: 240 seconds]
08:41 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
08:44 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
08:44 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
08:44 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
08:45 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
08:50 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
08:54 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has quit [Remote host closed the connection]
08:57 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
08:59 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
08:59 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
08:59 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
09:03 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
09:08 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
09:09 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
09:09 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
09:13 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
09:14 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
09:14 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
09:14 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
09:18 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has quit [Quit: Leaving.]
09:25 -!- harrigan [~harrigan@skynet.skynet.ie] has quit [Quit: ZNC 1.7.0 - https://znc.in]
09:26 -!- harrigan [~harrigan@skynet.skynet.ie] has joined #bitcoin-core-dev
09:31 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
09:32 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-sunxfqrhnxlrmqfh] has joined #bitcoin-core-dev
09:32 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to 0.17: https://github.com/bitcoin/bitcoin/compare/924cf794e1f4...3362a95be360
09:32 < bitcoin-git> bitcoin/0.17 fcdea8a Andrew Chow: Drop the unnecessary UTXO based on the UTXOs present, not on earlier wallet things...
09:32 < bitcoin-git> bitcoin/0.17 fcefc68 Andrew Chow: Convert non-witness UTXOs to witness if witness sig created...
09:32 < 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...
09:32 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-sunxfqrhnxlrmqfh] has left #bitcoin-core-dev []
09:46 -!- Guyver2_ is now known as Guyver2
09:53 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
09:54 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
10:05 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
10:05 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
10:10 -!- zautomata [~zautomata@41.43.121.10] has joined #bitcoin-core-dev
10:12 -!- zautomata [~zautomata@41.43.121.10] has quit [Changing host]
10:12 -!- zautomata [~zautomata@unaffiliated/zautomata] has joined #bitcoin-core-dev
10:14 < sipa> NicolasDorier: it seems people misunderstood your document then
10:15 < sipa> NicolasDorier: but i'm still worried about a lack of review procedure... what prevents you from signing a snapshot every day?
10:15 < sipa> the more frequently you do it, the better the user experience will be
10:19 -!- rhavar [uid237883@gateway/web/irccloud.com/x-nmuypxelkpgieaaz] has joined #bitcoin-core-dev
10:33 -!- _flow_ [~none@salem.informatik.uni-erlangen.de] has quit [Ping timeout: 250 seconds]
10:36 < 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 
10:36 < 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.
10:47 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
10:48 -!- _flow_ [~none@salem.informatik.uni-erlangen.de] has joined #bitcoin-core-dev
10:50 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
10:50 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
10:50 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
11:00 < 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.
11:00 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
11:04 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has joined #bitcoin-core-dev
11:07 -!- zallarak [~zain@c-71-202-100-255.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds]
11:21 -!- Guyver2_ [~Guyver@2001:985:f3f:1:a895:e507:4bb6:f6ac] has joined #bitcoin-core-dev
11:24 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds]
11:52 -!- FiatJustitia [~Fiat-Just@108-75-120-50.lightspeed.bcvloh.sbcglobal.net] has joined #bitcoin-core-dev
11:58 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
12:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
12:02 -!- Guyver2__ [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
12:04 -!- Guyver2_ [~Guyver@2001:985:f3f:1:a895:e507:4bb6:f6ac] has quit [Ping timeout: 264 seconds]
12:09 -!- FiatJustitia [~Fiat-Just@108-75-120-50.lightspeed.bcvloh.sbcglobal.net] has quit [Quit: Leaving]
12:16 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection]
12:17 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev
12:30 -!- Guyver2__ [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
12:34 -!- prova [5d331227@gateway/web/freenode/ip.93.51.18.39] has joined #bitcoin-core-dev
12:40 -!- zallarak [~zain@c-71-202-100-255.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
12:43 -!- prova [5d331227@gateway/web/freenode/ip.93.51.18.39] has quit [Quit: Page closed]
12:44 -!- kempc [1838e3ae@gateway/web/freenode/ip.24.56.227.174] has quit [Quit: Page closed]
12:45 -!- zallarak [~zain@c-71-202-100-255.hsd1.ca.comcast.net] has quit [Quit: leaving]
12:52 -!- wxss_ [~user@77.243.177.40] has quit [Ping timeout: 246 seconds]
12:52 -!- so [~so@unaffiliated/so] has quit [Ping timeout: 246 seconds]
12:53 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
12:54 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
12:54 -!- wxss [~user@77.243.177.40] has joined #bitcoin-core-dev
12:54 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
13:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
13:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 244 seconds]
13:10 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
13:11 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 250 seconds]
13:12 -!- benjamin8 [~benjamin@201-95-35-10.dsl.telesp.net.br] has joined #bitcoin-core-dev
13:13 -!- benjamin8 [~benjamin@201-95-35-10.dsl.telesp.net.br] has quit [Remote host closed the connection]
13:20 -!- so [~so@unaffiliated/so] has joined #bitcoin-core-dev
13:31 -!- Iahweh [~Iahweh@189.112.13.33] has joined #bitcoin-core-dev
13:34 -!- Iahweh [~Iahweh@189.112.13.33] has left #bitcoin-core-dev []
13:58 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
13:58 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
14:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
14:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
14:15 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has quit [Remote host closed the connection]
14:21 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
14:23 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has quit [Read error: Connection reset by peer]
14:24 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-dev
14:26 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
14:26 < phantomcircuit> interesting, i have a vm where select() calls are regularly being interrupted by signals on master
14:27 < phantomcircuit> hmm let me double chec that isn't master actually
14:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
14:45 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
14:45 < phantomcircuit> indeed it is
14:55 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
15:06 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 268 seconds]
15:06 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
15:06 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
15:06 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
15:15 < 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.
15:16 < 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).
15:16 < 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'.
15:18 < 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.
15:19 < gmaxwell> esotericnonsense: and if your have automated alarms then you have to worry about the automation being compromised.
15:19 < esotericnonsense> yes. e.g. externally someone can eclipse attack the nodes used for the checks.
15:19 < esotericnonsense> sorry, I think I wasn't clear enough, a short period is useless and shouldn't ever be used.
15: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.
15:20 < esotericnonsense> more*
15:22 < 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).
15:22 < 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".
15:23 < 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.
15:36 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has quit [Remote host closed the connection]
15:36 -!- ap4lmtree [~ap4lmtree@unaffiliated/ap4lmtree] has quit [Remote host closed the connection]
15:36 -!- ap4lmtree [~ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev
15:40 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-vwmlkoamzlxezqzc] has joined #bitcoin-core-dev
15:40 < bitcoin-git> [bitcoin] hebasto opened pull request #14854: qt: Cleanup SplashScreen class (master...20181201-cleanup-splashscreen) https://github.com/bitcoin/bitcoin/pull/14854
15:40 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-vwmlkoamzlxezqzc] has left #bitcoin-core-dev []
16:01 < phantomcircuit> gmaxwell, so the poll() implementation takes about 2us with 8 peers and select takes 1us with 8 peers
16:01 < phantomcircuit> im guessing it's basically linear 1:1 badness
16:02 < phantomcircuit> but that seems fine to me
16:05 < gmaxwell> yes, I think thats basically irrelevant.
16:15 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
16:23 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
16:39 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
16:39 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
16:40 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
16:43 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
16:44 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
16:52 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 268 seconds]
17:00 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev
17:12 -!- wxss [~user@77.243.177.40] has quit [Quit: leaving]
17:12 -!- ap4lmtree [~ap4lmtree@unaffiliated/ap4lmtree] has quit [Remote host closed the connection]
17:12 -!- ap4lmtree [~ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev
17:14 -!- ap4lmtree [~ap4lmtree@unaffiliated/ap4lmtree] has quit [Read error: Connection reset by peer]
17:15 -!- ap4lmtree [~ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev
17:27 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
17:28 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
17:29 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
17:29 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
17:29 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
17:31 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
17:32 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
17:32 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
17:32 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
17:37 -!- da2ce7_ [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 245 seconds]
17:38 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev
17:46 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
17:53 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
17:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]
18:15 -!- frrely [9903a9d9@gateway/web/freenode/ip.153.3.169.217] has joined #bitcoin-core-dev
18:35 -!- indistylo [~indistylo@106.51.29.204] has joined #bitcoin-core-dev
18:36 -!- _cryptodesktop_i [~John@91.245.77.21] has joined #bitcoin-core-dev
18:46 -!- gertjaap [uid322815@gateway/web/irccloud.com/x-mlsdkwtfgfbkvgmj] has quit [Ping timeout: 252 seconds]
18:46 -!- gertjaap [sid322815@gateway/web/irccloud.com/x-uuoqibuumqmkuyte] has joined #bitcoin-core-dev
18:47 -!- dongcarl [uid321684@gateway/web/irccloud.com/x-rmabtpzhpydqszuw] has quit [Ping timeout: 252 seconds]
18:49 -!- dongcarl [sid321684@gateway/web/irccloud.com/x-gdifntnxjpmpetls] has joined #bitcoin-core-dev
18:59 -!- indistylo [~indistylo@106.51.29.204] has quit [Ping timeout: 246 seconds]
19:05 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
19:06 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
19:06 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
19:06 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
19:07 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
19:09 -!- chenpo [~chenpo@2001-b011-5c0d-1f89-c832-86dc-12aa-0f2c.dynamic-ip6.hinet.net] has quit [Remote host closed the connection]
19:10 -!- chenpo [~chenpo@2001-b011-5c0d-1f89-4177-fac4-f407-327c.dynamic-ip6.hinet.net] has joined #bitcoin-core-dev
19:10 -!- _cryptodesktop_i [~John@91.245.77.21] has quit [Ping timeout: 250 seconds]
19:14 -!- chenpo [~chenpo@2001-b011-5c0d-1f89-4177-fac4-f407-327c.dynamic-ip6.hinet.net] has quit [Ping timeout: 268 seconds]
19:15 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
19:29 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has quit [Ping timeout: 250 seconds]
19:50 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev
20:09 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #bitcoin-core-dev
20:16 -!- killerCC [~Android@2607:fb90:4ae5:a1c3:0:17:5e3f:2201] has joined #bitcoin-core-dev
20:21 -!- killerCC [~Android@2607:fb90:4ae5:a1c3:0:17:5e3f:2201] has quit [Quit: -a- IRC for Android 2.1.28]
20:25 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
20:25 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
20:25 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
20:25 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
20:26 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
20:26 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
20:26 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
20:26 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
20:41 -!- chenpo [~chenpo@111-241-129-9.dynamic-ip.hinet.net] has joined #bitcoin-core-dev
20:41 -!- chenpo [~chenpo@111-241-129-9.dynamic-ip.hinet.net] has quit [Remote host closed the connection]
20:41 -!- chenpo [~chenpo@111-241-129-9.dynamic-ip.hinet.net] has joined #bitcoin-core-dev
20:47 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
20:49 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
20:52 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: https://www.Quanto.ga/]
20:52 -!- chenpo [~chenpo@111-241-129-9.dynamic-ip.hinet.net] has quit []
20:53 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
20:55 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 250 seconds]
21:12 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev
21:17 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.3]
21:18 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
21:19 -!- shesek [~shesek@5.22.134.170] has joined #bitcoin-core-dev
21:19 -!- shesek [~shesek@5.22.134.170] has quit [Changing host]
21:19 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
21:48 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
22:14 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
22:15 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
22:16 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
22:18 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
22:51 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has quit [Quit: Find me in #TheHolyRoger or https://theholyroger.com]
22:55 -!- indistylo [~indistylo@106.51.29.204] has joined #bitcoin-core-dev
22:55 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has joined #bitcoin-core-dev
22:59 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has quit [Client Quit]
23:02 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has joined #bitcoin-core-dev
23:25 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: No route to host]
23:26 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
23:43 -!- harrymm [~harrymm@69.161.195.103] has quit [Ping timeout: 268 seconds]
23:50 -!- prova [b9801b9b@gateway/web/freenode/ip.185.128.27.155] has joined #bitcoin-core-dev
23:52 -!- harrymm [~harrymm@69.161.195.103] has joined #bitcoin-core-dev
--- Log closed Sun Dec 02 00:00:40 2018