--- Log opened Wed Aug 22 00:00:47 2018
00:02 -!- someone235 [~someone23@unaffiliated/someone235] has quit [Ping timeout: 240 seconds]
00:10 < kallewoof> gmaxwell: since sdaftuar objected, I figured I could make a separate PR with that enabled. I'll do that soon.
00:23 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
00:23 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Read error: Connection reset by peer]
00:23 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
00:23 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
00:25 -!- Amuza [~amuza@85.159.207.5] has joined #bitcoin-core-dev
00:28 -!- someone235 [~someone23@unaffiliated/someone235] has joined #bitcoin-core-dev
00:28 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Ping timeout: 264 seconds]
00:37 -!- emzy [~quassel@unaffiliated/emzy] has joined #bitcoin-core-dev
00:43 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
00:53 -!- JackH [~laptop@host86-157-119-232.range86-157.btcentralplus.com] has quit [Quit: Leaving]
00:58 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev
01:18 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
01:26 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
01:27 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
01:31 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Ping timeout: 264 seconds]
01:34 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
01:44 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
01:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:03 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Quit: bye]
02:04 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 250 seconds]
02:04 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev
02:06 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev
02:11 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
02:17 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 268 seconds]
02:28 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Remote host closed the connection]
02:28 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev
02:35 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-hccdbyzcballmczo] has joined #bitcoin-core-dev
03:03 -!- profmac [~ProfMac@2001:470:1f0f:226:510c:aa9e:3b83:d01b] has quit [Ping timeout: 276 seconds]
03:16 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
03:19 -!- rls [~rls@69.197.143.181] has quit [Ping timeout: 260 seconds]
03:30 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
03:40 -!- profmac [~ProfMac@2001:470:1f0f:226:510c:aa9e:3b83:d01b] has joined #bitcoin-core-dev
03:47 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
03:51 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 265 seconds]
04:01 < wumpus> arhhhhh noooo why does restarting your node cut up the debug.log again
04:01 < wumpus> lost more than a day of perf data
04:04 < wumpus> luke-jr: whooops, okay, will build windows then
04:11 -!- windsok [~windsok@unaffiliated/windsok] has joined #bitcoin-core-dev
04:45 -!- qu4ku [~qu4ku@2a01:110f:d06:bd00:4138:d269:46b5:3dc6] has joined #bitcoin-core-dev
04:46 -!- plankers [~plank@38.87.81.82] has joined #bitcoin-core-dev
05:15 -!- wxss [~user@91.229.77.238] has joined #bitcoin-core-dev
05:20 -!- alicehatesbob [~aphex@51.179.162.234] has quit [Quit: Leaving]
05:20 -!- meshcollider [meshcollid@gateway/shell/elitebnc/x-wgvbdtbctoyeevjj] has joined #bitcoin-core-dev
05:39 -!- qu4ku [~qu4ku@2a01:110f:d06:bd00:4138:d269:46b5:3dc6] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
05:50 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
05:55 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 252 seconds]
06:00 -!- rex4539 [~rex4539@2a02:587:3516:600:14eb:801d:3875:4940] has joined #bitcoin-core-dev
06:04 -!- victorSN is now known as summitto
06:05 -!- summitto is now known as vicSN
06:05 -!- vicSN is now known as victorSN
06:20 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
06:22 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
06:23 -!- Amuza [~amuza@85.159.207.5] has quit [Quit: Leaving]
06:31 < wumpus> ok, everything pending for 0.17 has been merged again, time to tag rc2?
06:32 < wumpus> it should at least be deterministic this time
06:34 < MarcoFalke> go ahead
06:37 < instagibbs> SGTM
06:37 < instagibbs> appreciate the psbt fix merges last-minute
06:43 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
06:47 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
06:50 -!- qu4ku [~qu4ku@public-gprs354000.centertel.pl] has joined #bitcoin-core-dev
06:52 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 264 seconds]
06:53 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
06:53 < fanquake> wumpus 👍
06:54 < fanquake> I’d like to be able to re-create the NSIS issue at some point. Just for interest
06:55 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Client Quit]
06:57 -!- qu4ku [~qu4ku@public-gprs354000.centertel.pl] has quit [Read error: Connection reset by peer]
07:00 -!- Krellan [~Krellan@2601:640:4000:9258:6990:ddbb:83a0:d4b9] has quit [Read error: Connection reset by peer]
07:01 < wumpus>  * [new tag]                                                                           v0.17.0rc2 -> v0.17.0rc2
07:01 -!- Krellan [~Krellan@2601:640:4000:9258:6990:ddbb:83a0:d4b9] has joined #bitcoin-core-dev
07:04 < jonasschnelli> \o/
07:05 < jonasschnelli> Is there a known issue with ./test/functional/wallet_backup.py? It failes often on my branch (though did some unrelated changes)?
07:05 -!- JackH [~laptop@host86-157-119-232.range86-157.btcentralplus.com] has joined #bitcoin-core-dev
07:08 < wumpus> not known to me, at least
07:15 < wumpus> wallet_backup.py passed, Duration: 106 s
07:16 < jonasschnelli> okay... probably a local issue
07:17 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
07:20 -!- Guest11272 is now known as sturles
07:21 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
07:21 < fanquake> \o/
07:24 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Remote host closed the connection]
07:25 < wumpus>  /o\
07:25 < achow101> \o\
07:27 < wumpus> /o/
07:27 < wumpus> the new version of lxc did make a long-standing issue go away for me where the first build try after starting the VM would always fail
07:28 < achow101> apparently kvm is still broken even with the updated vmbuilder :(
07:29 < wumpus> so if you can build a bionic image succesfully, what is the problem?
07:30 < achow101> err, I mean that vmbuilder still doesn't work
07:30 < achow101> so you can't build the bionic image
07:35 < wumpus> maybe one of the ready-made ubuntu cloud images would be useful?
07:37 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has joined #bitcoin-core-dev
07:37 < wumpus> that's how I spin up new VMs locally, download the appropriate ubuntu cloud image, verify gpg signatures, convert to qcow2 format, resize, then launch it. I don't use this process for gitian, but I don't  see why it wouldn't be similar.
07:41 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
07:44 < jonasschnelli> wumpus: wallet_backup.py is also failing on master on my debian system
07:44 < jonasschnelli> 'importwallet' RPC took longer than 60.000000 seconds
07:45 < jonasschnelli> (4 instances of Core mainnet are runnning in the background though)
07:45 < wumpus> jonasschnelli: maybe you can make it pass by increaing the timeout 
07:45 < wumpus> if it's really crashing, it would be interesting to attach a debugger and see where
07:45 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
07:47 < fanquake> wumpus I think I’ve seen the same issue on my old Debian setup. Haven’t seen on the newer setup.
07:47 < jonasschnelli> wumpus: I think importwallet is just slower then the timeout,... but I'll investigate
07:50 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Remote host closed the connection]
07:50 < wumpus> right-importwallet is a call that can be slow so it doesn't surprise me
07:59 < MarcoFalke> jonasschnelli: You could maybe fix that with "self.rpc_timewait = 90"
07:59 < MarcoFalke> like in feature_dbcrash
07:59 < jonasschnelli> MarcoFalke: Yes. I think that is necessary
07:59 < MarcoFalke> or wallet_dump.py
07:59 < jonasschnelli> MarcoFalke: IMO wallet_dumps.py:L84 self.rpc_timeout = 120 is invalid
08:00 < jonasschnelli> It should be self.rpc_timewait = 120
08:00 < MarcoFalke> oh
08:00 < jonasschnelli> I saw both (wallet_dump and wallet_backup) failing on my system (and on travis)
08:01 < jonasschnelli> Maybe they don't fall on bitcoin/bitcoin travis due to the exta CPU cycles we bought
08:01 < MarcoFalke> right
08:02 < MarcoFalke> Looks it is wrong in wallet_dump
08:02 < MarcoFalke> Not sure about travis
08:02 < MarcoFalke> We only bought additional machines, but the machines are itself identical
08:03 < jonasschnelli> Okay. But when I enabled travis for my local branch, master failes
08:03 < jonasschnelli> And master fails always on my debian machine
08:08 < MarcoFalke> jonasschnelli: Huh, I can't find any recent travis builds on you repo https://github.com/jonasschnelli/bitcoin/commits/master
08:08 < jonasschnelli> https://api.travis-ci.org/v3/job/419216711/log.txt
08:08 < jonasschnelli> I was flipping forward and backward in my commit history...
08:09 < jonasschnelli> Its all on my BIP151 branch
08:11 < jonasschnelli> cef09c6e3d13bc082a5cdb878324b350a17c492fa77af805e0745ba52ee031aa  bitcoin-0.17.0-osx-unsigned.dmg
08:11 < jonasschnelli> 3e953061e6baa7dc4d759d8447041071bff6222bc70188a66eddbcee8136c55e  bitcoin-0.17.0-win-unsigned.tar.gz
08:15 < MarcoFalke> hmm, might be related to some bip151 changes?
08:15 -!- someone235 [~someone23@unaffiliated/someone235] has quit [Ping timeout: 272 seconds]
08:16 -!- itaseski [~itaseski@213.135.176.241] has joined #bitcoin-core-dev
08:17 < MarcoFalke> you could first push the current master and then rebase the bip151 branch on that?
08:19 -!- rex4539 [~rex4539@2a02:587:3516:600:14eb:801d:3875:4940] has quit [Quit: Textual IRC Client: www.textualapp.com]
08:22 < MarcoFalke> But yeah, you can just bump the timeouts a little and submit a pull request. I think there is no harm in that
08:32 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
08:41 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
09:04 < gmaxwell> damn, on the power9 host here at least the block loading step of a reindex takes an hour and five minutes.
09:04 < gmaxwell> now.
09:06 < sipa> gmaxwell: how much on x86?
09:07 < gmaxwell> dunno, don't have a reasonably fast x86 machine running right now.
09:10 < gmaxwell> It was about a half hour back in november... so it's totally plausable to me that its an hour now.
09:12 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
09:13 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
09:18 -!- MarcoFalke [~none@198.12.116.246] has quit [Read error: Connection reset by peer]
09:33 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
09:33 -!- Zenton [~user@54.104.135.37.dynamic.jazztel.es] has quit [Ping timeout: 272 seconds]
09:34 -!- vexbuy [~vexbuy@46.166.142.216] has joined #bitcoin-core-dev
09:53 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
09:58 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 265 seconds]
10:07 -!- phwalkr [~phwalkr@2001:1284:f019:69b1:c9d7:7e9c:51dc:edbf] has joined #bitcoin-core-dev
10:13 -!- phwalkr [~phwalkr@2001:1284:f019:69b1:c9d7:7e9c:51dc:edbf] has quit [Ping timeout: 276 seconds]
10:16 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
10:25 -!- Netsplit *.net <-> *.split quits: d9b4bef9, wxss, IGHOR_
10:26 -!- Netsplit *.net <-> *.split quits: twistedline, newbie--, thib, no_input_found, wraithm, StopAndDecrypt, tryphe, wumpus, Jbaczuk, [b__b],  (+5 more, use /NETSPLIT to show all of them)
10:33 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-dev
10:34 -!- vexbuy [~vexbuy@46.166.142.216] has quit [Remote host closed the connection]
10:36 -!- MarcoFalke [~none@198.12.116.246] has quit [Remote host closed the connection]
10:37 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-dev
10:37 < jonasschnelli> MarcoFalke: travis on my repository fails even on the lint level: https://travis-ci.org/jonasschnelli/bitcoin/jobs/419285727
10:37 < jonasschnelli> Any idea?
10:39 < MarcoFalke> rerun all jobs and cancel the linter
10:39 < MarcoFalke> They are known to be broken and only meant to run on bitcoin/bitcoin pull requests
10:42 < jonasschnelli> Okay. Done.. but meh
10:51 < MarcoFalke> Agree on meh, but I am not going to touch the linters again ;)
10:59 -!- MarcoFalke [~none@198.12.116.246] has quit [Remote host closed the connection]
11:00 -!- lone3lf [~lone3lf@179.222.90.216] has joined #bitcoin-core-dev
11:09 -!- dcousens [~dcousens@110.140.174.10] has joined #bitcoin-core-dev
11:09 -!- twistedline [~quassel@unaffiliated/twistedline] has joined #bitcoin-core-dev
11:14 -!- lone3lf [~lone3lf@179.222.90.216] has quit [Ping timeout: 256 seconds]
11:22 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Quit: Leaving]
11:23 -!- provoostenator [~vwDZ2BYsc@2a05:d014:5f:e100:fd30:8af7:2d6a:cbb1] has joined #bitcoin-core-dev
11:25 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has quit [Changing host]
11:25 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev
11:26 -!- wumpus [~wumpus@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev
11:27 < wumpus> fyi: gitian 0.17.0rc2 sigs up
11:28 < provoostenator> Building... By the way, the web chat logs now say "BotBot disconnected, possible missing messages"  
11:29 -!- CubicEarth [~CubicEart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
11:29 < wumpus> I was kicked off too (and couldn't easily come back, SASL timeout issue)
11:33 -!- CubicEarth [~CubicEart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
11:34 < wumpus> (so with sigs up, I mean my own, not codesigned sigs)
11:41 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
11:42 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Read error: Connection reset by peer]
11:52 -!- JackH [~laptop@host86-157-119-232.range86-157.btcentralplus.com] has quit [Ping timeout: 265 seconds]
11:59 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev
12:11 -!- chainhead_ [~chainhead@108.61.159.53] has quit [Ping timeout: 260 seconds]
12:18 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
12:23 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-dev
12:46 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
12:46 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Quit: WeeChat 2.2]
12:47 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-hccdbyzcballmczo] has quit [Quit: Connection closed for inactivity]
12:50 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving]
13:06 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
13:06 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Remote host closed the connection]
13:07 -!- larrybeck [~larrybeck@76-202-84-204.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev
13:08 -!- larrybeck [~larrybeck@76-202-84-204.lightspeed.tukrga.sbcglobal.net] has quit [Quit: Leaving]
13:11 -!- larrybeck [~larrybeck@76-202-84-204.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev
13:14 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
13:14 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Remote host closed the connection]
13:21 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]
13:22 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
13:25 -!- Krellan [~Krellan@2601:640:4000:9258:6990:ddbb:83a0:d4b9] has quit [Read error: Connection reset by peer]
13:26 -!- Krellan [~Krellan@2601:640:4000:9258:6990:ddbb:83a0:d4b9] has joined #bitcoin-core-dev
13:27 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 252 seconds]
13:30 -!- Jbaczuk [~Jbaczuk@ec2-18-237-204-133.us-west-2.compute.amazonaws.com] has joined #bitcoin-core-dev
13:30 -!- thib [~thib@wikimedia/Thibaut120094] has joined #bitcoin-core-dev
13:34 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has quit [Ping timeout: 272 seconds]
13:36 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
13:37 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
13:38 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
13:40 -!- larrybeck [~larrybeck@76-202-84-204.lightspeed.tukrga.sbcglobal.net] has quit [Quit: Leaving]
13:41 -!- larrybeck [~larrybeck@76-202-84-204.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev
13:46 -!- rex4539 [~rex4539@2a02:587:3516:600:c14f:3fd5:26a9:28a0] has joined #bitcoin-core-dev
13:51 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has joined #bitcoin-core-dev
13:51 < kanzure> can someone kill the spam plzkthx
13:51 < kanzure> on github
13:52 < sipa> blocked him
13:52 -!- thib [~thib@wikimedia/Thibaut120094] has quit [Quit: leaving]
13:55 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
13:56 -!- farmerwampum [~farmerwam@104.129.28.10] has joined #bitcoin-core-dev
13:56 < wumpus> thanks
13:59 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
13:59 -!- farmerwampum_ [~farmerwam@104.129.28.10] has quit [Ping timeout: 276 seconds]
13:59 -!- farmerwampum [~farmerwam@104.129.28.10] has quit [Client Quit]
14:00 -!- farmerwampum [~farmerwam@104.129.28.10] has joined #bitcoin-core-dev
14:04 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 276 seconds]
14:08 -!- grafcaps [~haroldbr@104.137.194.255] has joined #bitcoin-core-dev
14:09 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
14:10 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
14:13 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
14:17 -!- lesderid [~lesderid@anna.lesderid.net] has quit [Ping timeout: 268 seconds]
14:19 < gmaxwell> Is there a proper way to get information out of connOptions from some random place in the code? I want to make the tip may be stale stuff not run in all the cases where its pointless, (reindex/network inactive/-noconnect...)
14:19 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]
14:19 -!- lesderid [~lesderid@2a03:b0c0:1:d0::2a5:4002] has joined #bitcoin-core-dev
14:33 < wumpus> the variables from connOptions end up in CConnman, so I guess only where the code has access to that 
14:35 -!- larrybeck [~larrybeck@76-202-84-204.lightspeed.tukrga.sbcglobal.net] has quit [Quit: Leaving]
14:36 < gmaxwell> k, I'll add an accessor.
14:38 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev
14:52 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
14:57 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 265 seconds]
15:03 -!- str4d [~str4d@28.87.208.46.dyn.plus.net] has joined #bitcoin-core-dev
15:05 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev
15:18 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]
15:22 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev
15:24 -!- rls [~rls@69.197.143.181] has joined #bitcoin-core-dev
15:25 -!- str4d [~str4d@28.87.208.46.dyn.plus.net] has quit [Ping timeout: 265 seconds]
15:56 -!- itaseski [~itaseski@213.135.176.241] has quit [Ping timeout: 264 seconds]
16:05 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev
16:07 -!- grubles [~grubles@unaffiliated/grubles] has quit [Client Quit]
16:09 -!- grubles [~grubles@gateway/tor-sasl/grubles] has joined #bitcoin-core-dev
16:12 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
16:14 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
16:16 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
16:20 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 250 seconds]
16:21 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 268 seconds]
16:25 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev
16:26 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer]
16:27 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
16:51 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev
16:56 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Ping timeout: 240 seconds]
16:56 -!- grafcaps [~haroldbr@104.137.194.255] has quit [Ping timeout: 265 seconds]
17:05 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
17:19 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
17:22 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
17:39 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
17:40 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
17:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
17:59 -!- Zenton [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
17:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
18:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
18:17 -!- Krellan [~Krellan@2601:640:4000:9258:6990:ddbb:83a0:d4b9] has quit [Ping timeout: 252 seconds]
18:17 -!- Krellan [~Krellan@2601:640:4000:9258:6990:ddbb:83a0:d4b9] has joined #bitcoin-core-dev
18:21 -!- peevsie [~peevsie@2604:2000:f18f:e300::2] has joined #bitcoin-core-dev
18:26 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
18:26 -!- unholymachine [~quassel@2601:8c:c003:9f16:a9a2:a65b:627a:51ee] has joined #bitcoin-core-dev
19:03 -!- Jmabsd [~jmabsd@103.51.117.4] has joined #bitcoin-core-dev
19:04 < Jmabsd> sipa, re "uint256's ToString() method", what's the exact code location? it's not in uint256.h/c
19:04 < Jmabsd> ah dear, wait, it's there - "class uint256 : public base_blob<256>", and then base_blob has a toString, obviously.
19:05 < Jmabsd> ToString just calls GetHex, and it's defined as "return HexStr(std::reverse_iterator<.." - there we have it. thx!
19:12 < sipa> exactly.
19:16 -!- Jmabsd [~jmabsd@103.51.117.4] has quit [Ping timeout: 252 seconds]
19:22 -!- Lightsword_ [~Lightswor@2604:a880:1:20::1d3:9001] has joined #bitcoin-core-dev
19:28 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev
19:29 -!- Netsplit *.net <-> *.split quits: [b__b], dcousens, rex4539, e4xit
19:30 -!- Lightsword_ is now known as Lightsword
19:30 -!- achow101_ is now known as achow101
19:30 -!- Netsplit *.net <-> *.split quits: pierre_rochard, jonasschnelli, sipa, AdrianG
19:30 -!- Netsplit over, joins: dcousens
19:36 -!- Jmabsd [~jmabsd@103.51.117.4] has joined #bitcoin-core-dev
19:37 -!- keymone [~keymone@ip1f13761c.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev
19:41 < Jmabsd> oh, the HD wallet stuff uses reverse byte order too: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/rpcwallet.cpp#L3059
19:43 < Jmabsd> and the merkle root is printed in reverse order.
19:46 < gmaxwell> 21:29:12 < gmaxwell> Jmabsd: the point is that bitcoin's UI uses the same stuff to print all these 256 bit hashes.
19:46 < Jmabsd> gmaxwell, yeap and also 160bit.
19:47 < Jmabsd> (this one https://github.com/bitcoin/bitcoin/blob/master/src/wallet/rpcwallet.cpp#L3059 is 160bit)
19:47 < Jmabsd> gmaxwell, is there any 256bit hash that is *not* printed in this order? also,
19:47 < gmaxwell> I don't know what code would do that printing...
19:47 < Jmabsd> i see the stronger, material, original reason for this ordering was to get the zero bits in block hashes have the zeroes in the beginning
19:48 < gmaxwell> 21:30:21 < gmaxwell> block hash is interpreted as a 256-bit little endian number for target comparison as luke says, so then bitcoin needed to print  it that way too, otherwise the 0s would have been on the right which would have been confusing... and the same code was then  used to print other hashes.
19:48 < Jmabsd> however may there be some more general, common-sense reason too to print hashes in reverse order, or it's all just about symmetry with the block hash representation?
19:48 -!- profmac [~ProfMac@2001:470:1f0f:226:510c:aa9e:3b83:d01b] has quit [Ping timeout: 276 seconds]
19:49 < Jmabsd> ahaa, to get a proper ordering, interesting
19:50 < Jmabsd> that makes sense yes.   what code in Bitcoin Core compares two uint256:es, which would be used for sorting?
19:52 -!- plankers [~plank@38.87.81.82] has quit [Ping timeout: 252 seconds]
19:56 < Jmabsd> HEX STRING -----(funny reverse order deserialization)----> uint256 structure which is actually a 32B byte vector  ------(sort function, compares the uint256:es by normal < > logic) ---->  sorted list ----- (serialize with funny reverse order again) ----> alphanumeric order sorted list
19:56 < Jmabsd>  that only makes sense if the <  >  operator is little endian :)
19:57 < Jmabsd> ahh i see base_blob's < operator and Compare method
19:59 < Jmabsd> the < logics are in int256.h's base_blob, and implemented as "friend inline bool operator<(const base_blob& a, const base_blob& b) { return a.Compare(b) < 0; }", "inline int Compare(const base_blob& other) const { return memcmp(data, other.data, sizeof(data)); }".
19:59 < Jmabsd> memcmp here would react at the first byte that's different. this comparison logics are suitable for a *big endian* representation of a number right - 
19:59 < dcousens> Jmabsd at this point,  we're simply stuck with it
19:59 < dcousens> You can reason about it in a thousand ways,  network byte ordering,  etc,  but,  its merely what was done,  and now its stuck
20:00 < Jmabsd> i compare "0x12 0x54 0xfd 0x55" with "0x12 0x54 0xf0 0x55", in this case memcmp will give a negative value due to the third slot's difference
20:00 < Jmabsd> dcousens: yeap i see. i'm trying to make just a bit of sense here, so that, if you make a Dcousens Protocol to do some Bitcoin-related stuff, and you have some structure in your protocol that you hash and then give to people, in what order should it be.
20:01 < Jmabsd> for instance, for symmetry with Bitcoin, if you make a Dcousens Bitcoin Transaction format, then obviously its hash should be printed in reverse order.
20:01 < Jmabsd> (which is some Bitcoin transaction for some purpose)
20:01 < Jmabsd> e.g. Lightning channels certainly represent the channel open/close transactions as txid:s with reverse order, and maybe some other hashes too.
20:04 < Jmabsd> dcousens: so the uint256 < operator is a big endian thing.
20:04 < Jmabsd> wait where's the PoW bits counting done again - i guess it should count the *last* bits (at the last byte positions of the uint256 structure)?
20:04 < Jmabsd> otherwise the PoW counting and the uint256 < operator are not symmetrical
20:04 < luke-jr> it doesn't count bits at all
20:04 < Jmabsd> or, wait
20:04 < Jmabsd> they are
20:04 < Jmabsd> er.
20:05 < Jmabsd> luke-jr: where is the zero counting done again
20:05 < luke-jr> it's not
20:05 < luke-jr> "zero counting" is a simplification for end users
20:05 < luke-jr> the protocol itself simply does a <
20:07 < dcousens> personally,    I use the terms  `txhash` for the normal byte ordering,  and `txid` for reverse byte ordering  
20:07 < Jmabsd> luke-jr: https://github.com/bitcoin/bitcoin/blob/master/src/uint256.h#L49 is this the < operator used, or is the logics somewhere else?
20:08 < dcousens> if they need access to the raw data (aka, hashing),  they typically deal with the hash,   if they are doing lookups,  I give the reverse byte order hex string
20:08 < Jmabsd> dcousens: and for blocks you call it what?
20:08 < dcousens> blockhash blockid
20:08 < dcousens> respectively
20:08 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
20:08 < Jmabsd> dcousens: and if you ever print a 256bit or 160bit hash in a pubkeyscript, then you print it in *byte order* right
20:09 < Jmabsd> dcousens: merkle root "id" versus "hash" too? :-))
20:09 < dcousens> define print
20:09 < Jmabsd> dcousens: "show to a user in a web page or console"
20:09 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Quit: WeeChat 2.1]
20:09 < dcousens> yeah,  in normal byte order for that
20:09 < dcousens> again, I only make the distinction for block/tx id's
20:09 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
20:09 < Jmabsd> dcousens: aha. Bitcoin Core would print the merkle root in reverse order. anyhow right.
20:10 < Jmabsd> dcousens: i think your approach makes sense.
20:11 -!- peevsie [~peevsie@2604:2000:f18f:e300::2] has quit [Ping timeout: 264 seconds]
20:11 < dcousens> and merkleroots*
20:15 -!- cyber55 [~cyber55@unaffiliated/cyber55] has joined #bitcoin-core-dev
20:15 < Jmabsd> dcousens: you reverse-order your merkle roots too ??? 
20:15 < Jmabsd> wait, hashes are such are binary/byte concepts so the whole idea of relating to them as comparable numbers, is a concept that Bitcoin adds on top of them, right?  the inventor of SHA256 never related to hashing as   SHA256(byte string) => 256bit integer which may be little or big endian, right?
20:18 < dcousens> for display
20:18 < dcousens> IIRC
20:19 < dcousens> Bitcoin core reverse orders any 256-bit hex string, basically
20:19 < Jmabsd> dcousens: aha. so "blockid", "txid" and "merkle root" you do reverse order. any more?  HD wallet seeds?
20:19 < dcousens> I'd say that is all
20:19 < Jmabsd> (y)
20:19 -!- lone3lf [~lone3lf@179.222.90.216] has joined #bitcoin-core-dev
20:19 < dcousens> "blockid", "txid", and merkle roots... if I remember correctly.
20:20 < dcousens> Typically, I refer to it as "merkleRootId"
20:21 < achow101> Jmabsd: Bitcoin Core prints everything that is a byte array in reverse byte order
20:21 < achow101> Jmabsd: except for byte arrays in scripts. those are printed as-is
20:21 < achow101> literally everything else (block hash, merkle root, txid, tx hash, whatever) is reverse byte order
20:21 < Jmabsd> achow101: if you print a transaction's body, that's in normal byte order no ?? 
20:22 < Jmabsd> sorry for being spammy about this byte order question, in a way it's trivial however as soon as a user is trying to use this, if the ordering is wrong then things break.
20:22 < achow101> Jmabsd: a transaction is an object, not a byte array
20:22 < dcousens> achow101 except private keys
20:22 < Jmabsd> achow101: right so Bitcoin Core defines both 256bit and 160bit hashes as subclasses of "base_blob", is this what you mean by byte array?
20:22 < achow101> Jmabsd: yes
20:23 < Jmabsd> achow101: is anything else than 256bit and 160bit hashes represented as "base_blob"?? 
20:23 < achow101> no
20:23 < Jmabsd> achow101: right. (what you say i get confirmed by "grep -r base_blob *" too - it's only mentioned in uint256.*.)
20:24 < achow101> dcousens: private keys are printed as WIF :)
20:24 < Jmabsd> just for reference, where is the comparison of PoW, that is against the difficulty target, and in a reorg?
20:24 -!- lone3lf [~lone3lf@179.222.90.216] has quit [Ping timeout: 260 seconds]
20:24 < Jmabsd> that should be a "<" operator on the uint256_t type no?
20:24 < achow101> Jmabsd: src/pow.*
20:24 < dcousens> achow101: my point was,  in terms of a community standard
20:25 < achow101> Jmabsd: https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L87
20:25 < dcousens> the standard is reverse byte order    for   blockid, txid, merklerootid ... I don't think there is anything else you would want to adhere to in reverse byte order.
20:25 -!- lone3lf [~lone3lf@177.13.176.184] has joined #bitcoin-core-dev
20:26 < dcousens> And therefore,  even when displaying,  I would _only_ do reverse byte order for those things,  e.g,  if you are printing a private key,  you wouldn't print it in reveres byte order
20:26 < achow101> dcousens: it's actually anything that can be interpreted as an integer. e.g. version numbers are little endian which is a form of "reverse byte order"
20:26 < dcousens> I don't think I've seen the locktime printed as reverse byte
20:27 < dcousens> But maybe!
20:27 < achow101> dcousens: is it not reversed from whatever it is stored as?
20:27 < dcousens> it is stored in LE
20:28 < dcousens> so not reversed afaik
20:28 < achow101> right, so it is printed as a big endian decimal which is reverse byte order of little endian
20:29 < dcousens> ha
20:29 < dcousens> yeah I suppose
20:29 < dcousens> but if I saw it in hex
20:29 < dcousens> I'd probably assume LE,  not BE
20:29 < dcousens> unless I saw `0x...` haha, then I'd assume BE
20:29 < dcousens> what a mess
20:31 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds]
20:36 -!- rls [~rls@69.197.143.181] has quit [Ping timeout: 272 seconds]
20:46 -!- phwalkr [~phwalkr@2001:1284:f019:69b1:f15e:85d1:a133:857a] has joined #bitcoin-core-dev
21:06 < Jmabsd> wait, for mainnet, configuration includes: consensus.powLimit = uint256S("00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff");
21:07 < Jmabsd> this means that a single proof of work may not.. what?
21:09 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
21:09 < fanquake> cfields are you doing detached sigs now?
21:13 < Jmabsd> dcousens,achow101: facepalm lol.
21:14 < Jmabsd> dcousens,achow101: i like dcousens' way of relating to it that only blockid, transactionid and merklerootid should be reverse byte order, that limits the possible damage from ambiguous order conventions too ha.
21:17 -!- lone3lf [~lone3lf@177.13.176.184] has quit [Quit: :)]
21:17 < Jmabsd> achow101: the "nBits" value, which is copied from the block header and is applied in PoW here https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L80 : "arith_uint256 bnTarget;bnTarget.SetCompact(nBits, &fNegative, &fOverflow);"  , it's in the Bitcoin-internal 32bit floating point format right?? 
21:18 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit []
21:18 < achow101> Jmabsd: yes
21:18 < Jmabsd> achow101: actually what code generates that bits value?? 
21:19 < Jmabsd> achow101: at the genesis block, the bits value is *very low* and then it's getting *higher and higher*, slowly approaching 2^256 right?
21:19 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
21:19 < Jmabsd> achow101: each PoW generated out there, has the block hash proof of work 256bit-integer-compared with this target value right?
21:19 -!- lone3lf [~lone3lf@177.13.176.184] has joined #bitcoin-core-dev
21:20 < gmaxwell> it goes up and down, whatever is required to keep the block rate on target.
21:20 < Jmabsd> so, Bitcoin Core does "if (UintToArith256(hash) > bnTarget)" - so you're checking that the block hash is "more work" than the target value, and meanwhile LibBitcoin does "to_uint256(hash()) <= target;", https://github.com/libbitcoin/libbitcoin/blob/master/src/chain/header.cpp#L464
21:21 < Jmabsd> so LibBitcoin is checking that... err.. the target is.. BIGGER than the PoW?
21:21 < Jmabsd> gmaxwell ah yes.
21:21 < Jmabsd> LibBitcoin comments "Ensure actual work is at least claimed amount (smaller is more work)." - i wonder how they got this inverse definition of work, he. thoughts?
21:22 < achow101> Jmabsd: Bitcoin Core checks that if the block hash is bigger than the target, it should fail, hence the return false that follows
21:22 < Jmabsd> Ah. yes.
21:23 < achow101> libbitcoin checks that the hash is less than the target, and if it is, it continues
21:23 < achow101> they mean the same thing
21:23 < Jmabsd> achow101: noted.   and... what's the point here?
21:23 < gmaxwell> I've been asking myself that.
21:23 < Jmabsd> you want the work to be SMALLER than the target?  so the "bits" value is going to zero??
21:23 < Jmabsd> so zero means 256 leading zero bits to qualify? :-}
21:24 < achow101> Jmabsd: yes. the hash should be less than the target
21:24 < Jmabsd> achow101: this makes sense if "leading zero bits" means "the most significant bits in the block hash viewed as a 256bit unsigned integer" - 
21:24 < Jmabsd> then obviously zero bits means a SMALLER integer
21:25 < Jmabsd> ok interesting, this is a very curious piece of endianness juggling, ha.
21:25 < achow101> Jmabsd: the whole target checking works like this:
21:25 < achow101> interpret the hash (as output by the hash function) as a 256 bit little endian integer
21:26 < achow101> take nBits, decompress it and interpret it as a 256 bit little endian integer
21:26 < achow101> if the hash is less than or equal to the decompressed nBits, then it is valid.
21:27 < achow101> The whole reverse byte order thing is to get "256 bit little endian integer" into "256 big endian integer" because humans are used to looking at things in big endian
21:27 < Jmabsd> right. (and, nBits is a custom value format so "little endian integer" here doesn't make sense as such. point is just, "make a 256bit integer type so you can compare it, and don't mess up!" he.)
21:27 < achow101> yep
21:28 < Jmabsd> achow101: and then for sorting blockid/txid/merklerootid:s, you want the internal 256bit integer sorting to correspond to sorting the string serialization in big endian representation form lol
21:29 < gmaxwell> there isn't any normative sorting in the protocol.
21:30 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
21:30 < Jmabsd> mhm.
21:30 < Jmabsd> so we can only understand that transaction id:s and merkle root id:s (and in Bitcoin Core's case also hd wallet seeds) got this reverse byte order,
21:31 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
21:31 < Jmabsd> was just a coincidence of how Satoshi happened to write the code
21:31 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
21:31 < gmaxwell> they didn't "get" any reverse order.
21:31 < Jmabsd> at least we can't see more sense in it today. 
21:31 < Jmabsd> gmaxwell, well in the human readable string representation, they do, right
21:31 < gmaxwell> everywhere inside the system there isn't any reversing. It's just printed that way.
21:31 < gmaxwell> yes, as was explained to you a day ago.
21:32 < gmaxwell> Because blockhashes make sense to print in that order, every other 'big number' just used the same printing code.
21:32 < Jmabsd> yeap exactly - the convention of printing transaction id:s and merkle root id:s in reverse order, we can only understand it to be a coincidental design choice that originated from printing block id:s in reverse order, which does have sense in that you get the zeroes in the beginning that way, which is educative.
21:33 < Jmabsd> exactly. ok i think i got it now.     regarding dcousens' terminology of "block id" vs "block hash", "tx id" vs "tx hash", and "merkle root id" vs "merkle root hash", is this a widely accepted convention, or is it just his thing?? 
21:33 < Jmabsd> where "id" would mean reverse order and "hash" would be normal order
21:34 < gmaxwell> I'm not familar with it.
21:35 < gmaxwell> Really, if byte orders are tripping you up you're going to be really confused by every other detail of the system. :)
21:35 < Jmabsd> lolol. no i just look at this with particular attention as any user who would get his data trashed would get really confused, ha
21:35 < Jmabsd> i mean, say someone makes a program asking a user to pass a "block hash" as an argument
21:36 < Jmabsd> and the guy gives it in reverse order, and then the program says "no such block exists, bye"
21:36 < Jmabsd> that kind of consequental malbehavior
21:36 < Jmabsd> what about "id" versus "hash", is this an established convention re block/tx/merkleroot?
21:36 < achow101> Jmabsd: fun fact, bitcoin core does exactly that
21:36 < Jmabsd> achow101: :o where?
21:37 < achow101> if you give it the actual block hash, it will not find the block
21:37 < gmaxwell> achow just means that the input is in the same order as the output.
21:37 < gmaxwell> 21:36:50 < Jmabsd> what about "id" versus "hash",  > 21:34:51 < gmaxwell> I'm not familar with it.
21:38 < Jmabsd> achow101: derp derp. exactly.
21:38 < Jmabsd> > achow just means that the input is in the same order as the output.
21:38 < Jmabsd> what do you mean?
21:38 < gmaxwell> what was was trying to say is that the order bytes are in are the most trivial of 101 things you have to get right for software to work. I don't really spend any time thinking about it. Sometimes I'll do something and it won't work because I needed to reorder something, so I do, and I move on.
21:38 < achow101> Jmabsd: you give it the block hash in the way that it is printed, aka reverse byte order. if you give it how it actually is, it will not find the block
21:39 < Jmabsd> achow101: exactly. so all over the whole Bitcoin ecosystem, those three values (block HASH, transaction HASH and merkle root HASH aka ID whatever), when you're dealing with hex representation, it must ALWAYS be in reverse order bc otherwise you'll screw up
21:39 < gmaxwell> achow101: there is no spoon^w"how it is". I mean, it "is" electrical charges, but you enter it via moving buttons. Everything we deal with is an arbritary representation.
21:40 < Jmabsd> so if you have a tool / app / web site whatever that tells you which block, then you give it in reverse order
21:40 < Jmabsd> if you have a CLI tool / app / whatever that asks which block or tx, then you input it in reverse order, etc. 
21:40 < achow101> Jmabsd: yes
21:40 < Jmabsd> however aside from block hashes, transaction hashes and merkle roots, you're free to use the normal order.
21:41 < achow101> Jmabsd: no
21:41 < Jmabsd> achow101: no? :o
21:41 < achow101> Jmabsd: those still use reverse byte order
21:41 < Jmabsd> yea that's what i said:
21:41 < achow101> oh, I misread, nvm
21:42 < Jmabsd> achow101: if anywhere in this world you show a user a block hash, tx hash or merkle root hash, or ask him for it, then you do it in reverse order - but, for other values, such as for instance if you make a HD wallet and print him a hex dump of a seed, or,
21:42 < gmaxwell> hash160s are probably also in that order in the interface, if any show up in the interface anywhere.
21:42 < Jmabsd> some other hash, even if it relates to the bitcoin protocol, then normal order is fine
21:42 < Jmabsd> for instance, the 32B and 20B hashes in pubkeyscripts! those would be normal order
21:42 < achow101> gmaxwell: it depends on where the hash160 is, apparently
21:42 < gmaxwell> pubkeyscripts is not an arith/hash_n, it's just bytes.
21:42 < Jmabsd> gmaxwell: exactly, Bitcoin Core's HDwallet seeds are 160bit and presented in reverse order, yes
21:43 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
21:43 < gmaxwell> in any case, trying to come up with a greater theme is probably a waste of time. You do whatever works.
21:43 < achow101> if it is being output in, e.g. getaddressinfo it will be in reverse byte order. but in decodescript, it is not
21:43 < gmaxwell> There is a historical reason that it works the way it does, sure, but all that matters is that you do what works.
21:43 < Jmabsd> achow101,gmaxwell: maybe to help the world a bit, it's better actually to talk about "block id", "transaction id" and "merkle root id", and by "id" you mean "reverse order", even though it's not universally established nomenclature - tihs was a nice suggestion by dcousens.
21:44 < gmaxwell> if you want to predict what something will be (why?) then I believe "is it stored as a big uint type in the system" is the necessary and sufficient predictor.
21:44 < gmaxwell> I think if you're spening enough time thinking about this that you need names for it, you're probably doomed to never do anything useful.
21:44 < Jmabsd> achow101: actually when do you ever show a user the merkle root ID... 
21:45 < Jmabsd> the merkle root 256bit value is soo internal
21:45 < Jmabsd> you never compare it with anything else too
21:45 < achow101> Jmabsd: in getblock
21:45 < gmaxwell> I can tell you that it's possible to work for years on the system and never think about any of this for more than a moment.
21:45 < Jmabsd> achow101: you make a lookup of a block based on its merkle root or what :o
21:45 < achow101> Jmabsd: nope, just as output for a decoded block
21:45 < Jmabsd> right. and it's reverse order. derp derp. yeap.
21:45 < gmaxwell> and I've seen from years in this channel that people that come in asking lots of questions about byte order almost all just get frustrated and give up.
21:46 < Jmabsd> okok i got it. anyhow all clear now. thx. 
21:47 < gmaxwell> the order it prints big uints is arbritary, but no more or less arbritary than the decision to print them in hex instead of base2 or base64 or something else.
21:47 < gmaxwell> the order made sense for one thing, and then everything else just did the same because they share printing code and the order was irrelevant for everything else.
21:48 < Jmabsd> achow101: if you ever printed a merkle *node* to a user, would you do it in reverse order, i guess *not*.
21:48 < gmaxwell> of course.
21:49 < gmaxwell> if its represented as a uint in the software, it gets printed in that order.
21:49 < gmaxwell> so it would be 'revese' if you mean printing an interior node hash.
21:49 < gmaxwell> er. reverse.
21:50 < achow101> Jmabsd: it would be in reverse because I would use a uint256 and that prints in reverse :p
21:50 < achow101> (in a modification of Bitcoin Core)
21:50 < gmaxwell> there are already a zillion random fields that show up in the UI in reverse order that litterally no one ever thought about. They just printed a uint and thats how the uints print method works.
21:51 < gmaxwell> So, for example, there is something that prints a hash of the utxo set.
21:51 < gmaxwell> that was added last year.
21:51 < gmaxwell> Without looking I'm sure it's in "reverse" order. No one ever even thought about it. Because the order is irrelevant, so they just get the default behavior.
21:52 < Jmabsd> gmaxwell, a hash of all utxo:s in the blockchain at a given block height? 
21:52 < gmaxwell> at the current height.
21:52 < gmaxwell> it's useful for checking for corruption in the utxo set.
21:52 < Jmabsd> derp derp, ok Bitcoin Core gonna kick in more reverse order hex conventions in the ecosystem over time, he he. however users won't care really about those.
21:52 < Jmabsd> aha yep.
21:53 < Jmabsd> one could call it "utxo set id" to subtly emphasise that it's reverse order.
21:53 < gmaxwell> or, one could not care because it's a total waste of time.
21:54 < gmaxwell> no one ever had to think about it at all.
21:54 < gmaxwell> if you get too busy thinking about minutia you'll probably find your mind becomes too crowded to think about more complicated things. :)
22:02 -!- profmac [~ProfMac@2001:470:1f0f:226:4fa:dd19:ca84:f149] has joined #bitcoin-core-dev
22:13 < gmaxwell> achow101: https://bitcoin.stackexchange.com/questions/78292/insanely-high-fee lol I wonder if we should make it _harder_ to bypass that...
22:13 < gmaxwell> I wonder how many people hit that and then frantically work around it without realizing that its saving them from doom.
22:14 < gmaxwell> like maybe to bypass it the node should present you with a randomly generated nonogram puzzle. :P
22:15 < luke-jr> insanely high fee isn't enforced as a relay policy, is it? O.o
22:16 < gmaxwell> no.
22:16 < gmaxwell> it's just enforced at the user interfaces.
22:16 < gmaxwell> and its easy to bypass.
22:17 < gmaxwell> but I've several times seen people asking about how they could bypass it and it turns out it was saving them.
22:17 < gmaxwell> (as is the case in that link)
22:30 -!- Krellan [~Krellan@2601:640:4000:9258:6990:ddbb:83a0:d4b9] has quit [Read error: Connection reset by peer]
22:30 -!- Krellan [~Krellan@2601:640:4000:9258:7902:1f7a:6ab3:9f71] has joined #bitcoin-core-dev
23:13 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
23:16 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
23:35 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 240 seconds]
23:40 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
23:51 -!- jonasschnelli_ [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-dev
23:52 -!- jonasschnelli_ is now known as jonasschnelli
23:53 -!- Jmabsd [~jmabsd@103.51.117.4] has quit [Ping timeout: 265 seconds]
23:56 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
23:57 < jonasschnelli> cfields: I wonder why our OSX SDKs have a different hashs: https://github.com/bitcoin-core/gitian.sigs/commit/2ed8b5fba57623c0160eebc0c77ee4f9f2fe041a#diff-4bb2ae50ac744a39b2feaf294eb21d8eR9. https://github.com/bitcoin-core/gitian.sigs/pull/781/files#diff-0016af707809da5b52923d223d1943fcR9
23:58 < jonasschnelli> It's not a problem,... just wondering
--- Log closed Thu Aug 23 00:00:48 2018