< esotericnonsense> wow, syncing on the same host is quick. 25% progress in 24 minutes.
< esotericnonsense> (unpruned)
< * esotericnonsense> wonders if the whole thing would be sub-100.
< sipa> it won't due to signature validation
< sipa> which is only done after the assumevalid points
< esotericnonsense> ah bugger yes.
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e278f86c5369...d6d2c8503c40
< bitcoin-git> bitcoin/master a0b4c24 Dan Raviv: Trivial: Fix validation comments...
< bitcoin-git> bitcoin/master d6d2c85 MarcoFalke: Merge #11340: Trivial: Fix validation comments...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11340: Trivial: Fix validation comments (master...patch-12) https://github.com/bitcoin/bitcoin/pull/11340
< promag> is github user danra around?
< meshcollider> promag: don't think so, never seen them in here
< promag> ok
< promag> ty
< BlueMatt_> jonasschnelli: you got a poly hash patch lying around somewhere I can just steal?
< BlueMatt> hmm, guess not :/
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d6d2c8503c40...44e1fd926cfb
< bitcoin-git> bitcoin/master e9e9391 John Newbery: [tests] Check connectivity before sending in assumevalid.py...
< bitcoin-git> bitcoin/master 44e1fd9 MarcoFalke: Merge #11345: [tests] Check connectivity before sending in assumevalid.py...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11345: [tests] Check connectivity before sending in assumevalid.py (master...assume_valid_improvement) https://github.com/bitcoin/bitcoin/pull/11345
< achow101> do we have detached signatures yet?>
< jonasschnelli> BlueMatt: poly hash patch?
< jonasschnelli> You mean ChaCha20Poly1305? https://github.com/jonasschnelli/chacha20poly1305
< BlueMatt> jonasschnelli: yea, essentially that, msotly I was lazy and didnt want to figure out what the reasonable implementation to take was :p
< BlueMatt> (well, meant integrated in bitcoind, but thats fine too)
< jonasschnelli> BlueMatt: that above is ripped out form openssl (and made it independent from anything else)
< jonasschnelli> openssh! sry
< BlueMatt> ah, cool
< BlueMatt> looks like its just the dona one
< BlueMatt> donna
< RealM9> Bitcoin is again under a spam attack
< 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.
< RealM9> Isn't this evidence https://i.imgur.com/oCANzXW.png ?
< 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> I looked last night when people first started squaking about that and it appeared to be due to txs like https://blockchain.info/tx/87cd70a1859f1029d7619ca6b745232e34b8627fc7ac1e2e50a4b2705c6aba48 which are just plain aggregation tx
< 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.
< gribble> https://github.com/bitcoin/bitcoin/issues/11113 | [net] Ignore getheaders requests for very old side blocks. by jimpo · Pull Request #11113 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/11116 | [script] Unit tests for script/standard and IsMine functions. by jimpo · Pull Request #11116 · bitcoin/bitcoin · GitHub
< 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> Exception Type: EXC_BAD_ACCESS (SIGSEGV)
< sheldonthomas> Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000008
< sheldonthomas> Exception Note: EXC_CORPSE_NOTIFY
< sheldonthomas> Termination Signal: Segmentation fault: 11
< sheldonthomas> Termination Reason: Namespace SIGNAL, Code 0xb
< sheldonthomas> Terminating Process: exc handler [0]
< sheldonthomas> Note that the first time I ran 0.15 the UTXO set upgrade completed just fine. A moment later it crashed and now crashes every time.
< sipa> sheldonthomas: please open an issue on https://github.com/bitcoin/bitcoin/issues
< 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
< sipa> try updating to
< gribble> https://github.com/bitcoin/bitcoin/issues/11171 | RC2 Exits After Initialization · Issue #11171 · bitcoin/bitcoin · GitHub
< sipa> there is a known issue that can cause a crash
< achow101> sheldonthomas: please pastebin the contents of ~/Library/Preferences/org.bitcoin.Bitcoin-Qt.plist
< achow101> sheldonthomas: then start Bitcoin Core with -resetguisettings
< achow101> but I need to see the contents of that file first
< achow101> sipa: is not released yet (no codesigned gitian builds yet, not posted to bitcoin.org)
< sipa> achow101: thanks, i've been out of the loop
< sheldonthomas> my editor shows that plist with some garbled binary, shall I pastebin that as utf8 out?
< achow101> yes
< sheldonthomas> I’m running it via a command in my path like: open /Applications/bitcoin15/Bitcoin-Qt.app/ --args -datadir=‘…’
< achow101> wow, that's a weird looking file
< achow101> I thought plist files were xml like
< sheldonthomas> I can run it through a util. One moment
< sipa> sheldonthomas: can you paste a hexdump instead?
< sheldonthomas> sipa: https://pastebin.com/N3FjsnWE
< sheldonthomas> There’s nothing out of the ordinary in debug.log
< achow101> sheldonthomas: the hexdump should be enough to decipher this I think.
< achow101> start Bitcoin Core with the -resetguisettings option
< sheldonthomas> okay i was about to try the other one, the reindex one too
< achow101> backup the plist file first to some other place first
< sheldonthomas> should i do both, or the other...
< sheldonthomas> Ok I’ll back that up
< achow101> -resetguisettings is all you need to do. I believe this problem is #11171
< gribble> https://github.com/bitcoin/bitcoin/issues/11171 | RC2 Exits After Initialization · Issue #11171 · bitcoin/bitcoin · GitHub
< sheldonthomas> Just noticed I have another plist called org.bitcoinfoundation.Bitcoin-Qt.plist should I remove that?
< arubi> it's kinda cool how it goes through all control characters from a->z
< achow101> sheldonthomas: can you pastebin that too?
< achow101> and back it up
< sheldonthomas> achow: here is that dump https://pastebin.com/n2JSmSbp
< 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 ?
< sipa> yes
< sheldonthomas> seems to have fixed it.
< sheldonthomas> bitcoin core cruising again.
< sheldonthomas> much thanks
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/44e1fd926cfb...4ce2f3d0d333
< bitcoin-git> bitcoin/master 1817398 Cory Fields: mininode: add an optimistic write and disable nagle...
< bitcoin-git> bitcoin/master 4ce2f3d MarcoFalke: Merge #11323: mininode: add an optimistic write and disable nagle...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11323: mininode: add an optimistic write and disable nagle (master...optimistic-mininode) https://github.com/bitcoin/bitcoin/pull/11323
< bitcoin-git> [bitcoin] practicalswift opened pull request #11361: Remove redundant LOCK(…) and AssertLockHeld(…) (master...remove-redundant-locks) https://github.com/bitcoin/bitcoin/pull/11361
< jnewbery> promag: -29, -30 and -31 are already taken (look in the 'P2P client errors' section below)
< promag> doh
< promag> btw, just a little nit :P commit message should be sentence case?
< jnewbery> Thanks! Fixed
< jonasschnelli> cfields_: can you have a final look at https://github.com/bitcoin/bitcoin/pull/11113?
< jonasschnelli> Has some acks, ... but misses yours?
< goatpig> are there still milestones hardcoded in for boostrapping the chainstate db?
< luke-jr> checkpoints? yes
< luke-jr> although in Core, they haven't been updated in a long time (intentionally)
< gmaxwell> "for boostrapping the chainstate db?" for that, no there has never been anything like that.
< goatpig> i mean the set of milestones to check hashes instead of signatures for early chain data
< goatpig> luke-jr: why have they not been updated?
< sipa> goatpig: we want to get rid of checkpoints
< sipa> their functionality has been replaced by headers-first sync & assumevalid
< sipa> (almost, but not entirely - they still protect against a weak memory exhaustion attack, but old checkpoints suffice for that)
< goatpig> ah so the feature has been replaced
< sipa> assumevalid is maybe what you're after - it's a configurable block hash we know has valid signatures in its history
< goatpig> yeah that';s what im after
< sipa> but it doesn't force the client to only accept that chain (as checkpoints did)
< sipa> they just bypass validation IF that chain we to otherwise be validated
< goatpig> but there is a default hardcoded value in the code that's being updated now?
< sipa> that's correct
< goatpig> ok that's what i wanted to know
< goatpig> thanks
< goatpig> that's the current one in 0.15 right?
< sipa> yes
< goatpig> thanks a lot
< 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