--- Log opened Tue Dec 25 00:00:02 2018 00:51 -!- tiagotrs [~user@unaffiliated/tiagotrs] has joined #bitcoin-core-dev 01:19 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-nomcjpytojuxcprf] has joined #bitcoin-core-dev 01:19 < bitcoin-git> [bitcoin] laanwj opened pull request #15033: doc: Add historical release notes for 0.17.1 (master...2018_12_relnot_0.17.1) https://github.com/bitcoin/bitcoin/pull/15033 01:19 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-nomcjpytojuxcprf] has left #bitcoin-core-dev [] 01:22 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-rkyctgowcbchkfcx] has joined #bitcoin-core-dev 01:22 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.17: https://github.com/bitcoin/bitcoin/commit/fd616d8d08c61daf13671fbb744c74eb23980901 01:22 < bitcoin-git> bitcoin/0.17 fd616d8 Wladimir J. van der Laan: doc: Clean out release notes post-0.17.1... 01:22 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-rkyctgowcbchkfcx] has left #bitcoin-core-dev [] 01:35 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-sxxbtgemzoyfmavs] has joined #bitcoin-core-dev 01:35 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f8a3ab3b29fe...df73c23f5fac 01:35 < bitcoin-git> bitcoin/master 488563e Wladimir J. van der Laan: doc: Add historical release notes for 0.17.1 01:35 < bitcoin-git> bitcoin/master df73c23 Wladimir J. van der Laan: Merge #15033: doc: Add historical release notes for 0.17.1... 01:35 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-sxxbtgemzoyfmavs] has left #bitcoin-core-dev [] 01:36 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-yxaoiygljqckfmft] has joined #bitcoin-core-dev 01:36 < bitcoin-git> [bitcoin] laanwj closed pull request #15033: doc: Add historical release notes for 0.17.1 (master...2018_12_relnot_0.17.1) https://github.com/bitcoin/bitcoin/pull/15033 01:36 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-yxaoiygljqckfmft] has left #bitcoin-core-dev [] 01:40 < gmaxwell> \O/ Merry christmas. 01:41 < wumpus> \o/ 01:46 < meshcollider> Merry Christmas :D 01:49 < gmaxwell> https://www.reddit.com/r/Bitcoin/comments/a9dq3a/merry_christmas_bitcoin_core_0171_is_released/ 01:59 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has quit [Ping timeout: 246 seconds] 02:22 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has joined #bitcoin-core-dev 02:35 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 02:35 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 02:46 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection] 02:46 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 02:47 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev 02:55 -!- coderunner [57471db2@gateway/web/freenode/ip.87.71.29.178] has joined #bitcoin-core-dev 03:38 -!- coderunner [57471db2@gateway/web/freenode/ip.87.71.29.178] has quit [Ping timeout: 256 seconds] 04:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 04:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 04:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 05:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 06:23 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 250 seconds] 06:48 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection] 06:51 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev 07:25 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Ping timeout: 246 seconds] 07:27 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev 07:48 -!- CubicEarth [~CubicEart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 08:19 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev 08:25 -!- TheBug [5678fd16@gateway/web/freenode/ip.86.120.253.22] has joined #bitcoin-core-dev 08:25 -!- TheBug is now known as Guest14218 08:36 < Guest14218> I just want to drop two ideas here, what would make a difference in the future of bitcoin and crypto in general. 1. Solving real world problems through mining, like miners being tied to BOINC projects, so all the computing power is put to good use. 2. Wallets with AI budgeting, that takes care of your money for you, learns your expenses, auto-allocates budgets for economies, has investment schemes for low, medium and hig 08:36 < Guest14218> These 2 will give bitcoin and crypto the edge it needs over banks. 08:37 < sipa> Guest14218: try #bitcoin or bitcoin.stackexchange.com 08:37 < Guest14218> thanks 08:38 -!- Guest14218 [5678fd16@gateway/web/freenode/ip.86.120.253.22] has quit [Quit: Page closed] 08:49 -!- mistergold [~mistergol@77.243.19.162] has joined #bitcoin-core-dev 09:06 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Remote host closed the connection] 09:07 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 09:15 -!- tiagotrs [~user@unaffiliated/tiagotrs] has quit [Ping timeout: 250 seconds] 09:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 09:47 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 10:03 -!- tiagotrs [~user@unaffiliated/tiagotrs] has joined #bitcoin-core-dev 10:12 -!- cyber55 [~cyber55@unaffiliated/cyber55] has joined #bitcoin-core-dev 10:29 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 272 seconds] 10:56 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 11:05 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has quit [Quit: Laters] 11:08 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-core-dev 11:17 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has quit [Read error: Connection reset by peer] 11:17 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-dev 11:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 11:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 11:39 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 272 seconds] 11:47 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 11:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] 12:00 -!- Murch [~murch@adsl-89-217-32-254.adslplus.ch] has joined #bitcoin-core-dev 12:08 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 12:17 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Quit: Leaving] 12:36 -!- Murch [~murch@adsl-89-217-32-254.adslplus.ch] has quit [Quit: Snoozing.] 12:38 < jimmysong> question about neutrino: is there a way to get the input script pubkeys with a network message? 12:39 < jimmysong> if not, would it make sense to make those available with the block download to make sure the filter hash matches? 12:39 < jimmysong> the client can also validate the script part of every transaction input 12:40 < jimmysong> this is getting input script pubkeys for all the transactions for a given block 12:40 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev 12:47 -!- earlz is now known as huetime 12:51 -!- huetime is now known as earlz 12:51 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection] 12:59 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 13:03 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 13:15 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has joined #bitcoin-core-dev 13:23 -!- peevsie [~peevsie@2604:2000:f184:9300::4] has joined #bitcoin-core-dev 13:43 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 13:54 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection] 14:25 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has joined #bitcoin-core-dev 14:26 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [] 14:37 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 14:38 -!- peevsie [~peevsie@2604:2000:f184:9300::4] has quit [Ping timeout: 250 seconds] 14:46 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 14:58 < andytoshi> is there a url for the optech "cpfp best practices" 15:00 < achow101> andytoshi: I don't think that exists yet, but when it does, it should be here: https://github.com/bitcoinops/scaling-book/blob/master/1.fee_bumping/fee_bumping.md#child-pays-for-parent 15:17 -!- Dizzle [~Dizzle@unaffiliated/dizzle] has joined #bitcoin-core-dev 15:17 -!- jarthur [~jarthur@pool-108-4-180-254.ronkva.east.verizon.net] has joined #bitcoin-core-dev 15:22 -!- jarthur [~jarthur@pool-108-4-180-254.ronkva.east.verizon.net] has quit [Client Quit] 15:22 -!- Dizzle [~Dizzle@unaffiliated/dizzle] has quit [Quit: Leaving...] 15:27 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection] 15:28 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev 15:40 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has quit [Quit: rex4539] 15:49 < harding> jimmysong: when a node is validating a newly received block, it gets the prevout scripts (what I think you're calling input script pubkeys) from its utxo set. After the block has be verified, the now-spent UTXOs are purged from the set and the node no longer has fast access to them, so it can't provide the info you want. Furthermore, for a third party to verify that the prevout hasn't been tampered requires getting the whole 15:49 < harding> transaction that contained that prevout to check its txid against the outpoint (txid:vout). Since the max size of a tx is almost the max size of a block, that means you might need to download data equal to as many blocks as a block can have inputs (~16,000 maybe, times 4MB, or ~64GB), making this method impractical in pathological cases. 15:53 < jimmysong> i guess i have to wait for a cfilter coinbase commitment then? 15:53 < jimmysong> it would be nice to be able to verify a specific hash 15:54 < jimmysong> though now that i think about it, you're not giving away much info by requesting *every* transaction from the inputs to a block 15:54 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 15:54 -!- tiagotrs [~user@unaffiliated/tiagotrs] has quit [Ping timeout: 240 seconds] 15:55 < jimmysong> anyway, harding, there's no chance of putting that data in some sort of block store, is there? 15:58 -!- reardencode [~reardenco@shrugged.reardencode.com] has quit [Ping timeout: 244 seconds] 16:00 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 16:06 -!- reardencode [~reardenco@shrugged.reardencode.com] has joined #bitcoin-core-dev 16:08 -!- jarthur [~jarthur@pool-108-4-180-254.ronkva.east.verizon.net] has joined #bitcoin-core-dev 16:09 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 272 seconds] 16:12 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has quit [Read error: Connection reset by peer] 16:12 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-dev 16:13 < sipa> jimmysong: "block store" ? 16:18 < jimmysong> storing that data in the db for a full node so it can be given to a peer that requests it 16:18 < sipa> a bloomfilter (or gcd filter) can't store any data, it's just a probabilistic structure to let you query for set elements 16:18 < sipa> a full node has no need for that data 16:19 < jimmysong> a full node doesn't but it'd be useful for a light client wanting to verify a cfilter hash 16:19 < sipa> it is store on disk though, in the undo block data in bitcoin core, for as long as the block itself is stored 16:19 < sipa> ah, for verification it should just be committed to 16:20 < jimmysong> a coinbase commitment is better, but is that something that's got a proposal? 16:21 < sipa> it's pretty trivial to do, but mucb easier to get agreement on once bip157 itself is deployed and used 16:21 < sipa> i expect 16:21 < jimmysong> makes sense 16:22 < jimmysong> i'm asking because i'm trying to write a wallet that uses neutrino 16:22 < jimmysong> the annoying part is the verification 16:22 < jimmysong> but getting the filter, checking against my script pubkeys, etc is great 16:23 < jimmysong> much better for privacy 16:23 < sipa> the node giving you prevour scripts along with the filter doesn't let you verify anything 16:23 < sipa> they can forge anything 16:23 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has joined #bitcoin-core-dev 16:24 < jimmysong> it lets you verify that the filter bytes are what they said 16:24 < jimmysong> and you can check that the scripts for the inputs verify 16:24 < sipa> no, because the prevout scripts can be forged 16:24 < sipa> there is nothing committing to them 16:24 < jimmysong> wait, if you have a signature, you can make a pubkey that works with it? 16:25 < jimmysong> err, rather, a pubkey, you can make a hash preimage? 16:25 < jimmysong> the scriptsig/witness for p2pkh/p2wpkh is pubkey, sig 16:25 < jimmysong> so you'd have to forge a preimage of the pubkey 16:25 < sipa> oh, you mean full script validation? 16:26 < jimmysong> yes 16:26 < sipa> that shouldn't be something a light client cares about 16:26 < jimmysong> if it helps verify the cfilter hash, why not? 16:26 < jimmysong> commitment is obviously preferable 16:26 < jimmysong> but if we don't have that? 16:27 < roasbeef> jimmysong: yeh there's a half proposal on the ML to add that, the prior versions had the outpoint so they were fully verifiable, as is now you can verify half of it 16:27 < sipa> what is your attack model? 16:27 < roasbeef> differntiate honest peers from dishonest peers 16:27 < sipa> you don't want to get the prevout script for every block, right? 16:28 < roasbeef> it's not full script validation, it's verifying the filter is correct 16:28 < sipa> sure, but you'd need a full script interpreter for doing so 16:28 < roasbeef> yeh you'd fetch the block with the prior scripts and value why not while you're at it, w/ value you can verify fees to a degree as well 16:28 < roasbeef> no need to verify the script, just to verify a filter actually fully matchs a given block 16:29 < jimmysong> i was thinking full script interpreter 16:29 < jimmysong> which isn't trivial 16:29 < sipa> roasbeef: sure, that makes sense; but jimmysong was suggesring script validation, as without it, the prevout data can be trivially forged 16:29 < roasbeef> txscript.VM ;) 16:30 < sipa> jimmysong: but for which blocks would you get this prevout data? 16:30 < jimmysong> the blocks you download when you search for your utxos 16:30 < roasbeef> blocks for which you get conflicting advertisements 16:30 < jimmysong> that too 16:30 < sipa> jimmysong: a peer can still lie and give you a filter with no matches at all 16:30 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 16:31 < roasbeef> you can fetch the block and verify the outputs are properly included, but not fully inputs 16:31 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev 16:31 < sipa> yes, for confloct detection it makes sense, and you need no script validation etc 16:31 < roasbeef> main purpose if conflict detection 16:31 < roasbeef> is* 16:32 < roasbeef> harding: the prev outs are in the undo blocks 16:32 < roasbeef> this was a concern during the switch over (that it would be slower to construct our possibly impossible), but the data is still around 16:34 < jimmysong> what's the objection to writing a script interpreter? 16:34 < jimmysong> is it because of all the edge cases? 16:34 < roasbeef> many already exist 16:34 < jimmysong> i've written a partial one 16:35 < jimmysong> i still don't get op_codeseparator 16:35 < roasbeef> code sep should die, ppl should stop trying to save it lol 16:36 < jimmysong> btw, roasbeef, those test vectors for neutrino broke my script interpreter =) 16:36 < sipa> jimmysong: in my view script interpreting is so easy to get wrong, it should only be done by full nodes 16:37 < jimmysong> it is easy to get wrong, but isn't there value to at least interpreting some subset? 16:37 < jimmysong> p2wsh/p2sh stuff can get pretty complicated 16:37 < sipa> i don't think so 16:37 < sipa> a wallet can recognize its own outputs, bit that doesn't need interpretatiom 16:38 < roasbeef> you can't even verify the outputs fully exist, so script verification is w/e, main reason for getting the prevouts is filter verification and fee awareness 16:38 < sipa> for debugging purposes it can be useful of course, but imo that's it 16:39 < jimmysong> so wallets should stick to standard scripts, or whatever has been analyzed beforehand 16:39 < sipa> well they construct them themselves 16:40 < sipa> so you don't need an interpreter to find its semantics 16:40 < jimmysong> right, the ones analyzed beforehand by the programmer 16:40 < sipa> and you won't trigger any edge cases unless you go out of your way to trigger them 16:42 < jimmysong> in any case, if the outpoint data is in the undo blocks, that can be made available? 16:42 < roasbeef> yep, just add a new inv type, and message format 16:43 < jimmysong> sure, you need the full tx's to verify against the hashes, which as harding pointed out can get pathologically large in edge cases 16:44 < jimmysong> similar to jj's attack from breaking bitcoin last year 16:44 < sipa> jimmysong: needing the full txn is unrealistic 16:44 < sipa> that data isn't available in general, and expensive to index 16:44 < roasbeef> why do you care about the hashes? get the script+value, verify the sig+fee, reconstruct filter, dunzo 16:45 < roasbeef> ofc if the witness commitment was to a merkalized version of the transaction, you could fetch that proof as well, but mo bytes there, what we have available atm is good enough to achieve the goal of cross checking 16:46 < sipa> in general we should aim to only expose data that is verifiable or can be made verifiable 16:46 < sipa> and adding comitments to undo data seems overkill, when all that's needed is a commitmemt to the filters 16:46 < jimmysong> yes, that's the preferred solution 16:47 < roasbeef> yeh not undo, just filters eventually, mean as in if the wtxid was a merkle tree with leaves of the inputs/outputs etc 16:47 < roasbeef> would also let you have a more compact proof of spentnesss, especially if things are also mega super coin-joiny in the future 16:48 < jimmysong> wow, good point 16:49 < sipa> i think all these adhoc methods of verifying filters break down if you look at them in an adverserial setting... you can use heuristics and download from multiple peers, and detect conflicts, and spot check here and there... but those approaches all add complexity and bandwidth proportionl to the level of guarantee they give 16:49 < roasbeef> yep those other appraoches are just plain easier to mess up, i prefer dead simple methods 16:49 < sipa> the only foolproof, cheap, ... way is a filter comitment in blocks 16:50 < jimmysong> yep, which costs something for a miner, but not very much. but it is a soft fork 16:50 < jimmysong> any idea how that would be received? 16:51 < gmaxwell> the bigger limit there is just that there needs to be a higher level of confidence in the design, since removing the requirement is a hardfork. Fortunately, as it is now has actually had a fair level of refinement. 16:51 < roasbeef> jimmysong: filter commit in op return, message to fetch header along w/ path for coinbase transaction? i think the filter chain would prob still have some use in that case as well 16:52 < gmaxwell> I've suggested in the past potentially doing a kind of rolling softfork, where the commitment is required to be valid only if its provided and only until some height. And so long as people keep using it and it isn't replaced with something better, we just keep soft-forking in updated heights.. but if ever it gets replaced, it can just be allowed to expire. 16:52 < jimmysong> that would be a nice escape clause 16:52 < roasbeef> oooOOo, i guess the witness commitment is kinda like that for blocks w/o any witness data 16:53 < sipa> jimmysong: i think it's necessary; without commitment to the filters you can basically only use it locally or with a trusted full node 16:53 < sipa> which is pretty useful on itself, but nearly the same 16:53 < sipa> but not nearly 16:53 < gmaxwell> I'm very glad, e.g. that nothing about BIP37 ended up softforked in... that protocol turned out to be a lemon in a number of ways, but it took a couple years of use to realize that. 16:54 < roasbeef> well you can still use it in the open net, you have the same "one honest peer" assumption going on, the scripts just help you to distinguish between zero and 1 honest peer 16:55 < gmaxwell> roasbeef: even 1 honest peer requires you to have some kind of complex resolution to deal with disagreement, also-- because the p2p network is trivally sybable 'one honest peer' probably doesn't mean much unless you're doing something like manually configuring a trusted one. 16:55 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Remote host closed the connection] 16:56 < gmaxwell> One should also consider the effect of incentiving varrious kinds of trouble making. (like generally we've found that when we added vulnerablities like BIP37 attackers emerged that didn't exist previously, and then made more trouble even for people that didn't care about using BIP37) 16:57 < roasbeef> gmaxwell: you'd just fetch the blocks+scripts and reconstruct the filter, the commitment to the filters (the filter chain) helps you notice if something is funky at a glanec 16:58 < roasbeef> but then again, for smaller values you're prob not super concerned about this stuff 16:59 < gmaxwell> roasbeef: matching the spent inputs too requires fetching the inputs, which as sipa pointed out above is intractable in the worst case (and also astronishingly expensive even in the normal case) 16:59 < roasbeef> yeh the assumption is a new inv type to allow you to fetch the the input scripts, i guess i miss this worst case scenario? 16:59 < roasbeef> fetch with the block* 17:00 < gmaxwell> keeping also in mind that this stuff is saving you 30kbit/sec of bandwidth over downloading the whole blocks... in the ongoing case. 17:00 < gmaxwell> roasbeef: we have no way to provide that, and even if we did it couldn't be validated without fetching potentially gigabytes of additional data (you actually have to fetch the whole transactions). 17:03 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 17:07 < roasbeef> ahh ok yeh i was missing the outpoints in the equation 17:07 < sipa> roasbeef: what if you receive two different filters, and request block/prevout data for both, and they are both correct? (and it turns out you receiced one true prevout data and one false prevout data, but with correct filters for that data) 17:07 < roasbeef> well can still verify half of it today ;) 17:07 < gmaxwell> roasbeef: yes, half indeed. and really the more useful half. 17:07 < gmaxwell> but at the expense of fetching the whole block. 17:08 < sipa> that's still detectable, but you're rediced to a majoroty vote kind of model, and at a possibly very high bandwidh cost 17:08 < gmaxwell> which also means that it really only takes one clown with an aws instance to cause a lot of users to fetch the blocks anyways. I mean, perhaps not totally useless. But as I mentioned, vulnerablties seem to attract attackers. 17:10 < gmaxwell> so then you're left with the work of implementing the validation, testing it, dealing with vulnerablities in it... and some clown spins up a bunch of sybils and everyone is downloading the entire blocks anyways. And-- the sybils themselves act as a lasting nussance. I don't mean to argue against the non-commited usage, but considering the all in effects it's not the obvious big win that it 17:10 < gmaxwell> might seem at a glance. 17:11 < gmaxwell> and the historical rate of protocol additions introducing vulnerablties (either in implementation or design) is really high... 17:12 < roasbeef> it's a win for full nodes at least, serving the filters is much less intensive (and also stateless) compared to serving bip37, you also can't trigger worst case matching behavior over the entire chain 17:13 < gmaxwell> roasbeef: quite a few nodes just disable BIP37 completely (which seemed to stop the BIP37 based attacks) 17:14 < roasbeef> yeh i ended up doing that on my testnet nodes, seemed somsone was practicing their attacks on testnet lol 17:14 < gmaxwell> (I'm not disagreeing with your point though) 17:15 < gmaxwell> roasbeef: they were doing it on mainnet for a while. Though they seemed to give up after even a small set of their targets started disabling them. To the extent that they might have been targeting miners to cause block orphaning, that makes sense, but otherwise it's not really clear why it stopped. 17:16 < gmaxwell> Perhaps because they realized if they kept it up BIP37 was just going to end up removed and then they'd lose their toy. Who knows. 17:31 -!- jpe_ [~jpe@2001:16b8:48a0:2400:db67:25c3:eb00:7a93] has joined #bitcoin-core-dev 18:07 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 245 seconds] 18:13 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 250 seconds] 18:19 -!- jpe___ [~jpe@2001:16b8:48db:900:64ca:932b:dcc1:6374] has joined #bitcoin-core-dev 18:20 -!- jpe___ is now known as jpe 18:21 -!- jpe_ [~jpe@2001:16b8:48a0:2400:db67:25c3:eb00:7a93] has quit [Ping timeout: 268 seconds] 18:24 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 18:24 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Ping timeout: 256 seconds] 18:27 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev 18:29 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 256 seconds] 18:29 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 18:30 -!- peevsie [~peevsie@2604:2000:f184:9300::4] has joined #bitcoin-core-dev 18:34 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has joined #bitcoin-core-dev 18:54 -!- mistergold [~mistergol@77.243.19.162] has quit [Read error: Connection reset by peer] 19:24 -!- booyah [~bb@193.25.1.157] has quit [Ping timeout: 246 seconds] 19:26 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-dev 19:29 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection] 19:30 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev 20:12 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has quit [Quit: Textual IRC Client: www.textualapp.com] 20:49 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev 20:56 -!- jpe [~jpe@2001:16b8:48db:900:64ca:932b:dcc1:6374] has quit [Ping timeout: 264 seconds] 21:22 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-oniaqxuaupkjyllw] has joined #bitcoin-core-dev 21:22 < bitcoin-git> [bitcoin] markaw67 opened pull request #15036: Mwortham (master...patch-2) https://github.com/bitcoin/bitcoin/pull/15036 21:22 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-oniaqxuaupkjyllw] has left #bitcoin-core-dev [] 21:33 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 252 seconds] 21:49 -!- peevsie [~peevsie@2604:2000:f184:9300::4] has quit [Ping timeout: 252 seconds] 21:55 < fanquake> Wondering if I should even bother in #15036. The guy has turned up to the repo, spammed in one PR, then opened 15036. 21:55 < gribble> https://github.com/bitcoin/bitcoin/issues/15036 | Mwortham by markaw67 · Pull Request #15036 · bitcoin/bitcoin · GitHub 21:55 < fanquake> Clearly not bothering to read my comment, or from what I can tell, anything related to actually contributing to the project. 22:01 < gmaxwell> I'd recommend just closing and locking the PR. They aren't following the guidelines, and there is a good chance that its just trolling. 22:01 < gmaxwell> no different than any other driveby pr 22:07 -!- notmandatory [~notmandat@cpe-76-169-37-102.socal.res.rr.com] has joined #bitcoin-core-dev 22:09 < gmaxwell> and especially due to the principle that the project isn't a place that we'll tolerate other people turning into their performance art or battleground. 22:22 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 22:34 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 22:34 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ucaohwpecfucrvan] has joined #bitcoin-core-dev 22:34 < bitcoin-git> [bitcoin] fanquake closed pull request #15036: Mwortham (master...patch-2) https://github.com/bitcoin/bitcoin/pull/15036 22:34 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ucaohwpecfucrvan] has left #bitcoin-core-dev [] 22:39 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has joined #bitcoin-core-dev 22:40 -!- jarthur [~jarthur@pool-108-4-180-254.ronkva.east.verizon.net] has quit [] 22:53 < gwillen> fanquake: if you are able, it seems like preemptively locking might be a good idea. 22:55 < fanquake> I was going to leave it for a reply, but have done it now. 22:57 < gwillen> the quality of his previous comment doesn't make me sanguine 22:58 < gwillen> also, the account that hit 'approve' looks like a sockpuppet 23:47 -!- harrymm [~harrymm@69.161.195.103] has quit [Ping timeout: 244 seconds] --- Log closed Wed Dec 26 00:00:04 2018