< RealM9>
I know nobody here thinks about a way how to solve this, but i think it's a huge problem. Miners can spam network for free, if they work togather. Think about this. And antpool mines another VIP block
< RealM9>
14 MB mempool data of 100-140sat/byte TXes
< andytoshi>
miners can't spam any more cheaply than anybody else. 14 Mb at 100sat/byte is like $50000
< lvmbdv>
oh god forbid something takes up 15 MB of my RAM :o
< lvmbdv>
and proof-of-work assumes the expenses of spamming the network would drive bad guys away
< RealM9>
Well remember that mining is centralized and miners get fees
< RealM9>
And some big block conference is happening soon
< andytoshi>
#bitcoin please
< RealM9>
Maybe core should create some anti-spam mechanisms on 0.15.1
< Chicago>
... until when? Until Micro-Bitcoins are a common denomination?
< RealM9>
Because, you know that S2X fork is coming and if miners will spam, they will do it NOW. Before S2X
< gmaxwell>
this is stupid. I haven't seen any evidence of spam, just people aggregating txs at very low feerates.
< andytoshi>
RealM9: i am answering you in #bitcoin
< gmaxwell>
The only 'fix' to spam needed would be a magic want to stop people from putting up graphing sites that panic people about things the system already handled.
< RealM9>
What if they started spamming for let's say, 2 weeks. Their big-block agenda would get only more popular and S2X would be a solution
< RealM9>
Yeah, but there aren't really much to do about it without risking to delete legitimate TXes from mempool
< gmaxwell>
RealM9: What if? who cares. You just pay a slightly higher feerate than them and they stop existing as far as you're concerned.
< gmaxwell>
For every transaction paying feerate X they display by one block they have to pay x over again in fees. Even if it's a miner doing it the result is astronmically expensive.
< RealM9>
Hm, ok
< jimpo>
I have two PRs that have been lingering for a while, #11113 and #11116. Can I get another look from reviewers/maintainers? Otherwise I'll just close them.
< instagibbs>
jimpo, please don't close them, they both have at least one utACK
< instagibbs>
0.15 release means it's a better time to bug people likely
< sheldonthomas>
Hi - please correct me if this isn’t the place but I’m experiencing a 100% reproducible crash on 0.15 on Mac OS X using the offical bitcoincore binaries (I verified their sha sums). Is this known/discussed or have their been similar reports or am I alone in experiencing this? My debug.log gets passed 2017-09-18 17:47:45 GUI: Platform customization: "macosx" and then I see a few UpdateTip messages go by and I have a system exception. Key
< sheldonthomas>
here is it’s 100% reproducible, happens every time. Crashed Thread: 0 Dispatch queue: com.apple.main-thread
< sheldonthomas>
Okay. It’s not possible to run 0.14.2 after you’ve done the UTXO set db upgrade, correct?
< sipa>
indeed
< sheldonthomas>
ok, will open an issue. this effectively locks users out of their wallets since the program won’t run and the prior version cannot be run.
< sipa>
you're always able to reindex (start with -reindex-chainstate flag)
< sipa>
but maybe you want to help debug the issue
< sipa>
oh
< achow101>
sipa: sheldonthomas it's probably related to #11171
< sheldonthomas>
Am going to add resetguisettings to my bitcoin.conf will that suffice?
< achow101>
sheldonthomas: that will work. don't forget to remove that after you start Bitcoin Core otherwise you will be resetting those settings on every start
< sheldonthomas>
I guess it needs resetguisettings=1 ?
< gmaxwell>
goatpig: these thigns do not fix a particular chain, and only have an effect if they're in our best chain and burried by a couple weeks work.
< goatpig>
you mean if you are exposed to a chain that branches before the assume valid hash and that it's longer than the assumed one, it would check all sigs in that branch regardless?
< sipa>
yes
< goatpig>
sure, makes sense
< promag>
in that case doesn't make sense to assume valid from the fork backwards?
< goatpig>
im guessing it does assumevalid up until the branch point, then drops the behavior as soon as it forks
< sipa>
promag: assumevalid=X means that script validation is skipped for any block that is an ancestor of X
< sipa>
so i think it does what you're saying
< gmaxwell>
sipa: no, not if the assumevalid block is not in the best chain.
< gmaxwell>
promag: potentially but thats a dumb situation: Don't set the value on a fork and then there is no need for code to handle that case, nor need for tests to test it. :)
< gmaxwell>
but yes, I believe that what you suggest would be fine (other than the unnecessary complexity)
< goatpig>
gmaxwell: then what's the decision in case of a fork? don't forward the assumevalid hash past that fork point for ages?
< sipa>
goatpig: i'm confused
< goatpig>
gmax saying assumevalid does not afford you bypassing sig checks if the assumed valid hash is on the shortest branch of a fork
< gmaxwell>
goatpig: if its ambiguous what chain is correct for ages we have bigger problems.
< achow101>
goatpig: if the assumevalid block is not in your best chain, then you will be validating all signatures
< gmaxwell>
what I've been doing on updating them is setting it to a most recent block when I open the PR, and just checking that it's still in the chain by the time the PR is ready to be merged.
< goatpig>
therefor, how do you handle forks with that updating that hardcoded hash in the case there is a potential for the fork to sustain 2 semi equivalent branches (in term of work)
< achow101>
if the best chain changed to not include the assumevalid hash, then all blocks you have already been verified won't be re-verified
< gmaxwell>
if it were to fall out, oh well, sync would take somewhat longer. Not the end of the world.
< goatpig>
ok
< goatpig>
just curious about the whole mechanic
< gmaxwell>
goatpig: if something like that went on for weeks it would be doubtful if bitcoin would continue to exist at the end of such an event, regardless tweaking forward assumevalid wouldn't be a high priority. ... losing it entirely isn't that big of a deal.
< goatpig>
i get it
< wampy>
hello! v0.15.0.1 fixes the segfault I was getting upgrading from 0.14.2. Thanks to all who helped track that down
< gmaxwell>
wampy: thanks!
< promag>
> other than the unnecessary complexity gmaxwell: right, edge case.. better validate all :P
< bitcoin-git>
[bitcoin] gmaxwell opened pull request #11362: Remove nBlockMaxSize from miner opt struct as it is no longer used. (master...2017_09_rm_nBlockMaxSize) https://github.com/bitcoin/bitcoin/pull/11362