1 2015-01-16 01:11:38 <fanquake> sipa Do you no longer have your graphs? Or are they just down at the moment?
  2 2015-01-16 01:53:44 <Luke-Jr> fanquake: it's down
  3 2015-01-16 02:05:47 <morcos_> gmaxwell: u there?  in any case I agree #5535 is a good change.  just wanted to raise awareness in case there was commericial activity relying on the prior policy (as unreliable as that would have been anyway)
  4 2015-01-16 02:14:18 <infernobass7> Ok so first time I have done this but I am trying to setup bitcoin on a server for a pool. It is all configured and all but when I connect a miner to it, the miner doesn't get any shares.
  5 2015-01-16 02:15:08 <fanquake> infernobass7 Ask in #bitcoin
  6 2015-01-16 06:48:41 <DigitalURN> How hard will it be in reality to increase the block size? is it a hardfork?
  7 2015-01-16 07:10:11 <jonasschnelli> DigitalURN, have a look here: http://gavintech.blogspot.cz/2015/01/looking-before-scaling-up-leap.html
  8 2015-01-16 07:16:08 <DigitalURN> If we hard fork should it include side chains?
  9 2015-01-16 07:17:02 <jonasschnelli> sipa, do you see it problematic when adding a 4byte header-magic and a 4byte int for version number at the very beginning of a logdb file? In future the way of storing and reading data might change. That's why i propose a version number at the beginning
 10 2015-01-16 07:17:03 <jonasschnelli> sipa, or it could also be a 4byte flag bitmap with logdb futures instead of a version int?
 11 2015-01-16 07:17:46 <jonasschnelli> s/futures/features
 12 2015-01-16 07:18:05 <gmaxwell> DigitalURN: question doesn't make any sense; there is no need or use for any hardforking with relation to side chains.
 13 2015-01-16 07:20:00 <DigitalURN> I thought side chains took a hardfork
 14 2015-01-16 07:20:32 <phantomcircuit> nope, soft fork
 15 2015-01-16 07:21:20 <DigitalURN> what about block size? hardfork right?
 16 2015-01-16 07:22:00 <phantomcircuit> yup
 17 2015-01-16 07:22:52 <DigitalURN> so if it increases by 50% is that a hard fork every x days?
 18 2015-01-16 07:23:16 <phantomcircuit> DigitalURN, that depends on how it's implemented, my guess would be no
 19 2015-01-16 07:23:26 <DigitalURN> when will we see more features that alt coins have experimented with?
 20 2015-01-16 07:23:33 <wumpus> no, no hardforks
 21 2015-01-16 07:23:46 <DigitalURN> 0 hard forks?
 22 2015-01-16 07:24:03 <phantomcircuit> wumpus, increasing the block size > 1MB is a hard fork
 23 2015-01-16 07:24:04 <wumpus> upcoming fix for strict DER will be a softfork, nothing beyond that is planned
 24 2015-01-16 07:24:17 <wumpus> phantomcircuit: oh sure
 25 2015-01-16 07:24:27 <phantomcircuit> he's asking about hypothetical changes
 26 2015-01-16 07:24:37 <DigitalURN> Strict DER?
 27 2015-01-16 07:24:58 <phantomcircuit> i actually dont think a hardfork to increase the blocksize will work
 28 2015-01-16 07:25:05 <phantomcircuit> the risk to miners is just too high
 29 2015-01-16 07:25:13 <DigitalURN> i agree...(little dev knowlege)
 30 2015-01-16 07:25:21 <DigitalURN> (trader)
 31 2015-01-16 07:26:08 <jonasschnelli> yesterday i read about nightly builds. I'm also interested to add a script to one my server to build nightly master with gitian. but...
 32 2015-01-16 07:26:13 <DigitalURN> how do we fix the block size if a hardfork doesnt work?
 33 2015-01-16 07:26:41 <jonasschnelli> there should be a time-syncing so that we build at the same head so sigs can be verified.
 34 2015-01-16 07:26:55 <jonasschnelli> it would be good if at least three people could do synced nightly builds.
 35 2015-01-16 07:27:22 <DigitalURN> Are there any plans to decrease confirmation time? or is ripple / tether gonna take that over?
 36 2015-01-16 07:28:18 <phantomcircuit> DigitalURN, that garbage doesn't work...
 37 2015-01-16 07:28:55 <DigitalURN> tether or ripple?
 38 2015-01-16 07:29:20 <DigitalURN> I bought 47 btc today so i hope thats not what your talking about
 39 2015-01-16 07:31:18 <phantomcircuit> huh
 40 2015-01-16 07:32:38 <phantomcircuit> looks like tether is basically counterparty except they're backing the assets themselves
 41 2015-01-16 07:32:49 <phantomcircuit> ripple doesn't work
 42 2015-01-16 07:33:19 <DigitalURN> why is ripple broken?
 43 2015-01-16 07:33:30 <DigitalURN> the dev dumps?
 44 2015-01-16 07:33:38 <wumpus> jonasschnelli: good idea
 45 2015-01-16 07:33:56 <jonasschnelli> wumpus, you mean the nightly synced builds?
 46 2015-01-16 07:34:00 <wumpus> jonasschnelli: yes
 47 2015-01-16 07:34:08 <phantomcircuit> DigitalURN, spontaneous consensus failure (ie their design does not handle partitioning correctly)
 48 2015-01-16 07:34:31 <jonasschnelli> wumpus, how does one can verify the downloaded binaries and the sigs?
 49 2015-01-16 07:34:44 <DigitalURN> partitioning? im picturing defraging for some reason
 50 2015-01-16 07:34:53 <DigitalURN> or dual booting
 51 2015-01-16 07:35:01 <wumpus> jonasschnelli: check hashes against the gitian sigs
 52 2015-01-16 07:35:18 <jonasschnelli> wumpus, and the gitian sigs agains pub key?
 53 2015-01-16 07:36:04 <jonasschnelli> 
ACTION wonders if a tiny verify app would help users to trust in nightly builds

 54 2015-01-16 07:36:11 <wumpus> jonasschnelli: if at least three people signed it's considered ok
 55 2015-01-16 07:36:41 <wumpus> that's when the executables are pushed to bitcoin.org
 56 2015-01-16 07:36:44 <phantomcircuit> DigitalURN, network splits into 2 pieces
 57 2015-01-16 07:36:59 <jonasschnelli> wumpus, but the three sigs must contain the same hashes... i assume nobody will check all three repositories.. should be automated somehow
 58 2015-01-16 07:37:20 <jonasschnelli> wumpus, ah, you mean storing the night builds at bitcoin.org... yes. good idea
 59 2015-01-16 07:37:27 <DigitalURN> oh so forking?
 60 2015-01-16 07:37:30 <DigitalURN> makes sence
 61 2015-01-16 07:37:41 <wumpus> jonasschnelli: there's gverify to verify the gitian sigs, if you mean that
 62 2015-01-16 07:37:48 <wumpus> jonasschnelli: no, no automated uploads to there
 63 2015-01-16 07:38:28 <wumpus> jonasschnelli: uploading the releases to there is a heavily manual process right now for security reasons
 64 2015-01-16 07:38:48 <jonasschnelli> wumpus, okay. thats probably good so. but..
 65 2015-01-16 07:38:54 <wumpus> e.g. the keys are offline.
 66 2015-01-16 07:39:35 <wumpus> I think you could use bitcoincore.org
 67 2015-01-16 07:40:15 <jonasschnelli> wumpus, i just think is other do night build there should be a central space for storing them.
 68 2015-01-16 07:40:35 <wumpus> mind we're very suspicious of centralized solutions here :)
 69 2015-01-16 07:41:06 <wumpus> but yes, there should obviously be a place where people can download them from
 70 2015-01-16 07:41:24 <jonasschnelli> wumpus, truly. But the build itself is decentralized its just the storing...
 71 2015-01-16 07:42:01 <jonasschnelli> and the centralized storing could make it easier for the downloader to check the sigs, etc.
 72 2015-01-16 07:43:14 <wumpus> also it should be clear that these are for testing and such only - nightlies are not releases, they have no support, and are much less heavily tested so can be dangerous
 73 2015-01-16 07:44:02 <DigitalURN> what makes sidechains a soft fork and blocksize a hardfork
 74 2015-01-16 07:44:36 <jonasschnelli> wumpus, indeed. maybe it would have caught things like #5657 (char problems)
 75 2015-01-16 10:04:16 <wumpus> jonasschnelli: any UI pulls that can be merged?
 76 2015-01-16 10:04:27 <jonasschnelli> wumpus, let me check
 77 2015-01-16 10:06:40 <fanquake> wumpus, not gui but #5491
 78 2015-01-16 10:08:24 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/5491 looks good, has enough ACKs, but i didn't test this
 79 2015-01-16 10:11:15 <jonasschnelli> fanquake, mind testing some GUI stuff?
 80 2015-01-16 10:11:34 <jonasschnelli> wumpus, mostly all GUI pulls have lack of testing
 81 2015-01-16 10:11:37 <fanquake> jonasschnelli sure.
 82 2015-01-16 10:11:58 <wumpus> jonasschnelli: always been that way, they usually only will get testing after merge
 83 2015-01-16 10:12:08 <jonasschnelli> fanquake, i think this one is required because master looks currently ugly: https://github.com/bitcoin/bitcoin/pull/5632
 84 2015-01-16 10:12:23 <jonasschnelli> wumpus, is there a min. ACK merge policy?
 85 2015-01-16 10:12:36 <jonasschnelli> or do we just judge individually?
 86 2015-01-16 10:12:36 <wumpus> jonasschnelli: no
 87 2015-01-16 10:12:41 <fanquake> jonasschnelli it would depend on the pull request
 88 2015-01-16 10:13:09 <wumpus> not for UI changes at least
 89 2015-01-16 10:13:10 <jonasschnelli> fanquake, https://github.com/bitcoin/bitcoin/pull/5626 would also be a easy test
 90 2015-01-16 10:13:38 <wumpus> for consensus changes it's different, but those need *lots* of review
 91 2015-01-16 10:14:48 <wumpus> for UI changes I leave it up to you, as UI maintainer, what to merge
 92 2015-01-16 10:15:46 <jonasschnelli> wumpus, merging https://github.com/bitcoin/bitcoin/pull/5636 makes sense. It's dev only.
 93 2015-01-16 10:19:41 <jonasschnelli> fanquake, this one is a style thing and i would also like to see you testing this: https://github.com/bitcoin/bitcoin/pull/5628
 94 2015-01-16 10:20:17 <jonasschnelli> wumpus, i will focus on Diapolos payment server stuff soon, i like to nail this PRs down.
 95 2015-01-16 10:20:47 <jonasschnelli> wumpus, but somehow its hard to keep the overview on these because they somehow depend on each other
 96 2015-01-16 10:21:03 <wumpus> jonasschnelli: yes, he has been quite spamming them :)
 97 2015-01-16 10:21:19 <fanquake> jonasschnelli #5632 looks good
 98 2015-01-16 10:21:22 <jonasschnelli> wumpus, is he sometime available on IRC?
 99 2015-01-16 10:21:54 <wumpus> jonasschnelli: not regularly, he was around ~two days ago
100 2015-01-16 10:21:56 <jonasschnelli> wumpus, yes. https://github.com/bitcoin/bitcoin/pull/5632 is mergable
101 2015-01-16 10:22:03 <wumpus> !lastseen diapolo
102 2015-01-16 10:22:04 <gribble> Error: "lastseen" is not a valid command.
103 2015-01-16 10:23:09 <fanquake> jonasschnelli you need to rebase #5626
104 2015-01-16 10:23:38 <jonasschnelli> I hope to also find a way to offer gitian builds of GUI PRs so probably more people could test these
105 2015-01-16 10:24:05 <jonasschnelli> fanquake, oh yes. need to. will do.
106 2015-01-16 10:27:47 <gdm85> jonasschnelli: I was thinking of setting up nightly builds, although what you really need here is something like this: https://drone.io/
107 2015-01-16 10:28:19 <wumpus> jonasschnelli: indeed, per-PR builds may be more useful than nightly builds there
108 2015-01-16 10:28:33 <wumpus> if only travis offered that functionality
109 2015-01-16 10:28:36 <gdm85> I mean, even if I set it up and publish the webserver, I would only gitian-build master from time to time
110 2015-01-16 10:29:06 <gdm85> wumpus: that drone.io thingy seems free for public projects? (I never used it and I am not involved)
111 2015-01-16 10:29:12 <gdm85> maybe somebody could give it a try
112 2015-01-16 10:29:25 <gdm85> although I don't think it has KVM support
113 2015-01-16 10:29:37 <wumpus> e.g. if travis had a way to *securely* upload executables for a certain pull, without allowing pulls to pollute each other's results and such
114 2015-01-16 10:30:16 <wumpus> drone.io seems entirely similar to travis?
115 2015-01-16 10:30:46 <gdm85> true. I thought travis was in the jenkins niche only
116 2015-01-16 10:30:46 <jonasschnelli> wumpus, gdm85 i don't see travis or other CI as part of the signed deterministic build system (even for test, nightly)
117 2015-01-16 10:31:35 <jonasschnelli> gdm85, we should just sync our gitian build server so that they build the same commit in the "night" (maybe sync the commit hash at 00:00 GMT)
118 2015-01-16 10:31:41 <wumpus> jonasschnelli: well I'm fine with doing it another way, but the thing is, it already produces executables, there's just no secure and feasible way to expose them
119 2015-01-16 10:32:04 <gdm85> wumpus: the pollution part concerns me most
120 2015-01-16 10:32:13 <jonasschnelli> wumpus, yes. I personally had concerns installing a binary build by travis...
121 2015-01-16 10:33:29 <wumpus> gdm85: but if you run the builds on your own machine, especially PR builds (master branch you'd hope are properly audited), you need to be careful too
122 2015-01-16 10:34:43 <gdm85> wumpus: I was reading your line more as: the building of PRs/commits is not truly independent
123 2015-01-16 10:34:44 <jonasschnelli> wumpus, oh. good point. Automates PR builds is to dangerous.
124 2015-01-16 10:35:04 <wumpus> jonasschnelli: indeed.
125 2015-01-16 10:35:47 <wumpus> in the worst case the build script itself has been made harmful, or it contains malware, which is then spread through executables which are deterministic but still as dangerous :p
126 2015-01-16 10:35:49 <jonasschnelli> i think it would be enough if some authorized people could write a magic string into a command like ";;prbuild" and a bot will produce a build and write the link into a comment
127 2015-01-16 10:35:53 <gdm85> AFAIK, those drone.io folks use containers for each build, which is nice. but ofc if you prefer to run the CI system it's another story
128 2015-01-16 10:36:43 <wumpus> jonasschnelli: so a script that is manually triggered by you (after checking code changes) would be more useful then
129 2015-01-16 10:37:00 <jonasschnelli> ";;prbuild+screenshots" as action in comments would be great. Could provide a link to a html page with multiple automatic generated screenshots of win/linux/mac.
130 2015-01-16 10:37:32 <wumpus> right
131 2015-01-16 10:48:18 <jonasschnelli> fanquake, https://github.com/bitcoin/bitcoin/pull/5626 is rebased
132 2015-01-16 10:51:07 <jonasschnelli> wumpus, https://github.com/bitcoin/bitcoin/pull/5632 merge?
133 2015-01-16 10:53:55 <wumpus> jonasschnelli: yes, just merged it, it's a clear improvement
134 2015-01-16 10:54:04 <wumpus> jonasschnelli: although the about box is more boring now
135 2015-01-16 10:54:36 <jonasschnelli> wumpus, i will add the bitcoin icon on the left top soon. So it might look like the "About QT" screen which looks good IMO
136 2015-01-16 10:54:48 <wumpus> jonasschnelli: eh I think we had a misunderstanding about the RES_IMAGES. I've merged it as is.
137 2015-01-16 10:55:16 <jonasschnelli> wumpus, hmm... you also thought we should keep the RES_IMAGE line?
138 2015-01-16 10:55:25 <wumpus> yes
139 2015-01-16 10:55:37 <jonasschnelli> meh...
140 2015-01-16 10:55:40 <wumpus> anyhow your push was too late
141 2015-01-16 10:55:45 <fanquake> It’s weird that GH didn’t close #5632 after you merged it?
142 2015-01-16 10:55:51 <midnightmagic> wumpus: what's your gitian host for your builds?
143 2015-01-16 10:56:17 <jonasschnelli> wumpus, good so (that the push was to late)
144 2015-01-16 10:56:18 <wumpus> fanquake: because jonasschnelli was pushing to it at the same time, so the content of that pull is no longer exactly what was merged :)
145 2015-01-16 10:56:29 <wumpus> midnightmagic: KVM
146 2015-01-16 10:56:41 <fanquake> wumpus ah, I see.
147 2015-01-16 10:57:05 <wumpus> fanquake: I was already merging and testing it locally using the github-merge.sh script
148 2015-01-16 10:57:55 <fanquake> wumpus that script is great. Makes testing really easy.
149 2015-01-16 10:58:46 <fanquake> Speaking of that script, #5623 should be ok to merge now. Will just re-test.
150 2015-01-16 10:58:47 <wumpus> fanquake: it is!
151 2015-01-16 11:00:17 <midnightmagic> wumpus: no, the host. some kind of ubuntu? what kernel?
152 2015-01-16 11:02:13 <wumpus> midnightmagic: 14.04, 3.13.0-40-generic
153 2015-01-16 11:05:12 <jonasschnelli> wumpus, https://github.com/bitcoin/bitcoin/pull/5626 merge?
154 2015-01-16 11:14:34 <michagogo> midnightmagic: (though that presumably doesn't matter if he's using KVM…)
155 2015-01-16 11:25:01 <midnightmagic> michagogo: during the make-base-vm stage, using KVM actually fails for me entirely. I'm on 12.04 + 3.13.0-3x-generic
156 2015-01-16 11:25:03 <wumpus> eh, mruset_tests.cpp redefines MAX_SIZE?
157 2015-01-16 11:25:33 <wumpus> apparently it is a local MAX_SIZE unrelated to the one used by serialization
158 2015-01-16 11:25:38 <wumpus> jonasschnelli: looking at it
159 2015-01-16 11:25:40 <michagogo> midnightmagic: make-base-vm doesn't use KVM at all, AFAIK...
160 2015-01-16 11:26:02 <michagogo> Pretty sure it's just vmbuilder, which calls debootstrap and stuff, but doesn't require KVM
161 2015-01-16 11:26:40 <michagogo> I've looked at the script, iirc the only difference that --lxc makes is to add one more command at the very end to convert the VM into an LXC
162 2015-01-16 11:34:05 <midnightmagic> so it does. neither does the vmbuilder nor any of the python modules it uses make use of anything lxc-specific. it's a debootstrap into a chroot. that's interesting.
163 2015-01-16 11:50:57 <gdm85> is it possible to gitian-build using only LXC and no KVM?
164 2015-01-16 11:51:58 <wumpus> midnightmagic: crossdebootstrap is even more fun, it debootstraps into a chroot using qemu-user for a different platform
165 2015-01-16 11:52:28 <wumpus> gdm85: sure, that was the point of adding LXC support in the first place
166 2015-01-16 11:53:10 <gdm85> wumpus: mmh..perhaps I should give it another try. what confuses me is the USE_LXC=1
167 2015-01-16 11:59:15 <michagogo> gdm85: (some of) the scripts use that environment variable to know to use lxc, rather than kvm which is the default.
168 2015-01-16 12:00:00 <gdm85> michagogo: I have USE_LXC=1 and (I think) vmbuilder is using kvm as well. nonetheless need to double check this again
169 2015-01-16 12:00:03 <michagogo> If you're just using lxc, you probably want to put that into your .profile or equivalent
170 2015-01-16 12:00:18 <michagogo> gdm85: vmbuilder doesn't use kvm
171 2015-01-16 12:00:21 <michagogo> At all
172 2015-01-16 12:00:51 <michagogo> It outputs an image suitable for kvm, though
173 2015-01-16 12:00:54 <foo_> which popular bitcoin wallets generate a new change address for each transaction ?
174 2015-01-16 12:01:20 <gdm85> michagogo: right. so the SYS_ADMIN CAP must be needed for LXC/cgroups alone, not for KVM usage
175 2015-01-16 12:01:25 <gdm85> 
ACTION is going to run a test

176 2015-01-16 12:01:41 <michagogo> gdm85: not entirely sure what that means
177 2015-01-16 12:01:59 <btcdrak> have you seen the latest sensational post on coindesk about backing private keys? /research-hackers-install-backdoor-bitcoin-cold-storage/
178 2015-01-16 12:02:01 <michagogo> A docker thing?
179 2015-01-16 12:02:12 <gdm85> michagogo: a Linux kernel thing, mostly
180 2015-01-16 12:02:51 <midnightmagic> gdm85: I (normally) only do LXC builds. The only time I've ever had a problem that couldn't be solved in a day or fiddling have been the 0.10.0rc3 OSX builds
181 2015-01-16 12:03:04 <wumpus> btcdrak: yes, nothing new there
182 2015-01-16 12:03:17 <wumpus> btcdrak: see current discussion in #bitcoin
183 2015-01-16 12:04:11 <michagogo> midnightmagic: anything useful from bindiffs?
184 2015-01-16 12:04:29 <gdm85> michagogo: http://man7.org/linux/man-pages/man7/capabilities.7.html <-- see CAP_SYS_ADMIN (rather old documentation page btw)
185 2015-01-16 12:05:37 <gdm85> midnightmagic: last time I had an issue it was because I hadn't set USE_LXC correctly, and michagogo gave a hand. but yeah, it's pretty smooth here too. although last time we were looking at /dev/kvm and that shouldn't be a concern at all if I do use LXC only
186 2015-01-16 12:06:38 <midnightmagic> michagogo: no, too much is different. offsets are all different, data is re-arranged. I haven't even bothered to verify if the code itself is different.
187 2015-01-16 12:06:55 <michagogo> gdm85: it was just an issue of /dev/kvm being present in the container (passed down from the host) but without the actual software being installed in the container
188 2015-01-16 12:07:22 <wumpus> midnightmagic: indeed, the weird thing is that no one else reproduced your result
189 2015-01-16 12:07:29 <michagogo> In fact, it may have even possible to fix the issue by installing qemu-kvm in the container
190 2015-01-16 12:07:41 <midnightmagic> gdm85: at the moment, udevadm settle is taking more than 120 seconds to finish, which is interfering with my ability to debootstrap into a fresh vm. lxc-create is quite a bit simpler and quicker.
191 2015-01-16 12:07:53 <gdm85> michagogo: but one doesn't use /dev/kvm at all if gitian-building with LXC, right?
192 2015-01-16 12:08:01 <michagogo> Right
193 2015-01-16 12:08:02 <wumpus> midnightmagic: usually with issues like that there's a split, one side gets one deterministic result, the other side the other
194 2015-01-16 12:08:06 <gdm85> ok, now I understand
195 2015-01-16 12:08:18 <michagogo> (I mean, maybe you could just build with kvm)
196 2015-01-16 12:08:51 <midnightmagic> wumpus: really don't want to reboot that machine to get it into a pristine state, there are too many vms running on it. :(
197 2015-01-16 12:08:59 <gdm85> michagogo: from isolation perspective, much better to go with LXC than KVM (I am going to have nightly gitian-builds)
198 2015-01-16 12:09:02 <midnightmagic> maybe linux isn't meant to run that many vms.
199 2015-01-16 12:09:11 <wumpus> midnightmagic: so it wasn't just a different macos sdk?
200 2015-01-16 12:10:13 <michagogo> gdm85: Eh?
201 2015-01-16 12:10:31 <michagogo> Isn't kvm, being a real VM, more isolated?
202 2015-01-16 12:11:03 <midnightmagic> wumpus: well, nobody did an md5sum for me so I don't know if the contents differed, but all the filenames were identical and all the file sizes were identical. I had a bunch of additional "*._.*" files in mine, but even after deleting them things were the same (which was expected because they're just filesystem attribute files)
203 2015-01-16 12:11:12 <gdm85> michagogo: indeed. s/isolated/resource consumption/
204 2015-01-16 12:11:33 <midnightmagic> the timestamps were different in my MacOS SDK files.
205 2015-01-16 12:11:44 <michagogo> gdm85: Ah.
206 2015-01-16 13:05:50 <midnightmagic> wow cool. my udev was hung; and since debootstrap issues a udevadm settle, it was timing out while creating the base-vm. so, not kvm vs lxc at all. And now back to comparing osx builds I guess.
207 2015-01-16 13:54:30 <op_mul> fair warning, there's probably going to be lots of people asking very misinformed things about ECDSA. coindesk.com published a terrible article about using weak EC nonces as a sidechannel from airgapped wallets.
208 2015-01-16 13:55:41 <op_mul> a known nonce can reveal your private key, whew! but it's being read as "ECDSA IS BROKEN RUN".
209 2015-01-16 13:59:54 <dgenr8> well it does say that your airgapped host has to be compromised
210 2015-01-16 14:08:55 <justanotheruser> dgenr8: but "ECDSA COMPROMISED: Cold Wallets Can Be Stolen (Confirmed)" is quite an editorialized version of that
211 2015-01-16 14:09:11 <justanotheruser> people may not even read the article and if they do, they may not understand it
212 2015-01-16 14:14:05 <michagogo> Even without ECDSA a compromise in a cold wallet can introduce a side channel
213 2015-01-16 14:14:46 <op_mul> of course.
214 2015-01-16 14:14:49 <michagogo> e.g. Always having a few bytes of the key in a specific position in the signature
215 2015-01-16 14:15:08 <op_mul> michagogo: come on, think sneakier.
216 2015-01-16 14:15:35 <michagogo> A few bytes of the key... XOR'd with rotating keys?
217 2015-01-16 14:15:52 <michagogo> So you need to know the xor masks and their order?
218 2015-01-16 14:16:17 <op_mul> proably better to leak error correcting code of some sort in case you miss some signatures.
219 2015-01-16 14:16:49 <op_mul> or just go insane make make k H('secret' + time())
220 2015-01-16 14:17:34 <michagogo> Also, besides not being a new issue, this can be completely avoided by... Very simply... NOT REUSING ADDRESSES
221 2015-01-16 14:18:09 <op_mul> no, not really
222 2015-01-16 14:18:17 <michagogo> op_mul: how is that?
223 2015-01-16 14:18:18 <op_mul> weak k is as dangerous as reused k.
224 2015-01-16 14:18:19 <gmaxwell> A insecurely selected nonce leaks your keys even if you do not reuse.
225 2015-01-16 14:18:32 <gmaxwell> Though the attacker has to race your spend.
226 2015-01-16 14:18:43 <michagogo> Ah. Right.
227 2015-01-16 14:19:24 <michagogo> (Didn't that article say something about multiple signatures?)
228 2015-01-16 14:20:33 <op_mul> yes, their method uses two.
229 2015-01-16 14:21:31 <gmaxwell> but thats dumb, no reason to construct something that requires reuse.
230 2015-01-16 14:21:37 <gdm85> op_mul: so basically this article sums up to: if you are not in control of the ECDSA algorithm that was used, your keys might be compromised?
231 2015-01-16 14:22:53 <op_mul> in a loose way. they are describing a way of getting a compromise through an air-gapped wallet setup like Armory.
232 2015-01-16 14:23:31 <op_mul> ie, imagine your "cold" side armory computer was compromised, they describe a way of getting the compromise out through transactions.
233 2015-01-16 14:23:50 <gdm85> ah, right.
234 2015-01-16 14:23:54 <op_mul> it's not very novel, and the method of action is very well known.
235 2015-01-16 14:24:25 <gdm85> creative stenography at work there
236 2015-01-16 14:27:07 <gdm85> s/steno/stegano/
237 2015-01-16 14:33:33 <freefox> anyone know when the 0.10 release will be ready?
238 2015-01-16 14:35:08 <jgarzik> freefox, soon.  right now it's bacon.
239 2015-01-16 14:35:22 <freefox> jgarzik: bacon?
240 2015-01-16 14:36:04 <jgarzik> baking, e.g. currently under public testing, Release Candidate status.
241 2015-01-16 14:36:29 <jgarzik> as soon as bug fixes are all pushed and public testing doesn't turn up anything nasty
242 2015-01-16 14:38:06 <freefox> so we can say a week or two?
243 2015-01-16 14:40:27 <jgarzik> freefox, when the bacon is done :)   Vague target was Jan 1 2015 :)
244 2015-01-16 14:41:48 <freefox> jgarzik: I see, thanks
245 2015-01-16 14:44:40 <midnightmagic> right. So I don't suppose anyone has an OSX build leftover they can do be a favour on could they? I want to try just brute-forcing this.
246 2015-01-16 14:44:42 <wumpus> well unfortunately there will have to be a rc4, but I have some faith that could be the final
247 2015-01-16 14:46:09 <midnightmagic> find /home/ubuntu -type f -print0 | xargs -0 -P 2 md5sum | gzip -9 > to_make_mm_less_crazy.gz ?
248 2015-01-16 14:46:20 <midnightmagic> (inside the gitian VM)
249 2015-01-16 14:51:17 <gdm85> midnightmagic: I built master a couple of hours ago
250 2015-01-16 15:44:23 <morcos> gmaxwell: regarding low priority rejections, i'd previously thought this only affected non-core clients, because existing bitcoin core code wouldn't let you place a tx below the AllowFree cutoff anyway
251 2015-01-16 15:45:33 <morcos> gmaxwell: but now i think that maybe thats wrong, the calculation in wallet.cpp of what your priority would be in 1 block is optimistic (and assumes your in-mempool inputs would age)
252 2015-01-16 15:45:59 <morcos> but the reject check correctly does not make that optimistic assumption
253 2015-01-16 15:46:03 <gmaxwell> maraoz: thats my understanding; except for certian versions of git and for the 1 block look ahead.
254 2015-01-16 15:46:38 <gmaxwell> maraoz: what the look ahead is intended to do is to just leave it where your own node is rebroadcasting at the next block.
255 2015-01-16 15:47:55 <gmaxwell> (which was the justification given for the lookahead when it went in; at the time it was believed they wouldn't relay at all)
256 2015-01-16 15:50:34 <foo_> which popular bitcoin wallets generate a new change address for each transaction ?
257 2015-01-16 15:51:13 <morcos> gmaxwell: but do you see what i'm saying, the code in CreateTransaction uses GetDepthInMainChain()+1 for the age of every input
258 2015-01-16 15:52:29 <morcos> gmaxwell: this means in memory inputs will add to the projected priority when creating a transaction.  But that doesn't happen in the rejection code, so they'll get summarily rejected.
259 2015-01-16 15:53:51 <midnightmagic> gdm85: I'm trying to find the differences between trees that match the official build, and my tree. So, 0.10.0rc3 right now..
260 2015-01-16 15:55:22 <gdm85> midnightmagic: I built that one as well, but discarded the tree..
261 2015-01-16 15:55:41 <gdm85> midnightmagic: I can rebuild it, it's quite fast - although it's a crossbuild on Linux, not native Mac OS X
262 2015-01-16 15:55:52 <midnightmagic> gdm85: that's precisely what I do actually.
263 2015-01-16 15:56:12 <gdm85> midnightmagic: ok, np - let me start one
264 2015-01-16 15:56:50 <midnightmagic> gdm85: thanks man. this is bugging me.
265 2015-01-16 15:56:57 <gdm85> yw :)
266 2015-01-16 15:57:44 <Luke-Jr> foo_: I would hope all?
267 2015-01-16 15:57:56 <Luke-Jr> foo_: it's broken if it doesn't.
268 2015-01-16 15:58:47 <foo_> Multibit does not
269 2015-01-16 16:01:09 <foo_> and someonce recently claimed to me that most modern wallets don't. This claim was news to me and quite surprising, because I don't see the reason not to especially with deterministic wallets
270 2015-01-16 16:02:59 <jgarzik> foo_, indeed!
271 2015-01-16 16:06:22 <Luke-Jr> foo_: modern or not, reusing addresses has never been something any sane wallet has done for change
272 2015-01-16 16:06:33 <Luke-Jr> Bitcoin 0.1 used a new address every time
273 2015-01-16 16:06:50 <op_mul> s/address/pubkey/
274 2015-01-16 16:07:05 <Luke-Jr> sure
275 2015-01-16 16:08:16 <foo_> Right. That's what I thought--thanks. I was actually quite shocked when I found that multibit does not
276 2015-01-16 16:08:51 <helo> 
ACTION creates a pull req to skip v0.10 for the same reason microsoft skipped windows v9 (not)

277 2015-01-16 16:11:30 <wumpus> bad luck?
278 2015-01-16 16:12:50 <sipa> "skip" ?
279 2015-01-16 16:13:11 <wumpus> gavin would certainly prefer v0.11
280 2015-01-16 16:13:25 <gdm85> midnightmagic: ready :)
281 2015-01-16 16:14:13 <wumpus> 0.12 is will be ok, 0.13 will also raise superstitions
282 2015-01-16 16:14:56 <gdm85> midnightmagic: took 10 minutes, but I noticed just now it was complete. what files do you need? I am using LXC btw
283 2015-01-16 16:15:37 <gdm85> wumpus: then skip 0.17 as well, to be culture-neutral. and check Japanese numerology too :P
284 2015-01-16 16:16:07 <wumpus> gdm85: yes  :)
285 2015-01-16 16:16:23 <wumpus> midnightmagic: sha256's of the stuff in cache/ may help
286 2015-01-16 16:16:48 <sipa> after 0.13 there will be 0.131, then 0.31415, then 0.314159 etc :)
287 2015-01-16 16:17:52 <op_mul> 0.13.37?
288 2015-01-16 16:17:59 <gdm85> if gitian-builder does not throw away the filesystem it used in the lxc container, then everything is still here somewhere (target-precise-amd64..)
289 2015-01-16 16:20:08 <morcos> sipa: so master still depends on libgmp right?
290 2015-01-16 16:22:36 <sipa> morcos: hmm, unsure exactly; on a plane right noe
291 2015-01-16 16:23:42 <morcos> sipa: i commented on the closed pull, but i wasn't sure whether it was intended behavior or not, #5531 took it out of 0.10, but didn't make it into master
292 2015-01-16 16:24:37 <gdm85> midnightmagic: this is what wumpus suggested `cd cache && find -type f | xargs sha256sum' http://pastebin.com/raw.php?i=LZkw9HBN
293 2015-01-16 16:25:36 <wumpus> morcos: yes, as I replied there, it's intended to come with a run-off-the-mill secp256k1 update
294 2015-01-16 16:26:05 <wumpus> morcos: 0.10 had a special low-impact patch
295 2015-01-16 16:26:36 <sipa> right, that's it
296 2015-01-16 16:27:44 <morcos> wumpus: oh whoops sorry, don't know why i missed that response
297 2015-01-16 16:35:59 <op_mul> so I'm rescanning my blocks, why did I disconnect my peer for stalling the block download? o.o
298 2015-01-16 16:37:49 <midnightmagic> gdm85: okie dokie.
299 2015-01-16 16:39:12 <op_mul> oh right, it just ignored the blocks totally and is downloading them from the network. that makes more sense.
300 2015-01-16 16:39:13 <wumpus> op_mul: that doesn't sound right
301 2015-01-16 16:39:19 <wumpus> oh okay
302 2015-01-16 16:39:58 <wumpus> would be kind of sad if it completely ignored peers and then disconnected them for stalling the block download
303 2015-01-16 16:40:57 <wumpus> (e.g. during reindex it doesn't even accept blocks from peers)
304 2015-01-16 16:41:17 <op_mul> (I meant reindex)
305 2015-01-16 16:49:59 <midnightmagic> interesting: ./common/clang-llvm-3.2-x86-linux-ubuntu-12.04.tar.gz
306 2015-01-16 17:10:23 <ajweiss> op_mul: what was the exact log message?
307 2015-01-16 17:10:25 <midnightmagic> gdm85: why does your have 60d8f69f032d62ef61bf527857ebb933741ec3352d4d328c5516aa520662dab7  ./common/clang-llvm-3.3-amd64-Ubuntu-12.04.2.tar.gz in it..  I think that's probably the issue.
308 2015-01-16 17:11:05 <gdm85> midnightmagic: I think that's one of those golden frameworks, downloaded from somewhere upstream?
309 2015-01-16 17:11:47 <gdm85> I add nothing of my own to the automated scripts, except for the SDK of course.
310 2015-01-16 17:11:47 <op_mul> ajweiss: just the peer stalling block download, makes a lot more sense now I know it was downloading blocks not doing a reindex :)
311 2015-01-16 17:13:02 <ajweiss> when i do a full sync it will boot a few peers before it gets to the end
312 2015-01-16 17:13:12 <ajweiss> it's pretty aggressive about keeping the download moving
313 2015-01-16 17:13:37 <midnightmagic> gdm85: I'm mostly thinking out loud. Your clang was either built on-demand for amd64 while mine was built for x86, or the depends is downloading something for me completely differently than for you.
314 2015-01-16 17:27:41 <coryfields> midnightmagic: clang is 3.2 x86 for 0.10, 3.3 x86_64 for master
315 2015-01-16 17:29:05 <coryfields> re: nightly builds, travis could easily upload build results automatically
316 2015-01-16 17:34:45 <morcos> gmaxwell:  see https://github.com/bitcoin/bitcoin/pull/5675.  Without this you get confusing behavior from the wallet, because it'll automatically try to send things free if you're using that option, and its wrong about when that can happen some of the time.
317 2015-01-16 17:35:58 <morcos> wumpus: i know its late, but if you guys agree, this change should make it in 0.10, to keep behavior consistent
318 2015-01-16 17:36:58 <midnightmagic> coryfields: then he might have been building master instead of 0.10.0rc3 by accident?
319 2015-01-16 17:37:07 <midnightmagic> ah..  cache. nevermind
320 2015-01-16 17:37:25 <coryfields> midnightmagic: cache keeps both so that they're both quick. that's the point of it :)
321 2015-01-16 17:37:48 <midnightmagic> coryfields: right. so my original request for hashes of the tree is still on the table then.
322 2015-01-16 17:37:54 <midnightmagic> lol  doh
323 2015-01-16 17:38:48 <gdm85> midnightmagic: what do you need exactly? :)
324 2015-01-16 17:38:55 <coryfields> midnightmagic: what do you want, exactly? hashes of all files in build/ on the target vm?
325 2015-01-16 17:39:25 <gdm85> midnightmagic: yes, that was master, sorry.. :( will build it again
326 2015-01-16 17:41:36 <midnightmagic> gdm85: post-build of 0.10.0rc3, start the container and run: find /home/ubuntu -type f -print0 | xargs -0 -P 2 md5sum | gzip -9 > to_make_mm_less_crazy.gz
327 2015-01-16 17:42:02 <midnightmagic> then copy that file out. if you have a website someehere or a dropbox or something that would be perfect.
328 2015-01-16 17:42:12 <gdm85> roger that
329 2015-01-16 17:42:14 <midnightmagic> coryfields: yes.
330 2015-01-16 17:42:19 <midnightmagic> gdm85: thanks man. :)
331 2015-01-16 17:42:42 <coryfields> midnightmagic: you're making sure that you're running the descriptor checked out from the rc3 tag, and not from master, right?
332 2015-01-16 17:42:48 <gdm85> :)
333 2015-01-16 17:42:58 <midnightmagic> coryfields: of that, I am sitting up in the high-90s percent sure.
334 2015-01-16 17:44:06 <coryfields> actually nm, it wouldn't work the other way around
335 2015-01-16 17:44:10 <midnightmagic> coryfields: my other hashes wouldn't match the test builds if that were not the case, I think. only a few files in there, qt-related, seem to mismatch
336 2015-01-16 17:44:32 <coryfields> midnightmagic: the osx descriptor is the only one that's changed
337 2015-01-16 17:44:51 <midnightmagic> coryfields: versus master?
338 2015-01-16 17:44:55 <coryfields> yea
339 2015-01-16 17:45:10 <coryfields> i'm building with lxc now
340 2015-01-16 17:45:35 <midnightmagic> git log | head -n 1 -> 249bf0e0492758d71dc5d8fa77103b31b604979f, git log v0.10.0rc3 | head -n 1 -> 249bf0e0492758d71dc5d8fa77103b31b604979f
341 2015-01-16 17:45:38 <gdm85> midnightmagic: ETA +1h due to afk
342 2015-01-16 17:46:03 <midnightmagic> gdm85: no rush. somehow other people managed to get matching builds. I just want to know what's the diff with mine.
343 2015-01-16 17:46:46 <midnightmagic> it would be fantastic to discover a compiler seeding malware. that would make me pretty happy actually.
344 2015-01-16 17:50:29 <midnightmagic> LXC build returned same hash again. I'll try KVM next now that I solved by udevadm settle hang.
345 2015-01-16 17:53:34 <coryfields> midnightmagic: it's almost guaranteed to be a stupid permissions/umask/something difference between lxc and kvm
346 2015-01-16 17:55:47 <midnightmagic> coryfields: the non-qt stuff all matches up perfectly. and my test*qt matches. I guess gavin's test*qt didn't but his bitcoin-qt did.
347 2015-01-16 18:00:06 <gmaxwell> morcos: good point; thats an aspect of the behavior which I was not thinking about.
348 2015-01-16 18:01:10 <midnightmagic> KVM target VM creation is quite a bit quicker and smaller, presumably due to the qcow image backing.
349 2015-01-16 18:05:53 <coryfields> midnightmagic: make sure to clear your cache. Even If there's a difference between kvm/lxc, the cache will still be re-used
350 2015-01-16 18:07:04 <midnightmagic> coryfields: indeed. I'd prefer to see one, then the other. The machine's strong enough, technically it could be building a dozen of these various strains of gitian at once.
351 2015-01-16 18:07:53 <coryfields> midnightmagic: actually.. the cache results are useful in this case. Do you have a build.assert handy for results that didn't match the good ones?
352 2015-01-16 18:08:07 <coryfields> we can compare cached packages to see which ones differ
353 2015-01-16 18:08:07 <midnightmagic> hrm
354 2015-01-16 18:09:36 <midnightmagic> coryfields: I have a bitcoin-osx-0.10-res.yml which I believe was the result of the last LXC. I've only been going on the report results to see if things differ. So I'm not sure if it is.
355 2015-01-16 18:09:55 <midnightmagic> it's in the middle of a KVM build atm.  hang on I'll pastebin or something.
356 2015-01-16 18:10:21 <midnightmagic> coryfields: do you use the torbrowserbundle?
357 2015-01-16 18:12:00 <midnightmagic> coryfields: http://0bin.net/paste/ON9fmPj6cSsU6Xma#IfnYReu40LCXo6x2z34HfH6NzRZLFo10x5GY8qAhpKi
358 2015-01-16 18:22:04 <coryfields> midnightmagic: the depends match up, with the exception of comparisontool for some reason
359 2015-01-16 18:24:17 <midnightmagic> brutal. first kvm reports are different: http://0bin.net/paste/EnCACMXemmAdy-MM#ZyBhlD2V5HLHVAbj+MCcQJDJL6Lm569WdVWjrfyIkCN  I cleaned cache and am starting fresh
360 2015-01-16 18:24:40 <midnightmagic> this time with -j 20!
361 2015-01-16 18:25:55 <coryfields> midnightmagic: erm, those are correct
362 2015-01-16 18:27:08 <midnightmagic> I meant they're different from the LXC build.
363 2015-01-16 18:29:31 <midnightmagic> coryfields: I didn't bother to check them against the real builds, I was going to do that after.
364 2015-01-16 18:30:01 <midnightmagic> i guess i'm not surprised.
365 2015-01-16 18:32:37 <midnightmagic> if I get a match this time too I'll commit the osx sig to github and open a pullreq, and maybe just open an issue re: LXC builds. should I do it upstream? am I the only one who cares about gitian on LXC..? ;)
366 2015-01-16 18:33:35 <coryfields> midnightmagic: well it still doesn't help without finding out what the difference is
367 2015-01-16 18:33:50 <coryfields> so hashes and a ls -al diff will go a long way
368 2015-01-16 18:36:09 <midnightmagic> coryfields: I agree! :) I thought you skipped off on a tangent because you were doing an LXC instead of a kvm. Now that I can actually build a successful result, that means I can test against myself.
369 2015-01-16 18:36:45 <coryfields> midnightmagic: hmm? no, i was trying to do an lxc build so that i could test against myself as well
370 2015-01-16 18:36:48 <midnightmagic> ..  which, I'm sure some will be glad to discover, means I will no longer be spamming the channel :)
371 2015-01-16 18:37:00 <midnightmagic> coryfields: ah! :)
372 2015-01-16 18:40:51 <midnightmagic> oh cool: g++: internal compiler error: Killed (program cc1plus)
373 2015-01-16 18:43:04 <midnightmagic> rickety as yoga balls man. is this another artifact of the lack of test coverage a la the OOM killer kerfuffle
374 2015-01-16 18:43:11 <coryfields> don't use more than -j3 or so
375 2015-01-16 18:43:59 <midnightmagic> coryfields: I figure the kvm was just allocated too little ram/etc.
376 2015-01-16 18:45:21 <coryfields> sounds about right
377 2015-01-16 18:49:21 <morcos> gmaxwell: i never really used 0.9, and i'm trying to figure out how it works.  does it by default try to send free transactions?
378 2015-01-16 18:50:47 <morcos> or anyone for that matter?
379 2015-01-16 18:51:20 <gmaxwell> morcos: yes, it does. unless you've set a fee.
380 2015-01-16 18:51:32 <gmaxwell> it'll use the minimum 'relay' (but not really relay) fee otherwise.
381 2015-01-16 18:52:20 <morcos> so do we need to worry about all the 0.9 clients then?
382 2015-01-16 18:54:16 <gmaxwell> morcos: no, because they will _always_ with no way to override provide a fee if they don't meet the free relay criteria. +/- the concern you raised about the handling of unconfirmed inputs.
383 2015-01-16 18:54:52 <morcos> yeah but its that +/- that i was worried about.
384 2015-01-16 18:57:49 <gmaxwell> morcos: Right; hadn't considerd it enough. core tries really hard to avoid using unconfirmed inputs. Will only ever use its own change unconfirmed and only if the transaction fails otherwise. (and only if you haven't disabled spending unconfirmed coins)
385 2015-01-16 19:01:22 <andytoshi> hi, i'm seeing a QA test failure on git HEAD `./conflictedbalance.sh ../../src/` says `error: {"code":-6,"message":"Insufficient funds"}` and `bad balance: 99.99999694 (expected 0)` is this expected?
386 2015-01-16 19:01:39 <morcos> gmaxwell: ok and for 0.9, at least your own mempool would accept it, so the problem is only if it doesn't relay very well, same as for any non-core client.  not as bad as inconsistency within the same version.
387 2015-01-16 19:01:53 <gdm85> midnightmagic: how do I exactly run something in the LXC container? I am not familiar with lxc-attach etc
388 2015-01-16 19:04:32 <gdm85> I'll just loop-mount the partition, nvm
389 2015-01-16 19:11:25 <midnightmagic> gdm85: in an lxc container, even if it's not running you can run a bash inside it with a single line that looks something like this: lxc-start -n gitian -f var/lxc.config -- sudo -u root LXC_ARCH=amd64 -i -- netstat -rn
390 2015-01-16 19:11:49 <morcos> andytoshi: that must have been broken for a while?  it looks like the code assumes no fee is added.  if you pass -sendfreetransactions, it gets past that part, but then breaks later
391 2015-01-16 19:12:04 <gdm85> midnightmagic: yep. didn't remember all the magic words, I don't use that often. I am uploading mine bwt
392 2015-01-16 19:12:10 <midnightmagic> but you don't really need most of that.  change netstat -rn for "bash -l" and you'll get a shell inside. if you see display artifacts, type "reset" and hit enter, and reset your terminal window.
393 2015-01-16 19:13:10 <midnightmagic> gdm85: lxc-attach works for currently-running containers. it's instantaneous perspective-shift into the land of the lxc container.
394 2015-01-16 19:13:34 <midnightmagic> lxc-attach -n mirror (for example)
395 2015-01-16 19:14:02 <andytoshi> morcos: hmmm, i'm bisecting now ... have some chores to do also, will be a while
396 2015-01-16 19:14:52 <gdm85> midnightmagic: http://filebin.ca/1oNDO0aOXYGI/to_make_mm_less_crazy.gz here you go
397 2015-01-16 19:15:51 <gdm85> midnightmagic: but all of that will work only if you defined correct templates, right?
398 2015-01-16 19:18:11 <midnightmagic> gdm85: if the LXC build worked, the var/lxc.config file will contain enough config for lxc to function with that container, you can name it whatever you want, it doesn't need to be "gitian"
399 2015-01-16 19:18:25 <gdm85> clear
400 2015-01-16 19:19:17 <midnightmagic> gdm85: got it, filesize 693661, sha256: a9efef4a2edba4f944d28ed544f89c092af08e3d9ef52e80ea6ad3be842c2d25
401 2015-01-16 19:19:24 <midnightmagic> gdm85: thank you kindly for the effort I appreciate it.
402 2015-01-16 19:19:40 <gdm85> midnightmagic: oh, you're welcome :)
403 2015-01-16 19:20:56 <gdm85> midnightmagic: these builds are fully automated and from scratch, little-to-none chance to add  artifacts. see this script that I use for them: https://github.com/gdm85/tenku/blob/master/docker/scripts/bitcoin-gitian-build.sh
404 2015-01-16 19:21:32 <midnightmagic> cool
405 2015-01-16 19:21:36 <gdm85> midnightmagic: yes, that is the correct hash
406 2015-01-16 19:22:07 <gdm85> the comment line about KVM is wrong, I'll fix that
407 2015-01-16 19:31:30 <coryfields> midnightmagic: my lxc/kvm builds match
408 2015-01-16 19:33:18 <midnightmagic> :-/
409 2015-01-16 19:33:53 <midnightmagic> coryfields: what's your host system? ubuntu 14.04 I presume?
410 2015-01-16 19:34:20 <coryfields> 13.04
411 2015-01-16 19:35:01 <midnightmagic> ok.
412 2015-01-16 19:35:27 <midnightmagic> my host is 12.04 with the updated kernel 3.13.0-43-generic so I'm not stuck on a dead-end
413 2015-01-16 19:45:23 <morcos> andytoshi: yeah even if fixing for the fees, that test won't work any more, becasue the mutated transaction is non-standard and won't make it to the mempool of the second node
414 2015-01-16 19:48:17 <phantomcircuit> gmaxwell, so i cant reproduce the reindex at 2600 seconds with fscriptcheck = false
415 2015-01-16 19:48:29 <phantomcircuit> fscriptchecks *
416 2015-01-16 19:48:52 <sipa> reproduce what?
417 2015-01-16 19:53:28 <andytoshi> morcos: ok, thx for the explanation. i will do the bisection to confirm
418 2015-01-16 19:54:03 <phantomcircuit> sipa, cant get the reindex to complete in <4000 seconds
419 2015-01-16 19:57:40 <jonasschnelli> andytoshi also had a look recently at the conflictedbalance.sh test. Misses fees and something triggers a mem-pool refuse as morocs said.
420 2015-01-16 21:24:31 <owowo> ;;diffchange
421 2015-01-16 21:24:32 <gribble> Estimated percent change in difficulty this period | -6.00388 % based on data since last change | -1.13544 % based on data for last three days
422 2015-01-16 21:29:32 <coryfields> jonasschnelli: chinese/utf all good now. Thanks for that suggestion.
423 2015-01-16 22:40:40 <kanzure> is there anything running conflictedbalance.sh?
424 2015-01-16 22:41:54 <kanzure> jonasschnelli: any guesses as to why conflictedbalance.sh might be failing on my branch (fundrawtransactions-watchonly)?
425 2015-01-16 22:42:26 <andytoshi> kanzure: it is failing on master as well (and the previous two commits at least)
426 2015-01-16 22:43:02 <andytoshi> (i tried to bisect but it didn't fail at all during the bisection, so i'm checking a few commits near the tip as a sanity check. obvs i messed up the bisect command somehow..)
427 2015-01-16 22:43:23 <kanzure> my branch is actually based on jonasschnelli/2014_12_fundtransaction (1f8f85b73ec6c6dec3710ef706d03b336dd5ed1f)
428 2015-01-16 22:43:27 <kanzure> (and not master)
429 2015-01-16 23:02:35 <kanzure> qa/pull-tester/rpc-tests.sh does not seem to explicitly run conflictedbalance.sh
430 2015-01-16 23:41:19 <kanzure> where are the debian packaging scripts?
431 2015-01-16 23:45:16 <phantomcircuit> kanzure, iono but there's a debian readme
432 2015-01-16 23:48:56 <kanzure> er, where?
433 2015-01-16 23:49:56 <kanzure> doc/gitian-building.md ?
434 2015-01-16 23:50:50 <kanzure> ah, /contrib/deb/
435 2015-01-16 23:51:02 <kanzure> i mean /contrib/debian/