< 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..
< 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.
< 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/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 #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.