1 2016-06-26T00:52:07  *** MarcoFalke has left #bitcoin-core-dev
  2 2016-06-26T00:52:11  *** Alopex has quit IRC
  3 2016-06-26T00:53:17  *** Alopex has joined #bitcoin-core-dev
  4 2016-06-26T01:10:04  *** Chris_Stewart_5 has quit IRC
  5 2016-06-26T01:17:15  *** cryptapus_afk is now known as cryptapus
  6 2016-06-26T01:36:21  *** Alopex has quit IRC
  7 2016-06-26T01:37:27  *** Alopex has joined #bitcoin-core-dev
  8 2016-06-26T02:09:39  *** jtimon has quit IRC
  9 2016-06-26T02:58:31  *** Giszmo has joined #bitcoin-core-dev
 10 2016-06-26T03:00:46  <luke-jr> Lightsword: care to review Eloipool's BIP 9 pR? :P
 11 2016-06-26T04:05:45  *** Ylbam has quit IRC
 12 2016-06-26T04:38:16  *** cryptapus is now known as cryptapus_afk
 13 2016-06-26T06:07:11  *** Alopex has quit IRC
 14 2016-06-26T06:08:17  *** Alopex has joined #bitcoin-core-dev
 15 2016-06-26T06:24:32  *** Alopex has quit IRC
 16 2016-06-26T06:25:37  *** Alopex has joined #bitcoin-core-dev
 17 2016-06-26T06:26:42  <GitHub103> [bitcoin] Cannon-Ciota opened pull request #8268: Updating default max block size (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8268
 18 2016-06-26T06:51:16  *** Alopex has quit IRC
 19 2016-06-26T06:52:22  *** Alopex has joined #bitcoin-core-dev
 20 2016-06-26T07:32:23  *** Giszmo has quit IRC
 21 2016-06-26T07:35:16  <GitHub2> [bitcoin] jonasschnelli closed pull request #8268: Updating default max block size (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8268
 22 2016-06-26T07:52:51  <phantomcircuit> gmaxwell, is there a reason for simple things like IsNull to be in headers? (that dont use templates of course)
 23 2016-06-26T07:53:03  <phantomcircuit> i'd like to move a bunch of those into the .cpp file to improve build performance
 24 2016-06-26T07:56:50  *** Guyver2 has joined #bitcoin-core-dev
 25 2016-06-26T08:17:06  <gmaxwell> so they get inlined.
 26 2016-06-26T08:22:41  *** mkarrer has quit IRC
 27 2016-06-26T08:39:12  *** mkarrer has joined #bitcoin-core-dev
 28 2016-06-26T08:42:59  <phantomcircuit> gmaxwell, does that actually change the result with any kind of optimization enabled
 29 2016-06-26T08:56:59  <gmaxwell> phantomcircuit: yes, ignoring lto a function must be in the same compliation unit to get inlined.
 30 2016-06-26T08:57:32  <phantomcircuit> gmaxwell, are we using lto?
 31 2016-06-26T08:58:19  <gmaxwell> No.
 32 2016-06-26T08:58:48  <gmaxwell> (should we, perhaps, but it will likely signficiantly slow down compiling and increase memory usage, opposite of the changes you're thinking of making)
 33 2016-06-26T09:18:32  *** Guyver2 has quit IRC
 34 2016-06-26T09:49:49  <phantomcircuit> gmaxwell, yeah it would improve things and then make it much much worse all at the end
 35 2016-06-26T10:50:06  *** Alopex has quit IRC
 36 2016-06-26T10:51:11  *** Alopex has joined #bitcoin-core-dev
 37 2016-06-26T10:53:59  *** jonasschnelli has quit IRC
 38 2016-06-26T10:54:00  *** jonasschnelli has joined #bitcoin-core-dev
 39 2016-06-26T11:02:19  *** spudowiar has quit IRC
 40 2016-06-26T11:12:05  *** spudowiar has joined #bitcoin-core-dev
 41 2016-06-26T11:19:27  *** belcher has joined #bitcoin-core-dev
 42 2016-06-26T11:37:46  *** jtimon has joined #bitcoin-core-dev
 43 2016-06-26T12:04:18  *** davec_ has quit IRC
 44 2016-06-26T12:05:00  *** davec_ has joined #bitcoin-core-dev
 45 2016-06-26T13:22:52  *** gribble has quit IRC
 46 2016-06-26T13:39:04  *** gribble has joined #bitcoin-core-dev
 47 2016-06-26T13:43:19  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 48 2016-06-26T13:55:52  <GitHub195> [bitcoin] ChoHag opened pull request #8270: Tests: Use portable #! in python scripts (/usr/bin/env) (master...master) https://github.com/bitcoin/bitcoin/pull/8270
 49 2016-06-26T14:33:02  *** murch has joined #bitcoin-core-dev
 50 2016-06-26T14:58:50  *** NicolasDorier has quit IRC
 51 2016-06-26T14:59:08  *** NicolasDorier has joined #bitcoin-core-dev
 52 2016-06-26T15:33:41  *** molz has joined #bitcoin-core-dev
 53 2016-06-26T15:36:58  *** moli has quit IRC
 54 2016-06-26T15:39:45  *** challisto has joined #bitcoin-core-dev
 55 2016-06-26T15:49:04  *** cocoBTC has joined #bitcoin-core-dev
 56 2016-06-26T15:51:03  *** MarcoFalke has joined #bitcoin-core-dev
 57 2016-06-26T15:54:18  *** spudowiar has quit IRC
 58 2016-06-26T15:54:57  *** spudowiar has joined #bitcoin-core-dev
 59 2016-06-26T16:13:22  *** grubles has quit IRC
 60 2016-06-26T16:41:37  *** cocoBTC has quit IRC
 61 2016-06-26T16:50:53  *** Giszmo has joined #bitcoin-core-dev
 62 2016-06-26T17:20:31  *** molz has quit IRC
 63 2016-06-26T17:30:12  *** moli has joined #bitcoin-core-dev
 64 2016-06-26T17:35:26  <arubi> I'm looking at the famous "value overflow incident" transaction, it has a byte 0xA8 where the sighash type byte is normally found and I was wondering if either 0xa8 was ever a sighash type.  also, checking the signature, it seems to behave like ALL. maybe it is that unfamiliar sighash is treated as ALL?
 65 2016-06-26T17:36:45  <arubi> s/either//
 66 2016-06-26T17:50:30  <arubi> ah. I should've tried 'signrawtransaction'.  core says "error": "Signature hash type missing or not understood".  I wonder how it got into a block at all, unless the logic was different back then!
 67 2016-06-26T17:53:32  <sipa> the signing logic not being able to deal with it doesn't mean it's invalid
 68 2016-06-26T17:53:47  <arubi> good point, so it would just default to ALL?
 69 2016-06-26T17:54:25  <arubi> or, is any type of signature be acceptable in a block?  (sorry, brainstorming..)
 70 2016-06-26T17:54:45  <sipa> yes
 71 2016-06-26T17:54:54  <sipa> unknown values are treated as ALL
 72 2016-06-26T17:55:08  <sipa> or rather, look at the low 5 bits of the sighash versions
 73 2016-06-26T17:55:23  <sipa> if those are 2, SIGHASH_NONE
 74 2016-06-26T17:55:32  <sipa> if those are 3, SIGHASH_SINGLE
 75 2016-06-26T17:55:37  <sipa> anything else, SIGHASH_ALL
 76 2016-06-26T17:56:32  <arubi> thanks a lot.  should I be looking at interpreter.h/cpp for this logic?
 77 2016-06-26T17:56:45  <sipa> yes
 78 2016-06-26T17:56:56  <arubi> cool.  in I go
 79 2016-06-26T18:20:21  <GitHub138> [bitcoin] sipa opened pull request #8271: [bugfix] Do not send witnesses in cmpctblock (master...nowitnesscb) https://github.com/bitcoin/bitcoin/pull/8271
 80 2016-06-26T18:33:30  *** MarcoFalke has left #bitcoin-core-dev
 81 2016-06-26T18:33:31  <GitHub195> [bitcoin] sipa opened pull request #8272: Make the dummy argument to getaddednodeinfo optional (master...optionaladdnodedummy) https://github.com/bitcoin/bitcoin/pull/8272
 82 2016-06-26T18:40:47  *** Ylbam has joined #bitcoin-core-dev
 83 2016-06-26T19:41:52  *** Giszmo has quit IRC
 84 2016-06-26T19:55:48  *** Guyver2 has joined #bitcoin-core-dev
 85 2016-06-26T20:01:44  *** adiabat has joined #bitcoin-core-dev
 86 2016-06-26T20:02:39  <adiabat> howdy, trying to sync testnet3 with the latest master (1922e5)
 87 2016-06-26T20:02:55  <adiabat> getting Aborted (core dumped)
 88 2016-06-26T20:03:03  <adiabat> bitcoind: chain.cpp:96: CBlockIndex* CBlockIndex::GetAncestor(int): Assertion `pindexWalk->pprev' failed.
 89 2016-06-26T20:03:57  <adiabat> in debug.log, this happens right after Opened LevelDB successfully, then Using obfuscation key for chainstate
 90 2016-06-26T20:04:36  <sipa> can you run in gdb and get a backtrace?
 91 2016-06-26T20:05:13  <adiabat> possibly... this may be just out of memory?  I'm running it on a 1GB vps
 92 2016-06-26T20:05:32  <adiabat> is that the kind of error I'd get for running out of ram?
 93 2016-06-26T20:07:15  <sipa> i think you'd see a bad_alloc exception in that case
 94 2016-06-26T20:07:20  <adiabat> hm, think the db is corrupt though, so either way
 95 2016-06-26T20:07:28  <sipa> i don't expect such memory usage right at startup either
 96 2016-06-26T20:07:34  <adiabat> last line before the crash the first time was
 97 2016-06-26T20:07:38  <adiabat> 2016-06-26 19:55:36 Pre-allocating up to position 0x500000 in rev00013.dat
 98 2016-06-26T20:07:38  <adiabat> 2016-06-26 19:57:31
 99 2016-06-26T20:08:48  <adiabat> so there was a log line written with nothing in it, then the crash
100 2016-06-26T20:11:27  <adiabat> got an error in gdb:
101 2016-06-26T20:11:39  <adiabat> Thread 1 "bitcoind" received signal SIGABRT, Aborted.
102 2016-06-26T20:11:43  <adiabat> 0x00007ffff5640418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
103 2016-06-26T20:11:43  <adiabat> 54	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
104 2016-06-26T20:13:51  <sipa> can you pastebin the stacktrace?
105 2016-06-26T20:13:58  <sipa> (type 'bt' in gdb)
106 2016-06-26T20:14:15  *** dingus has joined #bitcoin-core-dev
107 2016-06-26T20:14:18  <adiabat> ok
108 2016-06-26T20:14:43  <adiabat> hm pastebin says no, it's not too long, just message you?
109 2016-06-26T20:17:03  <adiabat> got it
110 2016-06-26T20:17:04  <adiabat> http://pastebin.com/hV73dPW0
111 2016-06-26T20:20:01  <sipa> that's interesting...
112 2016-06-26T20:22:08  <adiabat> this is at height 447195 of segnet3, though I don't think that's related to what caused this...
113 2016-06-26T20:23:09  <adiabat> 447196 is pretty big but there's lots around that size I got through
114 2016-06-26T20:28:39  <btcdrak> you mean testnet3 i assume
115 2016-06-26T20:29:40  <adiabat> err yeah heh
116 2016-06-26T20:29:43  <adiabat> testnet3
117 2016-06-26T20:37:33  *** Chris_Stewart_5 has quit IRC
118 2016-06-26T20:52:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
119 2016-06-26T20:59:53  *** moli has quit IRC
120 2016-06-26T21:03:57  *** Chris_Stewart_5 has quit IRC
121 2016-06-26T21:05:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
122 2016-06-26T21:14:13  <gmaxwell> So, if the minimum difficulty were softfork increased to, say 2^24 (about 24 5TH/s miners), with an explicit exception for the existing blocks on the well known chain that are below that... would that eliminate the remaining unsolved reason for retaining the checkpoint code?  (assuming it's also doing the signature skipping based on headers)
123 2016-06-26T21:24:11  *** dingus has quit IRC
124 2016-06-26T21:29:45  <gmaxwell> e.g. the exception would work like, diff_bits < 24, store the 24-diff_bits least significant of the block hash... so then any replacement would need to do 2^56 work (24+32) per block to make a replacement of any of those blocks... which I think should make header flooding attacks sufficiently unattractive.
125 2016-06-26T21:31:44  *** dingus has joined #bitcoin-core-dev
126 2016-06-26T21:35:16  *** moli has joined #bitcoin-core-dev
127 2016-06-26T21:35:34  <sipa> by store you mean hardcode?
128 2016-06-26T21:37:49  <gmaxwell> Yes. Effectively this would boost all blocks in the chain to at least 2^56 work to produce an alternative, without specifically hardcoding any blocks.
129 2016-06-26T21:38:27  <sipa> i don't understand how you get to 56
130 2016-06-26T21:39:14  <gmaxwell> diff 1 is effectively 2^32 work. So diff 2^24 is 2^56 work.
131 2016-06-26T21:39:29  <sipa> oh, duh
132 2016-06-26T21:40:15  <gmaxwell> Boosting all blocks to at least 2^56 replacement work, given their actual difficulties would require 489132 bytes of data.
133 2016-06-26T21:40:37  <gmaxwell> assuming the information were bitpacked.
134 2016-06-26T21:41:25  <gmaxwell> (more than I expected before I went and measured it)
135 2016-06-26T21:41:41  <sipa> an alternative is just hardcoding the hash of the first block past 2^24 difficulty, and not downloading any blocks until a header chain past that one was built
136 2016-06-26T21:42:00  <gmaxwell> that leaves open the attack where I give you infinity alternatives for block 1.
137 2016-06-26T21:42:08  <gmaxwell> and exaust your resources with headers alone.
138 2016-06-26T21:43:28  <gmaxwell> in theory a single 5TH/s miner can make 1164 diff1 headers per second. (in practice they can't because their whole control infrastructure is not setup for solutions that fast, but I wouldn't be surprised if the asics could, given alternative control)
139 2016-06-26T21:46:30  <gmaxwell> also, if the going forward minimum is not increased, someone could start at the 2^24 point, then do 2^57 work to make a chain moving the difficulty back to 1, then continue the headerflooding attack at diff 1.
140 2016-06-26T21:52:10  <gmaxwell> actually that rampdown would be 2^67.39 work, (I forgot to account for the fact that difficulty is held constant for 2016 blocks).
141 2016-06-26T21:52:21  <gmaxwell> assuming mining hardware were actually efficient at low difficulty header creation the cost of that rampdown in lost subsidy income vs mining at current difficulty would be 5.3827 BTC.
142 2016-06-26T21:53:34  <gmaxwell> Cost of a rampdown from diff 2**32 would be 1377.977 BTC.
143 2016-06-26T21:55:34  <gmaxwell> pinning up to diff 2^32 would be 292320 blocks, about 1.11MB data if pinned with 32bits/block.
144 2016-06-26T21:55:53  <GitHub76> [bitcoin] MarcoFalke closed pull request #8265: src: Fix spelling error in comment - netbase.h (master...bitcoiner-fix-typo-netbase) https://github.com/bitcoin/bitcoin/pull/8265
145 2016-06-26T22:00:38  *** justanotheruser has quit IRC
146 2016-06-26T22:01:48  <gmaxwell> alternatively, including the first 292320 headers would add about 23MB to the package, but would actually save 23MB of data transfered from the network at start.
147 2016-06-26T22:02:33  <gmaxwell> 14MB if it was 'compressed' by exploiting the prevhash.
148 2016-06-26T22:02:33  *** justanotheruser has joined #bitcoin-core-dev
149 2016-06-26T22:47:55  <luke-jr> when does cfields get back, and when he does, can we set <someone else> up wiht access to the dev webserver so it's not entirely dependent on him? :x
150 2016-06-26T22:56:50  <sipa> i believe he'll return next week
151 2016-06-26T22:56:53  <sipa> and yes
152 2016-06-26T23:10:27  *** dingus is now known as grubles
153 2016-06-26T23:19:39  <Lightsword> is there a debug flag needed to see what IP address a block is downloaded from?
154 2016-06-26T23:19:55  <Lightsword> I’m using logips=1 already
155 2016-06-26T23:20:17  <sipa> debug=net will should you which messages are sent to which peers
156 2016-06-26T23:20:42  <sipa> (by node id, but you can match up node ids with ip address using -logips, or getpeerinfo)
157 2016-06-26T23:21:15  *** hsmiths has quit IRC
158 2016-06-26T23:23:00  *** hsmiths has joined #bitcoin-core-dev
159 2016-06-26T23:23:42  <Lightsword> kk, no way to have it print IP’s directly? that would make grepping a lot easier :P
160 2016-06-26T23:24:02  <sipa> nope
161 2016-06-26T23:59:52  *** Chris_Stewart_5 has quit IRC