1 2015-01-08 01:51:30 <earlz> bleh no 0.10RC2 yet :(
  2 2015-01-08 01:52:06 <earlz> I assume when it is built, it'll come out of the 0.10 branch right?
  3 2015-01-08 01:52:15 <sipa> yes
  4 2015-01-08 01:52:25 <earlz> and master will eventually be 0.11
  5 2015-01-08 01:52:54 <earlz> is there anywhere discussing the changes and issues with 0.10?
  6 2015-01-08 01:55:44 <sipa> github.com/bitcoin/bitcoin/issues :)
  7 2015-01-08 01:56:02 <earlz> I meant something for 0.10 specifically though
  8 2015-01-08 01:56:12 <sipa> you can report issues specifically with 0.10 there
  9 2015-01-08 02:08:05 <denisx> is there a changelog for 0.10 already?
 10 2015-01-08 02:09:46 <sipa> see the release notes
 11 2015-01-08 02:11:00 <sipa> https://github.com/bitcoin/bitcoin/blob/0.10/doc/release-notes.md
 12 2015-01-08 02:31:01 <ursar> hola:)
 13 2015-01-08 02:53:57 <nub33> hi
 14 2015-01-08 02:54:42 <nub33> I have one small question.  Is there any way theoretically to do anything resembling cascascius coins that you can have in your possession after someone else had possession of them, and still somehow know that you (then) exclusively control possession over whatever is represented?
 15 2015-01-08 02:55:11 <nub33> meaning like physical possession and trade-ability, just like real-world dollars.  (the fact that ten people held your dollar before you hold it doesn't mean you can just lose its value while it's safe in your possession)
 16 2015-01-08 02:55:35 <nub33> it can be swapped, etc.  Is there any theoretical basis for anything like that is possible?  (perhaps with verification from a server, whatever).  any crazy schemes you can think of?
 17 2015-01-08 03:49:57 <justanotheruser> nuttycom: probably not without trusting the issuer
 18 2015-01-08 07:40:15 <michagogo> nub33: well, look at the Casascius coins. There are two elements that need to exist for something like that to work.
 19 2015-01-08 07:40:53 <michagogo> First, you need to trust whoever's issuing/creating them, to keep the privkeys safe, forget them, etc
 20 2015-01-08 07:42:39 <michagogo> Then you need to trust that the tamper evidence is strong enough -- that is, that you can inspect the token and know with high confidence that nobody has been able to access the key within since it was sealed, and that it was sealed by the issuer
 21 2015-01-08 07:43:42 <justanotheruser> michagogo: while you're trusting the issuer, why not just have the issuer hold the private key and make the note counterfeit resistant rather than have it include the private key?
 22 2015-01-08 07:44:37 <michagogo> justanotheruser: Hm? Because that probably makes it harder to redeem
 23 2015-01-08 07:45:04 <michagogo> Also, that requires constant trust and security against future attacks on the isduer
 24 2015-01-08 07:45:09 <michagogo> Issuer*
 25 2015-01-08 07:45:54 <justanotheruser> That's true, but making a note both counterfeit resistant and tamper resistant is probably harder than just making it counterfeit resistant
 26 2015-01-08 07:45:59 <michagogo> With something like Casascius coins, you only need to trust the conditions of creation
 27 2015-01-08 07:46:14 <justanotheruser> And trust that it isn't a counterfeit
 28 2015-01-08 07:46:19 <michagogo> And that can be documented, audited, monitored, etc
 29 2015-01-08 07:46:20 <justanotheruser> and trust that it hasn't been tampered iwth
 30 2015-01-08 07:46:57 <michagogo> And once it's out, Mike can't be hacked or broken into or coerced into taking the funds back
 31 2015-01-08 07:47:12 <michagogo> justanotheruser: yeah, both ways do have tradeoffs
 32 2015-01-08 07:47:50 <michagogo> Iirc Casascius uses (used?) very good holographic seals
 33 2015-01-08 07:48:41 <justanotheruser> Yeah, counterfeit resistant notes are probably not feasable
 34 2015-01-08 07:48:43 <michagogo> (In fact, they were so sensitive that iirc a whole bunch were ruined in the process of trying to apply them)
 35 2015-01-08 07:49:02 <michagogo> Ah
 36 2015-01-08 07:49:11 <justanotheruser> So maybe doing it your way is better, but I don't think either way is good :P
 37 2015-01-08 07:49:19 <michagogo> Yeah, notes are probably harder to do well than coins
 38 2015-01-08 07:50:03 <michagogo> justanotheruser: right, I'm not arguing that having those tokens is necessarily always a good idea
 39 2015-01-08 07:50:13 <justanotheruser> Once they hit a certain volume, it becomes cost effective to reverse engineer them and make a ton.
 40 2015-01-08 07:50:38 <justanotheruser> I wonder how amish people will use bitcoin
 41 2015-01-08 07:50:40 <michagogo> But there are different ways to do something like that, each with their own pros and cons.
 42 2015-01-08 07:51:34 <michagogo> Also, there *are* some pretty good counterfeit-resistant notes out there
 43 2015-01-08 07:52:00 <michagogo> But the ability to make notes like that tends to be very restricted
 44 2015-01-08 07:52:21 <michagogo> (To avoid counterfeiting of the ones already existing :P )
 45 2015-01-08 08:26:11 <wumpus> justanotheruser: blockchains writtten on stacks of paper, carted by horse?
 46 2015-01-08 08:28:30 <justanotheruser> wumpus: yes, every town can have a guy on a soap box acting as a full node announcing spv proofs to towngoers
 47 2015-01-08 08:30:54 <wumpus> sounds good to me
 48 2015-01-08 09:13:23 <wumpus> cfields: how's the trivial tree going?
 49 2015-01-08 09:14:16 <wumpus> cfields: I think #5614 #5602 #5527 apply
 50 2015-01-08 09:15:24 <wumpus> cfields: also #5497, although it will be harder to rebase as it touches almost the entire source (but only strings, at that)
 51 2015-01-08 09:16:15 <wumpus> cfields: #5469 also
 52 2015-01-08 09:39:58 <paveljanik> wumpus, #5497 can be redone almost automatically with a script...
 53 2015-01-08 09:47:50 <wumpus> paveljanik: ok, that's great, so running that script can be part of the trivial merge/rebase
 54 2015-01-08 09:55:50 <fanquake> Can 5616 be squashed into a single commit?
 55 2015-01-08 10:11:57 <wumpus> fanquake: depends on whether and how much the changes overlap
 56 2015-01-08 10:12:39 <wumpus> as all three touch db.h and walletdb.h, I'd say yes
 57 2015-01-08 10:13:25 <wumpus> one  the other hand, e.g. the constness commit is clearly a separate logical change
 58 2015-01-08 10:13:53 <wumpus> so a bit of a grey area, I'm fine with it as three commits as well
 59 2015-01-08 10:22:23 <fanquake> wumpus Yea was just wondering. One of the commits only removes two lines. Seems to be a slight influx of small/trivial commits.
 60 2015-01-08 10:22:43 <fanquake> (in general)
 61 2015-01-08 10:25:09 <wumpus> yes, maybe this belongs in the trivial tree, I don't know - it does affect code and not just documentation/comments/strings
 62 2015-01-08 10:25:29 <wumpus> I like the const-correctness commit
 63 2015-01-08 10:26:19 <wumpus> the other two could be squashed/or even go with other changes into the trivial tree
 64 2015-01-08 10:28:50 <wumpus> but I don't think it's worth micro-managing this too much
 65 2015-01-08 10:31:55 <fanquake> wumpus sure. I guess it can be easier to just merge trivial changes quickly to keep the # of pull requests under control.
 66 2015-01-08 10:31:55 <wumpus> (changing the consts actually results in slightly different code, although the executable ends up the same size)
 67 2015-01-08 10:32:46 <wumpus> the really trivial changes should be merged quickly into the trivial tree
 68 2015-01-08 10:33:05 <wumpus> which would aggregate them for a while
 69 2015-01-08 10:33:36 <fanquake> How soon are you planning on cutting rc2?
 70 2015-01-08 10:34:30 <wumpus> https://github.com/bitcoin/bitcoin/pull/5608 still needs ACKs
 71 2015-01-08 10:36:16 <wumpus> also there is #5588 #5462 which need at least a trivial fix for 0.10
 72 2015-01-08 11:20:30 <fanquake> wumpus Can close #5609 & #5593
 73 2015-01-08 11:20:39 <wumpus> fanquake: thanks
 74 2015-01-08 11:25:56 <paveljanik> michagogo, [skip ci]: do you care enough to add a note to developer-notes.md?
 75 2015-01-08 11:26:08 <michagogo> I could do that
 76 2015-01-08 11:27:49 <michagogo> paveljanik: hm, there isn't anything there about Travis
 77 2015-01-08 11:28:25 <michagogo> Oh, wait
 78 2015-01-08 11:28:30 <michagogo> there's travis-ci.txt
 79 2015-01-08 11:29:12 <michagogo> Hm. Idk if there's really a good place to do that
 80 2015-01-08 11:29:44 <michagogo> I feel like it would fit in somewhere talking about Travis, and/or somewhere talking about trivial changes
 81 2015-01-08 11:29:57 <michagogo> But there doesn't really seem to be any good place for it
 82 2015-01-08 11:30:09 <michagogo> travis-ci.txt seems to just be general information about it
 83 2015-01-08 11:30:09 <wumpus> the place for that would be the developer notes I suppose
 84 2015-01-08 11:30:20 <michagogo> Not really tips or tricks or instructions or guideline
 85 2015-01-08 11:30:21 <michagogo> s
 86 2015-01-08 11:30:24 <wumpus> I don't think anyone will check travis-ci.txt for that
 87 2015-01-08 11:30:38 <fanquake> michagogo you could put it under development process in the line about trivial changes
 88 2015-01-08 11:30:46 <fanquake> in readme.md in root
 89 2015-01-08 11:31:31 <fanquake> Although it doesn’t quite fit there.
 90 2015-01-08 11:32:56 <michagogo> hm, it's confusing that we have a /README.md and a /doc/README.md
 91 2015-01-08 11:33:21 <wumpus> README.mds are picked up automatically by github and shown rendered when you're in the directory
 92 2015-01-08 11:33:31 <wumpus> so having them at multiple levels makes sense
 93 2015-01-08 11:33:33 <michagogo> Ah.
 94 2015-01-08 11:33:34 <michagogo> Right.
 95 2015-01-08 11:37:40 <fanquake> Looks like #5143 broke the tests. test/script_tests.cpp:526: error in "script_build": Missing auto script_valid test: P2PK with unnecessary input but no CLEANSTACK
 96 2015-01-08 11:38:15 <wumpus> curious - it was passing travis
 97 2015-01-08 11:39:49 <wumpus> looks like a json file has to be updated
 98 2015-01-08 11:54:26 <wumpus> see https://github.com/bitcoin/bitcoin/pull/5617
 99 2015-01-08 12:13:06 <jonasschnelli> what are the recommended steps to build bitcoin-qt for windows? This: https://bitcointalk.org/index.php?topic=149479.0 ?
100 2015-01-08 12:14:08 <wumpus> jonasschnelli: gitian
101 2015-01-08 12:14:16 <wumpus> or rather, cross-compile using depends
102 2015-01-08 12:14:26 <fanquake> #5617 is good
103 2015-01-08 12:15:02 <wumpus> e.g. cd depends; make HOST=i686-w64-mingw32; cd ..; ./configure --prefix=`pwd`/depends/i686-w64-mingw32
104 2015-01-08 12:15:28 <wumpus> that builds the depends for win64, and configures bitcoin against it, then do a make and you'll have the .exes
105 2015-01-08 12:16:21 <fanquake> jonasschnelli See also https://github.com/bitcoin/bitcoin/issues/1401
106 2015-01-08 12:19:30 <jonasschnelli> thanks
107 2015-01-08 12:22:53 <michagogo> wumpus: ah, so when you give configure the prefix it infers the build target from there?
108 2015-01-08 12:23:16 <michagogo> (I know that configure has an option to specify the target...)
109 2015-01-08 12:24:14 <wumpus> michagogo: in this case, yes
110 2015-01-08 12:24:59 <wumpus> the prefix will contain some special file that will pre-seed some configure settings to make this easier
111 2015-01-08 12:25:10 <michagogo> Ah, cool.
112 2015-01-08 12:44:12 <jonasschnelli> wumpus, hmm... i'm looking for a build solution directly on windows. gitian and i are not friends. And i'd like to have a script on my host-os ./mbuild #<github-pull-nr> which pulls and build on all my vm's (ubuntu, debian, windows)
113 2015-01-08 12:44:50 <jonasschnelli> maybe it could even create screenshots of some bitcoin-qt situations automatically.
114 2015-01-08 12:45:20 <wumpus> jonasschnelli: there is no supported way to build from windows directly; ideally, you could build the depends in msys, but that will require some work
115 2015-01-08 12:45:35 <jonasschnelli> hmm....
116 2015-01-08 12:46:14 <wumpus> so would be better to build all three on your host OS, then copy the executables to the Vms
117 2015-01-08 12:46:18 <jonasschnelli> maybe i have to give my Mac mini a rebirth and install a ubuntu there to make a smooth-running gitian host out of it. I mean it could be deployed from there to all my vms for auto-testing, etc.
118 2015-01-08 12:46:35 <michagogo> jonasschnelli: if you have an Ubuntu VM, you could have that script run a build in that VM and transfer it over to Windows :P
119 2015-01-08 12:46:42 <wumpus> note that, as said, you don't need gitian, just depends
120 2015-01-08 12:47:03 <wumpus> (the w64 cross compile toolchain can just be apt-get on ubuntu)
121 2015-01-08 12:47:05 <michagogo> wumpus: is there a list of dependencies for using depends?
122 2015-01-08 12:47:11 <jonasschnelli> michagogo i just had no success running a gitian host on a ubuntu vm on my mac. I tried some times but gave up (timeless)
123 2015-01-08 12:47:11 <wumpus> michagogo: just a toolchain
124 2015-01-08 12:47:17 <jonasschnelli> s/timeless/timewise
125 2015-01-08 12:47:41 <michagogo> (i.e. something like the apt-get commands in build-unix.md that tell you which packages you need to install on e.g. Ubuntu)
126 2015-01-08 12:47:43 <wumpus> michagogo: e.g. you can build a toolchain using crosstool-ng and immediately build the bitcoin depends using that toolchain, then bitcoin executables
127 2015-01-08 12:48:05 <wumpus> michagogo: well that depends on what target you want to build for
128 2015-01-08 12:48:10 <michagogo> ;;google crosstool-ng
129 2015-01-08 12:48:11 <altgribble> start [crosstool-NG]: <http://crosstool-ng.org/>; Index of /download/crosstool-ng/: <http://crosstool-ng.org/download/crosstool-ng/>; crosstool-NG - BZH_lan: <http://ymorin.is-a-geek.org/projects/crosstool>; crosstool-ng/crosstool-ng · GitHub: <https://github.com/crosstool-ng/crosstool-ng>; diorcety/crosstool-ng · GitHub: <https://github.com/diorcety/crosstool-ng>; (1 more message)
130 2015-01-08 12:48:26 <wumpus> I don't know the package name for the w64 cross toolchain, or the arm-eabi toolchain, but both just exist
131 2015-01-08 12:48:39 <michagogo> wumpus: right, well there would be different commands for the different targets
132 2015-01-08 12:48:52 <michagogo> I guess the packages in the gitian descriptors might be a good place to start
133 2015-01-08 12:49:06 <wumpus> yes
134 2015-01-08 12:49:16 <michagogo> Just for fun, I think I'll try that
135 2015-01-08 12:49:27 <michagogo> Clean Ubuntu 12.04 VM, seeing what it takes to do this
136 2015-01-08 12:49:47 <jonasschnelli> michagogo, keep me in the line for this...
137 2015-01-08 12:50:09 <wumpus> toolchain for windows: g++-mingw-w64 mingw-w64
138 2015-01-08 12:50:10 <jonasschnelli> michagogo did you had success running a gitian host on a ubuntu vm?
139 2015-01-08 12:50:24 <michagogo> jonasschnelli: yes, I have gitian set up in an Ubuntu VBox VM
140 2015-01-08 12:51:00 <michagogo> Works well for me.
141 2015-01-08 12:51:03 <wumpus> toolchain for ARM: g++-4.8-arm-linux-gnueabihf binutils-arm-linux-gnueabihf
142 2015-01-08 12:51:19 <jonasschnelli> michagogo, do you use gitian master (2bcc06e) and ubuntu 14.04?
143 2015-01-08 12:51:30 <michagogo> jonasschnelli: pretty sure I keep up to date on gitian
144 2015-01-08 12:51:37 <michagogo> And no, the VM is 12.04
145 2015-01-08 12:51:42 <jonasschnelli> michagogo, what host os?
146 2015-01-08 12:51:51 <sipa> jonasschnelli: note that you don't need gitian to just do osx/win/lin builds that aren't meant to be deterministic releases
147 2015-01-08 12:51:56 <jonasschnelli> maybe i try again with ubuntu 12.04
148 2015-01-08 12:51:57 <michagogo> jonasschnelli: WIndows 7 Home Premium 64-bit, but why does it matter?
149 2015-01-08 12:52:21 <jonasschnelli> sipa, yes. thanks. but on the other hand i'd like to have a running gitian host as well. so two flies on one.
150 2015-01-08 12:52:44 <jonasschnelli> michagogo, not sure. but could matter in case of LXC
151 2015-01-08 12:53:01 <michagogo> jonasschnelli: uh, I doubt the host OS matters for that
152 2015-01-08 12:53:06 <sipa> fanquake: 5143 still causing test failure?
153 2015-01-08 12:53:18 <jonasschnelli> michagogo, yes. shouldn't
154 2015-01-08 12:53:25 <michagogo> If I were trying to nest VMs (with a hypervisor that supports it), then maybe the host OS could have an effect
155 2015-01-08 12:53:30 <jonasschnelli> i'll give it a try soon with ubuntu 12.04
156 2015-01-08 12:54:05 <fanquake> sipa it’s fixed by #5617
157 2015-01-08 12:54:12 <jonasschnelli> michagogo, but isn't that nested? HW-Host (OS X) -> Gitian-Host (Ubuntu 12.04) -> Gitian VM?
158 2015-01-08 12:54:22 <michagogo> jonasschnelli: I'm using LXC
159 2015-01-08 12:54:27 <michagogo> LXC isn't a full VM
160 2015-01-08 12:54:32 <michagogo> just a contianer
161 2015-01-08 12:54:34 <michagogo> container*
162 2015-01-08 12:54:46 <jonasschnelli> michagogo, okay.
163 2015-01-08 13:02:11 <michagogo> git
164 2015-01-08 13:02:11 <michagogo> Okay, looks like another package to add that you need is...
165 2015-01-08 13:02:34 <michagogo> (apparently that doesn't come with Ubuntu by default)
166 2015-01-08 13:21:40 <michagogo> https://github.com/bitcoin/bitcoin/blob/v0.10.0rc1/depends/README.usage#L3
167 2015-01-08 13:21:42 <michagogo> Hmm, why twice?
168 2015-01-08 13:24:00 <Luke-Jr> wtf is 5618 failing test_bitcoin? :/
169 2015-01-08 13:26:35 <michagogo> Okay, got depends building for i686-w64-mingw32 now
170 2015-01-08 13:26:51 <michagogo> After a bunch of failures, I've got these packages so far: sudo apt-get install git g++-mingw-w64 mingw-w64 autoconf libtool g++
171 2015-01-08 13:29:34 <Luke-Jr> oh, master is borken
172 2015-01-08 13:29:39 <wumpus> Luke-Jr: going to re-trigger it, probably needs a retest after 5617 was merged, but give it some time, the travis site takes ages to load here and I accidentally logged out
173 2015-01-08 13:30:18 <Luke-Jr> easy enough to amend-push
174 2015-01-08 13:30:26 <Luke-Jr> (for me)
175 2015-01-08 13:30:37 <wumpus> ok, fine too
176 2015-01-08 13:31:01 <Luke-Jr> hmm. I wonder if I can have travis on my personal branches
177 2015-01-08 13:31:17 <sipa> pretty sure you can
178 2015-01-08 13:32:54 <Luke-Jr> just no way to manually start any I guess
179 2015-01-08 13:33:28 <jeremias> hh
180 2015-01-08 13:35:38 <michagogo> I'm watching htop while the depends builds
181 2015-01-08 13:35:47 <michagogo> (or rather, downloads, at this point)
182 2015-01-08 13:36:05 <michagogo> That's... a *very* long command line
183 2015-01-08 13:41:22 <michagogo> Question: might it not be a good idea to add a -c to the wgets in depends, so that if there's an interruption it won't restart the download from scratch?
184 2015-01-08 13:41:33 <michagogo> (especially with qt, which is very big)
185 2015-01-08 13:54:49 <michagogo> aha
186 2015-01-08 13:54:50 <michagogo> configure: loading site script /home/ubuntu/cross-test/bitcoin/depends/i686-w64-mingw32/share/config.site
187 2015-01-08 13:59:58 <michagogo> Ah, I see. So that script sets up all the various pointers to the assorted dependencies that configure looks for. Cool.
188 2015-01-08 14:01:39 <michagogo> So it looks like the full list of packages you need to install (on a clean Ubuntu 12.04 desktop installation, at least) to build for Windows is: sudo apt-get install git g++-mingw-w64 mingw-w64 autoconf libtool g++
189 2015-01-08 14:01:49 <michagogo> (plus nsis if you want to make an installer)
190 2015-01-08 14:01:51 <sipa> valt mee
191 2015-01-08 14:02:00 <sipa> eh, doesn't sound too bad
192 2015-01-08 14:03:03 <Jouke> :)
193 2015-01-08 14:19:27 <michagogo> Also: Wow, that was really easy.
194 2015-01-08 14:20:02 <michagogo> cfields: Just tried the depends/cross-compile system directly for the first time. Very impressive. Good job!
195 2015-01-08 14:50:31 <michagogo> Hm, maybe I should try seeing if I can upgrade my 12.04 VM to 14.04
196 2015-01-08 14:51:15 <jgarzik> wumpus, sipa: Are there any wallet bugs/issues I need to look at for 0.10?  I don't see any.  #5319 just got a ping but looks like post-0.10 material.
197 2015-01-08 14:51:33 <wumpus> jgarzik: no, nothing for 0.10
198 2015-01-08 14:53:46 <wumpus> pinged for that issue as it has been open for a while, comments were addressed, and seems ready to merge
199 2015-01-08 14:54:03 <wumpus> (into master, not 0.10 branch)
200 2015-01-08 14:55:21 <wumpus> everything open for 0.10 can as usual be found here: https://github.com/bitcoin/bitcoin/milestones/0.10.0
201 2015-01-08 14:55:38 <wumpus> (and I don't regard the bitcoin-tx.exe issue as blocking)
202 2015-01-08 14:56:09 <wumpus> the other two issues have a fix by sipa
203 2015-01-08 14:57:20 <jonasschnelli> i still right with gitian: install.log says: Could not connect to 10.0.3.2:3142 (10.0.3.2). - connect (113: No route to host)
204 2015-01-08 14:57:36 <michagogo> jonasschnelli: what instructions did you follow?
205 2015-01-08 14:57:36 <sdaftuar> i think 5157 doesn't actually fix 5138 -- i just ran gavin's test from his comment on Nov 14 and verified it still fails
206 2015-01-08 14:57:40 <jonasschnelli> but local connect to 'http://10.0.3.2:3142/archive.ubuntu.com' works
207 2015-01-08 14:57:50 <jonasschnelli> mainly: https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md
208 2015-01-08 14:58:08 <michagogo> Hm, I wonder if something about your setup is broken
209 2015-01-08 14:58:20 <wumpus> sdaftuar: ok, will reopen then, there was a comment in #5157 to that tone that it was fixing it
210 2015-01-08 14:58:33 <jonasschnelli> michagogo, im on ubuntu 12.04 now
211 2015-01-08 14:58:42 <jonasschnelli> the base image i did with 'bin/make-base-vm --lxc --arch amd64 --suite precise'
212 2015-01-08 14:58:52 <wumpus> sdaftuar: by Gavin, even
213 2015-01-08 14:58:58 <jonasschnelli> but looks like i have network troubles between LXC and gitian host
214 2015-01-08 14:59:11 <michagogo> Personally, I don't change gitian's default IP address settings, etc in my setup. I use vboxmanage to change the guest IP range instead, leaving 10.0.2/24 available for gitian
215 2015-01-08 14:59:22 <sipa> wumpus: i think gavin later commented elsewhere that it wasn't actually fixed
216 2015-01-08 14:59:31 <sipa> and i remember someone posting an analysis of why
217 2015-01-08 14:59:35 <sipa> but i can't remember where
218 2015-01-08 14:59:58 <sdaftuar> it looks like the problem is that when handling reorgs, we only download from preferred peers, but if those preferred peers don't have the blocks from the other fork, you'll never request them
219 2015-01-08 15:00:13 <wumpus> sdaftuar: I've reopened, please post into that issue
220 2015-01-08 15:00:28 <sdaftuar> will do
221 2015-01-08 15:01:21 <wumpus> sdaftuar: I suppose the block download timeout (#5608) won't fix that either?
222 2015-01-08 15:01:30 <sipa> it won't
223 2015-01-08 15:01:32 <sdaftuar> no it won't
224 2015-01-08 15:03:32 <morcos> it's not clear that its actually a problem? it depends on whether you're worried about the network being almost partitioned so that a portion is only connected by uni-directional links
225 2015-01-08 15:03:43 <jgarzik> gmaxwell, wumpus, sipa: on #5462 (node continues post leveldb err), I could work on that, but I presume there is always work underway?  I don't see anything on the PR, but ISTR comments in IRC RE progress.
226 2015-01-08 15:03:49 <jgarzik> *already
227 2015-01-08 15:03:56 <morcos> it happens easily in reg-test, but could be worked around by bidirectional connecting
228 2015-01-08 15:03:59 <wumpus> ok
229 2015-01-08 15:04:15 <sipa> jgarzik: #5619
230 2015-01-08 15:05:06 <sipa> morcos, wumpus: in normal steady-state it shouldn't be a problem, as it's only for IBD that this oly-download-from-poreferred-peers rule exists
231 2015-01-08 15:05:22 <sipa> the problem is that due to timestamp issues, in regtest we don't reliably detect that we're out of IBD
232 2015-01-08 15:05:55 <sdaftuar> it's not just an ibd problem though -- it also applies to handling reorgs
233 2015-01-08 15:06:10 <sipa> unless they're hours long, there shouldn't be a problem
234 2015-01-08 15:06:24 <sdaftuar> well, anytime you need intermediate blocks after an inbound peer announces a later tip
235 2015-01-08 15:06:27 <jgarzik> hooray, it crashes
236 2015-01-08 15:06:29 <sipa> oh!
237 2015-01-08 15:06:32 <sipa> sdaftuar: you're right
238 2015-01-08 15:07:18 <sipa> we could of course drop the only-fetch-from-outgoing-links rule, that would simplify a lot
239 2015-01-08 15:07:31 <morcos> yeah i suppose even if you're not worried about being actually partiioned, it really handicaps the reorg propogation
240 2015-01-08 15:07:50 <sdaftuar> yeah i wasn't sure how important it was that we do that?
241 2015-01-08 15:08:12 <jonasschnelli> michagogo, same troubles after unsetting env vars: Could not connect to 10.0.2.2:3142 (10.0.2.2). - connect (113: No route to host)
242 2015-01-08 15:08:21 <sipa> well the reason is that there is a current implicit assumption in the network that not listening for incoming connection means you'd get huge upstream due to people syncing from you
243 2015-01-08 15:08:26 <sdaftuar> right
244 2015-01-08 15:08:30 <michagogo> jonasschnelli: is the bridge set up properly?
245 2015-01-08 15:08:49 <sipa> with headersfirst that is no longer technically necessary, as we just fetch from wherever in parallel, but maybe people still want to avoid huge network upstream
246 2015-01-08 15:08:59 <michagogo> (and did you change the vbox NAT address?)
247 2015-01-08 15:09:06 <jonasschnelli> michagogo, brctl addbr br0; ifconfig br0 10.0.3.2/24 up
248 2015-01-08 15:09:15 <sdaftuar> i think the symmetry of eliminating the distinction makes it easier to reason about things
249 2015-01-08 15:09:19 <sipa> when a majoritry of the network syncs using headersfirst, we can introeuce upstream throttling or something
250 2015-01-08 15:09:24 <jonasschnelli> michagogo, eth0 is on 172.16.231.150
251 2015-01-08 15:09:27 <michagogo> jonasschnelli: right, you'd need to change that bridge address if you change the gitian address
252 2015-01-08 15:09:28 <michagogo> Ah
253 2015-01-08 15:09:29 <jonasschnelli> (i use vm ware)
254 2015-01-08 15:09:33 <michagogo> Ah, I see
255 2015-01-08 15:10:17 <jonasschnelli> michagogo, but when i have GITIAN_HOST_IP=10.0.3.2 the bridge setup is okay?
256 2015-01-08 15:10:27 <michagogo> jonasschnelli: hmm, maybe if you try what I did? I didn't use the gitian-building.md, since it didn't exist yet when I set mine up
257 2015-01-08 15:10:35 <michagogo> I just followed gitian's README
258 2015-01-08 15:10:59 <jonasschnelli> hmm.. let me try
259 2015-01-08 15:11:14 <morcos> sipa: are there ever assumptions about defending against an attack, because attacker is way more likely to be incoming connection?
260 2015-01-08 15:11:28 <sdaftuar> just brainstorming: it seemed to me we could change the logic someday so that we only download from inbound peers if they have a block in the headers chain that none of the preferred download peers have
261 2015-01-08 15:11:58 <sipa> morcos: so there is some assumption that we have better control over outgoing connections than about incoming ones
262 2015-01-08 15:12:06 <sdaftuar> i don't know if that approach is worth the effort, compared with other solutions for throttling traffic
263 2015-01-08 15:12:27 <wumpus> sdaftuar: that sounds sensible; still prefer outgoing connections for fetching, but if the incoming connections have something that the outgoing connections have not, make an exception and fetch from them anyhow
264 2015-01-08 15:12:34 <sipa> sdaftuar: it's not solving the same problem; i don't understand
265 2015-01-08 15:12:35 <wumpus> sdaftuar: is more complex though...
266 2015-01-08 15:12:57 <jonasschnelli> michagogo, what does lxcbr0 with addr:10.0.3.1 means?
267 2015-01-08 15:13:18 <sipa> there is of course a trivial solution, which is to count the number of sendmessage cycles we have done since the last block fetch, and only if that number is higher than X, consider incoming peers
268 2015-01-08 15:13:27 <michagogo> jonasschnelli: I think LXC sets up some kind of bridge, not sure exactly
269 2015-01-08 15:13:48 <wumpus> sipa: yes, exactly
270 2015-01-08 15:13:57 <sipa> or to guard that fetch block with a (preferredpeer || rand() % 100 = 0), to make it unlikely to fetch much from incoming peers
271 2015-01-08 15:14:26 <wumpus> so there would still be an assymetry, but not as stark
272 2015-01-08 15:15:05 <sdaftuar> sipa: i think i didn't understand your upstream throttling comment
273 2015-01-08 15:15:27 <jgarzik> morcos, What sipa said; we have more control over outgoing connections, so there are a few preferences to that effect in the code.
274 2015-01-08 15:16:32 <sipa> sdaftuar: 1) currently people assume that not accepting incoming connections means low upstream 2) we couldn't introduce actual throttling before, as that hurts 0.9 and earlier badly 3) with headersfirst we could introduce throttling, but only when there are not many old clients left 4) until that time we want to be able to keep the nolisten == lowupload assumption
275 2015-01-08 15:16:40 <jonasschnelli> michagogo, do you think the base image somehow stores the bridge ip?
276 2015-01-08 15:16:46 <wumpus> sipa: at least the 'never' would then be replaced by 'eventually'
277 2015-01-08 15:16:52 <wumpus> jonasschnelli: yes, it does store the IP
278 2015-01-08 15:16:53 <michagogo> jonasschnelli: maybe? *shrug*
279 2015-01-08 15:17:01 <michagogo> Actually, that makes sense
280 2015-01-08 15:17:05 <jonasschnelli> wumpus, michagogo okay. let me recreate the images
281 2015-01-08 15:17:27 <michagogo> The address probably needs to be written into the source list
282 2015-01-08 15:17:43 <wumpus> michagogo: exactly!
283 2015-01-08 15:17:44 <michagogo> which would happen when vmbuilder is creating the VM
284 2015-01-08 15:18:11 <sipa> sdaftuar: perhaps this is not that problematic, and people will adapt etc, but i wouldn't like comments like "since 0.10, bitcoin core is killing my upstream, i'm switching to yourscamwallet.com!"
285 2015-01-08 15:18:13 <michagogo> jonasschnelli: wait, did you say you're using VMWare? Did you try gitian with KVM? I seem to recall VMWare supporting nested virtualization
286 2015-01-08 15:18:39 <wumpus> sipa: OTOH it'd affect people connecting to you, not yourself
287 2015-01-08 15:18:45 <jonasschnelli> no. I use LXC. VMWare Fusion (mac) does not support KVM i assume.
288 2015-01-08 15:18:45 <sipa> yeah
289 2015-01-08 15:19:01 <wumpus> he's using LXC as the guide says
290 2015-01-08 15:19:06 <sipa> also, the download fetching logic is not really tuned for downloading from very many peers simultaneously
291 2015-01-08 15:19:08 <sdaftuar> sipa: in pre-0.10, did we have a concept of only doing initial block download from outbound peers?
292 2015-01-08 15:19:23 <sipa> sdaftuar: in practice, yes
293 2015-01-08 15:19:27 <jonasschnelli> michagogo, LXC looks good it just the net-conf stuff
294 2015-01-08 15:20:32 <michagogo> jonasschnelli: which version of Fusion?
295 2015-01-08 15:20:54 <jonasschnelli> michagogo, 6.0.5
296 2015-01-08 15:21:24 <jonasschnelli> michagogo, damit. same issue: Could not connect to 10.0.2.2:3142 (10.0.2.2). - connect (113: No route to host)
297 2015-01-08 15:21:30 <michagogo> jonasschnelli: do you know the "virtual hardware version"?
298 2015-01-08 15:21:45 <michagogo> is it 9 or 10? Or something else?
299 2015-01-08 15:22:05 <jonasschnelli> michagogo, using curl 'http://10.0.2.2:3142' from gitian host works fine...
300 2015-01-08 15:22:12 <michagogo> And finally, which CPU do you have?
301 2015-01-08 15:22:23 <jonasschnelli> michagogo, 2.6 GHz Intel Core i7
302 2015-01-08 15:22:34 <michagogo> jonasschnelli: do you have the model number?
303 2015-01-08 15:23:12 <jonasschnelli> michagogo, no. found no model nr.
304 2015-01-08 15:23:15 <michagogo> jonasschnelli: run `sysctl -n machdep.cpu.brand_string`
305 2015-01-08 15:23:28 <jonasschnelli> michagogo, Intel(R) Core(TM) i7-4960HQ CPU @ 2.60GHz
306 2015-01-08 15:24:02 <jonasschnelli> michagogo, i have a bra running at inet addr:10.0.2.2, why gitian can't connect to is?
307 2015-01-08 15:24:03 <michagogo> jonasschnelli: do you know what the VMWare "virtual hardware version" is?
308 2015-01-08 15:24:15 <jonasschnelli> michagogo, do i have to enable ip forwarding or nat or something similar?
309 2015-01-08 15:24:28 <michagogo> jonasschnelli: I'm not sure :-/
310 2015-01-08 15:24:53 <jonasschnelli> michagogo, virtual hardware version = 10