< gmaxwell> oh theo, trolling about the openssl license thing by targing unrelated parties: http://marc.info/?l=openbsd-tech&m=149032069130072&w=2
< luke-jr> crap, sizefp is broken
< luke-jr> hm, or is it
< luke-jr> actually, I think it might be okay. it's possible to produce a fraud proof that lies about the tx count, but you'd never be able to make one that proves it's bigger than it really is I think
< da2ce7> luke-jr: what is the cost of just relaying the full oversized block. Or at least the first 1mb of the block? Most SPV wallets have enough bandwidth for 1mb
< luke-jr> da2ce7: up to 4 MB with segwit
< da2ce7> that doesn't sound unreasonable for my phone either.
< da2ce7> Is SVP fraud proof spam/dos a concern?
< gmaxwell> da2ce7: yes, because if you don't like your fraud being proven first you claim fraud falsely on every block to every client... all the time and they waste bandwidth.
< gmaxwell> and the users get pissed and change software or turn off the feature.
< gmaxwell> though you're right to say that 1mb isn't that burdensom... kinda sad that all these wallets totally screw user privacy to save a bandwidth amount the user probably doesn't care about.
< da2ce7> Banning the Peer that gives a false proof isn't sufficient? I suppose not, because the new peer that you could connect to could give a false fraud proof again.
< gmaxwell> well once you're convinced a given block was okay, you never need to fetch it.
< gmaxwell> er again.
< gmaxwell> but it can just happen for the next block.
< gmaxwell> luke-jr: a radically different approach would be able to have miners mergemine a message [Block 0x00023023423 is oversized.]... then you have some minimum difficulty for such messages such that dos is ineffectual.
< gmaxwell> and when you get one of those messages, you just go download the whole block to check for yourself.
< da2ce7> cool
< gmaxwell> hm. well I suppose the attacker can cheaply produce false proofs for all the good blocks, scratch that idea.
< da2ce7> Banning the offending peer isn't enough? A bad peer can only send 1 bad fraud proof... You would cycle through to 8 good peers quite quickly.
< da2ce7> You can also have a rate-limit, where if you get a new peer, you won't accept a fraud proof until they have been well behaved for a certain time, (such 1/2 * time connected to longest peer).
< da2ce7> This will severely rate-limit bad fraud proofs.
< luke-jr> da2ce7: these nodes don't even accept incoming connections, so..
< bitcoin-git> [bitcoin] luke-jr opened pull request #10074: Block size/weight fraud proofs (master...sizefp) https://github.com/bitcoin/bitcoin/pull/10074
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a0b1e57b20a1...530fcbd49be2
< bitcoin-git> bitcoin/master cc995e2 flack: add missing spaces so that markdown recognizes headline
< bitcoin-git> bitcoin/master 530fcbd Wladimir J. van der Laan: Merge #10063: add missing spaces so that markdown recognizes headline...
< bitcoin-git> [bitcoin] laanwj closed pull request #10063: add missing spaces so that markdown recognizes headline (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10063
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/530fcbd49be2...5d7eb39aecda
< bitcoin-git> bitcoin/master c59aedc Thomas Snider: [trivial] Dead code removal
< bitcoin-git> bitcoin/master 5d7eb39 Wladimir J. van der Laan: Merge #10067: [trivial] Dead code removal...
< bitcoin-git> [bitcoin] laanwj closed pull request #10067: [trivial] Dead code removal (master...tjps_dead_code) https://github.com/bitcoin/bitcoin/pull/10067
< luke-jr> wumpus: blkindex.dat was the UTXO BDB database IIRC
< sipa> it was everything
< sipa> it has the byte position of every transactions
< sipa> and the byte position of the transaction that spent each input
< wumpus> ok
< sipa> 12 bytes for every output ever :)
< sipa> bla bla scability
< sipa> *scalability
< wumpus> yes you did so much incredible work on that sipa :)
< wumpus> Huh! https://github.com/bitcoin/bitcoin/issues/8218 "this issue was closed" by whom? github admin?
< luke-jr>  ghost closed this on Jun 18, 2016
< wumpus> oh. I was looking at the notifications and saw "this issue was closed" at the end, assuming that was the recent activity
< gmaxwell> 'ghost' ?!
< wumpus> if it was closed in 2016 already, okay, I still don't realy understand why but that makes sense
< wumpus> ghost is github's "removed user" account
< gmaxwell> oh the opened user.
< wumpus> jonasschnelli's post there still makes a lot of sense, we need a standard for these things
< wumpus> anyhow, sorry for the false alarm, github confused me
< da2ce7> Hello. #bitcoin-core-dev, I've made a patch for BIP 148, unfortunately I'm not a developer so building it a secure manner is a bit over my head. If anyone can fire-up their gitian, and help me verify the build it would be a great help for me.
< da2ce7> (based upon bitcoin knots).
< wumpus> one gitian builder doesn't really accomplish much, the strength in that process is to make multiple people build something and compare. Or have you gitian-built it and want to compare hashes?
< da2ce7> I've only built bitcoin privately, I haven't used gitian before. I don't want to release my private binaries.
< wumpus> you shouldn't feel okay distributing someone else's gitian-built binaries either
< wumpus> unless it's multiple independent people I guess
< luke-jr> I wouldn't mind providing one of multiple builds (not as an endorsement).
< wumpus> yes I wouldn't mind building either, but am a bit wary of subverting trust in gitian :) for the releasses we usually wait for 5 signers at least before distributing executables
< luke-jr> wumpus: sadly, Knots only usually has 2 signers to work with; maybe we can improve on this in general
< wumpus> luke-jr: yes, I don't mind building/signing that
< da2ce7> once I have the expected hashes, then I'll ask around for many people to build and verify it.
< luke-jr> wumpus: latest tag is v0.14.0.knots20170307 and the bitcoin-knots github has a sigs repo
< wumpus> as you say it's not an endorsement (though I have nothing against knots either) and improves general bitcoin security so anyhow
< sipa> why do we need gitian builds for a single patch?
< luke-jr> sipa: I guess people want to upgrade to it sooner rather than later; da2ce7 isn't the first wanting such binaries
< da2ce7> I want to release binaries that include this patch. Gitian (with many people verifying) is the only way I know that I would feel confident in doing so.
< * luke-jr> wonders where to put unofficial gitian sigs
< wumpus> no idea, though having an official 'unofficial gitian sigs' repository would be kind of strange :)
< da2ce7> luke-jr you can just pm me. I will collect them and publish them once I have enough. Be clear to include "unoffical" or something in the sig.
< * luke-jr> wonders how to indicate anything in gitian sigs :P
< da2ce7> maybe possible to append something to the end of the binary hash?
< wumpus> the assert file is YAML, I think you can add additial fields that will be ignored by the tooling
< luke-jr> ideally GPG would print a message upon verification
< wumpus> I doubt it's possible to add custom messages there
< wumpus> (as mimicing GPG output there could fool scripts, or even people expecting a certain output)
< luke-jr> true
< bambum> any agreement / concensus between core / miners / bu regarding onchain blocksize foreseeable or do we have to wait for 1. bu hard fork or/and 2. uasf or/and 3. pow change ? I am long term holder but considering to sell now :(
< wumpus> bambum: that's not a bitcoin-core-dev topic, #bitcoin please
< bambum> well #bitcoin is just speculation and fud, I would be happy to see some core opinion
< luke-jr> bambum: you can get that in #bitcoin too
< sipa> core is a software project; we don't decide what people should run
< sipa> please keep politics out of here
< wumpus> amen
< bambum> well you naturally dont need to answer this question. I just hoped to get some prospectics. I think its really important for bitcoin holder to know about it and i am sure you have your own view and don´t only focus on tecnical
< sipa> i have my own view, but it is completely off topic here
< sipa> please understand that the politics in this space severely affect people's lives here
< wumpus> right, everyone has their own view, but discussing those views is of topic here for the exact reason of preventing this from becoming a "speculation and fud" channel. We had that problem with bitcoin-dev and that's why this channel was created
< bambum> ok I got it, but you should also know that it also affects my life. I have almost my entire savings into bitcoin, its not so easy for me to get allthat money into my bank account.
< luke-jr> bambum: again, please take it to #bitcoin ; many of us are there as well and would answer you if you ask there
< bambum> ok
< bitcoin-git> [bitcoin] practicalswift opened pull request #10075: Remove unused C++ code not covered by unit tests (master...unused) https://github.com/bitcoin/bitcoin/pull/10075
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5d7eb39aecda...90dd9e6c4c0c
< bitcoin-git> bitcoin/master b1f584d Matthew Zipkin: fix build if spaces in src dir path
< bitcoin-git> bitcoin/master 90dd9e6 Wladimir J. van der Laan: Merge #9946: Fix build errors if spaces in path or parent directory...
< bitcoin-git> [bitcoin] laanwj closed pull request #9946: Fix build errors if spaces in path or parent directory (master...dirspaces2) https://github.com/bitcoin/bitcoin/pull/9946
< guyonabike> https://github.com/bitcoin/bitcoin/pull/10074 <- are the names for the p2p messages accurate? I was thinking that maybe "fraud/getfraud" may be a good name to be used for other fraud proofs for spv, like tx inclusion/exclusion
< luke-jr> guyonabike: yes, it's extensible
< luke-jr> guyonabike: see the FP type
< guyonabike> as far as i understood from the code, the fraud, but I'm not sure about getfraud, perhaps add something analogous to invtype in getinv?
< guyonabike> luke-jr: sorry if I'm not making much sense, I'm relatively new in this
< luke-jr> did you read BIP 180? that might help ;)
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #10076: [qa] combine_logs: Use ordered list for logfiles (master...Mf1703-orderedLog) https://github.com/bitcoin/bitcoin/pull/10076
< guyonabike> luke-jr: thanks. i was thinking on fraud proofs for mempool txs received by spv clients, where I could ask a random node for validation, but now I think that might be dangerous and probably more aligned to be a rpc call
< guyonabike> luke-jr: thanks for writing this bip, its great work
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #10077: [qa] Add setnetworkactive smoke test (master...Mf1703-toggleNet) https://github.com/bitcoin/bitcoin/pull/10077
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/90dd9e6c4c0c...111849345bb5
< bitcoin-git> bitcoin/master 803e6a3 Nicolas Dorier: [QA] Fix typo in fundrawtransaction test...
< bitcoin-git> bitcoin/master 1118493 MarcoFalke: Merge #10069: [QA] Fix typo in fundrawtransaction test...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10069: [QA] Fix typo in fundrawtransaction test (master...patch-3) https://github.com/bitcoin/bitcoin/pull/10069
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #10078: [qa] Fundraw: Use named args to limit scope of names (master...Mf1703-qaNamedShadow) https://github.com/bitcoin/bitcoin/pull/10078
< RealM9> So, when will you sign BIP148 binaries?
< gmaxwell> In case "RealM9" comes back, I don't think anyone who regularly works on Bitcoin Core has even looked much at BIP148 yet.
< gmaxwell> We're certantly not going to ship a consensus change proposal that is only a couple weeks old.