1 2015-06-01 04:21:16 <hulkhogan_> lol
  2 2015-06-01 04:21:27 <hulkhogan_> wrong chan*
  3 2015-06-01 05:53:40 <petertodd> ahmed_: yo
  4 2015-06-01 06:48:54 <Luke-Jr> wumpus: for whatever reason, GitHub does not show theuni/bitcoin as a PR target
  5 2015-06-01 06:49:50 <wumpus> Luke-Jr: hmm let me see
  6 2015-06-01 06:50:09 <wumpus> he does have pulls, so it worked at some point https://github.com/theuni/bitcoin/pulls
  7 2015-06-01 06:50:30 <Luke-Jr> hm, I wonder if it's because there are 115 commits difference
  8 2015-06-01 06:50:45 <Luke-Jr> manually crafting https://github.com/theuni/bitcoin/compare/theuni:trivial-next…luke-jr:fix_kB works it seem
  9 2015-06-01 06:50:48 <wumpus> could be
 10 2015-06-01 06:51:18 <wumpus> probably it needs to be rebased again
 11 2015-06-01 06:52:28 <Luke-Jr> or just cherry-pick mine into it I guess
 12 2015-06-01 06:52:55 <wumpus> right
 13 2015-06-01 06:53:50 <Luke-Jr> midnightmagic: ?
 14 2015-06-01 06:54:56 <midnightmagic> Luke-Jr: git's merging. It's crap.
 15 2015-06-01 06:55:17 <Luke-Jr> wfm? :P
 16 2015-06-01 06:55:33 <midnightmagic> :-P
 17 2015-06-01 06:55:42 <midnightmagic> conformist!
 18 2015-06-01 06:55:52 <wumpus> then fix it, it's open source :)
 19 2015-06-01 06:55:58 <Luke-Jr> but I use: git config merge.conflictstyle diff3
 20 2015-06-01 06:56:09 <midnightmagic> wumpus: I'm pretty sure I would be sued if I did that.
 21 2015-06-01 06:56:20 <wumpus> ok, this is starting to be off-topic
 22 2015-06-01 06:56:26 <midnightmagic> yes, apologies.
 23 2015-06-01 07:12:13 <wumpus> ooh it's 0.11.1rc1 tagging day
 24 2015-06-01 07:12:24 <wumpus> 0.11.0rc1*
 25 2015-06-01 07:15:58 <Luke-Jr> wumpus: too late for the feerate thing?
 26 2015-06-01 07:50:17 <wumpus> Luke-Jr: not too late, but too controversial it seems
 27 2015-06-01 08:42:57 <wumpus> preliminary 0.11 release notes: https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md
 28 2015-06-01 08:44:06 <wumpus> please let me know if you know more people who "contributed additional code review and/or security research" and needs to be credited
 29 2015-06-01 08:50:12 <wumpus> (who is not already mentioned in the authors list)
 30 2015-06-01 08:54:20 <gmaxwell> wumpus: on the branch please patch libsecp256k1 back to turn off gmp (As we were on 0.10), if you haven't yet
 31 2015-06-01 08:54:58 <wumpus> gmaxwell: isn't that supposed to be addressed already by the various secp256k1 updates?
 32 2015-06-01 08:55:04 <gmaxwell> (right now that actually breaks bitcoin on my ppc64 host-- causing a crash at runtime-- because of some snafu with 32bit vs 64bit headers)
 33 2015-06-01 08:55:40 <wumpus> the original 'promise' there was that we had to hot-patch the 0.10 branch but that it'd be solved in master by a secp256k1 upgrade, and there have been several
 34 2015-06-01 08:55:49 <gmaxwell> wumpus: no, libsecp256k1 autodetects gmp and uses it if there, but we currently want it not using it in bitcoin core.  ('uses' is somewhat in accurate, it links it but only the init code even calls it)
 35 2015-06-01 08:56:36 <wumpus> there needs to be a more robust solution to this
 36 2015-06-01 08:56:52 <gmaxwell> wumpus: okay pieter should be back soon, then.  But no its still enabled in 0.11 as of last week.
 37 2015-06-01 08:57:00 <wumpus> (using the 0.10 solution for 0.11 is fine with me, but we keep pushing this ahead)
 38 2015-06-01 08:57:20 <wumpus> should we disable it upstream?
 39 2015-06-01 08:57:48 <gmaxwell> well at some point I think we'll be fine with having it on; I'd even say I was fine now with having it on, except for the aformentioned crash at runtime on one ppc64 host (which might just be a local issue)
 40 2015-06-01 08:58:19 <wumpus> ok
 41 2015-06-01 08:58:30 <gmaxwell> It's on the order of a 20% improvement for verification.    We may just implement the single operation we use it for directly in libsecp256k1.
 42 2015-06-01 08:59:01 <gmaxwell> (it has a VERY fast non-constant time modular inverse; which is only used for verification and building the tables at init)
 43 2015-06-01 08:59:43 <wumpus> agreed, 20% is no small fries - though that will only be relevant as soon as we use secp256k1 in bitcoin core
 44 2015-06-01 08:59:53 <wumpus> +for verification
 45 2015-06-01 08:59:58 <gmaxwell> yea, thats why disabling it was a no brainer.
 46 2015-06-01 09:00:16 <gmaxwell> but also why we don't just drop it entirely from upstream.
 47 2015-06-01 09:01:40 <wumpus> I agree. I suppose the most sensible is to make bitcoin core pass a flag to secp256k1's configure to disable using gmp
 48 2015-06-01 09:02:33 <wumpus> is this --with-bignum=no?
 49 2015-06-01 09:02:37 <gmaxwell> yes
 50 2015-06-01 09:03:35 <jeremias> "One such application is selective Tor usage, where the node runs on the normal internet but transactions are broadcasted over Tor."
 51 2015-06-01 09:03:44 <jeremias> really nice feature, thanks!
 52 2015-06-01 09:08:09 <wumpus> jeremias: yes it's nice to have a mechanism for that now
 53 2015-06-01 09:19:06 <wumpus> gmaxwell: https://github.com/bitcoin/bitcoin/pull/6210
 54 2015-06-01 09:20:11 <wumpus> gmaxwell: note regarding testing: I had to clean my git tree for the internal secp256k1 to pick up on the configure arguments change
 55 2015-06-01 09:49:20 <Luke-Jr> wumpus: fwiw, --without-* is equivalent to --with-*=no
 56 2015-06-01 10:14:17 <wumpus> Luke-Jr: right, makes sense
 57 2015-06-01 10:28:32 <petertodd> wumpus: it'd be helpful for that off-by-one error with nLockTime to get released in v0.11, which would allow v0.12 to use the right nLockTime for the anti-fee-sniping protection. Right now if it did that payments wouldn't show up in v0.11 wallets
 58 2015-06-01 10:28:46 <wumpus> petertodd: yes
 59 2015-06-01 11:26:50 <wumpus> cfields: can you take a look at https://github.com/bitcoin/bitcoin/pull/6210?
 60 2015-06-01 12:34:57 <morcos> wumpus: you're going to merge 6172 before rc1 right? or some other solution?
 61 2015-06-01 13:20:39 <jonasschnelli> wumpus: regarding the osx "Bitcoin-Core" rename. What about reverting the renaming of the application-bundle and only keep the renaming of the disk image?
 62 2015-06-01 13:22:38 <jonasschnelli> I think the rename would have only made sense if we had renamed all bitcoin-qt binaries on all platforms (which we disagreed to because this would be to risky and without sense)
 63 2015-06-01 15:33:43 <hexu> hi, is there any admin to bitcoinstats website here online?
 64 2015-06-01 16:07:50 <jonasschnelli> hexu: ask cdecker
 65 2015-06-01 16:23:33 <wumpus> morcos: sure, though I'd hoped to get some more (ut)ACKs there
 66 2015-06-01 16:30:06 <wumpus> morcos: does it need to go into 0.10 too?
 67 2015-06-01 16:35:41 <wumpus> jonasschnelli: on windows the installer script can do things like remove old, stale files
 68 2015-06-01 16:36:12 <wumpus> jonasschnelli: although if you want to install in a different directory, you get two installed instances
 69 2015-06-01 16:37:04 <wumpus> jonasschnelli: so it's sort of the same. BUt the installer script is somewhat smarter if the path changes, I think. people upgrading it will reuse the same directory, for people installing anew it will use the new one.
 70 2015-06-01 16:42:48 <cfields> jonasschnelli: did you look through all .plist keys to make sure there's no concept of "replaces"? IIRC android has that for activities, so I'd be surprised if ios/osx didn't have some similar concept
 71 2015-06-01 16:43:27 <morcos> wumpus: no, its not needed for 0.10 i don't think...
 72 2015-06-01 16:46:10 <morcos> yeah i was also hoping it would get more eyes, perhaps sipa will take a look when he returns
 73 2015-06-01 17:05:47 <CodeShark> Why the rush to increase block size?!?!?! Is something about to happen to Bitcoin that I don't know about?
 74 2015-06-01 17:06:21 <StephenM347> CodeShark: most miners leave the max block size limit at the default 750 kb. We are now having ~500 kb blocks on average.
 75 2015-06-01 17:08:38 <CodeShark> I'm far more concerned about the centralization of verification and the inability for new clients to sync up efficiently than I am about confirmation delays, to be quite honest - especially in regards to mass adoption
 76 2015-06-01 17:09:17 <helo> CodeShark: there hasn't been "hard" block size pressure yet. a lot of wallet software (including core), business plans, and other software/dreams weren't created to gracefully handle the consequences.
 77 2015-06-01 17:09:53 <CodeShark> most of those things you listed weren't built to handle very much of any kind of pressure :p
 78 2015-06-01 17:09:55 <helo> the software stuff can mitigate many of the problems (so i see that part as mostly a red herring)
 79 2015-06-01 17:10:28 <StephenM347> CodeShark: and that's where you'll find many who agree and disagree with you. I am of the opposite opinion, that hitting the limit would cause usability problems, and turn people away from bitcoin
 80 2015-06-01 17:10:58 <helo> people's utopic dreams and business contraptions may not allow for a significant deviation from the current free-flowing transaction situation
 81 2015-06-01 17:11:09 <CodeShark> I'm not saying it won't cause problems - it just seems a case of misplaced priorities - and a bit of a late reaction to a problem we all saw coming a long time ago
 82 2015-06-01 17:11:43 <CodeShark> the bitcoin core data structures inherently do not support very much scalability
 83 2015-06-01 17:13:28 <CodeShark> just increasing the block size seems like a brute-force way of avoiding having to deal with the issue for another little while
 84 2015-06-01 17:13:44 <helo> it is, that is how gavin referred to it
 85 2015-06-01 17:17:38 <CodeShark> we can pretty much give up on any new users being able to participate much in validation and mining, I suppose
 86 2015-06-01 17:20:00 <CodeShark> wallets will eventually just become dumb signers
 87 2015-06-01 17:20:58 <CodeShark> SPV still has a linear complexity factor (at least), significantly complicates client-side logic, and lacks a solid security model
 88 2015-06-01 17:22:48 <CodeShark> and we have to continue supporting a protocol that we know is flawed in many ways because most of the software written atop it is crappy :p
 89 2015-06-01 17:26:45 <helo> i hope the implication of calling it "kicking the can down the road" is that a more encompassing solution can obviate the need for it
 90 2015-06-01 18:20:10 <jonasschnelli> cfields, wumpus: i think there is no concept/function in osx to replace application installed in the way we use.
 91 2015-06-01 18:20:36 <cfields> jonasschnelli: yea, i looked around an came to the same conclusion :\
 92 2015-06-01 18:21:13 <jonasschnelli> i mean the rename PR (merged), is kind of a android/ios like thing. It uses the same bundle identifier. But most users still use the filesystem to start applications
 93 2015-06-01 18:21:13 <wumpus> ok, thanks for checking
 94 2015-06-01 18:21:16 <cfields> jonasschnelli: though i really don't think it's a big issue. I was happy to see (when testing) that it worked better than i would've hoped
 95 2015-06-01 18:21:24 <jonasschnelli> they go to /Applications folder and double click (old style)
 96 2015-06-01 18:21:49 <jonasschnelli> but as written in #6212, my main concerns are the mix between osx and win/linux.
 97 2015-06-01 18:22:02 <jonasschnelli> users start to mean the same application but are using different names.
 98 2015-06-01 18:22:07 <wumpus> cfields: well we had the same issue on windows once where people ended up with two versions, it resulted in quite a lot of trouble, people using either version alternatingly etc...
 99 2015-06-01 18:22:35 <jonasschnelli> but i still feel that bitcoin-qt as a application name (binary) is not ideal. But i can live with it. :)
100 2015-06-01 18:22:38 <wumpus> an upgrade should not result in the application being installed twice
101 2015-06-01 18:23:20 <jonasschnelli> wumpus: agreed. OSX softwaremanagement is slightly uncommon.
102 2015-06-01 18:23:50 <jonasschnelli> On the other hand it is cool to just copy one folder to another system and *bing* application is installed.
103 2015-06-01 18:24:01 <cfields> right. In OSX, you really don't install in the typical sense. You drag the app to whereever you want it.
104 2015-06-01 18:27:55 <wumpus> right
105 2015-06-01 18:29:56 <wumpus> well, if you think this will give no problems, and mac users can handle this, I'm fine with it
106 2015-06-01 18:30:10 <wumpus> I just don't want zillions of complaining users for a stupid name change
107 2015-06-01 18:31:16 <cfields> jonasschnelli: did you look into CFBundleDisplayName at all?
108 2015-06-01 18:32:02 <cfields> I wonder if we could keep the name on the filesystem the same, but change the CFBundleDisplayName, and have the app display as "Bitcoin Core"
109 2015-06-01 18:32:10 <wumpus> that'd be nice
110 2015-06-01 18:32:20 <jonasschnelli> wumpus: i think they can handle. But don't you have a bad feeling that new bitcoin osx users don't know what bitcoin-qt is and linux users getting confused because bob who uses a mac and talk about bitcoin-core and alice who uses linux thinks he talks about bitcoind?
111 2015-06-01 18:32:54 <wumpus> jonasschnelli: I don't really mind that, different platforms can be slightly different
112 2015-06-01 18:32:55 <jonasschnelli> cfields: i know CFBundleDisplayName from iOS. This could work... let me check
113 2015-06-01 18:33:04 <wumpus> jonasschnelli: it has been called Bitcoin Core on e.g. windows for ages
114 2015-06-01 18:33:25 <wumpus> jonasschnelli: there people don't see the executable name at all in normal use
115 2015-06-01 18:33:50 <jonasschnelli> wumpus: right. But the application name (which they actually double click to start) is named as "bitcoin-qt". IMO it's that what count.
116 2015-06-01 18:33:51 <cfields> same for osx, it's only the bundle (app) name that's ever visible to end-users
117 2015-06-01 18:34:16 <wumpus> jonasschnelli: no, it's not - the application name in the menu is bitcoin core
118 2015-06-01 18:36:04 <jonasschnelli> wumpus: ah. Okay. Maybe i was only playing around with self-built bitcoin-qt's on windows.
119 2015-06-01 18:36:21 <jonasschnelli> I think the CFBundleDisplayName could work. Let me try this tmr.
120 2015-06-01 18:36:54 <cfields> looking in win7 vm right now. "Bitcoin Core/Bitcoin Core (x-bit)" in start menu. "Bitcoin Core - Wallet" in taskbar. Only task manager says bitcoin-qt.exe.
121 2015-06-01 18:37:09 <wumpus> cfields: right, that's how I remember it too
122 2015-06-01 18:49:49 <jzk> the sword of damocles hangs over the developers by a single blockchain
123 2015-06-01 18:51:03 <wumpus> jzk: ?
124 2015-06-01 19:25:21 <paveljanik> looks like the attack to the Bitcoin Core developers is orchestrated. This time, it is about name calling. Keep calm and concentrate on the technical side of the problem(s), please.
125 2015-06-01 19:37:03 <wumpus> let's at least try to keep it out of here
126 2015-06-01 22:46:27 <raisemenow> test
127 2015-06-01 23:03:22 <Mattx> Hey people!
128 2015-06-01 23:03:49 <Mattx> I'm trying to find out how to use these "HD wallets" like electrum. has anyone used them in any project?
129 2015-06-01 23:04:26 <Mattx> I like the idea of Electrium but it seems it's only a client app, implementing a BIP32 protocol or something
130 2015-06-01 23:04:47 <Mattx> how am I intended to use them in an app?
131 2015-06-01 23:05:17 <Luke-Jr> Mattx: #electrum or #bitcoin
132 2015-06-01 23:05:18 <Mattx> s/intended/supposed/
133 2015-06-01 23:05:40 <Mattx> Luke-Jr, none reads #electrium, #bitcoin is not for dev topics, is it?
134 2015-06-01 23:05:47 <Luke-Jr> Mattx: your topic is not a dev topic.
135 2015-06-01 23:06:10 <Mattx> of course it is, I'm developing an app and I want to use an HD wallet
136 2015-06-01 23:06:32 <Luke-Jr> Mattx: you're developing an app, you're not develping Bitcoin.
137 2015-06-01 23:06:48 <Mattx> oh, well, so this channel is for developers of bitcoins only :P
138 2015-06-01 23:07:01 <Mattx> I'm joining #bitcoin, thanks
139 2015-06-01 23:07:11 <Luke-Jr> np