--- Day changed Mon Oct 24 2016
00:00 -!- mkarrer [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
00:01 < wumpus> + stupid laws that disallow circumventing "
00:01 < wumpus> security measures"
00:01 < wumpus> all to protect mickey mouse, of course
00:06 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
00:06 < wumpus> "International Journal of Proof-of-Concept or Get The Fuck Out" hah I'd never seen that one written out
00:15 < wumpus> -noconnect seems to work fine w/ 9002
00:17 -!- mkarrer_ [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
00:18 < GitHub101> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f08222e882b1...fd29348dbe82
00:18 < GitHub101> bitcoin/master 1d8e12b Pavel Janík: Fix doxygen comment: the transaction is returned in txOut
00:18 < GitHub101> bitcoin/master fd29348 Wladimir J. van der Laan: Merge #8993: Trivial: Fix doxygen comment: the transaction is returned in txOut...
00:19 < GitHub145> [bitcoin] laanwj closed pull request #8993: Trivial: Fix doxygen comment: the transaction is returned in txOut (master...20161021_fix_GetTransaction_comment) https://github.com/bitcoin/bitcoin/pull/8993
00:20 -!- mkarrer [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has quit [Ping timeout: 244 seconds]     
00:20 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Ping timeout: 260 seconds]     
00:21 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:23 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds]     
00:25 -!- whphhg [~whphhg@unaffiliated/whphhg] has quit [Ping timeout: 245 seconds]     
00:31 -!- whphhg [whphhg@gateway/vpn/mullvad/x-qbszzdfnigpsozgf] has joined #bitcoin-core-dev     
00:39 -!- Squidicc [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
00:43 -!- squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 248 seconds]     
00:47 -!- Guest16408 is now known as thestringpuller     
00:47 -!- thestringpuller [~stevie@ec2-52-3-128-9.compute-1.amazonaws.com] has quit [Changing host]     
00:47 -!- thestringpuller [~stevie@unaffiliated/thestringpuller] has joined #bitcoin-core-dev     
00:50 < GitHub87> [bitcoin] unsystemizer opened pull request #9004: Clarify `listenonion` (master...patch-3) https://github.com/bitcoin/bitcoin/pull/9004
00:51 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
01:14 -!- laurentmt [~Thunderbi@80.215.210.207] has joined #bitcoin-core-dev     
01:14 < da2ce7> Hello, is there a overview of this blocksign feature that is being developed?
01:15 < gmaxwell> da2ce7: I presume it would be a cut down port of whats in elements alpha.
01:16 < da2ce7> I can only suppose it is only to be used for testnet.
01:16 < gmaxwell> the motivation is just to have testnets that are less unreliable than a very small pow blockchain for use for testing that doesn't really care about the consensus mechenism.
01:16 < gmaxwell> yea, of course.
01:16 < gmaxwell> I'm curious where you heard about it where that wasn't clear?
01:16 < wumpus> yes, which is the only thing that makes the implementation difficult in practice
01:17 -!- laurentmt [~Thunderbi@80.215.210.207] has quit [Client Quit]     
01:18 < wumpus> if you are looking for a proposal to enable it on mainnet, there's none, no chance
01:18 < da2ce7> I'm curious as it is similar to a feature that where a miner signs their block with a random key (with the pk fingerprint included in the coin base), where after-the-fact the miner could prove that he/she mined that block.
01:18 < gmaxwell> that doesn't make a lot of sense, someone signing something doesn't demonstrate authorship
01:19 < gmaxwell> instead, to achieve what you describe needs only a commitment to a public key in the block.
01:19 < gmaxwell> Though it's somewhat important to the system that miners operate anonymously, to reduce their exposure to coersion.
01:20 < da2ce7> well it dose prove that you own that public key, so it means that I cannot put _your_ public key in my block.
01:21 < luke-jr> not necessarily. you could sign the template and ask me to mine it for you :p
01:21 < gmaxwell> If the key is random and used once it doesn't really matter.
01:23 < da2ce7> however then you would need a mechanism to enforce using a different key eveyblock.  Otherwise, BadMiner could put a GoodMiner public key, and be a nuance.
01:24 < gmaxwell> da2ce7: huh? no... if you care about that you just ignore reuse.
01:24 < da2ce7> *nuisance
01:24 < gmaxwell> same as someone not providing a key at all.
01:27 < da2ce7> well anyway, maybe there is no demand (or it isn't a wise thing at all), for there to be a standard way for miners to prove they made a particular block.
01:27 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ymyqlgugyrbfgtmb] has joined #bitcoin-core-dev     
01:29 < gmaxwell> Sort of the opposite. I think it's extremely risky for the system for miners to be attaching any kind of identity to blocks at all.
01:29 < da2ce7> it could/would make miner/share statistics more reliable if used, again, if that is a wise idea is very debatable.
01:29 < gmaxwell> There are ways to do that without any publication of info to the general public though.
01:32 < gmaxwell> (presumably we'll see a change to miners self identifying the first time after someone gets sued because someone was unhappy about which transactions they happened to confirm. :( )
01:32 < da2ce7> I can imagine that it could be useful in the case the network was under a 51% attack, if miners could attach pseudo-anonymous identities to blocks. However it would be much preferable to never be in such a dystopian state.
01:34 < da2ce7> anyway, off-topic.  Blocksign for testnet is good for testing :).
01:38 < gmaxwell> yes, centeralizing the system can make it more secure against many kinds of attacks... :)
01:50 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
02:17 < GitHub42> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fd29348dbe82...ced22d035ac0
02:17 < GitHub42> bitcoin/master dfe7906 Matt Corallo: Add missing cs_main lock to ::GETBLOCKTXN processing...
02:17 < GitHub42> bitcoin/master ced22d0 Wladimir J. van der Laan: Merge #8995: Add missing cs_main lock to ::GETBLOCKTXN processing...
02:17 < GitHub156> [bitcoin] laanwj closed pull request #8995: Add missing cs_main lock to ::GETBLOCKTXN processing (master...2016-10-fix-getblocktxn-locks) https://github.com/bitcoin/bitcoin/pull/8995
02:18 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
02:32 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
02:40 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
02:45 -!- gluytium [~g@45.63.97.181] has quit [Quit: IRC (Quit: Not that there is anything wrong with that)]     
03:37 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
03:44 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
03:47 < arubi> wumpus, so specifically re. parsing partial transactions as pre-segwit (#8837), I actually hit this issue in my own toy parser and it shows in core too: http://paste.debian.net/plainh/8c80d8cd  so having some flag would be great
03:47 < wumpus> thanks, so I wasn't being overly paranoid about that
03:48 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
03:48 < arubi> yea those 0 inputs pre segwit are something to think about when fundrawtransaction
03:49 < wumpus> please comment on the issue too
03:49 < wumpus> ah yes :(
03:50 < arubi> well those fivepiece comments are mine :)
03:50 < arubi> I'll copy this comment too
03:57 -!- gluytium [~g@45.63.76.107] has joined #bitcoin-core-dev     
04:01 -!- cdecker [~quassel@2a02:aa16:1105:4a80:2df5:2764:457c:288] has joined #bitcoin-core-dev     
04:01 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
04:04 < wumpus> does anyone care about DecodeBase58 performance? If so, please review/test https://github.com/bitcoin/bitcoin/pull/8736
04:04 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
04:49 < jonasschnelli> during IBD, there is "chainActive" like (CChain) object that contains the headers-only chain?
04:49 < jonasschnelli> *there is no "chainActive"
04:50 < jonasschnelli> It looks like that getchaintips is ripping out the headers-tip from setOrphans
04:54 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:04 < jonasschnelli> nm: I think pindexBestHeader is acceptable for my usecase
05:05 < wumpus> ok :)
05:06 -!- cryptapus_afk is now known as cryptapus     
05:10 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]     
05:11 < jonasschnelli> hmm.. why points pindexBestHeader->pprev to pindexBestHeader?!
05:12 < jonasschnelli> looks like it not traversable
05:12 < jonasschnelli> again... nm! local issue.
05:36 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has joined #bitcoin-core-dev     
05:38 -!- berndj-blackout [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev     
05:39 -!- trippysa1mon [~trippy@cyberdynesys.org] has joined #bitcoin-core-dev     
05:39 -!- Pasha [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
05:40 -!- aj_ [aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev     
05:40 -!- harding_ [~harding@mail.dtrt.org] has joined #bitcoin-core-dev     
05:40 -!- wolfspra1l [~wolfsprau@bobbin.q-ag.de] has joined #bitcoin-core-dev     
05:40 -!- haakonn_ [~haakonn@datapusher.net] has joined #bitcoin-core-dev     
05:42 -!- instagibbs_ [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
05:43 -!- afk11_ [~afk11@79.97.105.226] has joined #bitcoin-core-dev     
05:43 -!- bad_duck [~arthur@area51.powaaa.com] has joined #bitcoin-core-dev     
05:44 -!- laurentmt [~Thunderbi@80.215.210.213] has joined #bitcoin-core-dev     
05:45 -!- Netsplit *.net <-> *.split quits: Guest13412, whphhg, harding, Cory, wolfspraul, instagibbs, aj, haakonn, afk11, kcud_dab,  (+4 more, use /NETSPLIT to show all of them)
05:46 -!- laurentmt [~Thunderbi@80.215.210.213] has quit [Client Quit]     
05:46 -!- Pasha is now known as Cory     
05:51 -!- whphhg [whphhg@gateway/vpn/mullvad/x-oezagxmxbgtvphke] has joined #bitcoin-core-dev     
05:53 -!- BonyM1 [~BonyM-I@ua-83-227-211-4.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev     
05:59 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
06:03 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
06:09 -!- aalex [~aalex@64.187.177.58] has quit [Max SendQ exceeded]     
06:10 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
06:14 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds]     
06:16 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has quit [Quit: Whatever]     
06:18 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
06:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:23 -!- jujumax [~jujumax@200.117.99.162] has joined #bitcoin-core-dev     
06:24 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
06:37 -!- fengling [~fengling@43.255.176.6] has joined #bitcoin-core-dev     
06:41 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
06:48 -!- fengling [~fengling@43.255.176.6] has quit [Ping timeout: 268 seconds]     
07:04 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev     
07:08 -!- berndj-blackout is now known as berndj     
07:19 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev     
07:24 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
07:24 -!- cjcj_ [d4555899@gateway/web/freenode/ip.212.85.88.153] has joined #bitcoin-core-dev     
07:26 -!- dzijeka [~dzijeka@95.215.44.99] has joined #bitcoin-core-dev     
07:34 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev     
07:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:46 -!- bsm1175321 is now known as bsm117532     
08:15 -!- sumit_sethia [0e8becd2@gateway/web/freenode/ip.14.139.236.210] has joined #bitcoin-core-dev     
08:17 -!- sumit_sethia [0e8becd2@gateway/web/freenode/ip.14.139.236.210] has quit [Client Quit]     
08:18 -!- andytosh1 is now known as andytoshi     
08:20 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
08:20 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
08:25 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 245 seconds]     
08:36 -!- Giszmo1 [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
08:42 -!- jujumax [~jujumax@200.117.99.162] has quit [Remote host closed the connection]     
08:45 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
08:49 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
08:56 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
09:25 < BlueMatt> wait, what?
09:25 < BlueMatt> argh, we did break addnode :(
09:26 < sipa> how so?
09:26 < BlueMatt> i was just trying to use it for fibre and the hostname as both ipv4 and ipv6 but it will only try to connect to one resolved addr even though the other one will work
09:27 < sipa> hmm     
09:27 < BlueMatt> i didnt realize we broke the pick-different-address-if-it-doesnt-connect logic :(
09:28 < sipa> i didn't think so either
09:28 < BlueMatt> there doesnt seem to be any handling for it
09:29 < sipa> ConnectSocketByName should pick a random resolved address for each attempt
09:29 < BlueMatt> ThreadOpenAddedConnections does a LooupNumeric before calling OpenNetworkConnection
09:30 < BlueMatt> lol, the client in question doesnt even have a v6 default route...bitcoind was trying (and failing) to connect to the v6 host, it seems :/
09:30 < sipa> and LookupNuumeric will fail if it's not a x.y.z.w or aaaa::bbbb:ccc or .onion style string
09:30 < BlueMatt> ahh     
09:31 < BlueMatt> hmm, maybe they just didnt wait long enough
09:31 < BlueMatt> but it did try to connect to v6, get a network unreachable error, and give up :(
09:32 < sipa> it will only retry 2 minutes later, i think
09:32 < BlueMatt> yes, it did, and tried again to ipv6
09:33 < BlueMatt> though if its random i suppose he could have waited longer and maybe it would have worked
09:33 < BlueMatt> though its possible the hosts ipv6-preference logic is bad?
09:33 < Lightsword> it’s a fairly standard EC2 ubuntu 16.04 VPS
09:34 < sipa> maybe it only resolves to IPv6 addresses for some reason?
09:34 < BlueMatt> Lightsword: can you disconnect the ipv4 peer and just addnode the hostname and wait a few sets of 2 minutes?
09:44 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]     
09:44 < Lightsword> BlueMatt, yeah not seeing any connection
09:44 < Lightsword> 2016-10-24 16:40:07.057232 trying connection us-west.fibre.bitcoinrelaynetwork.org lastseen=0.0hrs
09:44 < Lightsword> 2016-10-24 16:40:07.237914 connect() to [2607:f0d0:2002:169::2]:8333 failed: Network is unreachable (101)
09:45 < BlueMatt> yea, so it seems broken :(
09:46 -!- Squidicc is now known as squidicuz     
09:46 < BlueMatt> argh, someone wanna tag https://github.com/bitcoin/bitcoin/issues/9007 0.13.1?
09:49 < paveljanik> I can't do so, sorry.
09:52 < wumpus> already done
09:53 < wumpus> another assert that should be removed, like 1ab21cf344ed0547de5ae679b7e479cb4b1a923b I guess...
09:53 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev     
09:53 < wumpus> should check there's no other weird asserts added
09:53 < sipa> is 9007 in 0.13?
09:54 < wumpus> yes     
09:56 < wumpus> https://github.com/bitcoin/bitcoin/blob/0.13/src/net.cpp#L1024
09:56 < sipa> ah, caused by feelers?
09:57 < wumpus> yes, maxconnections cannot be lower than maxoutbound+maxfeeler, I suppose if he'd just set maxconnections=9 it'd be ok
09:58 < gmaxwell> addnode can take you beyond the nMaxOutbound count.
09:58 < wumpus> that's not what that assert is checking though
09:59 < wumpus> it doesn't look at your actual connections, just the max possible
09:59 < gmaxwell> ah, indeed.
09:59 < gmaxwell> that should be a return, not an assert, in any case.
09:59  * gmaxwell feels stupid for missing that.
10:04 < gmaxwell> There was another inappropriate assert added in the same commit, but it was already removed by PR 8944.
10:04 < wumpus> well the previous assert based bug was that
10:04 < wumpus> right
10:07 < gmaxwell> sipa: I can't see how that couldn't be reproduced in rc2.
10:10 < gmaxwell> even returning there wouldn't be right.
10:10 < gmaxwell> lets say I set -connect=1.2.3.4 and maxconnections=4 ... I should still be able to accept 3 connections.
10:11 -!- Cheeseo [~x@208.167.254.33] has joined #bitcoin-core-dev     
10:11 -!- Cheeseo [~x@208.167.254.33] has quit [Changing host]     
10:11 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
10:11 < sipa> if you set -connect, isn't listening disabled by default?
10:12 < gmaxwell> its softset off.
10:12 < gmaxwell> so if you -connect + listen=1 to be precise. 
10:13 < sipa> ok     
10:14 < gmaxwell> I was about to suggest that maxconnections<8 should hard force listen off, because then it would make it easier to troubleshoot why things aren't connecting; then realized that no actually in some configs inbounds should still be working even with low max connections.
10:16 < gmaxwell> wait.. what.. is eviction now broken?!
10:18 < gmaxwell> okay, its not, just kind of stupid.
10:20 < gmaxwell> without the insert, the -noconnect + listen=1 case with maxconnections<8 will continually try evicting a connection and fail.
11:02 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Ping timeout: 260 seconds]     
11:06 < morcos> sipa: sorry for the annoying questions here..  it appears to me that the dynamic memory usage tracking in CCoinsViewCache assumes that the memory usage of a pruned coins is 0.  i'm guess this is usually the case, but its not guaranteed right?   (depends on capacity = 0)
11:07 -!- laurentmt [~Thunderbi@80.215.138.202] has joined #bitcoin-core-dev     
11:07 < sipa> morcos: i believe we actually always call CCoins::Cleanup()
11:07 < sipa> which sets the capacity to 0
11:07 < morcos> i was trying to track down some signficant variations between actual usage and the tracked usage that appear in my code.. and am starting by trying to understand why the existing code is correct
11:07 < morcos> well it calls a new vector and swaps
11:08 < sipa> yes, that was the C++03 trick to set the capacity to 0
11:08 < morcos> but from my googling it seems implementation dependent whether a new vector has capacity 0?
11:08 -!- laurentmt [~Thunderbi@80.215.138.202] has quit [Client Quit]     
11:08 < sipa> ok, i agree there is in theory a standard-compliant implementations which doesn't have that behaviour
11:08 -!- cheese_ [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
11:09 < morcos> ok..  i noticed that a while ago.. and its probably not the cause of my problem, but just wanted to understand
11:09 < morcos> second , kind of unrelated question
11:09 < morcos> prevector.resize(0) doesn't seem like the fastest way to clean up a prevector<unsigned char> does it?
11:09 < sipa> the c++11 way is std::vector::shrink_to_fit() btw
11:10 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
11:10 < morcos> looking at the resize code, it calls erase, which iterates the elements destructing them
11:10 < morcos> but in our case where we're always using unsigned chars and we want to clear the whole thing.. couldn't we do that faster?
11:11 < sipa> so there is a question of what prevector should support
11:11 < sipa> if it can only contain POD types, i think more complexity can go away
11:11 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 245 seconds]     
11:12 < sipa> but if it's to be value for any movable c++ type (as it does now), it has to call erase (which may still be optimized out, when instanciated for simple types)
11:12 < sipa> i thought cfields_ was working on some improvements to prevector?
11:12 < cfields_> sipa: one of many things that got to 90% and shelved.
11:13 < sipa> s/erase/destructors/
11:13 < morcos> maybe.. i'm not sure.   seems like it might be nice to at least optimize that one particular case, would we subtemplate or something that particular call.  
11:13 < cfields_> sipa: in particular, I was doing a specialiazation for size=1
11:13 < sipa> yes, in c++11 you can use templates to figure out whether it's POD, and use a simpler implementation in that case or something
11:13 < cfields_> since that's our main use-case, and you can get huge speedups with that assumption
11:14 < morcos> ok..   thanks for the thoughts..  
11:23 -!- dermoth [~thomas@dsl-66-36-159-136.mtl.aei.ca] has quit [Ping timeout: 252 seconds]     
11:31 -!- cjcj_ [d4555899@gateway/web/freenode/ip.212.85.88.153] has quit [Quit: Page closed]     
11:36 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
12:07 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
12:19 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
12:32 -!- roasbeef_ is now known as roasbeef     
12:34 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
12:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]     
13:13 < GitHub49> [bitcoin] MarcoFalke opened pull request #9008: [net] Remove assert(nMaxInbound > 0) (master...Mf1610-netAssert) https://github.com/bitcoin/bitcoin/pull/9008
13:21 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]     
13:22 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev     
13:29 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
13:33 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
13:34 -!- instagibbs_ is now known as instagibbs     
13:38 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
13:48 < btcdrak> https://github.com/bitcoin-core/bitcoincore.org/pull/239
14:04 -!- Alina-malina is now known as alina-malina     
14:09 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke]     
14:24 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]     
14:39 -!- cryptapus is now known as cryptapus_afk     
14:54 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
14:54 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev     
14:54 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host]     
14:54 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
14:58 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 252 seconds]     
14:58 < nibor> Could someone let me know what they think about:  https://gist.github.com/n1bor/d5b0330a9addb0bf5e0f869518883522
14:59 < nibor> Is a functioning proof of concept of chainstate only sync. Syncs in about 30mins to a pruned full node state.
15:00 < nibor> Obviously need a soft-fork to be any use.
15:08 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 258 seconds]     
15:09 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
15:10 < gmaxwell> nibor: it's more frequent than the model I've been thinking of. For security reasons you really don't want to have a case where miners could make a 100 block fork and then forward print themselves a lot of coins. :)  Also it's quite common for nodes to be offline for 1-2 weeks, so if nodes aren't keeping that much in blocks easily available, then security redegrades to SPV history (new chainstat
15:10 < gmaxwell> e sync). ... and downloading and syncing a few thousand blocks isn't really slow compared to 100 (relative to current sync times).
15:10 < gmaxwell> This is all particular relevant because the snapshot management means that different peers really can't choose their own checking time.
15:10 < gmaxwell> I'd been thinking of something that was more like a 3 month interval.
15:11 < gmaxwell> Petertodd will protest that requring a particular UTXO set construction will be a hard barrier to even more scalable things like STXO commitments in the future.  I came up with a solution to that which you might want to use:
15:12 < gmaxwell> Two softfork rules: (1) if the commitment is present, it must be correct. and (2) the commitment must be present from activation until block XXX.   If halfway to XXX everyone is still happy with the scheme, a new softfork is applied that says the commitment must be presnet until YYY.
15:12 < gmaxwell> That way if someothing better comes along, the commitment can eventually be dropped in a smooth and compatible manner.
15:13 < gmaxwell> (perhaps making new installs of old software take a long time to sync :) )
15:14 < gmaxwell> nibor: the hash chunking thing should use some kind of tree hash, it probably doesn't need to go down to the indivigual entry, but if I fetch chunks from N peers in parallel and one peer gives me garbage, I should be able to tell _which_ peer gave me garbage, otherwise you get DOS attacks.
15:15 < nibor> Could not see how tree helped. The snapshot message contains hash of all the chunks. So you know if a node is nasty after the 1st chunk.
15:16 < gmaxwell> okay, that potentially makes the snapshot message quite large, the only difference that a tree would make is that the snapshot value is just the single hash in the blockchain, and the chunks give you enough to verify membership.
15:17 < nibor> Regarding gap between snapshots problem with going too long is that the chainstate grows quite fast. Keeping snapshot from 300 blocks back makes chainstate 2.4G vs 1.7G with no snapshots.
15:17 < gmaxwell> The other important thing about this proposal is that it needs to be very upfront about this being a signficant change to the Bitcoin security model, and justify it.  I believe it is a nessary one.
15:18 < gmaxwell> We generally need to engineer for the worst case, so we should probably just assume that they're maximum size even though fancy COW handling could reduce that.
15:18 < nibor> Current snapshot message is about 200k and chunks are about 200k each. So msgs small so should scale by factor of 10..
15:18 < gmaxwell> reorginizing chainstate into 'old' and 'new' could help with that churn fwiw.
15:19 < nibor> Annoyingly the leveldb snapshots are only held in RAM. So with a big gap node would really need to do a bit rewind to check state.
15:19 < gmaxwell> yea, I was surprised you got this working using leveldb snapshots.
15:20 < nibor> s/bit/big/
15:20 < nibor> Not sure I understand your 1st comment though. About miners creating big fork?
15:21 < gmaxwell> no rewind should be needed however, you should compute the hash as it goes by, e.g. snapshot at the height as you validate it, then at two blocks after, start computing the hash, and just save it.
15:22 < nibor> Sorry - yes you are right. Was thinking of putting hash 20 blocks after chainstate. So have time to compute even when chainstate say 50gig.
15:22 < gmaxwell> (50 gb chainstate is likely unworkable with leveldb :(  but thats an aside. :) )
15:23 < nibor> Prob ok with 64Gig RAM... In day job just order 2 boxes with 2Tb so not so much..
15:23 < gmaxwell> nibor: majority hashpower can make their new commitment say that a million bitcoin that wasn't theirs is now theirs. Then all newly joining nodes will get the new chainstate, and eventually all old nodes will think they've hit a reorg larger than people have blocks available, and so they'll do a chainstate sync too... 
15:24 < gmaxwell> nibor: we'd like to have a decenteralized system you know, :P 
15:26 < nibor> With a 100gig download?...
15:26 < gmaxwell> nibor: did you understand my "phase out" suggestion? (the line refereincing petertodd)
15:27 < gmaxwell> nibor: more people handle a 100 GB download today than have more than 8GB ram available. (in particular hosted systems, VPSes, are often quite ram starved) but we're on a tangent.
15:28 < nibor> Not sure I do.. but might in a bit...
15:29 < gmaxwell> OKAY.
15:29 < gmaxwell> In any case, exciting work
15:29 < gmaxwell> Your POC is awesome.
15:29 < nibor> Thinking about a 3month interval. That is quite easy. Just copy the whole chainstate to another leveldb. Is not more work than hashing it really.
15:29 -!- murch [~murch@p4FE386AB.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
15:30 < gmaxwell> Or not another leveldb but just a seralized flat blob. 
15:30 < gmaxwell> It would be faster and more space efficient. And random access is not needed, except to chunks.
15:30 < gmaxwell> (could be one file per chunk. Though 8000 chunks is a bit excessive for that.) 
15:31 < nibor> Not really - leveldb is up to 1000 files.
15:31 < gmaxwell> I believe that only needs two snapshots at any time too... 
15:32 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
15:32 < nibor> Yes - I only had 3 cos was short gap. And did not want a client that took over 100 blocks to download be left with nothing to find.
15:33 < nibor> Will think about Petertodd issue to. Is nasty to cause future issues.
15:34 < nibor> I guess some of the 100fork issues would be reduced if client back populated blocks over time.
15:34 < gmaxwell> There is a longer term proposal that would eliminate the utxo set, effectively, that we don't want to block.
15:34 < gmaxwell> nibor: yes, though if we just want the fastest possible start, it could start immediately as SPV, and then back populate.. irrespective of the snapshotting behavior.
15:36 < nibor> Thanks for thoughts... am off now. Will see what others think..
15:36 < gmaxwell> (just as background for you: the way the utxo set is eliminated, is that there is a small, perhaps fixed size utxo set, and transactions are expired out of it and commited into an insertion ordered hash tree... then when spending one of those outputs the spending transaction must provide a membership and update proof that lets nodes verify it was there and mark the entry as spent)
15:36 < gmaxwell> Great!
15:38 < murch> Hey gmaxwell, I was missing you at Scaling Bitcoin. :)
15:39 < murch> I was curios what you'd say about my coin selection talk after we had chatted here about it.
15:46 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
15:48 < gmaxwell> molz: I was sad to see that wider-match only made a fairly modest improvement!
15:49 < sipa> s/molz/murch/
15:49 < gmaxwell> oops!
15:49 < gmaxwell> murch:
15:49 < molz> haha i was scratching my head "what's the wider-match" lol 
15:49 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
15:50 < murch> gmaxwell: After Scaling Bitcoin I came up with a new algorithm. I'm still running experiments on it (and writing my evaluation chapter, thesis is due next week), but it looks pretty promising in all aspects.
15:50 < molz> gmaxwell, btw, is there a way to load the ban list into my node or do i have to type each line manually?  
15:50 < murch> It has a much higher rate of direct matches than the current core coin selection and is less computationally expensive.
15:50 < sipa> molz: they're remembered across restarts already
15:50 < sipa> bans.dat
15:51 < gmaxwell> murch: one thing your framework doesn't consider is patalogical cases, in the past, people actually attacked litecoin wallets by paying them lots of dust, with enough of it, the subset sum solver would come up with solutions so bad that it couldn't transact.
15:51 < molz> sipa but i haven't banned any bad nodes
15:51 < gmaxwell> They 'solved' this in a really kludgy way just making the wallet ignore payments below a dust threshold.
15:51 < gmaxwell> molz: just paste the lines in a sutiable format.
15:52 < molz> yea i meant copy and paste, ok thanks 
15:52 < gmaxwell> murch: so I think SRD would suffer badly from that.  But I think that could be addressed by trying multiple strategies and taking the 'best'.
15:52 < gmaxwell> molz: I put up pastbins with the commands in cli format as well as sutiable for pasting into the debug console..
15:52 < murch> gmaxwell: Yeah, that's true. My new algorithm uses a two phase approach. First it purposefully looks for direct matches. It will not consider inputs there that have a negative payload (more fees than value), but after that it falls back to random selection, which may spend small inputs over time.
15:53 < murch> (Experiment is still running, can't give you good details on the final set composition yet)
15:54 < gmaxwell> By direct matches, you mean no change created--but possible 'extra fee', not one-input only, right?
15:54 < murch> gmaxwell: yeah, that
15:54 < gmaxwell> Good! sounds reasonable to me.
15:54 < gmaxwell> Then again lots of things that didn't work sounded reasonable to me.
15:55 < murch> Since a change output causes an additional output on creation, then an additional input some time in the future. So I allow up to the cost of one input + one output as a padding for the "exact" match.
15:56 < murch> gmaxwell: Is a "flood with dust" attack still reasonable? I thought that transactions with dust outputs are considered non-standard and they'd have a hard time getting confirmed?
15:56 < gmaxwell> Good, that is a rational way to set it. (arguably, even more would be justified either on the basis of of fees being higher in the future, or on the basis of that you may get faster confirmation for it... but your approach sounds reasonably conservative)
15:57 < gmaxwell> murch: That particular one, perhaps less so (well a miner could do it fine)-- but I meant it more of a concrete example that patalogical cases could be created and it is desirable if the wallet doesn't behave badly in any situation easily setup by an attacker.
15:58 < murch> mh.     
15:58 < murch> I haven't considered that attack scenario too much yet.
15:58 < gmaxwell> e.g. if you have one 50 btc input and 200 0.00001 inputs (still above dust threshold!) ... then the random selection would pick a pretty bad solution.
15:58 < murch> I was thinking to replace the SDR fall back with 7 random drawings and the median input set size
15:58 < murch> or some similar scheme
15:59 < gmaxwell> (er my example just now should have also said "and you try to pay 1 btc")
15:59 < murch> random drawing should have nice privacy properties though, and generates a wider range of utxos which are beneficial for finding direct matches
15:59 < murch> gmaxwell: Yes, of course.
16:00 < gmaxwell> I agree, well you don't have data for it too, but I think all cases the selection should try to spend all inputs paid to a particular scriptpubkey to limit linkage graph inflation, but that can be layered right on top of your ideas by treating a input set as an input. 
16:00 < murch> exactly
16:01 < murch> I'm planning to put addresses in my simulation in the future, but right now I'm focusing on writing up what I have. ;)
16:01 < murch> I have to print next wednesday. :D
16:01 < murch> gmaxwell: https://github.com/Xekyo/CoinSelectionSimulator/blob/master/src/BnBWallet.scala#L59
16:01 < murch> This is the new algorithm I have come up with, in case you want to take a look
16:02 < murch> gmaxwell: some preliminary results on the same data set I talked about at Scaling Bitcoin: https://docs.google.com/spreadsheets/d/1dzugGnAw2nBNL_BwpFR44jci8rO3RkkF5M9OcP2ESN0/pubhtml
16:02 -!- jujumax [~jujumax@200.117.99.162] has joined #bitcoin-core-dev     
16:03 < murch> the perpetrator is "BranchAndBoundWallet"
16:04 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev     
16:04 < murch> What I also like is that it has a very low standard deviation in the input set. (Although, as you have pointed out, I have not considered pathological cases yet.)
16:07 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 260 seconds]     
16:07 -!- michagogo [uid14316@wikia/Michagogo] has quit [Ping timeout: 245 seconds]     
16:08 -!- cdecker [~quassel@2a02:aa16:1105:4a80:2df5:2764:457c:288] has quit [Ping timeout: 250 seconds]     
16:10 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 256 seconds]     
16:13 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev     
16:14 -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev     
16:15 -!- jujumax [~jujumax@200.117.99.162] has quit [Ping timeout: 248 seconds]     
16:24 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev     
16:24 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
16:30 -!- tulip [uid192128@gateway/web/irccloud.com/x-zsjmdpicvqwkknod] has quit [Quit: Connection closed for inactivity]     
16:38 -!- gijensen [~gijensen@gijensen.xyz] has quit [Ping timeout: 256 seconds]     
16:42 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Quit: ZNC - http://znc.in]     
16:42 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev     
16:42 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
16:43 -!- gijensen92 [~gijensen@gijensen.xyz] has joined #bitcoin-core-dev     
16:44 -!- Netsplit *.net <-> *.split quits: nickler_, squidicuz, whphhg, GreenIsMyPepper, [b__b], eragmus, haakonn_, gmaxwell, mappum, CodeShark,  (+3 more, use /NETSPLIT to show all of them)
16:44 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection]     
16:44 -!- Netsplit over, joins: PaulCapestany, CodeShark, eragmus, neha, gmaxwell, [b__b], nickler_, squidicuz, whphhg, haakonn_ (+2 more)
16:44 -!- Netsplit over, joins: GreenIsMyPepper
16:44 -!- Arnavion3 [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev     
16:44 -!- gijensen92 is now known as gijensen     
16:44 -!- Arnavion3 is now known as AtashiCon     
16:46 -!- zmanian____ [sid113594@gateway/web/irccloud.com/x-qqujesaelcdtohed] has quit [Remote host closed the connection]     
16:50 -!- zmanian____ [sid113594@gateway/web/irccloud.com/x-abzjglpinuplmtdd] has joined #bitcoin-core-dev     
17:02 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
17:02 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer]     
17:07 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
17:10 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
17:12 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Ping timeout: 265 seconds]     
17:20 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 245 seconds]     
17:20 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
17:29 -!- murch [~murch@p4FE386AB.dip0.t-ipconnect.de] has quit [Remote host closed the connection]     
17:29 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
17:29 -!- nickler_ [~nickler@185.12.46.130] has quit [Ping timeout: 245 seconds]     
17:30 -!- alpalp [~allen@2605:6000:f4d6:d600:275c:538f:fa83:370b] has joined #bitcoin-core-dev     
17:30 -!- alpalp [~allen@2605:6000:f4d6:d600:275c:538f:fa83:370b] has quit [Changing host]     
17:30 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
17:33 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 250 seconds]     
17:43 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 260 seconds]     
17:49 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
17:52 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
18:03 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
18:06 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
18:27 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev     
18:36 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
19:02 -!- jujumax [~jujumax@200.117.99.162] has joined #bitcoin-core-dev     
19:04 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
19:04 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has left #bitcoin-core-dev []     
19:29 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 260 seconds]     
19:31 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
19:35 -!- brg444 [415ce2de@gateway/web/freenode/ip.65.92.226.222] has joined #bitcoin-core-dev     
19:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]     
19:37 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev     
19:37 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host]     
19:37 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
19:41 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 256 seconds]     
19:48 -!- tulip [uid192128@gateway/web/irccloud.com/x-yixvcbjnvzvdknir] has joined #bitcoin-core-dev     
19:51 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
20:07 -!- fengling [~fengling@223.223.187.136] has quit [Quit: WeeChat 1.5]     
20:23 -!- DigiByteDev [~JT2@101.78.224.202] has joined #bitcoin-core-dev     
20:32 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
20:55 -!- jujumax [~jujumax@200.117.99.162] has quit [Remote host closed the connection]     
20:57 -!- brg444 [415ce2de@gateway/web/freenode/ip.65.92.226.222] has quit [Ping timeout: 260 seconds]     
20:58 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]     
21:01 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
21:56 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Ping timeout: 265 seconds]     
21:56 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 256 seconds]     
21:56 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds]     
21:57 -!- DigiByteDev [~JT2@101.78.224.202] has quit [Quit: DigiByteDev]     
21:58 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
21:58 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev     
21:58 -!- zxzzt [~prod@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
21:58 -!- morcos [~morcos@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev     
22:00 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
22:19 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
22:38 < GitHub169> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ced22d035ac0...67728a389ccf
22:38 < GitHub169> bitcoin/master 3421e74 unsystemizer: Clarify `listenonion`...
22:38 < GitHub169> bitcoin/master 67728a3 Wladimir J. van der Laan: Merge #9004: Clarify `listenonion`...
22:38 < GitHub2> [bitcoin] laanwj closed pull request #9004: Clarify `listenonion` (master...patch-3) https://github.com/bitcoin/bitcoin/pull/9004
22:44 -!- jacurn [~justin@47.148.176.74] has quit [Remote host closed the connection]     
22:51 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]     
22:52 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev     
22:54 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Read error: Connection reset by peer]     
22:59 < luke-jr> can someone reopen https://github.com/bitcoin/bitcoin/pull/8775 ? the other PR had only a tiny part of it.. (ping wumpus)
23:00 < luke-jr> thanks
23:00 < GitHub15> [bitcoin] laanwj reopened pull request #8775: RPC refactoring: Never access wallet directly, only via new CRPCRequestInfo (master...multiwallet_prefactor_rpc) https://github.com/bitcoin/bitcoin/pull/8775
23:02 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
23:21 < jonasschnelli> wumpus: what do you think about 10.8 as min OSX version for core?
23:22 < wumpus> hehe
23:23 < wumpus> sorry, have to laugh after how difficult it has turned out to deprecate 32-bit windows version, or windows XP for that matter. OSX is so different in that regard, no one cares about old versions support
23:23 < jonasschnelli> Heh. Yes. Thats somehow true...
23:23 < jonasschnelli> Though, the original 10.7 bug was reported in #bitcoin
23:24 < jonasschnelli> I guess some users are still on 10.7 for some server-based OSX systems
23:24 < wumpus> "things break all the time on 10.x and no one notices" "if a tree falls..."
23:24 < jonasschnelli> We can reduce the tree-falling risks by setting 10.8 as min OSX.
23:24 < jonasschnelli> Also, we could get rid of some warnings
23:25 < jonasschnelli> I mean we only speak about the official binaries... I guess self-compile should still work fine on OSX
23:25 < sipa> when was 10.7 released?
23:25 < wumpus> so that'd be for 0.14.0 I guess
23:25 < jonasschnelli> IF we do a rc3, then we could add it there
23:25 < jonasschnelli> But no 0.13.1 rc just because of that issue
23:26 < wumpus> in any case I don't really want to have an opionion about this: if there's anyone willing to fix problems that come up with 10.7, I'll merge them and keep supporting
23:26 < sipa> 10.7 is 5 years old
23:26 < jonasschnelli> sipa: i'm looking... I guess 2-3 years
23:26 < sipa> july 2011
23:26 < wumpus> if not, well, too bad then
23:26 < jonasschnelli> Okay. I'll work on a patch... 
23:27 < jonasschnelli> Well... we could still build against 10.7 but set 10.8 as min osx runtime version... but that would be pretty bad
23:27 < wumpus> I didn't mean 'you should fix this now'
23:27 < sipa> windows 7 is already much older than osx 10.7
23:27 < jonasschnelli> "I'm working on a patch" could result in a work-duration of couple of month . :)
23:28 < sipa> haha
23:28 < jonasschnelli> First finishing the SPV hybrid mode
23:29 < sipa> sounds like a 5 year plan
23:29 < jonasschnelli> hah     
23:29 < jonasschnelli> It's already working... but that probably 5% of the work.
23:29 < wumpus> sipa: yes, it's weird, you can't really compare windows and OSX users in that regard, windows users love their old versions, macosx users upgrade both hardware and software when they can
23:30 < jonasschnelli> sipa: I'm not sure how we could reuse blocks (lets say around the tip) to be reused once they where downloaded (without connecting the tip).
23:31 < wumpus> I've yet to see any exceptions to this, well there are a few that truly like windows 10 better than the previous versions, but there's always a reluctance to upgrading
23:31 < luke-jr> pretty sure my father is still using hardware incapable of 64-bit <.<
23:31 < sipa> luke-jr: use qemu :p
23:31 < sipa> jonasschnelli: i don't understand
23:31 < luke-jr> sipa: does qemu support XP? :P
23:32 < sipa> wumpus: microsoft has the world's worst customer base. mostly corporate machines whose maintainers don't like change :)
23:32 < jonasschnelli> sipa: I'm downloading blocks - required for SPV, have a modified AcceptBlock() (no tip update), that stores the block with WriteBlockToDisk(),... but I guess the validation-part does not check if blocks are stored on disk?
23:33 < jonasschnelli> they always re-download the required blocks
23:33 < jonasschnelli> s/they/it
23:33 < sipa> jonasschnelli: there is no validation in SPV mode
23:33 < jonasschnelli> sipa: there is in hybrid...
23:34 < sipa> what do you mean by hybrid?
23:34 < jonasschnelli> I have now a state where i have some random non-validated blocks (around the tip) used for SPV that are stored on my disk...
23:34 < jonasschnelli> the full-node part could once reuse those already downloaded blocks
23:34 < wumpus> sipa: btw re: 8753, are you sure comparing void* pointers with greater/lesser is defined behavior? I'm fairly sure but...
23:34 < wumpus> C has so many scary edge cases there
23:35 < jonasschnelli> but how-every,... hard to explain,... i'll show you some code sipa during the next days/weeks
23:35 < luke-jr> jonasschnelli: I don't get the purpose?
23:35 < sipa> 6.5.8 Relational operators
23:35 < sipa> 5 When two pointers are compared, the result depends on the relative locations in the address space of the objects pointed to. If two pointers to object types both point to the same object, or both point one past the last element of the same array object, they compare equal. If the objects pointed to are members of the same aggregate object, pointers to structure members declared later compare greater than pointers to members declared earlier...
23:35 < sipa> in the structure, and pointers to array elements with larger subscript values compare greater than pointers to elements of the same array with lower subscript values. All pointers to members of the same union object compare equal. If the expression P points to an element of an array object and the expression Q points to the last element of the same array object, the pointer expression Q+1 compares greater than P. In all other cases, the...
23:35 < sipa> behavior is undefined.
23:35 < jonasschnelli> The idea is, you start your IBD, but in parallel, you download blocks down to your wallet-birthday and do SPV-ismine check with these
23:36 < jonasschnelli> these downloaded blocks can later be used for the validation-full-node part
23:36 < sipa> jonasschnelli: that's no different from how block fetching works today
23:36 < sipa> jonasschnelli: we often have unvalidated blocks ahead of the point we're fully synced to
23:36 < wumpus> so this would compare pointers in different arenas, which can be seen as different "arrays"
23:37 < sipa> wumpus: ah, i guess...
23:37 < luke-jr> sipa: I think he means you'd download blocks from the other end
23:37 -!- RoyceX [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
23:38 < luke-jr> (in order to scan them for unconfirmed transactions)
23:38 < sipa> well if you combine it with pruning you wouldn't keep the blocks on disk downloaded for SPV
23:38 < luke-jr> indeed
23:38 < sipa> which makes things much easier
23:38 < jonasschnelli> Yes. With pruning...
23:38 < jonasschnelli> I think i'll start with not keeping these blocks for now.
23:39 < jonasschnelli> But it would be a nice use case for full-block SPV (if pruning is disabled)
23:39 < jonasschnelli> Because you need the blocks anyways.
23:39 < luke-jr> IMO the more valuable SPV-hybrid mode is one where cellular data isn't wasted on downloading full blocks ;)
23:41 -!- niska [~niska@68.ip-149-56-14.net] has joined #bitcoin-core-dev     
23:42 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 265 seconds]     
23:42 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 265 seconds]     
23:42 -!- cheese_ [~x@unaffiliated/cheeseo] has quit [Ping timeout: 265 seconds]     
23:42 -!- niska` [~niska@68.ip-149-56-14.net] has quit [Ping timeout: 265 seconds]     
23:42 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Ping timeout: 265 seconds]     
23:42 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev     
23:43 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev     
23:43 < wumpus> sipa: but one'd hope that "the result depends on the relative locations in the address space of the objects pointed to" is stil true in every case
23:44 < sipa> wumpus: well, the last sentence is that anything else is undefined behaviour. So the compiler may delete your wallet.dat in that case.
23:44 < wumpus> welcome to adversarial compiler design 101 :)
23:51 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev     
23:51 < sipa> and conversion of pointer to int is implementation defined, but must be convertable back to a valid pointer if the integer is large enough
23:51 < sipa> so your solution seems perfectly fine
23:51 < wumpus> I'll just keep it as it is then, thanks
23:51 < sipa> actually, i don't know if the mapping from pointer to integer is required to keep continuous ranges continuous :)
23:51 < wumpus> "     
23:51 < wumpus> "Ok, bad news. I ended up in the bowels of osx"
23:51 < wumpus> poor cfields_ 
23:51 < sipa> did he come across a digest function?
23:51 < wumpus> sipa: I'm not sure that is required either, outside arrays. But think I wrote the code in a way in which that doesn't matters, as long as the different ranges are disjunct, it's just a membership test after all
23:52 < sipa> wumpus: if the pointers inside the arena's memory range are not mapped to a continuous set of uintotrs, your membership test won't work
23:52 < sipa> *uintptrs
23:52 < wumpus> but that wouldn't make sense as the arena is allocated at once, so it needs to be a linear area
23:52 < sipa> the pointers need to be linear
23:53 < sipa> the integers they map to do not
23:53 < wumpus> or at least monotonic, linear isn't even necessary
23:59 < sipa> of course, in any compiler below adversialness level 7, this will be the case
23:59 < wumpus> hehe, phew, so that's still safe for ~5 years then
23:59 < sipa> the question is really whether you can do pointer arithmetic by converting to uintptr, doing the arithmetic (multiplied the the pointer type's size), and converting back
23:59 < sipa> i don't know whether the standard requires that
23:59 < sipa> if not, the cast to uintptr could for example bitflip the result or so
23:59 < sipa> or switch the bit or byte order