1 2015-06-27 00:11:16 <jtimon> petertodd then I guess the answer to my question "can softforks be voted with the old and new system simultaneusly?" is no
  2 2015-06-27 02:33:29 <Rozal> Anyone here with an iOS dev account
  3 2015-06-27 02:42:39 <Luke-Jr> hum, someone is actually using bitcoind on x32 now
  4 2015-06-27 03:29:49 <phantomcircuit> Luke-Jr, interesting
  5 2015-06-27 03:41:05 <brand0> x32 is common in low-cost VMs
  6 2015-06-27 03:41:33 <phantomcircuit> brand0, requires a special build
  7 2015-06-27 03:41:47 <brand0> yes, I am familiar :(
  8 2015-06-27 04:06:26 <Luke-Jr> good to see x32 taking off finally
  9 2015-06-27 04:41:58 <Diablo-D3> [11:41:05] <brand0> x32 is common in low-cost VMs
 10 2015-06-27 04:42:06 <Diablo-D3> brand0: no, it is common in incompetent VMs
 11 2015-06-27 04:43:14 <Diablo-D3> first of all, please don't call it x32, x32 has a specific meaning, this is not it
 12 2015-06-27 04:43:23 <Diablo-D3> ia32 vs amd64, x86 vs x86-64, both valid
 13 2015-06-27 04:43:29 <Diablo-D3> x32 vs x64, NEITHER are valid.
 14 2015-06-27 04:44:41 <Diablo-D3> that said, running x86 code on a native x86-64 means, on average, a 15-20% loss in computation power, due to conversion done entirely in microcode, and compilers being unable to optimize a lot of code well due to lack of registers
 15 2015-06-27 04:45:05 <Diablo-D3> when you're already trying to get as much margin out of a server as possible, a 20% loss of CPU time, just thrown away, is just fucking retarded
 16 2015-06-27 04:45:30 <Diablo-D3> now, as for memory usage, due to pointers and longs being promoted to 64 bit, this is not an issue
 17 2015-06-27 04:45:44 <Diablo-D3> for apps heavily effected by this issue, it is about a 5% increase in memory usage
 18 2015-06-27 04:45:51 <Diablo-D3> for apps not effected by it, it is so low it is not worth meansuring
 19 2015-06-27 04:49:04 <phantomcircuit> Diablo-D3, Luke-Jr actually meant x32
 20 2015-06-27 04:51:06 <Diablo-D3> phantomcircuit: wait, like, real x32? linux's "thumb for x86-64" shit/
 21 2015-06-27 04:51:32 <Diablo-D3> Ive seen it in changelogs for gcc/clang, libc, and the kernel for awhile now
 22 2015-06-27 04:51:37 <Diablo-D3> is anyone using it for prod?
 23 2015-06-27 05:46:42 <wumpus> Diablo-D3: please take your rants elsewhere
 24 2015-06-27 05:48:48 <brand0> Diablo-D3, semantics
 25 2015-06-27 05:48:54 <Diablo-D3> wumpus: not a rant, just correcting someone
 26 2015-06-27 05:49:51 <brand0> I was only speaking to difficulties in compiling bitcoin/bitcoin-qt in x86, 32-bit native, environments
 27 2015-06-27 05:52:35 <wumpus> what difficulties? we test on 32 and 64 bit x86, as well as 32 bit ARM, it shouldn't be anything more problematic
 28 2015-06-27 05:55:21 <brand0> shit, i meant x86-64 32-bit non-native, I shouldn't be speaking and drinking here
 29 2015-06-27 05:56:07 <Diablo-D3> brand0: you mean compiling 32 bit binaries on a 64 bit machine?
 30 2015-06-27 06:02:44 <wumpus> cross-compiling bitcoin should be easy too, especially with the depends system. gitian does this too - everything is built in a 64-bit VM
 31 2015-06-27 06:06:41 <wumpus> ./configure --host=i686-pc-linux-gnu  should do to build for x86-32
 32 2015-06-27 06:10:13 <wumpus> gmaxwell: https://github.com/laanwj/bitcoin/tree/2015_06_softforkinfo  adds softfork status to getblockchaininfo, I use this locally but never bothered to submit it because next softforks will use a different system
 33 2015-06-27 06:14:03 <Diablo-D3> yeah what wumpus said
 34 2015-06-27 06:14:12 <Diablo-D3> afaik bitcoin's autoconf script is sane and should work correctly
 35 2015-06-27 06:14:45 <Diablo-D3> all you need is a correctly built gcc and binutils built for cross compiling, and 32 bit copies of any external dep libs
 36 2015-06-27 06:50:31 <leakypat> Anyone know how I should build secp256k1 on windows?
 37 2015-06-27 07:06:00 <Luke-Jr> leakypat: why do you think that you want to?
 38 2015-06-27 07:07:50 <wumpus> leakypat: secp256k1 is extremely portable; just point any C compiler at the proper file in src/
 39 2015-06-27 07:08:48 <wumpus> shouldn't matter whether it's on windows or linux or embedded VxWorks for that matter
 40 2015-06-27 07:09:54 <Luke-Jr> (but note the authors will get annoyed if you actually try to use it for now)
 41 2015-06-27 07:12:17 <wumpus> I think they like when people try to compile it as well as test it on weird systems, I didn't say anything about using it *ducks*
 42 2015-06-27 07:14:10 <Luke-Jr> ☺
 43 2015-06-27 07:16:46 <leakypat> I'm actually trying to build BitcoinD using visual studio 2012 if there is a quicker way...
 44 2015-06-27 07:17:53 <leakypat> I had a successful build for 0.8 now trying to migrate it for 0.10
 45 2015-06-27 07:23:11 <jonasschnelli> leakypat: you might read https://bitcointalk.org/index.php?topic=149479.0  But i'm pretty sure you are much faster when you download VMBox (or buy VMWare), install Ubuntu, and cross-compile for windows.
 46 2015-06-27 07:27:56 <leakypat> jonasschnelli wumpus cool, thanks
 47 2015-06-27 07:28:34 <Luke-Jr> leakypat: for a long time, Visual Studio did not support C; I am not sure if that has changed in recent years.
 48 2015-06-27 07:28:54 <jonasschnelli> leakypat: if you want to have a setup where you can debug and test changes, don't use windows. You can use it as host system, but it's really recommended to dev on linux (or osx).
 49 2015-06-27 07:31:46 <leakypat> I see, well my end goal is to build a windows version of the Full RBF patched version, so it sounds like the cross compile method will be the best
 50 2015-06-27 07:32:03 <Luke-Jr> indeed
 51 2015-06-27 07:32:59 <jonasschnelli> leakypat: is there a according github PR? if yes, i can kick a gitian build (https://builds.jonasschnelli.ch/pulls/).
 52 2015-06-27 07:34:22 <leakypat> Yes, let me find it
 53 2015-06-27 07:35:42 <leakypat> https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2?files=1
 54 2015-06-27 07:36:19 <jonasschnelli> leakypat: can you search the bitcoin/bitcoin PR number?
 55 2015-06-27 07:39:49 <jonasschnelli> anyone knows by heart what CWalletTX::nTimeSmart is for?
 56 2015-06-27 07:40:57 <gmaxwell> jonasschnelli: trying to produce a time for transactions which behaves in a way that doesn't surprise the heck out of users.
 57 2015-06-27 07:41:42 <jonasschnelli> gmaxwell: Okay. I see.
 58 2015-06-27 07:41:58 <jonasschnelli> gmaxwell: but what's wrong with nTimeReceived?
 59 2015-06-27 07:42:19 <gmaxwell> because your node can be offline.
 60 2015-06-27 07:43:25 <jonasschnelli> gmaxwell: aha. so nTimeSmart is a try to "guess" or "produce" a relative realistic wtx receive time?
 61 2015-06-27 07:44:21 <gmaxwell> jonasschnelli: right. It synthesizes a time out of several potential sources based on the available data. Basically taking several different kinds of bug reports from users into account.
 62 2015-06-27 07:44:41 <gmaxwell> it must be doing something right because people basically never complain about the times now... they used to pretty often.
 63 2015-06-27 07:44:48 <wumpus> indeed gmaxwell
 64 2015-06-27 07:45:36 <jonasschnelli> Okay....
 65 2015-06-27 07:45:55 <Luke-Jr> the only thing I regret about smart times, is that if you send before sync'd, it can mess it up
 66 2015-06-27 07:46:03 <jonasschnelli> I wasn't aware of the fact, that the wallet is deeply coupled to the core part over mapBlockIndex and mempool interactions...
 67 2015-06-27 07:46:11 <Luke-Jr> since the send tx time influences the smart time for syncing txs
 68 2015-06-27 07:46:51 <jonasschnelli> somehow i like to keep the new wallet as independent as possible to allow later process separation...
 69 2015-06-27 07:47:41 <Luke-Jr> jonasschnelli: as I've said before, best to design it separate from the start..
 70 2015-06-27 07:48:22 <jonasschnelli> Luke-Jr: i think this is a unrealistic approach (separate from the beginning).
 71 2015-06-27 07:48:55 <leakypat> jonasschnelli: it looks like #4298 , maybe petertodd can confirm this is he correct one?
 72 2015-06-27 07:49:00 <Luke-Jr> I don't see why. It seems plainly easier.
 73 2015-06-27 07:50:10 <jonasschnelli> Luke-Jr: complete separation would mean to copy base/primitive classes (or include over submodule). Use a separate RPC server, decouple everything. The UI as well as the hole wallet interacts deeply with the full node.
 74 2015-06-27 07:50:54 <Luke-Jr> jonasschnelli: well, the wallet could be implemented as a library, and just have the minimal tie-ins in Core itself, for example
 75 2015-06-27 07:51:05 <jonasschnelli> Long term: yes. From the beginning separated would mean to include many changes in the core without actually a obvious benefit. These PR will have a hard time. :)
 76 2015-06-27 07:51:36 <jonasschnelli> Luke-Jr: i agree with that. It's also my long term goal. But i think it would fail if you move to fast...
 77 2015-06-27 08:06:45 <btcdrak> BIP66 upgrade status: v2: 98/1000, v3: 902/1000
 78 2015-06-27 08:09:59 <Luke-Jr> huh?
 79 2015-06-27 08:10:04 <Luke-Jr> oh
 80 2015-06-27 08:10:50 <jonasschnelli> leakypat: #4298 is pretty old und un-rebased. I think i can't built that on my gitian system... needs rebase first... but i give it a try anyways
 81 2015-06-27 08:11:10 <leakypat> jonasschnelli: I think that pull request is closed because it wasn't going to get acked, hence he ended up doing it in his own repo
 82 2015-06-27 08:11:25 <leakypat> So it's an alternative client basically
 83 2015-06-27 08:11:46 <Luke-Jr> pretty sure it was never PR'd
 84 2015-06-27 08:12:10 <Luke-Jr> well, not the "non-PR" version anyhow
 85 2015-06-27 08:12:11 <jonasschnelli> leakypat: if you have a gitian setup ready, you can build it yourself.
 86 2015-06-27 08:12:35 <leakypat> Sounds like that would be the best thing for me to do
 87 2015-06-27 08:13:13 <leakypat> I found the doc on GitHub
 88 2015-06-27 08:15:06 <leakypat> Actually this is for Debian , is this preferable to Ubuntu ?
 89 2015-06-27 08:18:23 <jonasschnelli> leakypat: You can also do it with ubuntu.
 90 2015-06-27 08:18:44 <wumpus> although the  document was written using debian, ubuntu is almost the same in that regard
 91 2015-06-27 08:18:53 <jonasschnelli> I would recommend to use a linux as host system and use KVM. I never got LXC running (and believe me, i tried!).
 92 2015-06-27 08:19:31 <jonasschnelli> If you have a remote vserver or a root server, this is probably the best option.
 93 2015-06-27 08:19:48 <wumpus> jonasschnelli: yes, KVM on real machine (not VM) is absolutely easier (instead of LXC in a VM), if possible
 94 2015-06-27 08:20:00 <wumpus> the reason for using LXC in that guide is that KVM in a VM gives problems
 95 2015-06-27 08:20:44 <wumpus> (e.g. it assumes people will be using virtualbox on say, windows, and want to build in that, then KVM won't work)
 96 2015-06-27 08:20:53 <jonasschnelli> I also tried KVM in a VMWare VM with enabled KVM support... but didn't succeed. After investing serval hours (or even days) i thought it gona be easier if i just use a root server...
 97 2015-06-27 08:21:30 <wumpus> using KVM is much easier if you already have, say, an Ubuntu machine ready to use, maybe it makes sense to do a write-up on that as well
 98 2015-06-27 08:22:06 <wumpus> yes the nested KVM support I also never got to work.
 99 2015-06-27 13:04:46 <leakypat> jonasschnelli: so I'm trying with windows running Ubuntu on virtual box, then on the virtual box i am using LXC
100 2015-06-27 13:06:23 <leakypat> When I run the build I get a "Warning: kvm not loaded, this will probably not work out" message
101 2015-06-27 13:34:23 <aliakbar> Hi! Can someone think of a cause for my bitcoind regtest node crashing? following problem: ive changed changed "SendMessages" function of "main.cpp" in a way PushMessage("inv") is skipped when a if-statement (added by myself) turns true. I'm using "pto" (of class CNode) in my if-statement. When connected to more than 1 peer the server gets disconnected after "setgenerate true ...".
102 2015-06-27 13:38:06 <wumpus> if you changed code, that's probably the cuase of the crash. But in any case, in case of a crash run it in a debugger (usually gdb) and get a traceback
103 2015-06-27 13:41:23 <aliakbar> wumpus: I didn't change the flow of program anywhere except for one place I added an additional function in order to clone a vector: I mimicked what other similar functions did, namely LOCK(cs_inventory)
104 2015-06-27 13:41:27 <aliakbar> May this be the cause?
105 2015-06-27 13:43:15 <aliakbar> wumpus: i created a function and named it AddHonestInventory in the way AddInventoryKnown was introduced: https://github.com/bitcoin/bitcoin/blob/v0.10.0/src/net.h#L383
106 2015-06-27 13:44:26 <wumpus> as said, you should get a traceback where the crash happens, that will tell you more
107 2015-06-27 13:51:57 <aliakbar> wumpus: ok, thanks a lot though! I'll try to get familiar with gdb and backtrace!
108 2015-06-27 13:58:34 <leakypat> make-base-vm gives me "chroot: failed to run command 'mount' : Exec format error"
109 2015-06-27 14:16:11 <leakypat> I'm an idiot , wrong architecture for my virtual box OS
110 2015-06-27 14:30:28 <langerhans> hey there! is someone around who is informed about the DoS issue that was topic on the mailing list today?
111 2015-06-27 15:37:43 <petertodd> jtimon: actually, softforks can be signaled by old and new simultaneously, in the sense that any pending soft-forks using the old system can be signalled while the new system is itself being signalled
112 2015-06-27 15:38:31 <petertodd> jtimon: soft-forks on the new system can also be signalled while it is being signalled into existance, but that's a level of complexity that we'd probably not bother to actually do
113 2015-06-27 15:47:46 <petertodd> leakypat: there is (currently) no full-RBF pull-req; the 0.10.2 tree you mentioned is correct, and there is a similar tree for 0.11.0rc2: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.11.0rc2
114 2015-06-27 15:47:55 <petertodd> leakypat: (though the 0.11 tree has had little testing!)
115 2015-06-27 16:25:17 <xxd1> Hi, I'd like feedback on 8MB block size increase.
116 2015-06-27 16:25:26 <xxd1> Specifically this post...
117 2015-06-27 16:25:28 <xxd1> "For the record, I'm against "extremists" who want 20MB or nothing, but also against those at the other extreme who are being too fearful of moving past 1MB. I've voiced concerns of higher caps in the past, but raising to 4MB (or even 8MB) surely is not the end of the world, and as the common refrain among core devs has gone, I think these sizes are "within safety limits", yes? Even if we lose some nodes on the margin, so what? Pra
118 2015-06-27 16:25:48 <xxd1> Okay it didn't show up, here's the link to the post: https://www.reddit.com/r/Bitcoin/comments/3bajai/by_expecting_a_few_developers_to_make/cskibr0
119 2015-06-27 16:26:11 <xxd1> gmaxwell: are you here?
120 2015-06-27 16:26:42 <xxd1> You would probably be the most ideal person to comment on this.
121 2015-06-27 16:27:42 <xxd1> or Luke-Jr...
122 2015-06-27 16:28:18 <xxd1> or cdecker! Wow, didn't know he was here too.
123 2015-06-27 16:46:34 <mjerr> [HD] It is possible to derive M/0'/0' and the complete chain under it, by knowing only M\0', right?
124 2015-06-27 17:06:39 <jonasschnelli> mjerr: No.
125 2015-06-27 17:06:51 <jonasschnelli> By knowing M: yes.
126 2015-06-27 17:06:57 <mjerr> yea, I mean the private key
127 2015-06-27 17:07:09 <jonasschnelli> Okay. Then yes.
128 2015-06-27 17:07:44 <mjerr> it's like its a new root again, right?
129 2015-06-27 17:07:53 <jonasschnelli> If you have the private extended key you can derive any child and child of child, etc.
130 2015-06-27 17:08:16 <mjerr> right, then I don't understand the bitcoinj implementation of it :/
131 2015-06-27 17:08:41 <jonasschnelli> mjerr: i don't know the bitcoinj implementation... whats wrong there?
132 2015-06-27 17:09:12 <mjerr> Trying to initiate a DeterministicKey object with a privkey gives me Depth is 41 and no parent key was provided, so we cannot reconstruct the key path from the provided data.
133 2015-06-27 17:09:29 <jonasschnelli> mjerr: but a wallet should not keep a ext private key in the database IMO. Only the ext pub key of the external chain.
134 2015-06-27 17:10:37 <mjerr> you mean only the very root key should be saved?
135 2015-06-27 17:11:01 <jonasschnelli> I assume you want to derive pub-keys/addresses?
136 2015-06-27 17:11:46 <mjerr> No, I'm working on a lightning implementation currently, trying to implement the way keys should be stored
137 2015-06-27 17:12:02 <mjerr> so we need to be able to sign and to give away some priv keys
138 2015-06-27 17:12:45 <jonasschnelli> As said, i don't know the bitcoinj implementation. But you should be able to take a extented private key and derive the next depth/child at index of it.
139 2015-06-27 17:13:15 <mjerr> yea no problem, you assured me anyway, as I had it laid out in my head correctly at least ;)
140 2015-06-27 17:13:16 <jonasschnelli> You can also use a non-hardened ext pub key to derive subkeys.
141 2015-06-27 17:14:30 <mjerr> but then I can't give away single privkeys?
142 2015-06-27 17:15:59 <jonasschnelli> No. Public parent key can only derive public child keys.
143 2015-06-27 17:16:36 <mjerr> But knowing a public key and any child private key does expose the whole chain?
144 2015-06-27 17:19:04 <jonasschnelli> (afk: back in 45min)
145 2015-06-27 17:19:10 <mjerr> sure
146 2015-06-27 17:33:49 <langerhans> sorry to ask again, but any dev around with knowledge about the DoS topic from today? I don't want details, just confirm something real quick :)
147 2015-06-27 17:40:04 <xxd1> Bitcoin transactions/second (TPS) rate is now averaging 1.8, only 0.5 TPS (27%) away from TradeBlock's 2.3 TPS "wall": https://tradeblock.com/blog/bitcoin-network-capacity-analysis-part-4-simulating-practical-capacity
148 2015-06-27 17:40:42 <harding> gmaxwell, other devs: do you need anything from Bitcoin.org regarding the DoS stuff?  We still have the 'alert' mechanism that will put a banner on the top of every page.
149 2015-06-27 17:41:30 <harding> xxd1: conversation about the block size debate is probably better addressed to #bitcoin
150 2015-06-27 17:42:04 <xxd1> Oh, okay thanks.
151 2015-06-27 18:06:44 <xxd1> Hey harding, sorry to pop in again, but I noticed the Reddit thread (on this: https://tradeblock.com/blog/bitcoin-network-capacity-analysis-part-4-simulating-practical-capacity) was never participated in by gmaxwell or any other developer. Can you please fwd this analysis to them? Also to Wladamir, and whoever else is concerned?
152 2015-06-27 18:07:28 <xxd1> I don't know how else to get in touch with these people.
153 2015-06-27 18:10:32 <rnicoll> There's a lot of discussion on the bitcoin-dev mailing list
154 2015-06-27 18:11:04 <rnicoll> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev - but do catch up with the discussion before diving in, there's a lot to read
155 2015-06-27 18:21:30 <jonasschnelli> mjerr: IIRC, if you have an attacker knows your a *hardened* extended pub key and a derived child private key, thats save IMO.
156 2015-06-27 18:21:59 <jonasschnelli> if you give out child private keys your should derive them from a hardened parent key.
157 2015-06-27 18:34:03 <xxd1> Okay rnicoll thanks
158 2015-06-27 22:20:57 <berndj> is a:mail.linuxfoundation.org a good entry to add to a domain's SPF, or is that hopelessly flawed?