12016-06-26T00:52:07  *** MarcoFalke has left #bitcoin-core-dev
  22016-06-26T00:52:11  *** Alopex has quit IRC
  32016-06-26T00:53:17  *** Alopex has joined #bitcoin-core-dev
  42016-06-26T01:10:04  *** Chris_Stewart_5 has quit IRC
  52016-06-26T01:17:15  *** cryptapus_afk is now known as cryptapus
  62016-06-26T01:36:21  *** Alopex has quit IRC
  72016-06-26T01:37:27  *** Alopex has joined #bitcoin-core-dev
  82016-06-26T02:09:39  *** jtimon has quit IRC
  92016-06-26T02:58:31  *** Giszmo has joined #bitcoin-core-dev
 102016-06-26T03:00:46  <luke-jr> Lightsword: care to review Eloipool's BIP 9 pR? :P
 112016-06-26T04:05:45  *** Ylbam has quit IRC
 122016-06-26T04:38:16  *** cryptapus is now known as cryptapus_afk
 132016-06-26T06:07:11  *** Alopex has quit IRC
 142016-06-26T06:08:17  *** Alopex has joined #bitcoin-core-dev
 152016-06-26T06:24:32  *** Alopex has quit IRC
 162016-06-26T06:25:37  *** Alopex has joined #bitcoin-core-dev
 172016-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
 182016-06-26T06:51:16  *** Alopex has quit IRC
 192016-06-26T06:52:22  *** Alopex has joined #bitcoin-core-dev
 202016-06-26T07:32:23  *** Giszmo has quit IRC
 212016-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
 222016-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)
 232016-06-26T07:53:03  <phantomcircuit> i'd like to move a bunch of those into the .cpp file to improve build performance
 242016-06-26T07:56:50  *** Guyver2 has joined #bitcoin-core-dev
 252016-06-26T08:17:06  <gmaxwell> so they get inlined.
 262016-06-26T08:22:41  *** mkarrer has quit IRC
 272016-06-26T08:39:12  *** mkarrer has joined #bitcoin-core-dev
 282016-06-26T08:42:59  <phantomcircuit> gmaxwell, does that actually change the result with any kind of optimization enabled
 292016-06-26T08:56:59  <gmaxwell> phantomcircuit: yes, ignoring lto a function must be in the same compliation unit to get inlined.
 302016-06-26T08:57:32  <phantomcircuit> gmaxwell, are we using lto?
 312016-06-26T08:58:19  <gmaxwell> No.
 322016-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)
 332016-06-26T09:18:32  *** Guyver2 has quit IRC
 342016-06-26T09:49:49  <phantomcircuit> gmaxwell, yeah it would improve things and then make it much much worse all at the end
 352016-06-26T10:50:06  *** Alopex has quit IRC
 362016-06-26T10:51:11  *** Alopex has joined #bitcoin-core-dev
 372016-06-26T10:53:59  *** jonasschnelli has quit IRC
 382016-06-26T10:54:00  *** jonasschnelli has joined #bitcoin-core-dev
 392016-06-26T11:02:19  *** spudowiar has quit IRC
 402016-06-26T11:12:05  *** spudowiar has joined #bitcoin-core-dev
 412016-06-26T11:19:27  *** belcher has joined #bitcoin-core-dev
 422016-06-26T11:37:46  *** jtimon has joined #bitcoin-core-dev
 432016-06-26T12:04:18  *** davec_ has quit IRC
 442016-06-26T12:05:00  *** davec_ has joined #bitcoin-core-dev
 452016-06-26T13:22:52  *** gribble has quit IRC
 462016-06-26T13:39:04  *** gribble has joined #bitcoin-core-dev
 472016-06-26T13:43:19  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 482016-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
 492016-06-26T14:33:02  *** murch has joined #bitcoin-core-dev
 502016-06-26T14:58:50  *** NicolasDorier has quit IRC
 512016-06-26T14:59:08  *** NicolasDorier has joined #bitcoin-core-dev
 522016-06-26T15:33:41  *** molz has joined #bitcoin-core-dev
 532016-06-26T15:36:58  *** moli has quit IRC
 542016-06-26T15:39:45  *** challisto has joined #bitcoin-core-dev
 552016-06-26T15:49:04  *** cocoBTC has joined #bitcoin-core-dev
 562016-06-26T15:51:03  *** MarcoFalke has joined #bitcoin-core-dev
 572016-06-26T15:54:18  *** spudowiar has quit IRC
 582016-06-26T15:54:57  *** spudowiar has joined #bitcoin-core-dev
 592016-06-26T16:13:22  *** grubles has quit IRC
 602016-06-26T16:41:37  *** cocoBTC has quit IRC
 612016-06-26T16:50:53  *** Giszmo has joined #bitcoin-core-dev
 622016-06-26T17:20:31  *** molz has quit IRC
 632016-06-26T17:30:12  *** moli has joined #bitcoin-core-dev
 642016-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?
 652016-06-26T17:36:45  <arubi> s/either//
 662016-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!
 672016-06-26T17:53:32  <sipa> the signing logic not being able to deal with it doesn't mean it's invalid
 682016-06-26T17:53:47  <arubi> good point, so it would just default to ALL?
 692016-06-26T17:54:25  <arubi> or, is any type of signature be acceptable in a block?  (sorry, brainstorming..)
 702016-06-26T17:54:45  <sipa> yes
 712016-06-26T17:54:54  <sipa> unknown values are treated as ALL
 722016-06-26T17:55:08  <sipa> or rather, look at the low 5 bits of the sighash versions
 732016-06-26T17:55:23  <sipa> if those are 2, SIGHASH_NONE
 742016-06-26T17:55:32  <sipa> if those are 3, SIGHASH_SINGLE
 752016-06-26T17:55:37  <sipa> anything else, SIGHASH_ALL
 762016-06-26T17:56:32  <arubi> thanks a lot.  should I be looking at interpreter.h/cpp for this logic?
 772016-06-26T17:56:45  <sipa> yes
 782016-06-26T17:56:56  <arubi> cool.  in I go
 792016-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
 802016-06-26T18:33:30  *** MarcoFalke has left #bitcoin-core-dev
 812016-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
 822016-06-26T18:40:47  *** Ylbam has joined #bitcoin-core-dev
 832016-06-26T19:41:52  *** Giszmo has quit IRC
 842016-06-26T19:55:48  *** Guyver2 has joined #bitcoin-core-dev
 852016-06-26T20:01:44  *** adiabat has joined #bitcoin-core-dev
 862016-06-26T20:02:39  <adiabat> howdy, trying to sync testnet3 with the latest master (1922e5)
 872016-06-26T20:02:55  <adiabat> getting Aborted (core dumped)
 882016-06-26T20:03:03  <adiabat> bitcoind: chain.cpp:96: CBlockIndex* CBlockIndex::GetAncestor(int): Assertion `pindexWalk->pprev' failed.
 892016-06-26T20:03:57  <adiabat> in debug.log, this happens right after Opened LevelDB successfully, then Using obfuscation key for chainstate
 902016-06-26T20:04:36  <sipa> can you run in gdb and get a backtrace?
 912016-06-26T20:05:13  <adiabat> possibly... this may be just out of memory?  I'm running it on a 1GB vps
 922016-06-26T20:05:32  <adiabat> is that the kind of error I'd get for running out of ram?
 932016-06-26T20:07:15  <sipa> i think you'd see a bad_alloc exception in that case
 942016-06-26T20:07:20  <adiabat> hm, think the db is corrupt though, so either way
 952016-06-26T20:07:28  <sipa> i don't expect such memory usage right at startup either
 962016-06-26T20:07:34  <adiabat> last line before the crash the first time was
 972016-06-26T20:07:38  <adiabat> 2016-06-26 19:55:36 Pre-allocating up to position 0x500000 in rev00013.dat
 982016-06-26T20:07:38  <adiabat> 2016-06-26 19:57:31
 992016-06-26T20:08:48  <adiabat> so there was a log line written with nothing in it, then the crash
1002016-06-26T20:11:27  <adiabat> got an error in gdb:
1012016-06-26T20:11:39  <adiabat> Thread 1 "bitcoind" received signal SIGABRT, Aborted.
1022016-06-26T20:11:43  <adiabat> 0x00007ffff5640418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
1032016-06-26T20:11:43  <adiabat> 54	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
1042016-06-26T20:13:51  <sipa> can you pastebin the stacktrace?
1052016-06-26T20:13:58  <sipa> (type 'bt' in gdb)
1062016-06-26T20:14:15  *** dingus has joined #bitcoin-core-dev
1072016-06-26T20:14:18  <adiabat> ok
1082016-06-26T20:14:43  <adiabat> hm pastebin says no, it's not too long, just message you?
1092016-06-26T20:17:03  <adiabat> got it
1102016-06-26T20:17:04  <adiabat> http://pastebin.com/hV73dPW0
1112016-06-26T20:20:01  <sipa> that's interesting...
1122016-06-26T20:22:08  <adiabat> this is at height 447195 of segnet3, though I don't think that's related to what caused this...
1132016-06-26T20:23:09  <adiabat> 447196 is pretty big but there's lots around that size I got through
1142016-06-26T20:28:39  <btcdrak> you mean testnet3 i assume
1152016-06-26T20:29:40  <adiabat> err yeah heh
1162016-06-26T20:29:43  <adiabat> testnet3
1172016-06-26T20:37:33  *** Chris_Stewart_5 has quit IRC
1182016-06-26T20:52:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1192016-06-26T20:59:53  *** moli has quit IRC
1202016-06-26T21:03:57  *** Chris_Stewart_5 has quit IRC
1212016-06-26T21:05:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1222016-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)
1232016-06-26T21:24:11  *** dingus has quit IRC
1242016-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.
1252016-06-26T21:31:44  *** dingus has joined #bitcoin-core-dev
1262016-06-26T21:35:16  *** moli has joined #bitcoin-core-dev
1272016-06-26T21:35:34  <sipa> by store you mean hardcode?
1282016-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.
1292016-06-26T21:38:27  <sipa> i don't understand how you get to 56
1302016-06-26T21:39:14  <gmaxwell> diff 1 is effectively 2^32 work. So diff 2^24 is 2^56 work.
1312016-06-26T21:39:29  <sipa> oh, duh
1322016-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.
1332016-06-26T21:40:37  <gmaxwell> assuming the information were bitpacked.
1342016-06-26T21:41:25  <gmaxwell> (more than I expected before I went and measured it)
1352016-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
1362016-06-26T21:42:00  <gmaxwell> that leaves open the attack where I give you infinity alternatives for block 1.
1372016-06-26T21:42:08  <gmaxwell> and exaust your resources with headers alone.
1382016-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)
1392016-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.
1402016-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).
1412016-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.
1422016-06-26T21:53:34  <gmaxwell> Cost of a rampdown from diff 2**32 would be 1377.977 BTC.
1432016-06-26T21:55:34  <gmaxwell> pinning up to diff 2^32 would be 292320 blocks, about 1.11MB data if pinned with 32bits/block.
1442016-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
1452016-06-26T22:00:38  *** justanotheruser has quit IRC
1462016-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.
1472016-06-26T22:02:33  <gmaxwell> 14MB if it was 'compressed' by exploiting the prevhash.
1482016-06-26T22:02:33  *** justanotheruser has joined #bitcoin-core-dev
1492016-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
1502016-06-26T22:56:50  <sipa> i believe he'll return next week
1512016-06-26T22:56:53  <sipa> and yes
1522016-06-26T23:10:27  *** dingus is now known as grubles
1532016-06-26T23:19:39  <Lightsword> is there a debug flag needed to see what IP address a block is downloaded from?
1542016-06-26T23:19:55  <Lightsword> I’m using logips=1 already
1552016-06-26T23:20:17  <sipa> debug=net will should you which messages are sent to which peers
1562016-06-26T23:20:42  <sipa> (by node id, but you can match up node ids with ip address using -logips, or getpeerinfo)
1572016-06-26T23:21:15  *** hsmiths has quit IRC
1582016-06-26T23:23:00  *** hsmiths has joined #bitcoin-core-dev
1592016-06-26T23:23:42  <Lightsword> kk, no way to have it print IP’s directly? that would make grepping a lot easier :P
1602016-06-26T23:24:02  <sipa> nope
1612016-06-26T23:59:52  *** Chris_Stewart_5 has quit IRC