--- Day changed Sat Oct 03 2015 00:06 -!- bitdevsnyc [bitdevsnyc@gateway/vpn/mullvad/x-ulegvlrolsrjkfmw] has quit [Remote host closed the connection] 00:35 -!- wladimir [~wladimir@dhcp-089-098-228-253.chello.nl] has joined #bitcoin-core-dev 00:44 -!- alpalp [6836eb1c@gateway/web/cgi-irc/kiwiirc.com/ip.104.54.235.28] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 01:03 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 01:13 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 01:17 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev 01:22 -!- wladimir [~wladimir@dhcp-089-098-228-253.chello.nl] has quit [Quit: /humanexit] 01:48 -!- n0n0__ [~n0n0@x4d0665f2.dyn.telefonica.de] has joined #bitcoin-core-dev 01:53 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 260 seconds] 02:45 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: Leaving] 03:18 < petertodd> btcdrak: I'll open a pull-req for FSS-RBF soon, now that the mempool is settling down a bit 03:28 < petertodd> dgenr8: the attack spree after f2pool turned full-rbf on happened *after* they turned full-rbf *off* 03:37 < CodeShark> petertodd: I'm a good ways along in implementing versionbits 03:38 < CodeShark> I hope to have a PR ready next week 03:39 < CodeShark> and we can merge all this and still continue to use IsSuperMajority for the time being 03:43 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-core-dev 03:52 < petertodd> CodeShark: cool! 03:52 < petertodd> CodeShark: yeah, deploying versionbits in parallel to IsSuperMajority() is fine 03:56 < sipa> CodeShark: i've been busy, but i'll review your code soon 03:58 < CodeShark> thanks, sipa 04:43 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 04:44 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 244 seconds] 05:06 < btcdrak> where did --with-gui=no go as a ./configure option? 05:06 < btcdrak> has it been renamed? 05:08 < sipa> --without-X is an alias for --with-X=no 05:08 < btcdrak> ty 05:09 < btcdrak> --with-gui=no now returns an error 05:14 -!- GAit [~GAit@2-228-102-100.ip191.fastwebnet.it] has joined #bitcoin-core-dev 05:15 < sipa> oh? 05:15 < sipa> really? 05:15 < btcdrak> yeah, said unrecognised option, --without-gui worked 05:17 < btcdrak> sipa: interesting, --with-gui works, but not --with-gui=no 05:18 < sipa> works for me 05:18 < sipa> maybe it depends on what version of autoconf you use? 05:19 < btcdrak> 2.69 05:23 < CodeShark> http://manpages.ubuntu.com/manpages/saucy/man3/endian.3.html 05:23 < CodeShark> err, wrong window :p 05:28 -!- belcher_ [~user@unaffiliated/belcher] has joined #bitcoin-core-dev 05:34 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [] 05:48 < btcdrak> has something else changed recently in the build requirements? I've been struggling to build master on a fresh Ubuntu instance https://www.irccloud.com/pastebin/35OCOFYh/ - doesnt make sense. 05:48 -!- CodeShark [~androirc@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev 05:51 < wumpus> btcdrak: something is very wrong with your autoconf/configure run, looks like presence of byte-swap primitives is misdetected 05:54 < wumpus> --without-gui works fine here 05:55 < wumpus> what version of ubuntu is that? are you sure it's a fresh checkout, or an old polluted tree? 05:56 < btcdrak> wumpus: yeah it was an old tree, git clean -dfx solved it. 05:59 < wumpus> ok 05:59 < GitHub18> [bitcoin] petertodd opened pull request #6751: Document pull-req #6424 in release-notes (master...pull-req-6424-release-notes) https://github.com/bitcoin/bitcoin/pull/6751 06:00 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.] 06:20 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 255 seconds] 06:23 < wumpus> cfields, jonasschnelli: looks like we collected some warning cruft in the build system, probably introduced by the unicode subtree change: make[2]: Circular univalue/lib/libunivalue.la <- univalue/lib/libunivalue.la dependency dropped. 06:23 -!- jl2012 [~jl2012@unaffiliated/jl2012] has quit [Quit: Leaving] 06:39 -!- alpalp [6836eb1c@gateway/web/cgi-irc/kiwiirc.com/ip.104.54.235.28] has joined #bitcoin-core-dev 07:18 -!- JoeLiu [uid88238@gateway/web/irccloud.com/x-cfzcbastkrwmggov] has joined #bitcoin-core-dev 07:47 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 08:07 < GitHub103> [bitcoin] ptschip opened pull request #6752: Changed rpc-tests.sh to rpc-tests.py in README.md (master...readme) https://github.com/bitcoin/bitcoin/pull/6752 08:09 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 08:09 < wumpus> AddLocal(addr) automatically sets SetReachable(addr.net). Although I understand why, I don't think this is always correct, for example listening on an ONION address (-externalip=XXX.onion, or through #6639) doesn't mean we can do outgoing connections to them 08:13 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 08:19 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 08:40 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 08:45 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds] 09:10 -!- n0n0_ [~n0n0@x4d066f08.dyn.telefonica.de] has joined #bitcoin-core-dev 09:14 -!- n0n0__ [~n0n0@x4d0665f2.dyn.telefonica.de] has quit [Ping timeout: 264 seconds] 09:29 -!- JoeLiu [uid88238@gateway/web/irccloud.com/x-cfzcbastkrwmggov] has quit [Quit: Connection closed for inactivity] 10:53 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 11:01 -!- bitdevsnyc [~bitdevsny@cpe-74-68-119-97.nyc.res.rr.com] has joined #bitcoin-core-dev 11:08 -!- bitdevsnyc [~bitdevsny@cpe-74-68-119-97.nyc.res.rr.com] has quit [Ping timeout: 240 seconds] 11:09 < jonasschnelli> wumpus: yes. I also saw the "circular reference" warning. Will have a look at it soon. 11:29 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has left #bitcoin-core-dev [] 11:30 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 11:32 -!- ParadoxSpiral [~ParadoxSp@p508B9429.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 11:35 -!- ParadoxSpiral_ [~ParadoxSp@p508B990D.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 11:44 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 272 seconds] 13:09 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 13:09 -!- n0n0_ [~n0n0@x4d066f08.dyn.telefonica.de] has quit [Ping timeout: 250 seconds] 13:25 -!- ParadoxSpiral [~ParadoxSp@p508B9429.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 13:30 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 14:44 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds] 14:47 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 14:51 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 15:06 -!- ProfMac [~ProfMac@2001:470:b8ac:0:5cc1:a999:7262:4dfc] has quit [Ping timeout: 240 seconds] 15:18 -!- ProfMac [~ProfMac@2001:470:b8ac::2009:103] has joined #bitcoin-core-dev 15:46 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has quit [Ping timeout: 240 seconds] 15:47 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined #bitcoin-core-dev 16:20 -!- belcher_ [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer] 16:22 -!- belcher_ [~user@unaffiliated/belcher] has joined #bitcoin-core-dev 16:24 -!- CodeShark is now known as CodeShark_ 16:25 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev 16:35 -!- PRab [~chatzilla@2601:40a:8000:8f9b::3416:dab0] has quit [Read error: Connection reset by peer] 17:22 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev 17:34 -!- fkhan [~weechat@unaffiliated/loteriety] has quit [Ping timeout: 260 seconds] 17:42 -!- fkhan [weechat@gateway/vpn/mullvad/x-sctfgutvdtvqpuex] has joined #bitcoin-core-dev 18:32 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Max SendQ exceeded] 18:33 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev 18:35 -!- sipa [~pw@unaffiliated/sipa1024] has quit [Ping timeout: 252 seconds] 18:35 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev 19:10 < Luke-Jr> FYI: Someone in #bitcoin is actively trying to get a virus signature mined into the blockchain. 19:13 < phantomcircuit> gmaxwell, https://github.com/pstratem/bitcoinconsensus_fuzzer 19:47 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev 19:49 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 246 seconds] 19:51 < CodeShark> getting it mined is the easy part - it's figuring out something that will trip off scanners that's a little trickier ;) 19:52 < BlueMatt> there is a standard virus test signature that will trip up all virus scanners if they see it 19:52 < BlueMatt> eicar 19:53 < CodeShark> how big is it? 19:53 < BlueMatt> 68 bytes 19:53 < BlueMatt> X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* 19:53 < BlueMatt> put that in a file 19:53 < BlueMatt> heh, i had hide parts turned on..did anyone just part? 19:54 < BlueMatt> oh, nvm, it only works at the beginning of a file that is not longer than 128 chars 19:54 < gmaxwell> the eicar thing triggers almost nothing. 19:54 < gmaxwell> because, that. 19:55 < BlueMatt> gmaxwell: oh? If you put it in by itself I've seen it trigger almost everything 19:55 < BlueMatt> you just cant put it in the middle of a file 19:56 < CodeShark> we should store all blocks using symmetric crypto with the block hash as the key :p 19:59 < Luke-Jr> CodeShark: you're aware we have an open PR to obfuscate the chainstate, right? ;) 19:59 < sipa> CodeShark: being done for the utxo set now 19:59 < CodeShark> oh? 19:59 < CodeShark> since when? 19:59 < sipa> just xor, not symmetric crypto 19:59 < Luke-Jr> https://github.com/bitcoin/bitcoin/pull/6650 19:59 < Luke-Jr> sipa: eh? xor doesn't count as symm crypto? :P 20:00 < CodeShark> someone stole my idea! :p 20:01 < sipa> Luke-Jr: it's symmetric, but not cryptographic :) 20:01 < Luke-Jr> CodeShark: I've been recommending it to newbies for a while 20:01 < Luke-Jr> sipa: but.. but.. 20:01 < CodeShark> it's ultimately a matter of degree 20:01 < CodeShark> an xor one-time pad is more secure than any asymmetric cypher 20:02 < CodeShark> *cipher 20:02 < sipa> well, if XOR is symmetric cryptography, then { return 4; } is a CSPRNG :) 20:02 < CodeShark> damn, I of all people should know how to spell that word :p 20:03 < gmaxwell> importantly it's an xor with a per node random key.. which should be more than enough. 20:03 < CodeShark> xor is as secure as any other symmetric cipher if the key is at least as long as the message ;) 20:03 < gmaxwell> unless there are virus signatures that deal with the xor relationships of 8 byte apart groups... I couldn't find anything like that. 20:03 < CodeShark> or even more secure 20:04 < CodeShark> and as long as you only use it once 20:08 < CodeShark> I suppose something similar could be said for { return 4; } as a CSPRNG...if you only call it once :p 20:09 < CodeShark> however, 4 is a rather improbable number given cryptograpically-sized output 20:10 < CodeShark> it's no less probable than any other...but it still looks suspiciously small :) 20:10 < CodeShark> moreover, in both cases you need external entrop 20:10 < CodeShark> *entropy 20:11 < sipa> yes yes yes 20:11 < sipa> :) 20:18 -!- belcher_ [~user@unaffiliated/belcher] has quit [Quit: Leaving] 20:19 -!- neha [~narula@mint-square.mit.edu] has quit [Ping timeout: 260 seconds] 20:19 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds] 20:19 -!- neha [~narula@mint-square.mit.edu] has joined #bitcoin-core-dev 20:20 -!- zxzzt_ [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds] 20:20 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 20:21 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 20:32 < CodeShark> a virus signature that involves xor relationships 8 bytes apart would likely give many false alarms :p 20:33 < CodeShark> just dividing two large numbers could trip it off :p 21:20 < Luke-Jr> CodeShark: has that ever stopped them? 21:20 < Luke-Jr> CodeShark: most AVs have at one time or another made a signature for BFGMiner just because it was a semi-common payload 21:44 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Remote host closed the connection] 21:44 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev 22:03 < phantomcircuit> gmaxwell, the current version of the fuzzer logic only modifies the script portion 22:03 < phantomcircuit> it's significantly slower when the entire transaction can be modified 22:04 < phantomcircuit> i seem to have stopped finding interesting cases with 256 byte scripts though 22:08 < CodeShark> did you do an ordered search? or bruteforce? 22:09 < CodeShark> wasn't it 256-byte transactions that were of interest? 22:13 < phantomcircuit> CodeShark, afl-fuzz 22:13 < phantomcircuit> see https://github.com/pstratem/bitcoinconsensus_fuzzer 22:15 < phantomcircuit> CodeShark, definitely cant brute force all the 256 byte combinations :) 22:16 < CodeShark> is the goal simply to find valid transactions that are exactly 256 bytes long? 22:16 < BlueMatt> phantomcircuit: do you need a faster box to run that on? 22:18 < CodeShark> or nvm, I don't really know what you're trying to do :p 22:18 < phantomcircuit> CodeShark, no the goal is to find interesting transactions 22:18 < phantomcircuit> valid or otherwise 22:19 < phantomcircuit> BlueMatt, i dont think it would matter much, it's been running for about two days and hasn't found a new .... wait 22:19 < phantomcircuit> damn it i screwed up the afl-fuzz setup! 22:19 * phantomcircuit grubles 22:19 < CodeShark> by "valid" I'm just talking in terms of parser logic - not the chainstate and crypto validation stuff :p 22:19 < BlueMatt> phantomcircuit: if you send me the vm image I can run it on my workstation..... 22:19 < phantomcircuit> hmm actually maybe not 22:20 < phantomcircuit> looks like i didn't screw it up 22:20 < phantomcircuit> CodeShark, i have 1 testcase which fails the parser logic, but because of how afl-fuzz works it's only th eone 22:38 < phantomcircuit> gmaxwell, there seems to be an issue with the frequency of wallet flushes and the pruning logic 22:39 < phantomcircuit> the pruning logic can prune blocks where the wallet hasn't flushed indicating it's sync'd to them 22:39 < phantomcircuit> BlueMatt, you should fix! :P 22:39 < BlueMatt> huh? 22:40 < gmaxwell> hahah 22:40 < gmaxwell> phantomcircuit: yea that sounds bad. :P 22:42 < phantomcircuit> i would bet the same thing can happen with the block index, but i'd need to double check on that 22:43 < CodeShark> it would really be nice to put all the header logic into its own unit 22:45 < CodeShark> separate issue...but just thought I'd bring it up :p 22:46 < CodeShark> then other parts of the app can sync to the headers in different ways 22:46 < CodeShark> and the header index can carry additional state information 22:49 < CodeShark> (i.e. what rules to enforce for the particular block :) ) 22:53 < CodeShark> we could also shave off 80 bytes of data from getblock if we always use getheader to grab the header 22:54 < CodeShark> not that 80 bytes is that much when put into context of downloading the entire block :p 22:54 < CodeShark> but we could have more sophisticated queries for partial blocks 22:56 < CodeShark> I'm very much not satisfied with the filteredblock mechanism we currently have ;) 22:57 < CodeShark> even pruned nodes could serve useful data if the query structure were better 22:58 < CodeShark> in retrospect, perhaps Satoshi should have tried to implement SPV first :p 23:00 < gmaxwell> he did. 23:00 < gmaxwell> there was a begin a it in bitcoin core that was long since stripped out 23:01 < CodeShark> begin a it? 23:01 < gmaxwell> at 23:01 < CodeShark> I'm saying perhaps the header sync should have been the first consensus code written 23:01 < gmaxwell> today it will be much easier to do, but long ago the architecture was probably a bit too alien. 23:02 < gmaxwell> CodeShark: you have some hindsight benefit of how we think about the architecture of the system in modern times. :) 23:03 < CodeShark> yes, I said "in retrospect" 23:05 < CodeShark> in terms of what we can do now, I think if we really want to build a consensus library we should think in terms of isolating header sync into a standalone unit 23:05 < CodeShark> then we can build whatever kind of node on top of that 23:05 < CodeShark> whether it be full validation, pruned or not, SPV, etc... 23:07 < CodeShark> it will also help in avoiding unintended forks and other such issues in the future as we can explicitly know which rules can and cannot be enforced by a given node 23:07 < CodeShark> there's a whole spectrum here 23:07 < CodeShark> from "check absolutely everything" to "check nothing" 23:09 < gmaxwell> the structure of bitcoin core today is much more agreeable to that than it was in the past. 23:09 < CodeShark> yes, sipa did a good job with the headers-first sync 23:09 < CodeShark> so it's going in the right direction 23:11 < CodeShark> I did some outlining of everything that happens in ProcessNewBlock...there's a lot of redundancy and plenty of things that can be cleaned up 23:12 < CodeShark> ContextualCheckBlockHeader gets called twice 23:12 < CodeShark> it would be nice to just make all the state info checked in that part of the header index itself 23:29 -!- ParadoxSpiral [~ParadoxSp@p508B9429.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 23:31 < CodeShark> ultimately, I'd even like the version bits logic itself to be directly part of the header index - so instead of doing something like Rules rules GetRulesFromBlockIndex(pblockIndex); you can just do blockHeader.GetRules(); 23:33 < CodeShark> or headerIndex(block_hash).getRules(); 23:33 < CodeShark> or whatever 23:33 < CodeShark> something pretty like that :) 23:35 < CodeShark> then the rest of the block checking stuff can have conditionals like if(rules.contains(BIP66)) { } 23:36 < CodeShark> and from that point on we can easily isolate ANY changes to consensus checks and test them independently 23:38 < CodeShark> even alt coins could be built that can contribute useful ideas back to Bitcoin ;) 23:38 < CodeShark> rather than having to constrain our refactoring efforts to avoid pushback from people who long ago forked Bitcoin Core :p