1 2015-01-11 04:22:17 <epilido> linux 64 btc core v0.9.3.0 -- started with 12 day out of sync. Why when syncing is the out 550 MB and the in 258 MB seems like it should sync then start seeding. what is it doing?
  2 2015-01-11 04:25:46 <justanotheruser> epilido: it is seeding before it syncs
  3 2015-01-11 04:26:07 <justanotheruser> bitcoin core can't know when it is synced
  4 2015-01-11 04:33:36 <mr_burdell> it could make a decent guess based on timestamps
  5 2015-01-11 04:35:36 <mr_burdell> I guess if there's ever a deep reorg, you wouldn't want the network to completely stop though
  6 2015-01-11 04:41:43 <epilido> ok thanks
  7 2015-01-11 04:42:44 <sipa> epilido: also, the downloading mechanism used up to 0.9.x is known to have many flaws, and is rewritten in 0.10
  8 2015-01-11 04:44:19 <epilido> sipa, going to update my node box tonight.  I think I will keep my wallet at 0.9 until 0.10 is out of rc status
  9 2015-01-11 04:45:31 <sipa> good decision; just saying that it's not an unknown fact that there are problems with sync in 0.9
 10 2015-01-11 05:55:29 <gmaxwell> (ignore this line ae9c5916ffe9cb5bca3d6bb5b2afbacd9b690dc880e1918ae4d5261f35d371db)
 11 2015-01-11 06:19:46 <midnightmagic> too late, I signed it and inserted it into some namecoin stamps. :)
 12 2015-01-11 08:48:53 <Krellan> Hi all, whiteilsting again
 13 2015-01-11 08:49:08 <Krellan> -whitebind and -whitelist apply only to inbound, right?
 14 2015-01-11 08:49:23 <Krellan> Any good reason why -addnode and -connect (connections the user has intentionally, explicitly, chosen to make)
 15 2015-01-11 08:49:25 <Krellan> should not be whitelisted?
 16 2015-01-11 08:49:26 <gmaxwell> whitebind, yes, whitlist no.
 17 2015-01-11 08:49:43 <gmaxwell> kefkius: because thats strictly less flexible.
 18 2015-01-11 08:49:52 <Krellan> I connected to some peers, whitelisted, only to be surprised to see "false" in the getpeerinfo list.
 19 2015-01-11 08:50:10 <Krellan> And their IP's are in the mask.  Even tried whitelist=0.0.0.0/0 to whitelist the entire world, no luck.
 20 2015-01-11 08:50:41 <Krellan> Bug? Or my misconfig?
 21 2015-01-11 09:02:45 <kefkius> ...What's strictly less flexible?
 22 2015-01-11 09:03:18 <gmaxwell> Krellan: or I'm mistaken.
 23 2015-01-11 09:03:40 <gmaxwell> kefkius: automatically whitelisting anything you addnode.
 24 2015-01-11 09:03:40 <kefkius> Ahh I see
 25 2015-01-11 09:04:12 <kefkius> gmaxwell: I think you're auto-completing the wrong nick
 26 2015-01-11 09:04:36 <kefkius> gmaxwell | kefkius: because thats strictly less flexible.
 27 2015-01-11 09:04:47 <gmaxwell> darnit. sorry
 28 2015-01-11 09:04:54 <kefkius> No problem
 29 2015-01-11 09:05:05 <gmaxwell> Krellan:
 30 2015-01-11 09:33:13 <michagogo> wumpus: has someone already filed a debian bug about that update?
 31 2015-01-11 09:35:35 <wumpus> michagogo: yes
 32 2015-01-11 09:37:55 <michagogo> Hm, I can't seem to find it... Maybe I'm looking in the wrong place, not so familiar with Debian's bug tracker
 33 2015-01-11 09:41:18 <michagogo> wumpus: do you have a link/number, by any chance?
 34 2015-01-11 09:54:06 <wumpus> michagogo: it was reported to debian in private, no clue if there is a number for it
 35 2015-01-11 09:54:42 <michagogo> wumpus: oh, I mean specifically the need to patch Bitcoin Core
 36 2015-01-11 09:55:14 <michagogo> (If that wasn't clear)
 37 2015-01-11 10:25:30 <wumpus> michagogo: there's no official debian package, so that is not possible
 38 2015-01-11 10:25:56 <michagogo> wumpus: yes there is
 39 2015-01-11 10:26:06 <michagogo> It's unstable-only
 40 2015-01-11 10:38:31 <wumpus> anyhow, we've not released a new version in the 0.9 series yet, I'd prefer if they waited for that before packaging, ie if they go patching and packaging on their own they may just make things worse
 41 2015-01-11 10:57:12 <michagogo> wumpus: is the new 0.9 about to be tagged? Seems to me like this specific change is important, because as of now every user of debian unstable using their bitcoin package who has updated their openssl package is going to have it broken.
 42 2015-01-11 10:57:32 <michagogo> If that impression is wrong, just tell me.
 43 2015-01-11 11:00:42 <wumpus> for an 'official' 0.9 release at least https://github.com/bitcoin/bitcoin/pull/5640 still needs to be in, and as I understand possibly preparations for the DER stricctness softfork, as doing that on yet another release will likely result in slower adoption
 44 2015-01-11 11:02:38 <wumpus> I do understand why debian/ubuntu/distros would prefer a quick intermediate release with just those patches, but it's always a compromise
 45 2015-01-11 11:08:13 <michagogo> wumpus: right.
 46 2015-01-11 11:09:23 <michagogo> My instinct is that an 0.9.3-2 or something with that one patch is better than nothing until there's an 0.9.4, but I guess there are arguments on both sides
 47 2015-01-11 11:09:45 <wumpus> as said, we also don't want to rush something that makes things even worse, or gives people a false sense of security
 48 2015-01-11 11:10:07 <wumpus> right
 49 2015-01-11 11:13:19 <phantomcircuit> keeping in mind that the existing binary release isn't effected
 50 2015-01-11 11:13:21 <wumpus> anther intermediate solution for distros, without any patching (that may introduce further bugs), may be to link 0.9.3 statically to the same version that is used for the gitian builds
 51 2015-01-11 11:13:55 <wumpus> s/version/version of openssl/
 52 2015-01-11 11:14:20 <wumpus> phantomcircuit: right, the gitian releases aren't affected, but some distro packages may be
 53 2015-01-11 11:16:07 <wumpus> if only the distro packages just packaged the gitian executables
 54 2015-01-11 11:17:42 <wumpus> though I understand the practical reasons why that's not the case, e.g. for one we don't have gitian releases for all the platforms and variations they may want to support
 55 2015-01-11 11:20:05 <wumpus> at least in-tree secp256k1 will, in the long run, solve this part of the issue
 56 2015-01-11 11:29:12 <elichai2> hey
 57 2015-01-11 11:30:05 <elichai2> i did sent some mempool request to 'seed.bitcoin.sipa.be' and i'm trying to get the transactions details, and it looks like there aren't existing anywhere
 58 2015-01-11 11:30:18 <elichai2> (not in my own client and not in any online client i tried)
 59 2015-01-11 11:30:51 <elichai2> and over 2 blocks mined since i requested these mempool tx's
 60 2015-01-11 11:31:01 <elichai2> can anyone try verify any of them? http://paste.ubuntu.com/9711029/
 61 2015-01-11 11:32:19 <elichai2> (you can easily do it by this: `while read in; do bitcoin-cli gettransaction "$in"; done < mempool.txt 2>> result; cat result | grep -v error`)
 62 2015-01-11 14:42:07 <elichai2> petertodd, here?
 63 2015-01-11 15:26:35 <michagogo> Hm. After upgrading my VM from precise to trusty, trying to gbuild fails
 64 2015-01-11 15:26:57 <michagogo> bash: cannot set terminal process group (-1): Inappropriate ioctl for device
 65 2015-01-11 15:26:57 <michagogo> bash: no job control in this shell
 66 2015-01-11 15:26:57 <michagogo> --- Building for precise amd64 ---
 67 2015-01-11 15:26:57 <michagogo> Making a new image copy
 68 2015-01-11 15:26:57 <michagogo> micha@Trusty-64-VM:~/build/gitian-builder$ ./bin/gbuild -j4 --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml
 69 2015-01-11 15:26:57 <michagogo> root@Trusty-64-VM:~#
 70 2015-01-11 15:26:57 <michagogo> Stopping target if it is up
 71 2015-01-11 15:27:17 <michagogo> Looks like I'm root, inside the container
 72 2015-01-11 15:28:13 <michagogo> http://i.imgur.com/A53VNYB.png
 73 2015-01-11 15:29:16 <michagogo> Looks like it's at https://github.com/devrandom/gitian-builder/blob/master/libexec/make-clean-vm#L64
 74 2015-01-11 15:31:53 <michagogo> And it looks like it didn't run that command
 75 2015-01-11 15:32:04 <michagogo> erm, the commands in that file*
 76 2015-01-11 15:33:19 <michagogo> I manually ran those commands, and exited, now I'm getting this:
 77 2015-01-11 15:33:20 <michagogo> https://www.irccloud.com/pastebin/dEUCm74t
 78 2015-01-11 15:33:33 <michagogo> So now I'm ubuntu in the container?
 79 2015-01-11 15:34:57 <michagogo> Okay, I think I'll try installing a fresh 14.04... that should rule out a problem with the upgrade, or confirm it
 80 2015-01-11 15:36:29 <Magicking_> Check if you have all your mount points correctly mounted in your container
 81 2015-01-11 15:36:52 <michagogo> Magicking_: I'm not doing any of this myself, this is all gitian managing everything
 82 2015-01-11 15:37:16 <Magicking_> Oh, so your problem is gitian then uh ?
 83 2015-01-11 15:37:28 <michagogo> well, I don't know where it originates
 84 2015-01-11 15:46:02 <earlz> So any news about the potential soft-fork?
 85 2015-01-11 15:49:31 <earlz> Also, what exactly does this do? https://github.com/bitcoin/bitcoin/pull/5640
 86 2015-01-11 15:52:25 <sipa> earlz: d2i_ECDSA_SIG parses the signature using OpenSSL (in a manner that supports non-DER); this parsing may fail, and in that case we shouldn't continue operating with the resulting data
 87 2015-01-11 15:52:54 <sipa> earlz: it is safe as OpenSSL actually clears the data and deallocates cleanly in case of error, and when parsing fails, we don't end up with a valid signature anyway
 88 2015-01-11 15:53:12 <sipa> but it's not very neat code, and hard to argue that it is correct
 89 2015-01-11 15:54:48 <michagogo> Oh, wait.
 90 2015-01-11 15:55:20 <michagogo> I think it's https://github.com/devrandom/gitian-builder/issues/63
 91 2015-01-11 15:56:46 <michagogo> ;;later tell devrandom How hard would it be to detect if lxc-execute is needed (as opposed to lxc-start) and use iy?
 92 2015-01-11 15:56:48 <michagogo> it?*
 93 2015-01-11 15:56:49 <gribble> The operation succeeded.
 94 2015-01-11 15:58:52 <michagogo> ;;later tell devrandom How hard would it be to detect if lxc-execute is needed (as opposed to lxc-start) and use it, rather than leaving a somewhat cryptic error message?
 95 2015-01-11 15:58:53 <gribble> The operation succeeded.
 96 2015-01-11 16:04:25 <michagogo> Yep, that looks like it solved it
 97 2015-01-11 16:05:00 <michagogo> setting LXC_EXECUTE=lxc-execute made it work
 98 2015-01-11 16:05:03 <michagogo> ACTION adds to .profile
 99 2015-01-11 16:44:45 <elichai2> petertodd, here?
100 2015-01-11 17:31:17 <jgarzik> ACTION brings the CloudAtCost server back online
101 2015-01-11 17:31:40 <jgarzik> it randomly stopped responding to pings and ssh a few days ago..   great for a bitcoin node but not much else ;p
102 2015-01-11 17:40:48 <earlz> So, how can extranonce data be put into the coinbase of a block? My understanding is coinbase transactions still needed to be valid
103 2015-01-11 17:41:22 <sipa> the input script of a coinbase transaction is not executed, so it can contain anything
104 2015-01-11 17:41:46 <sipa> the extranonce, as well as auxiliary data commitments, the bip34 height-in-coinbase and other things can be put in it
105 2015-01-11 17:42:45 <earlz> ah, I see
106 2015-01-11 17:43:36 <earlz> where does the 100 byte extranonce limit come from? Is that from bitcoin itself, or just mining pools?
107 2015-01-11 17:44:48 <sipa> it's a consensus rule
108 2015-01-11 17:44:52 <sipa> why? ask satoshi
109 2015-01-11 17:45:31 <earlz> I'll do that ;)
110 2015-01-11 17:45:35 <sipa> oh, the extranonce is just whatever miners choose to put in the coinbase input script; it's the entire script that is limited by consensus to 100 bytes
111 2015-01-11 17:46:11 <sipa> note that bip34 requires that that script starts with a push of the height, meaning the first 4 bytes are fixed
112 2015-01-11 17:46:53 <earlz> and then I assume the extranonce bit makes mining easier (since nonce is easily exhausted) so it really is limited to probably more like 90 or so bytes
113 2015-01-11 17:47:53 <sipa> 4 bytes of extranonce is enough to accomodate 16 exahash/s
114 2015-01-11 17:48:45 <earlz> ah, that would be 64bits, so assuming you can use coinbase for about 92 bytes should be fine
115 2015-01-11 17:50:22 <atgreen> jgarzik: hadn't heard of cloudatcost.. looks nice. But you're saying they are flakey?
116 2015-01-11 18:15:27 <petertodd> elichai2: python-bitcoinlib-v0.3.0 isn't on pip because no-one's done it, and I'm swamped. And frankly, I'm a little dubious about pip's security and don't use it myself.
117 2015-01-11 19:00:49 <michagogo> wumpus: you have an extra /src in your email in the instructions for 0.9 and 0.10
118 2015-01-11 21:22:23 <jgarzik> atgreen, main symptom (across many months) is lots of mysterious pauses
119 2015-01-11 21:22:35 <jgarzik> atgreen, typical of an overloaded VM environment, IMO
120 2015-01-11 22:06:06 <michagogo> I think #5643 can probably be closed...
121 2015-01-11 22:13:54 <phantomcircuit> michagogo, that's weird
122 2015-01-11 22:30:51 <dfletcher> anyone have a comment on this? http://pastebin.com/vwN8uGUE worth doing a pull request? it avoids a DOS shell box popping up for blocknotify and walletnotify
123 2015-01-11 22:31:42 <edcba> use right CreateProcess flahs
124 2015-01-11 22:31:44 <edcba> flags
125 2015-01-11 22:32:18 <edcba> http://stackoverflow.com/questions/780465/winapi-createprocess-but-hide-the-process-window
126 2015-01-11 22:32:20 <dfletcher> ah yeah heh i should've cleaned it up a bit, just got it working a moment ago
127 2015-01-11 22:32:33 <edcba> ie don't use system
128 2015-01-11 22:32:45 <dfletcher> yeah that's what it does
129 2015-01-11 22:33:02 <dfletcher> heh window seems hidden though even without SW_HIDE
130 2015-01-11 22:33:17 <edcba> oh the color hilighting mislead me
131 2015-01-11 22:33:20 <dfletcher> prob because what I actually execute is pythonw.exe
132 2015-01-11 22:33:47 <edcba> then it's not really equivalent i guess
133 2015-01-11 22:34:05 <edcba> maybe system allow urls/documents etc ?
134 2015-01-11 22:34:16 <dfletcher> hmm
135 2015-01-11 22:34:23 <dfletcher> yeah it probably allows .bat too
136 2015-01-11 22:34:32 <dfletcher> which createprocess probably won't
137 2015-01-11 22:34:41 <dfletcher> or well, with cmd.exe in front perhaps
138 2015-01-11 22:34:49 <dfletcher> or `start` maybe
139 2015-01-11 22:34:53 <dfletcher> yeah that's tricky
140 2015-01-11 22:34:58 <edcba> now maybe it's better i don't know where that code is used....
141 2015-01-11 22:36:08 <dfletcher> heh i could code it so if CreateProcess returns false fall back to ::system
142 2015-01-11 22:41:39 <edcba> well you may have a lot of security problems with system like calls
143 2015-01-11 22:42:47 <dfletcher> hmm
144 2015-01-11 22:43:39 <dfletcher> well considering C does not define how system() is actually suppsed to behave I think the security issues probalby already exist and I'm not really exacerbating anything by using an alternate on Windows ;>
145 2015-01-11 22:44:18 <dfletcher> but heh it's not like arbitrary code flows through that util func
146 2015-01-11 22:44:23 <dfletcher> only stuff you put yourself into bitcoin.conf
147 2015-01-11 23:06:33 <dfletcher> ok fleshed out a bit more, I'll test and see how this goes and try it with some other commands like URLs and batch files http://pastebin.com/bmakxrnY
148 2015-01-11 23:14:49 <phantomcircuit> dfletcher, iirc there's a flag in the pe header that changes how system() works
149 2015-01-11 23:15:34 <dfletcher> huh really. and suppress the unnecessary and distracting pop up DOS box?
150 2015-01-11 23:15:54 <dfletcher> this is working nicely at least I have a local solution heh
151 2015-01-11 23:16:12 <phantomcircuit> yes
152 2015-01-11 23:16:20 <dfletcher> i'll check it out
153 2015-01-11 23:33:24 <dfletcher> phantomcircuit, wait are you suggesting changing the PE header of bitcoin-qt.exe ? or the target executable?
154 2015-01-11 23:34:31 <dfletcher> wonder if linking with -Wl,--subsystem,windows would do anything differently
155 2015-01-11 23:34:48 <dfletcher> im having a heck of a time even finding info about this bleh
156 2015-01-11 23:43:17 <phantomcircuit> dfletcher, i've only ever dont it with the visual c++ compiler
157 2015-01-11 23:43:46 <dfletcher> heh yes mingw is not helping me here heh