1 2017-09-18 03:25:36	0|esotericnonsense|wow, syncing on the same host is quick. 25% progress in 24 minutes.
  2 2017-09-18 03:25:44	0|esotericnonsense|(unpruned)
  3 2017-09-18 03:35:36	0|sipa|it won't due to signature validation
  4 2017-09-18 03:35:57	0|sipa|which is only done after the assumevalid points
  5 2017-09-18 03:36:04	0|esotericnonsense|ah bugger yes.
  6 2017-09-18 09:40:04	0|bitcoin-git|13bitcoin/06master 14a0b4c24 15Dan Raviv: Trivial: Fix validation comments...
  7 2017-09-18 09:40:04	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e278f86c5369...d6d2c8503c40
  8 2017-09-18 09:40:05	0|bitcoin-git|13bitcoin/06master 14d6d2c85 15MarcoFalke: Merge #11340: Trivial: Fix validation comments...
  9 2017-09-18 09:40:46	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11340: Trivial: Fix validation comments (06master...06patch-12) 02https://github.com/bitcoin/bitcoin/pull/11340
 10 2017-09-18 10:29:14	0|promag|is github user danra around?
 11 2017-09-18 11:52:01	0|meshcollider|promag: don't think so, never seen them in here
 12 2017-09-18 12:19:51	0|promag|ok
 13 2017-09-18 12:19:52	0|promag|ty
 14 2017-09-18 13:26:08	0|BlueMatt_|jonasschnelli: you got a poly hash patch lying around somewhere I can just steal?
 15 2017-09-18 13:27:10	0|BlueMatt|hmm, guess not :/
 16 2017-09-18 14:06:12	0|bitcoin-git|13bitcoin/06master 14e9e9391 15John Newbery: [tests] Check connectivity before sending in assumevalid.py...
 17 2017-09-18 14:06:12	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d6d2c8503c40...44e1fd926cfb
 18 2017-09-18 14:06:13	0|bitcoin-git|13bitcoin/06master 1444e1fd9 15MarcoFalke: Merge #11345: [tests] Check connectivity before sending in assumevalid.py...
 19 2017-09-18 14:06:56	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11345: [tests] Check connectivity before sending in assumevalid.py (06master...06assume_valid_improvement) 02https://github.com/bitcoin/bitcoin/pull/11345
 20 2017-09-18 14:09:03	0|achow101|do we have 0.15.0.1 detached signatures yet?>
 21 2017-09-18 14:22:36	0|jonasschnelli|BlueMatt: poly hash patch?
 22 2017-09-18 14:23:00	0|jonasschnelli|You mean ChaCha20Poly1305? https://github.com/jonasschnelli/chacha20poly1305
 23 2017-09-18 14:29:18	0|BlueMatt|jonasschnelli: yea, essentially that, msotly I was lazy and didnt want to figure out what the reasonable implementation to take was :p
 24 2017-09-18 14:29:30	0|BlueMatt|(well, meant integrated in bitcoind, but thats fine too)
 25 2017-09-18 14:29:57	0|jonasschnelli|BlueMatt: that above is ripped out form openssl (and made it independent from anything else)
 26 2017-09-18 14:30:02	0|jonasschnelli|openssh! sry
 27 2017-09-18 14:40:22	0|BlueMatt|ah, cool
 28 2017-09-18 14:40:32	0|BlueMatt|looks like its just the dona one
 29 2017-09-18 14:40:38	0|BlueMatt|donna
 30 2017-09-18 16:33:48	0|RealM9|Bitcoin is again under a spam attack
 31 2017-09-18 16:33:51	0|RealM9|https://imgur.com/a/Jxfvy
 32 2017-09-18 16:34:47	0|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
 33 2017-09-18 16:37:56	0|RealM9|14 MB mempool data of 100-140sat/byte TXes
 34 2017-09-18 16:39:46	0|andytoshi|miners can't spam any more cheaply than anybody else. 14 Mb at 100sat/byte is like $50000
 35 2017-09-18 16:39:52	0|lvmbdv|oh god forbid something takes up 15 MB of my RAM :o
 36 2017-09-18 16:40:16	0|lvmbdv|and proof-of-work assumes the expenses of spamming the network would drive bad guys away
 37 2017-09-18 16:40:30	0|RealM9|Well remember that mining is centralized and miners get fees
 38 2017-09-18 16:41:04	0|RealM9|And some big block conference is happening soon
 39 2017-09-18 16:41:35	0|andytoshi|#bitcoin please
 40 2017-09-18 16:42:04	0|RealM9|Maybe core should create some anti-spam mechanisms on 0.15.1
 41 2017-09-18 16:42:45	0|Chicago|... until when?  Until Micro-Bitcoins are a common denomination?
 42 2017-09-18 16:42:55	0|RealM9|Because, you know that S2X fork is coming and if miners will spam, they will do it NOW. Before S2X
 43 2017-09-18 16:42:56	0|gmaxwell|this is stupid. I haven't seen any evidence of spam, just people aggregating txs at very low feerates.
 44 2017-09-18 16:43:31	0|RealM9|Isn't this evidence https://i.imgur.com/oCANzXW.png ?
 45 2017-09-18 16:43:43	0|andytoshi|RealM9: i am answering you in #bitcoin
 46 2017-09-18 16:45:30	0|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.
 47 2017-09-18 16:47:09	0|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
 48 2017-09-18 16:48:16	0|RealM9|Yeah, but there aren't really much to do about it without risking to delete legitimate TXes from mempool
 49 2017-09-18 16:48:23	0|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
 50 2017-09-18 16:49:09	0|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.
 51 2017-09-18 16:50:16	0|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.
 52 2017-09-18 16:54:05	0|RealM9|Hm, ok
 53 2017-09-18 17:09:33	0|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.
 54 2017-09-18 17:09:35	0|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
 55 2017-09-18 17:09:36	0|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
 56 2017-09-18 17:57:44	0|instagibbs|jimpo, please don't close them, they both have at least one utACK
 57 2017-09-18 17:57:56	0|instagibbs|0.15 release means it's a better time to bug people likely
 58 2017-09-18 18:01:01	0|sheldonthomas|here is it’s 100% reproducible, happens every time. Crashed Thread:        0  Dispatch queue: com.apple.main-thread
 59 2017-09-18 18:01:01	0|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
 60 2017-09-18 18:01:03	0|sheldonthomas|Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
 61 2017-09-18 18:01:04	0|sheldonthomas|Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000008
 62 2017-09-18 18:01:06	0|sheldonthomas|Exception Note:        EXC_CORPSE_NOTIFY
 63 2017-09-18 18:01:07	0|sheldonthomas|Termination Signal:    Segmentation fault: 11
 64 2017-09-18 18:01:08	0|sheldonthomas|Termination Reason:    Namespace SIGNAL, Code 0xb
 65 2017-09-18 18:01:09	0|sheldonthomas|Terminating Process:   exc handler [0]
 66 2017-09-18 18:02:10	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.
 67 2017-09-18 18:02:52	0|sipa|sheldonthomas: please open an issue on https://github.com/bitcoin/bitcoin/issues
 68 2017-09-18 18:04:01	0|sheldonthomas|Okay. It’s not possible to run 0.14.2 after you’ve done the UTXO set db upgrade, correct?
 69 2017-09-18 18:04:17	0|sipa|indeed
 70 2017-09-18 18:05:10	0|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.
 71 2017-09-18 18:05:49	0|sipa|you're always able to reindex (start with -reindex-chainstate flag)
 72 2017-09-18 18:05:58	0|sipa|but maybe you want to help debug the issue
 73 2017-09-18 18:06:14	0|sipa|oh
 74 2017-09-18 18:06:18	0|achow101|sipa: sheldonthomas it's probably related to #11171
 75 2017-09-18 18:06:20	0|sipa|try updating to 0.15.0.1
 76 2017-09-18 18:06:21	0|gribble|https://github.com/bitcoin/bitcoin/issues/11171 | RC2 Exits After Initialization · Issue #11171 · bitcoin/bitcoin · GitHub
 77 2017-09-18 18:06:40	0|sipa|there is a known issue that can cause a crash
 78 2017-09-18 18:06:43	0|achow101|sheldonthomas: please pastebin the contents of ~/Library/Preferences/org.bitcoin.Bitcoin-Qt.plist
 79 2017-09-18 18:06:50	0|achow101|sheldonthomas: then start Bitcoin Core with -resetguisettings
 80 2017-09-18 18:06:58	0|achow101|but I need to see the contents of that file first
 81 2017-09-18 18:07:27	0|achow101|sipa: 0.15.0.1 is not released yet (no codesigned gitian builds yet, not posted to bitcoin.org)
 82 2017-09-18 18:07:37	0|sipa|achow101: thanks, i've been out of the loop
 83 2017-09-18 18:09:40	0|sheldonthomas|my editor shows that plist with some garbled binary, shall I pastebin that as utf8 out?
 84 2017-09-18 18:09:49	0|achow101|yes
 85 2017-09-18 18:11:00	0|sheldonthomas|https://pastebin.com/jHYvg2NE
 86 2017-09-18 18:12:10	0|sheldonthomas|I’m running it via a command in my path like: open /Applications/bitcoin15/Bitcoin-Qt.app/ --args -datadir=‘…’
 87 2017-09-18 18:13:28	0|achow101|wow, that's a weird looking file
 88 2017-09-18 18:13:55	0|achow101|I thought plist files were xml like
 89 2017-09-18 18:14:19	0|sheldonthomas|I can run it through a util. One moment
 90 2017-09-18 18:14:21	0|sipa|sheldonthomas: can you paste a hexdump instead?
 91 2017-09-18 18:15:16	0|sheldonthomas|sipa: https://pastebin.com/N3FjsnWE
 92 2017-09-18 18:16:40	0|sheldonthomas|There’s nothing out of the ordinary in debug.log
 93 2017-09-18 18:17:34	0|achow101|sheldonthomas: the hexdump should be enough to decipher this I think.
 94 2017-09-18 18:17:43	0|achow101|start Bitcoin Core with the -resetguisettings option
 95 2017-09-18 18:17:55	0|sheldonthomas|okay i was about to try the other one, the reindex one too
 96 2017-09-18 18:17:56	0|achow101|backup the plist file first to some other place first
 97 2017-09-18 18:18:01	0|sheldonthomas|should i do both, or the other...
 98 2017-09-18 18:18:05	0|sheldonthomas|Ok I’ll back that up
 99 2017-09-18 18:18:16	0|achow101|-resetguisettings is all you need to do. I believe this problem is #11171
100 2017-09-18 18:18:17	0|gribble|https://github.com/bitcoin/bitcoin/issues/11171 | RC2 Exits After Initialization · Issue #11171 · bitcoin/bitcoin · GitHub
101 2017-09-18 18:20:00	0|sheldonthomas|Just noticed I have another plist called  org.bitcoinfoundation.Bitcoin-Qt.plist should I remove that?
102 2017-09-18 18:20:02	0|arubi|it's kinda cool how it goes through all control characters from a->z
103 2017-09-18 18:20:56	0|achow101|sheldonthomas: can you pastebin that too?
104 2017-09-18 18:21:02	0|achow101|and back it up
105 2017-09-18 18:28:02	0|sheldonthomas|achow: here is that dump https://pastebin.com/n2JSmSbp
106 2017-09-18 18:28:40	0|sheldonthomas|Am going to add resetguisettings to my bitcoin.conf will that suffice?
107 2017-09-18 18:29:27	0|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
108 2017-09-18 18:30:52	0|sheldonthomas|I guess it needs resetguisettings=1 ?
109 2017-09-18 18:31:06	0|sipa|yes
110 2017-09-18 18:31:29	0|sheldonthomas|seems to have fixed it.
111 2017-09-18 18:31:33	0|sheldonthomas|bitcoin core cruising again.
112 2017-09-18 18:31:47	0|sheldonthomas|much thanks
113 2017-09-18 19:13:58	0|bitcoin-git|13bitcoin/06master 141817398 15Cory Fields: mininode: add an optimistic write and disable nagle...
114 2017-09-18 19:13:58	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/44e1fd926cfb...4ce2f3d0d333
115 2017-09-18 19:13:59	0|bitcoin-git|13bitcoin/06master 144ce2f3d 15MarcoFalke: Merge #11323: mininode: add an optimistic write and disable nagle...
116 2017-09-18 19:14:32	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11323: mininode: add an optimistic write and disable nagle (06master...06optimistic-mininode) 02https://github.com/bitcoin/bitcoin/pull/11323
117 2017-09-18 21:13:12	0|promag|jnewbery: any reason to jump to -32 in https://github.com/bitcoin/bitcoin/pull/11031/files#diff-7563bce5f7cf8ee3e5568afc8578e9e7R60?
118 2017-09-18 21:24:13	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11361: Remove redundant LOCK(…) and AssertLockHeld(…) (06master...06remove-redundant-locks) 02https://github.com/bitcoin/bitcoin/pull/11361
119 2017-09-18 21:48:43	0|jnewbery|promag: -29, -30 and -31 are already taken (look in the 'P2P client errors' section below)
120 2017-09-18 21:49:29	0|promag|doh
121 2017-09-18 21:51:41	0|promag|btw, just a little nit :P commit message should be sentence case?
122 2017-09-18 21:54:48	0|jnewbery|Thanks! Fixed
123 2017-09-18 22:03:55	0|jonasschnelli|cfields_: can you have a final look at https://github.com/bitcoin/bitcoin/pull/11113?
124 2017-09-18 22:04:08	0|jonasschnelli|Has some acks, ... but misses yours?
125 2017-09-18 22:17:17	0|promag|jonasschnelli: btw https://github.com/bitcoin/bitcoin/pull/11281#pullrequestreview-63497928
126 2017-09-18 22:18:00	0|promag|jnewbery: wdyt https://github.com/bitcoin/bitcoin/pull/10552#issuecomment-330271664 ?
127 2017-09-18 22:58:41	0|goatpig|are there still milestones hardcoded in for boostrapping the chainstate db?
128 2017-09-18 23:00:37	0|luke-jr|checkpoints? yes
129 2017-09-18 23:00:50	0|luke-jr|although in Core, they haven't been updated in a long time (intentionally)
130 2017-09-18 23:03:38	0|gmaxwell|"for boostrapping the chainstate db?" for that, no there has never been anything like that.
131 2017-09-18 23:05:40	0|goatpig|i mean the set of milestones to check hashes instead of signatures for early chain data
132 2017-09-18 23:05:47	0|goatpig|luke-jr: why have they not been updated?
133 2017-09-18 23:07:28	0|sipa|goatpig: we want to get rid of checkpoints
134 2017-09-18 23:07:53	0|sipa|their functionality has been replaced by headers-first sync & assumevalid
135 2017-09-18 23:08:21	0|sipa|(almost, but not entirely - they still protect against a weak memory exhaustion attack, but old checkpoints suffice for that)
136 2017-09-18 23:08:46	0|goatpig|ah so the feature has been replaced
137 2017-09-18 23:08:57	0|sipa|assumevalid is maybe what you're after - it's a configurable block hash we know has valid signatures in its history
138 2017-09-18 23:09:07	0|goatpig|yeah that';s what im after
139 2017-09-18 23:09:09	0|sipa|but it doesn't force the client to only accept that chain (as checkpoints did)
140 2017-09-18 23:09:24	0|sipa|they just bypass validation IF that chain we to otherwise be validated
141 2017-09-18 23:09:35	0|goatpig|but there is a default hardcoded value in the code that's being updated now?
142 2017-09-18 23:09:56	0|sipa|that's correct
143 2017-09-18 23:10:03	0|goatpig|ok that's what i wanted to know
144 2017-09-18 23:10:04	0|goatpig|thanks
145 2017-09-18 23:11:01	0|sipa|https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L107
146 2017-09-18 23:11:27	0|goatpig|that's the current one in 0.15 right?
147 2017-09-18 23:11:35	0|sipa|yes
148 2017-09-18 23:11:40	0|goatpig|thanks a lot
149 2017-09-18 23:13:12	0|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.
150 2017-09-18 23:14:12	0|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?
151 2017-09-18 23:14:19	0|sipa|yes
152 2017-09-18 23:14:26	0|goatpig|sure, makes sense
153 2017-09-18 23:17:04	0|promag|in that case doesn't make sense to assume valid from the fork backwards?
154 2017-09-18 23:18:16	0|goatpig|im guessing it does assumevalid up until the branch point, then drops the behavior as soon as it forks
155 2017-09-18 23:18:27	0|sipa|promag: assumevalid=X means that script validation is skipped for any block that is an ancestor of X
156 2017-09-18 23:18:37	0|sipa|so i think it does what you're saying
157 2017-09-18 23:18:51	0|gmaxwell|sipa: no, not if the assumevalid block is not in the best chain.
158 2017-09-18 23:19:05	0|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. :)
159 2017-09-18 23:19:49	0|gmaxwell|but yes, I believe that what you suggest would be fine (other than the unnecessary complexity)
160 2017-09-18 23:20:10	0|goatpig|gmaxwell: then what's the decision in case of a fork? don't forward the assumevalid hash past that fork point for ages?
161 2017-09-18 23:20:49	0|sipa|goatpig: i'm confused
162 2017-09-18 23:21:30	0|goatpig|gmax saying assumevalid does not afford you bypassing sig checks if the assumed valid hash is on the shortest branch of a fork
163 2017-09-18 23:21:38	0|gmaxwell|goatpig: if its ambiguous what chain is correct for ages we have bigger problems.
164 2017-09-18 23:22:12	0|achow101|goatpig: if the assumevalid block is not in your best chain, then you will be validating all signatures
165 2017-09-18 23:22:17	0|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.
166 2017-09-18 23:22:24	0|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)
167 2017-09-18 23:22:33	0|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
168 2017-09-18 23:22:35	0|gmaxwell|if it were to fall out, oh well, sync would take somewhat longer. Not the end of the world.
169 2017-09-18 23:22:59	0|goatpig|ok
170 2017-09-18 23:23:03	0|goatpig|just curious about the whole mechanic
171 2017-09-18 23:23:56	0|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.
172 2017-09-18 23:24:24	0|goatpig|i get it
173 2017-09-18 23:26:11	0|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
174 2017-09-18 23:26:21	0|gmaxwell|wampy: thanks!
175 2017-09-18 23:27:03	0|promag|> other than the unnecessary complexity gmaxwell: right, edge case.. better validate all :P
176 2017-09-18 23:35:46	0|midnightmagic|lol https://pbs.twimg.com/media/DJw1oWRW4AEnICf.jpg
177 2017-09-18 23:42:57	0|bitcoin-git|[13bitcoin] 15gmaxwell opened pull request #11362: Remove nBlockMaxSize from miner opt struct as it is no longer used. (06master...062017_09_rm_nBlockMaxSize) 02https://github.com/bitcoin/bitcoin/pull/11362