1 2014-12-15 00:17:17 <Luke-Jr> tdlfbx: you have the wrong channel, this is #bitcoin-dev
  2 2014-12-15 00:17:43 <Luke-Jr> oh, missed the second part
  3 2014-12-15 00:17:58 <tdlfbx> 
ACTION deletes snarky response.

  4 2014-12-15 00:18:09 <Luke-Jr> tdlfbx: I speculate you will see similar results if you do % 0x10000 as well
  5 2014-12-15 00:18:28 <Luke-Jr> tdlfbx: that is, you're looking at it in the opposite endian the miner is, and they're counting upward
  6 2014-12-15 00:18:46 <Luke-Jr> (and restarting at 0 when there's a new block or whatever)
  7 2014-12-15 00:19:53 <tdlfbx> here's the same thing, by bit: http://pbrd.co/1wxg3VO
  8 2014-12-15 00:20:13 <sipa> tdlfbx: which block range?
  9 2014-12-15 00:20:18 <tdlfbx> all of them.
 10 2014-12-15 00:20:40 <tdlfbx> height 334337
 11 2014-12-15 00:20:43 <sipa> ignore the first 100k and see if you get the same result
 12 2014-12-15 00:21:13 <tdlfbx> sipa yes basically same result
 13 2014-12-15 00:21:17 <sipa> very early on, the nonce ranges were rarely explored entirely before starting over
 14 2014-12-15 00:21:20 <sipa> ok
 15 2014-12-15 00:21:28 <Luke-Jr> sipa: even today, there are patterns
 16 2014-12-15 00:21:36 <Luke-Jr> for example, bitfury chips only scan 768/1024 of the nonces
 17 2014-12-15 00:21:45 <tdlfbx> This isn't nearly as bad as what's going on with scrypt.  But it has me slightly concerned.
 18 2014-12-15 00:22:00 <Luke-Jr> tdlfbx: it's patterns in the searching, not biases in the result
 19 2014-12-15 00:22:05 <Luke-Jr> for Bitcoin, at least
 20 2014-12-15 00:22:47 <tdlfbx> Luke-Jr: That was my first thought
 21 2014-12-15 00:23:11 <tdlfbx> Is this a BitFury hardware bug?
 22 2014-12-15 00:23:52 <Luke-Jr> tdlfbx: it's not a bug, it's just how it's designed
 23 2014-12-15 00:24:03 <Luke-Jr> tdlfbx: there's 768 cores, so they split the work up by bits
 24 2014-12-15 00:24:46 <Luke-Jr> some newer revisions have a few more cores IIRC
 25 2014-12-15 00:24:55 <tdlfbx> If anyone wants to see the same plots for scrypt, join #dogecoin-dev.
 26 2014-12-15 00:25:21 <tdlfbx> But no one is awake over there.  ;-)
 27 2014-12-15 00:27:15 <Luke-Jr> 864/1024 in gen 2 bitfury chips
 28 2014-12-15 00:47:29 <proserpine-> tdlfbx: 90% of the blocks found in scrypt/x11 have (nonce mod 256) = 0 .... miner implementation?
 29 2014-12-15 00:48:39 <tdlfbx> Can't possibly be.  asics are way behind.  It was designed as a CPU/GPU.  Also it's present in Doge from the very beginning.
 30 2014-12-15 00:49:07 <tdlfbx> @prosperpine- ---> #dogecoin-dev
 31 2014-12-15 04:50:24 <proserpine-> in the bitcoin core, given a COutPoint, how to get the corresponding CTxOut if it is spent? currently calling GetTransaction with the hash to get the whole tx and then extract the CTxOut but it is slooow and probably not the correct way to do
 32 2014-12-15 04:56:12 <Luke-Jr> proserpine-: don't think that's possible.. GetTransaction may fail too, if all the outpoints are spent
 33 2014-12-15 04:57:22 <Luke-Jr> proserpine-: heck, the data may not even be on disk at all
 34 2014-12-15 04:58:04 <proserpine-> i'm trying to get the corresponding scriptpubkey from an input
 35 2014-12-15 04:58:56 <Luke-Jr> once the outpoint is spent, it's effectively gone
 36 2014-12-15 04:59:49 <proserpine-> yea i figured that..
 37 2014-12-15 05:05:00 <proserpine-> well thanks anyway, parsing the scriptsig will give me what i need but its bit extra work
 38 2014-12-15 05:05:20 <Luke-Jr> what are you trying to do?
 39 2014-12-15 05:08:37 <proserpine-> get the btc address from the input, i have to check the tx type etc..
 40 2014-12-15 05:10:14 <Luke-Jr> proserpine-: I mean what is the end goal.. inputs don't have addresses
 41 2014-12-15 05:10:34 <Luke-Jr> the address associated with the previous output is irrelevant to the tx using that outpoint as an input.
 42 2014-12-15 05:11:15 <proserpine-> i know i know, its pointless but im still learning how it all works
 43 2014-12-15 05:11:53 <Luke-Jr> things that have no value to do, are not generally made efficient to do :P
 44 2014-12-15 07:02:14 <Belxjander> Would getting core built on both ARM and PowerPC Processors (working or not) be helpful in trying to sort out and find any endianness issues ?
 45 2014-12-15 07:02:33 <Belxjander> 
ACTION is only after getting blockchain recording and wallet functionality running...

 46 2014-12-15 07:02:46 <Belxjander> I have no current interest in trying to use any of the core code for mining
 47 2014-12-15 07:02:55 <Belxjander> that can be left to dedicated devices
 48 2014-12-15 07:44:43 <wumpus> Belxjander: I've been working on big-endian support; at the moment there is none though (see issue https://github.com/bitcoin/bitcoin/issues/888), so testing won't help us. FYI bitcoin core does compile and work for armel and mipsel.
 49 2014-12-15 07:50:45 <wumpus> it compiles for aarch64 (also el), though I have no devices to test on and qemu refuses my toolchain's executables so I don't know if it runs or whether the tests even pass
 50 2014-12-15 07:53:28 <Belxjander> wumpus
 51 2014-12-15 07:54:08 <Belxjander> the ARM is an RPi
 52 2014-12-15 07:54:58 <Belxjander> and my PPC is an AMCC440EP embedded processor,  the PPC is non-posix so will need me to look at syscall usage and libraries as well
 53 2014-12-15 07:55:10 <wumpus> RPI works fine, it is a tad slow and may lack memory, but it is little endian so running the code gives no problems
 54 2014-12-15 07:55:20 <Belxjander> the ARM is ArchLinux prepped
 55 2014-12-15 13:24:28 <jaromil> ack on PR #5171 by jtimon. it really makes code more readable, sort of trivial modification, hope you merge it
 56 2014-12-15 15:39:43 <jonasschnelli> paveljanik: regarding #5477 (10.9 VM is up and running, build output comes soon)
 57 2014-12-15 15:39:57 <jonasschnelli> -()
 58 2014-12-15 15:40:00 <paveljanik> jonasschnelli, thanks!
 59 2014-12-15 15:40:20 <paveljanik> I plan to create a few test PRs to see what travis knows.
 60 2014-12-15 15:40:24 <paveljanik> This is very strange...
 61 2014-12-15 15:40:48 <jonasschnelli> it looks like that the macro MAC_OS_X_VERSION_MIN_REQUIRED is faulty
 62 2014-12-15 15:41:27 <jonasschnelli> it should be available on cross build linux machines also because of https://opensource.apple.com/source/CarbonHeaders/CarbonHeaders-18.1/AvailabilityMacros.h
 63 2014-12-15 15:41:59 <jonasschnelli> i assume building on 10.9 will go error-free
 64 2014-12-15 15:43:36 <jonasschnelli> paveljanik: guitool.o built successfully without warning on my 10.9 VM
 65 2014-12-15 15:44:31 <paveljanik> The AvailabilityMacros.h say explicitly, that if the user doesn't define it, it is MAC_OS_X_VERSION_10_4 on Interl...
 66 2014-12-15 15:44:41 <paveljanik> what is travis, BTW? ;-)
 67 2014-12-15 15:44:52 <paveljanik> is it some form of cross platform build?
 68 2014-12-15 15:45:30 <paveljanik> how it builds for OS X?
 69 2014-12-15 15:46:02 <sipa> paveljanik: you can build for OSX without anything special; the depends system has instructions
 70 2014-12-15 15:46:06 <sipa> paveljanik: from linux
 71 2014-12-15 15:46:15 <sipa> paveljanik: you need the 10.7 OSX SDK from apple, though
 72 2014-12-15 15:51:35 <paveljanik> sipa, I prefer to build the binary for my native OS on my native OS 8)
 73 2014-12-15 15:51:48 <sipa> sure
 74 2014-12-15 15:52:08 <paveljanik> but this is interesting, I was not aware of this possibility.
 75 2014-12-15 15:52:12 <jonasschnelli> paveljanik you might need to find another way/MACRO to determine the OSX version
 76 2014-12-15 15:52:47 <paveljanik> we can simply try ifdef both macros around this and fallback to old
 77 2014-12-15 15:52:48 <jonasschnelli> no worries. We'll figure it out. I like the pull because the warning is somehow annoying...
 78 2014-12-15 15:52:58 <paveljanik> yup
 79 2014-12-15 15:53:04 <jonasschnelli> paveljanik yes. something like that was also in my mind.
 80 2014-12-15 15:53:31 <paveljanik> this is where release engineers step in and solve the problem ;-)
 81 2014-12-15 15:54:06 <sipa> what is the problem?
 82 2014-12-15 15:56:02 <wumpus> you could do an autotools check for LSSharedFileListItemCopyResolvedURL, which makes the build use that if available
 83 2014-12-15 15:57:37 <jonasschnelli> i think the problem is a missing MACRO because of a outdates apple open-source implementation...
 84 2014-12-15 15:57:43 <jonasschnelli> file https://opensource.apple.com/source/CarbonHeaders/CarbonHeaders-18.1/AvailabilityMacros.h is not up to 10.9 and 10.10
 85 2014-12-15 15:57:54 <jonasschnelli> which make the used marco = 0
 86 2014-12-15 15:58:31 <jonasschnelli> paveljanik, you might switch the if so the default would use the 'old' (10.0 till 10.9) method.
 87 2014-12-15 15:58:41 <jonasschnelli> (a bit a hack)
 88 2014-12-15 16:04:16 <paveljanik> jonasschnelli, what about this then? #if ((MAC_OS_X_VERSION_MIN_REQUIRED == 0) || (MAC_OS_X_VERSION_10_10 == 0)) || (MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_10)
 89 2014-12-15 16:05:02 <paveljanik> with a description that this STRANGE looking code is there because of Travis build?
 90 2014-12-15 16:07:32 <paveljanik> hmm, but the code will look best when I revert the if and else branches and the condition.
 91 2014-12-15 16:09:54 <paveljanik> wumpus, I'd prefer to use OS X native stuff to solve this (and workaround Travis). In this case I'm all for reversing the condition...
 92 2014-12-15 16:11:33 <paveljanik> If no objections, I'll do it this way
 93 2014-12-15 16:19:31 <jonasschnelli> paveljanik: looks to complicated for me. Just switch the if (from < to >=) so that the default runs the old code.
 94 2014-12-15 16:19:48 <paveljanik> can I use = there?
 95 2014-12-15 16:20:02 <paveljanik> what is the value of both macros in the Travis build? ;-)
 96 2014-12-15 16:20:22 <jonasschnelli> Good question: probably 0
 97 2014-12-15 16:22:43 <paveljanik> #if (MAC_OS_X_VERSION_MIN_REQUIRED == 0) || (MAC_OS_X_VERSION_10_10 == 0) || (MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_10)
 98 2014-12-15 16:23:28 <paveljanik> it will be a lot of laugh when some Mac programmer reads this line :-(
 99 2014-12-15 16:32:10 <paveljanik> jonasschnelli, pushed the change. We will see. I have to move now. See you later.
100 2014-12-15 17:08:49 <xabbix> Can a thin client be considered a full node? Or do I have to keep the blockchain data to be a full node?
101 2014-12-15 17:09:47 <StephenM347> I noticed that chainActive is used in rpcrawtransaction.cpp->TxToJSON without having a lock on cs_main. Is this safe because it's read only?
102 2014-12-15 17:14:08 <wumpus> xabbix: full node means that you verify blocks and transactions; in principle this does not imply storing the block chain, just the running state (UTXO set)
103 2014-12-15 17:14:56 <wumpus> StephenM347: are you sure? most of the RPC methods are called with cs_main held
104 2014-12-15 17:16:01 <xabbix> wumpus, and with regards to helping the bitcoin network, if I deploy a 1000 thin, full nodes. It will basically help verify transactions/blocks but might have some impact on syncing new bitcoind clients, right?
105 2014-12-15 17:17:35 <wumpus> xabbix: those nodes will not help syncing new bitcoind clients, they'll just verify the consensus, so they're useful to the network but not as useful as full archival nodes
106 2014-12-15 17:18:17 <xabbix> wumpus, Thanks for the quick answers.
107 2014-12-15 17:23:18 <StephenM347> @wumpus, you are right, it does have a lock already. Thanks!
108 2014-12-15 17:48:14 <xabbix> bitcoind used to have a performance issue when creating hundreds/thousands of transactions and addresses. Is this still the case?
109 2014-12-15 17:48:39 <wumpus> yes
110 2014-12-15 17:49:44 <wumpus> bitcoin core's wallet is a reference wallet, it is not suitable for large-scale operations (although it *can* handle a lot, it will just degrade performance)
111 2014-12-15 17:50:08 <xabbix> I'm looking for a service that can provide me with an API where I can generate new wallet addresses (in the hundreds) and check their balances every X seconds/minutes or even have a webhook when money goes into an address in my wallet. Any options other than BC.i?
112 2014-12-15 17:53:11 <wumpus> hundreds of addresses is no problem
113 2014-12-15 17:53:52 <xabbix> Does the performance issue comes to play when there are many addresses created or many transactions?
114 2014-12-15 17:54:17 <sipa> transactions
115 2014-12-15 17:54:30 <xabbix> Cool, thanks!
116 2014-12-15 17:54:52 <sipa> xabbix: bitcoin (neither the implementation nor the protocol, nor the suggested way or dealing with it) really care about addresses or their balance
117 2014-12-15 17:55:18 <sipa> issue an address for every payment you expect, and check for transactions credititng to know when the payment is fullfilled
118 2014-12-15 17:56:57 <xabbix> sipa, ok, thank you.
119 2014-12-15 18:09:07 <gmaxwell> wumpus: I don't like that "not suitable" trope, we actually perform much better under scale than many other things that have been advertised for those applications. :)
120 2014-12-15 18:25:38 <wumpus> gmaxwell: ok, I should say "is not a goal of development", but I'm just a bit tired of people complaining that things are slow so I l tone their expectations down
121 2014-12-15 18:26:28 <syskall> If I understand correctly, peers only relay a subset of all possible scriptPubkey formats right?
122 2014-12-15 18:29:48 <stonecoldpat> peers should relay all valid scriptPubKey formats, from what I can remember
123 2014-12-15 18:32:41 <syskall> I was under the impression that "non-standard" scripts were not relayed. Unless that's what you meant by "valid"
124 2014-12-15 18:33:30 <stonecoldpat> oh okay, yes it will only send standard scripts, so a transaction with two OP_RETURNS will not be relayed
125 2014-12-15 18:34:08 <wumpus> syskall: only standard output scripts are relayed, see bool IsStandard(const CScript& scriptPubKey, txnouttype& whichType)
126 2014-12-15 18:34:52 <ajweiss> won't somebody please think of the wallet?!
127 2014-12-15 18:35:00 <sipa> ajweiss: ?
128 2014-12-15 18:35:37 <ajweiss> it's a bad joke, nvm
129 2014-12-15 18:35:52 <sipa> k
130 2014-12-15 18:36:49 <syskall_> wumpus: ok thanks, is there a wiki / bip that defines standard output scripts? also does bitcoind checks for standard scriptSig as well? otherwise it seems scripts could be done indirectly by using pay-to-script-hash?
131 2014-12-15 18:39:13 <Luke-Jr> syskall_: there are multiple wiki pages and BIPs definiting standards for output scripts
132 2014-12-15 18:40:05 <Luke-Jr> side note: IsStandard overlaps with "standard output scripts", but neither are a superset of the other
133 2014-12-15 18:40:59 <sipa> transactions are also verified with stronger validation flags than strictly necessary to be accepted into blocks
134 2014-12-15 18:41:04 <Luke-Jr> eg, IsStandard will accept some OP_RETURN outputs (which are non-standard), but won't accept bare 4-of-4 multisig (which are standard)
135 2014-12-15 18:41:43 <syskall_> ok I see
136 2014-12-15 18:42:06 <Luke-Jr> also, IsStandard is not the same node-to-node
137 2014-12-15 18:42:14 <syskall_> what about the last part of my comment. can non standard scripts be relayed by putting them in the scriptSig and using pay-to-script-hash scheme?
138 2014-12-15 18:42:25 <lechuga_> yes
139 2014-12-15 18:42:27 <Luke-Jr> syskall_: some nodes may relay those, yes
140 2014-12-15 18:42:39 <syskall_> ok
141 2014-12-15 18:43:31 <Luke-Jr> in the end, it's up to each node to decide what they will relay
142 2014-12-15 18:43:34 <syskall_> what is the purpose of the IsStandard check actually?
143 2014-12-15 18:43:48 <Luke-Jr> syskall_: avoiding bugs due to untested code
144 2014-12-15 18:43:48 <sipa> syskall_: originally, feat about untested code paths
145 2014-12-15 18:43:52 <syskall_> yes, I was asking about a vanilla bitcoind build
146 2014-12-15 18:43:59 <syskall_> ok
147 2014-12-15 18:44:07 <sipa> these days, it's also used to prevent difficulties with potential future upgrades
148 2014-12-15 18:44:12 <sipa> it also provides some dos protection
149 2014-12-15 18:44:57 <Luke-Jr> syskall_: consider, for instance, CVE-2013-2292, which is "unfixable"
150 2014-12-15 18:45:19 <syskall_> makes sense
151 2014-12-15 18:46:05 <Luke-Jr> syskall_: versions prior to 0.10 only allow IsStandard scriptSigs
152 2014-12-15 18:46:05 <syskall_> I'm surprised that there is no IsStandard check on scriptSig though.. don't the same concerns apply there as well?
153 2014-12-15 18:49:30 <syskall_> ok thanks
154 2014-12-15 18:58:06 <ajweiss> speaking of which, do you guys have any thoughts on #5463 steady state timeouts?
155 2014-12-15 18:59:33 <sipa> ajweiss: i'll have a look, but i haven't had too much time lately
156 2014-12-15 19:01:30 <ajweiss> cool...  if there anything particularly helpful i could do to help with 0.10?  testing pulls or whatnot?
157 2014-12-15 19:04:13 <paveljanik> jonasschnelli, thanks for testing!
158 2014-12-15 19:07:54 <wumpus> ajweiss: you can help test the 0.10 branch https://github.com/bitcoin/bitcoin/tree/0.10
159 2014-12-15 19:08:19 <wumpus> ajweiss: testing and reviewing pulls helps development a lot, but 0.10 is more or less closed
160 2014-12-15 19:09:06 <wumpus> ajweiss: e.g. what can help is to try building what is there w/ gitian and run the resulting executables on different platforms
161 2014-12-15 19:09:24 <ajweiss> ok i can do that
162 2014-12-15 19:20:12 <wumpus>  Wheeee I got the tests to pass on mipsbe32. Running 132 test cases... *** No errors detected ... <3
163 2014-12-15 19:20:44 <sipa> awesome
164 2014-12-15 19:21:41 <paveljanik> great!
165 2014-12-15 19:22:08 <Luke-Jr> wumpus: wow, nice
166 2014-12-15 19:23:02 <wumpus> let's see if it can sync the chain
167 2014-12-15 19:24:10 <Luke-Jr> I'd sync testnet first
168 2014-12-15 19:24:16 <Luke-Jr> more likely to trigger issues, and quicker ;)
169 2014-12-15 19:24:37 <wumpus> good point
170 2014-12-15 19:26:23 <paveljanik> I'd start with bootstrap.dat 8)
171 2014-12-15 19:38:27 <Luke-Jr> btw, is CLTV somehow on the 0.10 radar still? or did it miss the merge window entirely?
172 2014-12-15 19:40:06 <sipa> nope, bip62 and cltv are off
173 2014-12-15 19:49:56 <lechuga_> some bip62 stuff is already merged isnt it?
174 2014-12-15 19:50:44 <Luke-Jr> lechuga_: not as consensus code though
175 2014-12-15 19:52:53 <lechuga_> ic
176 2014-12-15 19:56:45 <akaiiro> hi guys
177 2014-12-15 19:58:04 <akaiiro> does somebody know the size range for a transaction hash?
178 2014-12-15 19:58:52 <lechuga_> its 32 bytes
179 2014-12-15 19:59:11 <lechuga_> 64 characters when encoded in hex
180 2014-12-15 20:00:24 <akaiiro> oh, I see. thanks. I was a little confused thinking these followed similar specs than addresses
181 2014-12-15 21:47:57 <btcdrak> I managed to build using gitian successfully using the offline download method.
182 2014-12-15 22:01:22 <wumpus> btcdrak: great!
183 2014-12-15 22:04:47 <btcdrak> wumpus: I dont think there are blockers, but I think there are some download edge cases that probably need to be solved. 1) sf sees fit to return HTTP 200 for failed downloads, so the make download fails the checksum, the solution might be to try failover on checksum fail. 2) the CA certificate bundle needs to be updated else it refuses to download from
184 2014-12-15 22:04:48 <btcdrak> bitcoincore .org but tbh, I dont think SSL is that important because we're checking the checksums of the downloads. It might be OK to skip SSL.
185 2014-12-15 22:06:35 <wumpus> yes, an option on depends to skip the certificate check on download would be enough
186 2014-12-15 22:06:53 <wumpus> WUT, sf returns 200 on error? how broken can it be
187 2014-12-15 22:09:35 <btcdrak> wumpus so when sf goes into maintenance mode, which is often it seems, it requires JS to be enabled in the browser to download files. If JS is not enabled you get a <noscript> page with a 200 status header instead of 503 or something appropriate.
188 2014-12-15 22:10:03 <btcdrak> if you have JS, the download works while in maintenance mode. Most weird.
189 2014-12-15 22:10:32 <btcdrak> anyway the better way to handle would be just fail over to bitcoincore.org if there is a checksum fail.
190 2014-12-15 22:12:00 <wumpus> yes
191 2014-12-15 23:04:02 <cfields> btcdrak: that's the way it currently works
192 2014-12-15 23:04:18 <cfields> btcdrak: i've reported that to sourceforge, sounds like it's still unfixed
193 2014-12-15 23:05:45 <cfields> thanks for building, btw
194 2014-12-15 23:07:18 <btcdrak> cfields: cool. just finished with the osx builds as well, so tested win/lin/osx.
195 2014-12-15 23:07:55 <cfields> great. glad to see it's finally all working
196 2014-12-15 23:57:45 <syskall> does anyone know why OP_EVAL didn't end up being implemented?
197 2014-12-15 23:58:26 <sipa> the alternative was simpler
198 2014-12-15 23:58:45 <sipa> and it was implemented, just not.picked
199 2014-12-15 23:59:32 <gmaxwell> syskall: the original implementation introduced vulnerabilties that were subtle and not found for a while, so the simpler implementation was preferable.  Also, because of other limits (maximum push size) it wouldn't have been more useful in any case.