1 2014-12-11 00:00:21 <ryan-c> (I'm looking at the OP_CHECKSIG wiki page)
2 2014-12-11 00:04:06 <gmaxwell> ryan-c: huh? it certantly can have more inputs than outputs. Its just that the inputs past the output count can't be sighash single.
3 2014-12-11 00:04:26 <sipa> well... they can be
4 2014-12-11 00:04:29 <ryan-c> gmaxwell: "Note: The transaction that uses SIGHASH_SINGLE type of signature should not have more inputs than outputs. However if it does (because of the pre-existing implementation), it shall not be rejected, but instead for every "illegal" input (meaning: an input that has an index bigger than the maximum output index) the node should still verify it, though assuming the hash of 0000000000000000000000000000000000000000000000000000000000000001"
5 2014-12-11 00:04:32 <sipa> they just don't sign anything useufl
6 2014-12-11 00:04:46 <ryan-c> maybe i am just not understanding that right.
7 2014-12-11 00:05:05 <gmaxwell> ryan-c: the warnings is incorret.
8 2014-12-11 00:05:07 <gmaxwell> er incorrect.
9 2014-12-11 00:05:23 <ryan-c> gmaxwell: okay, thanks
10 2014-12-11 00:05:36 <gmaxwell> It's perfectly fine to have, say, two inputs, the first is sighash single, and one output.
11 2014-12-11 00:44:54 <huma_> sipa: hi. sadly, reindexing ended with "LevelDB read failure: Corruption: block checksum mismatch" when it was only 34 weeks left to index. people here suggested a hardware issue. i ran memtest - no errors. hdd smart status is ok. i ran bitcoin-qt again without -reindex. it picked up from 34 weeks and seems to be crunching blocks so far.
12 2014-12-11 00:45:16 <sipa> how long did you run memtest?
13 2014-12-11 00:45:33 <sipa> some errors only appear after significant time, or overheating or something
14 2014-12-11 00:45:40 <huma_> sipa: about 20 min
15 2014-12-11 00:45:41 <sipa> and bitcoin really can stress the hardware
16 2014-12-11 00:45:45 <gmaxwell> usually you leave memtest running overnight. Unfortunately even then it won't catch everything.
17 2014-12-11 00:45:59 <huma_> i see
18 2014-12-11 00:47:23 <sipa> how old is the machine?
19 2014-12-11 00:47:28 <huma_> i suppose 99% of the time it's not critical (my apps do not crash or anything in daily use), but bitcoin is sensitive to precision.
20 2014-12-11 00:47:37 <huma_> 3 years
21 2014-12-11 00:47:50 <huma_> or 4 now
22 2014-12-11 00:48:26 <sipa> try running bitcoin with -par=1
23 2014-12-11 00:48:48 <sipa> that will use only a single thread for script validation
24 2014-12-11 00:49:44 <huma_> thank you. will try that.
25 2014-12-11 00:50:09 <huma_> 33 weeks left. slowly going there.
26 2014-12-11 00:51:00 <huma_> i'm waiting for skylake to upgrade
27 2014-12-11 00:51:18 <sipa> skylake?
28 2014-12-11 00:51:46 <huma_> intel's new architecture
29 2014-12-11 00:52:10 <huma_> http://en.wikipedia.org/wiki/Skylake_%28microarchitecture%29
30 2014-12-11 00:52:56 <sipa> yeah, was already reading that :)
31 2014-12-11 01:08:35 <huma_> sipa: i note a substantial slowdown in block processing after some time. down to 1-2 blocks per second.
32 2014-12-11 01:09:43 <sipa> yup, once you pass the last checkpoint, bitcoin actually starts validating every transaction
33 2014-12-11 01:09:53 <sipa> that's the point where -par=X matters
34 2014-12-11 01:10:01 <sipa> by default, it will use all available cores on your system
35 2014-12-11 01:10:16 <sipa> which can push hardware a bit too much
36 2014-12-11 01:10:26 <huma_> it's now at -par=0 by default
37 2014-12-11 01:10:55 <huma_> got your advice after i started it
38 2014-12-11 01:11:46 <huma_> sipa: wait, what is "last checkpoint"?
39 2014-12-11 01:12:03 <sipa> use -par=1
40 2014-12-11 01:12:10 <sipa> -par=0 means default: use all cores
41 2014-12-11 01:12:14 <sipa> -par=1 means just one core
42 2014-12-11 01:12:28 <huma_> i know, read that :) will do on my next run
43 2014-12-11 01:12:36 <huma_> thank you
44 2014-12-11 01:33:27 <huma_> heh, this is good. here's a new error during the second reindex run: "IO error: c:\wallet\bitcoin\chainstate\012660.ldb: The process cannot access the file because it is being used by another process."
45 2014-12-11 01:34:45 <gmaxwell> You have some broken antivirus software that is screwing up your system.
46 2014-12-11 01:35:09 <huma_> no antivirus here
47 2014-12-11 01:35:30 <sipa> some virus then? :)
48 2014-12-11 01:38:17 <midnightmagic> or spyware
49 2014-12-11 01:39:31 <huma_> unlikely, but with regin kind anything is possible
50 2014-12-11 01:46:31 <huma_> is it safe to downgrade to 0.8.5? never had a problem with this version
51 2014-12-11 01:46:53 <sipa> it may or may not work
52 2014-12-11 01:47:25 <sipa> if you're not relying on it for production, maybe you can help test 0.10 on it? :)
53 2014-12-11 01:47:56 <huma_> i mean, are there outstanding issues with 0.8.5 on the current network? :)
54 2014-12-11 01:49:47 <gmaxwell> 0.8.5 has unfixed vulnerabilties. Seriously, there is something wrong with your host.
55 2014-12-11 02:04:04 <huma_> gmaxwell: what would be your guess is wrong giving the errors so far: 1. hashMerkleRoot mismatch, 2. LevelDB read failure: Corruption: block checksum mismatch, 3. IO error: c:\wallet\bitcoin\chainstate\012660.ldb: The process cannot access the file because it is being used by another process.
56 2014-12-11 02:04:21 <sipa> your OS, your disk, your CPU or your memory are broken
57 2014-12-11 02:04:22 <sipa> really...
58 2014-12-11 02:04:58 <huma_> that's a lot to cover :)
59 2014-12-11 02:05:27 <gmaxwell> huma_: thats all very consistent with what other people have seen from 'antivirus' or 'indexing' software that corrupts their databases. The file in use message is basically a dead giveaway.
60 2014-12-11 02:06:57 <huma_> thank you. will look into that. maybe there's an indexing service that kicks in at the wrong time.
61 2014-12-11 02:12:43 <chipmadness> Hey guys
62 2014-12-11 02:13:00 <chipmadness> I was wondering if anyone here knows a good place to learn more about the coding inside bitcoin
63 2014-12-11 02:13:11 <sipa> github.com/bitcoin/bitcoin :p
64 2014-12-11 02:13:38 <chipmadness> any where else?
65 2014-12-11 02:14:01 <sipa> (though you should probably first read through the developer documentation on bitcoin.org)
66 2014-12-11 02:14:27 <phantomcircuit> gmaxwell, sadly i've left memtest running on systems for 48+ hours and failed to catch errors
67 2014-12-11 02:14:33 <chipmadness> thank you sipa
68 2014-12-11 02:14:41 <phantomcircuit> then rebooted and immediately found them
69 2014-12-11 02:15:11 <phantomcircuit> memory correctness is suitably random to be difficult to diagnose
70 2014-12-11 02:18:10 <Diablo-D3> phantomcircuit: sounds like issue with bios
71 2014-12-11 02:18:20 <Diablo-D3> race conditions can happen in bioses
72 2014-12-11 02:18:24 <Diablo-D3> its _hilarious_
73 2014-12-11 02:19:27 <phantomcircuit> Diablo-D3, it's SO-DIMM slots with capacitors that got knocked clean off
74 2014-12-11 02:19:42 <phantomcircuit> so reliability is variable based on tight electric tolerances
75 2014-12-11 02:19:46 <phantomcircuit> fun right
76 2014-12-11 02:19:58 <phantomcircuit> i cant replace it either because it's basically stuck under a heat pipe
77 2014-12-11 02:19:59 <Diablo-D3> HAHAHA
78 2014-12-11 02:20:14 <Diablo-D3> phantomcircuit: so basically, it may boot correctly depending on how warm it is.
79 2014-12-11 02:20:28 <phantomcircuit> oh it boots either way since it's high mem
80 2014-12-11 02:20:37 <Diablo-D3> you know what I mean
81 2014-12-11 02:20:45 <phantomcircuit> yeah
82 2014-12-11 02:20:54 <Diablo-D3> oh that is priceless
83 2014-12-11 02:21:03 <Diablo-D3> ACTION adds that to his list of wtf stories
84 2014-12-11 02:21:36 <phantomcircuit> Diablo-D3, it's actually pretty interesting how many circuits are designing with total capacitance being from multiple ceramic caps
85 2014-12-11 02:21:47 <Diablo-D3> phantomcircuit: best one is still the one about the pdp11 that had a switch on it with one wire going into it that will promptly crash it, and the wire is going into a ground on the mobo
86 2014-12-11 02:21:53 <phantomcircuit> where removing a few of them has no apparent effect but changes the reliability significantly
87 2014-12-11 02:21:58 <Diablo-D3> yeah
88 2014-12-11 02:22:03 <Diablo-D3> thats why they have arrays of them often
89 2014-12-11 02:22:13 <Diablo-D3> if one happens to fail, your shit might keep working
90 2014-12-11 02:22:25 <Diablo-D3> or at least, limp along enough to get a new box
91 2014-12-11 02:24:21 <phantomcircuit> Diablo-D3, for high assurance systems maybe doing that is a bad idea
92 2014-12-11 02:24:22 <phantomcircuit> heh
93 2014-12-11 02:24:31 <Diablo-D3> well
94 2014-12-11 02:24:35 <Diablo-D3> thats how you START to build them
95 2014-12-11 02:24:46 <Diablo-D3> but you add more shit to them
96 2014-12-11 02:24:58 <Diablo-D3> phantomcircuit: like ever see large scale VRM arrays on overclock-oriented mobos?
97 2014-12-11 02:25:27 <Diablo-D3> its pretty much assured that at the peak of overclocking on that board, that shit is waaaay out of spec
98 2014-12-11 02:25:35 <Diablo-D3> but its so overengineered that it doesnt quite matter
99 2014-12-11 02:25:57 <Diablo-D3> you'll get your 8ghz overclock for the several minutes of liquid nitrogen you have
100 2014-12-11 02:26:03 <Diablo-D3> and then it will promptly burn up
101 2014-12-11 05:49:20 <op_null> would anybody oppose a sendrawtransaction "dry run" patch (not for 0.10.0 though)? does all the checks but doesn't actually broadcast.
102 2014-12-11 05:55:57 <gmaxwell> op_null: maybe instead just a checkrawtransaction ? or a "valid" flag on decode raw transactions output?
103 2014-12-11 05:56:19 <gmaxwell> op_null: you could go one further and write a patch that let you disable all transaction transmission, which we were musing about being very useful. e.g. lets you use the wallet like normal but then submit your transactions over some more private method.
104 2014-12-11 05:57:37 <op_null> that sounds sensible enough
105 2014-12-11 05:58:01 <op_null> do you mean that the GUI would have that feature, hitting "send" just gives you the hex encoded raw treansaction?
106 2014-12-11 05:58:47 <gmaxwell> well the first step would just be some command line / config switch that disables all the codepaths that would actually broadcast a transaction.
107 2014-12-11 05:59:06 <gmaxwell> Thats actually enough to be useful on its own, since you can flip it on then getrawtransaction your own txn through the rpc or debug console.
108 2014-12-11 05:59:56 <gmaxwell> (or even run an RPC applet that autosnarfs your transactions and submits them via pond-bitmessage-mixmaster)
109 2014-12-11 06:00:56 <op_null> ACTION nods
110 2014-12-11 06:01:53 <gmaxwell> obviously more functionality would be to have the gui automatically hand it to you at send time.. also tracking when its heard it via the network, right now we have no indicator of that I think.
111 2014-12-11 06:02:19 <gmaxwell> which would be useful even without the broadcast surpression.
112 2014-12-11 06:03:37 <op_null> out of scope for what I was planning to do, but can lay the foundation with some sort of squelch option. I'll look into how to do that properly, I don't know any of that part of the codebase at all.
113 2014-12-11 06:04:14 <op_null> (you're right it should be in decoderawtransaction, I just liked the idea of calling it a dry run)
114 2014-12-11 06:07:12 <gmaxwell> dry run sounds nice but sounds error prone
115 2014-12-11 06:07:22 <gmaxwell> oops forgot the option now the coins are poof.
116 2014-12-11 06:08:11 <op_null> right. decoderawtransaction should be assumed to be "safe" in that regard.
117 2014-12-11 06:10:01 <Diablo-D3> gmaxwell: https://commerce.microsoft.com/PaymentHub/Help/Right?helppagename=CSV_BitcoinHowTo.htm
118 2014-12-11 06:10:02 <Diablo-D3> wat
119 2014-12-11 06:14:25 <gmaxwell> interesting. What service is that for? (also OT here, #bitcoin)
120 2014-12-11 09:55:25 <wumpus> cfields: looks like the windows travis builds have problems again
121 2014-12-11 09:55:30 <wumpus> "No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself."
122 2014-12-11 10:34:36 <huma_> sipa: -par=1 seems to be helpful. it's *very* slow, but at least no errors in 6 hours. i start thinking i'd be better off just re-download the blockchain.
123 2014-12-11 10:40:23 <wumpus> re-downloading should never be necessary, better do -reindex
124 2014-12-11 10:41:39 <wumpus> though problems with higher -par= generally point toward cpu overheating issues causing corruption, so be careful with using that machine for crypto
125 2014-12-11 10:43:50 <jonasschnelli> while trying to fix mem-leaks around the berkey-db implementation it just came to my mind: did nobody every tried to get rid of bdb/wallet.dat?
126 2014-12-11 10:45:10 <jonasschnelli> the implementation looks awful, maybe a possibility to factor out the wallet interaction and write a proper class where multiple "backend" would be possible.
127 2014-12-11 10:45:40 <wumpus> moving the wallet code to another repository would have a higher priority
128 2014-12-11 10:46:22 <jonasschnelli> so the wallet repo should use the libs and provide the wallet-code only?
129 2014-12-11 10:46:24 <wumpus> the legacy wallet will have to support berkeleydb forever, either directly or through a compatibility script, otherwise people cannot open their old wallets
130 2014-12-11 10:47:08 <jonasschnelli> wumpus: bdb needs to be there, but there could be a startup-arg (-walletbackend=bdb) where user could switch backend. A manual migration would be necessary.
131 2014-12-11 10:47:34 <wumpus> anyhow this has been talked about zillions of times, you'd first have to define a new wallet format
132 2014-12-11 10:47:55 <wumpus> which should be self-contained to avoid this kind of trouble in the future
133 2014-12-11 10:48:27 <wumpus> but I don't really want the wallet stuff in the bitcoind repository anymore, it's too much to maintain already, let alone if you add wallet backends and such
134 2014-12-11 10:50:24 <jonasschnelli> wumpus: that would also mean to move the whole Qt part to the "wallet repository"? Qt as RPC console only would not make sense
135 2014-12-11 10:50:31 <wumpus> bitcoin core wallet, if it is to have any future beyond 'example reference implementaiton' at all, would have to turn into a SPV wallet and be its own project
136 2014-12-11 10:51:01 <wumpus> well a simple node-watch qt gui is useful for people on more graphical oses
137 2014-12-11 10:51:22 <wumpus> but yes the main part would move with it
138 2014-12-11 10:53:44 <huma_> wumpus: i've had corruption related errors 3 times already. it's day 2 of reindexing.
139 2014-12-11 10:54:46 <wumpus> bitcoin-qt -disablewallet GUI is useful to say monitor the node bandwidth, invoke debug commands, see statistics, change configuration, that should stay and is independent from the wallet... ofcourse it could be replaced with a web interface of some kind instead of a qt gui, if someone writes that
140 2014-12-11 10:55:46 <wumpus> huma_: redownloading the blockchain won't help anything with that
141 2014-12-11 10:55:59 <jonasschnelli> so you mean someone should start a independent wallet which uses the current wallet-code but while the rest of the ref. implementation comes over the libbitcoin_*?
142 2014-12-11 10:56:35 <wumpus> jonasschnelli: I don't really care :< it's up to the person creating that project, I suppose
143 2014-12-11 10:57:58 <wumpus> jonasschnelli: it shouldn't be a full node anymore, so a lot of the current code you won't need
144 2014-12-11 10:58:15 <jonasschnelli> wumpus but i think the libs first need a clean API with docs
145 2014-12-11 11:00:36 <wumpus> jonasschnelli: you don't need, say, the consensus code in a SPV wallet
146 2014-12-11 11:01:37 <wumpus> jonasschnelli: and a 'clean API with docs' isn't a goal right now, except for the consensus libraries
147 2014-12-11 11:04:59 <wumpus> I think the first step would be implementing SPV in the first place, that gives an idea what overlap there will be with the bitcoind project
148 2014-12-11 11:06:59 <wumpus> e.g.at least 1) (de)serialization 2) some form of P2P network handling 3) RPC server
149 2014-12-11 11:08:59 <jonasschnelli> lots of things could be conceptual adopted form bitcoinj?
150 2014-12-11 11:14:06 <rusty> BlueMatt: any clues on that relay old-tx issue? If not I can try setting up a relay server tomorrow with extra annotations, see if I can catch it in the act..
151 2014-12-11 11:23:10 <wumpus> jonasschnelli: yes. which begs the question, is it worth doing this in the first place?
152 2014-12-11 11:23:34 <wumpus> jonasschnelli: there is plenty of choice in the wallet arena
153 2014-12-11 11:29:38 <wumpus> jonasschnelli: I don't mean to demotivate you, I originally wrote bitcoin-qt and it'd be nice to see it as new full-featured SPV wallet
154 2014-12-11 11:33:00 <wumpus> but at this point it may be better for bitcoin as a whole to contribute to one of the existing projects, which already do HD, SPV, aim to be more user friendly (and/or offer a saner developer interface, like codeshark's coinvault project)
155 2014-12-11 11:33:44 <wumpus> and leave just the core node infrastructure to bitcoin core
156 2014-12-11 11:36:17 <iwilcox> FWIW from someone who hasn't contribute, I disagree. What Core's wallet lacks in features, it makes up for in quality.
157 2014-12-11 11:36:24 <iwilcox> *contributed
158 2014-12-11 11:37:21 <wumpus> well, you can keep using it, it won't go away anytime soon, just don't expect much new from it
159 2014-12-11 11:40:43 <wumpus> maybe that's ok with you and the quality is *because* the code is mature and doesn't receive much more than bug fixes
160 2014-12-11 11:43:20 <iwilcox> It's more about the conservatism wrt features (whether that's deliberate or simply through feeling the wallet isn't something that deserves focus)
161 2014-12-11 11:44:18 <iwilcox> And I guess the fact that you can mostly take the guard rails off if you really want to with the rawtransaction stuff.
162 2014-12-11 11:46:37 <wumpus> almost all of the rawtransaction stuff is available even without the wallet enabled
163 2014-12-11 11:49:35 <wumpus> infrastructure and consensus code.
164 2014-12-11 11:49:35 <wumpus> it's not that I dont think it deserves focus, I'd be happy if it received focus, but it's scope for growth is very small as long as it's still part of the bitcoin repository and all has to pass through the current bottlenecks (such as me). The number of hours in a day is limited and I have to choose my battles, I can't maintain a full scale user-friendly-as-well-as-enterprise-scalable wallet project in addition to the core
165 2014-12-11 11:54:22 <wumpus> I suppose someone else could step up to be wallet-maintainer. But there's not really a good way to delegate within the current repository...
166 2014-12-11 12:15:19 <sipa> huma_: redownloading won't do anything
167 2014-12-11 13:18:35 <jtimon> iwilcox as wumpus says what the wallet needs to evolve faster is to become a separated repository
168 2014-12-11 13:19:33 <jtimon> the roadmap for that is not clear though, it could be 1) Add SPV support 2) Then Separate, or the other way around
169 2014-12-11 13:20:01 <sipa> there are many possibilities, i guess it'll be up to whoever implements something
170 2014-12-11 13:20:43 <jtimon> hopefully refactors libconsensus can help with the separation too
171 2014-12-11 13:21:08 <iwilcox> jtimon: To be clear, I'm not really fussed about faster evolution, only about preservation of the existing code in a working state.
172 2014-12-11 13:21:15 <iwilcox> Anything more is a bonus.
173 2014-12-11 13:23:22 <jtimon> everybody seems to agree that separating the wallet (probably leaving a minimal "demo wallet" [similar to the "demo miner"]) would be a good thing but it's not so easy to do and so far nobody has done it
174 2014-12-11 13:24:02 <sipa> separating is pretty hard to do cleanly
175 2014-12-11 13:25:28 <jtimon> yes, at least at this point
176 2014-12-11 13:26:41 <jtimon> as said I hope that as libconsensus grows things will need to become more modular
177 2014-12-11 13:27:05 <sipa> well separating off the consensus code is pretty independent
178 2014-12-11 13:27:33 <sipa> but yeah, in general, i like the evoluation of modularizing things
179 2014-12-11 13:29:58 <paveljanik> wumpus: should I PR #5454?
180 2014-12-11 13:32:32 <wumpus> libconsensus has virtually nothing to do with it
181 2014-12-11 13:33:44 <wumpus> paveljanik: sure!
182 2014-12-11 13:35:27 <wumpus> the consensus library project is much more pressing because there is no other way to get the consensus right than to use bitcoind's version, so it needs to be available as a library
183 2014-12-11 13:35:29 <jtimon> yes, is orthogonal but it requires modularization as well and it's a simpler way to get it little by little
184 2014-12-11 13:36:26 <jtimon> but sure I agree it is more pressing
185 2014-12-11 13:37:14 <jtimon> btw, what do people think could be the next thing in libconsensus?
186 2014-12-11 13:39:00 <sipa> we'll probably need some mechanism for callbacks to query to UTXO set, and you give it a block and it tells you whether it's valid
187 2014-12-11 13:39:21 <sipa> not as trivial as the scripting
188 2014-12-11 13:39:52 <jtimon> another reorganization effort that I think it's more pressing than separating the wallet is separating policy decissions, which I believe will also help with modularization
189 2014-12-11 13:40:30 <sipa> well, if we separate off all consensus code into some module, everything that's left is policy
190 2014-12-11 13:40:51 <sipa> you can easily parametrize things to make the decisions external
191 2014-12-11 13:40:57 <warptangent> in what format is the bootstrap.dat stored? it is a portable file format, correct? is it read through a leveldb interface or something else?
192 2014-12-11 13:41:02 <jtimon> a full block directly? why not a single full transaction first?
193 2014-12-11 13:41:23 <wumpus> warptangent: it's simply the network serialization format for blocks
194 2014-12-11 13:41:25 <sipa> jtimon: fair enough, yes; though that equally needs the hard parts (UXTO interface)
195 2014-12-11 13:41:49 <jtimon> yeah, the utxo interface is probably the hardest next step
196 2014-12-11 13:41:49 <warptangent> wumpus, and it is portable? one bootstrap.dat for all platforms?
197 2014-12-11 13:41:52 <sipa> warptangent: yes
198 2014-12-11 13:41:57 <wumpus> warptangent: block after block, head-to-tail w/ no gaps
199 2014-12-11 13:42:04 <warptangent> thank you, wumpus, sipa.
200 2014-12-11 13:42:15 <sipa> warptangent: each block is prefixed with a 4-byte network magic, and a 4-byte length descriptor (in little endian), and then the block itself as it would be sent over the network in a 'block' message
201 2014-12-11 13:42:59 <warptangent> ok
202 2014-12-11 13:45:39 <sipa> jtimon, wumpus: one thing i'd like to see happen as well is a more pluggable network mechanism
203 2014-12-11 13:46:09 <sipa> where you can install individual handlers for particular network messages, and respond to them, keep per-node or per-peer state, do proper locking on those, ...
204 2014-12-11 13:46:23 <sipa> the askfor rewrite was a nice step in that direction
205 2014-12-11 13:47:23 <sipa> for example, i'd like to see block processing become a separate independent module that installs some handlers in the network code and in the block validation, but it otherwise independent of them
206 2014-12-11 13:47:25 <wumpus> sipa: agreed
207 2014-12-11 13:48:19 <wumpus> the network packet handling, which is currently a monolithic mess in main, it should be split up per aspect
208 2014-12-11 13:48:38 <sipa> block handling, transaction handling, alert handling, ping handling, address handling
209 2014-12-11 13:48:50 <sipa> i think those could be pretty much totally independent from eachother
210 2014-12-11 13:49:00 <wumpus> I think so too
211 2014-12-11 13:49:35 <hearn> first order of business there would be to write unit test frameworks that allow for injection and reception of test messages
212 2014-12-11 13:50:29 <wumpus> isn't that what the comparison tool does?
213 2014-12-11 13:50:37 <sipa> he means inside the core codebase
214 2014-12-11 13:51:01 <sipa> and i agree that would be very useful, but it would be trivial if we had pluggable network handlers in the first place :)
215 2014-12-11 13:51:29 <wumpus> or some framework based on bitcoin-python that can test P2P aspects, similar to the current RPC tests but that test P2P
216 2014-12-11 13:51:43 <sipa> unit tests can't replace network interaction tests
217 2014-12-11 13:51:53 <sipa> but getting more of both is never a bad thing :)
218 2014-12-11 13:52:12 <paveljanik> ok, will do in the evening.
219 2014-12-11 13:52:20 <wumpus> right, unit tests would test the individual functions in the networking code
220 2014-12-11 13:52:34 <wumpus> but how it fits together can only be tested by actual network interaction
221 2014-12-11 13:53:00 <sipa> right, you wouldn't test whether 'block synchronization' works in a unit test
222 2014-12-11 13:53:11 <sipa> but you can test whether sending an inv triggers a getdata
223 2014-12-11 13:53:41 <wumpus> but you don't have to build actual network messages for that, just call the functions as if a packet was received
224 2014-12-11 13:53:54 <sipa> that's what hearn means i think
225 2014-12-11 13:54:01 <sipa> being able to intercept those
226 2014-12-11 13:55:27 <hearn> in bitcoinj there is a framework that lets you create fake peers, send messages from them and then block waiting for messages to them
227 2014-12-11 13:56:07 <hearn> so you can exercise as much of the networking paths as possible, including things like reconnection logic
228 2014-12-11 14:16:41 <jtimon> sipa wumpus: I would like something similar to jgarzik's #4646 as a first step
229 2014-12-11 14:17:08 <sipa> meh
230 2014-12-11 14:17:10 <jtimon> moving moving the several message types to different files directly
231 2014-12-11 14:17:18 <jtimon> maybe moving
232 2014-12-11 14:17:19 <sipa> moving files is nice, no problem with it
233 2014-12-11 14:17:33 <sipa> but it's not a structural improvement
234 2014-12-11 14:17:58 <sipa> and it doesn't actually make further improvements easier
235 2014-12-11 14:18:20 <jtimon> well, not very big but you're separating dependencies on main
236 2014-12-11 14:18:51 <jtimon> I mean, yeah, obviously the important part is separating related messages together and the like
237 2014-12-11 14:20:02 <jtimon> something like #4646 has to be done one way or another
238 2014-12-11 14:20:20 <sipa> #4646 introduced a circular dependency between procmsg and main, imho that's a sign that there is no separation whatsoever, and really all that happened is a move
239 2014-12-11 14:20:33 <sipa> imho, the only benefit of that is making your compiler use less RAM
240 2014-12-11 14:20:47 <jtimon> specifically something like https://github.com/jgarzik/bitcoin/commit/78edf5cb8cf65caf38080ac57040469cc9c6957f
241 2014-12-11 14:21:12 <sipa> yup, that does have to happen
242 2014-12-11 14:21:13 <jtimon> that can be done in main before moving things though
243 2014-12-11 14:21:49 <jgarzik> It was a first step, not a complete picture. After that first step, the kitchen sink is contained within two files rather than One Big File, but it's still a kitchen sink.
244 2014-12-11 14:22:05 <sipa> no, in 4 instead of 3
245 2014-12-11 14:22:29 <sipa> net/main/protocol are still very intimately related, with no clear separation
246 2014-12-11 14:22:33 <jgarzik> And it introduces an amount of source code modularity that enables easier future separation, while making diffs a bit better.
247 2014-12-11 14:22:51 <sipa> moving part to a new files just means there's now 4 files with no clear separation
248 2014-12-11 14:23:04 <sipa> half of the datastructures used in message handler are defined in net
249 2014-12-11 14:23:28 <jgarzik> using the same code does not imply no separation
250 2014-12-11 14:23:31 <jgarzik> s/code/core/
251 2014-12-11 14:23:59 <sipa> anyway, my only objection against moving to a new file is that it hurts existing pull requests for imho little (but not none) benefit
252 2014-12-11 14:24:24 <sipa> while separating small pieces of the processing provides real benefit, and touches less code
253 2014-12-11 14:24:30 <jgarzik> I view it as transformational steps, similar to multi-step algebraic simplification, or transforming a proof.
254 2014-12-11 14:24:30 <jtimon> I agree with jgarzik that it makes later modularization and ckeanup easier
255 2014-12-11 14:24:57 <jtimon> although is obviously not the only possible way to do it
256 2014-12-11 14:25:11 <sipa> see #4831 for example
257 2014-12-11 14:25:23 <hearn> sipa: are the gitian docs up to date? i think you're the last guy who went through the process afresh
258 2014-12-11 14:25:27 <sipa> which just moves part of the processing to a new file, and making it actually independent
259 2014-12-11 14:26:02 <jtimon> separating the messages in main first would delay the breaking some PRs
260 2014-12-11 14:26:53 <jgarzik> nod. there are benefits at the patch review & PR level
261 2014-12-11 14:28:05 <jtimon> yes, #4646 in itself is very easy to review
262 2014-12-11 14:28:52 <hearn> the risk of refactoring code without unit tests is that you end up breaking things without realising it
263 2014-12-11 14:29:00 <sipa> yup
264 2014-12-11 14:29:04 <wumpus> I do like splitting off the message handling out of main (so that what remains is the backend, the consensus of block handling)
265 2014-12-11 14:29:14 <sipa> though pure code-movements are easy to review
266 2014-12-11 14:30:02 <jtimon> well, #4646 is practically move-only, I don't think it can break anything
267 2014-12-11 14:30:20 <wumpus> apart from modularization of the network code itself
268 2014-12-11 14:30:45 <sipa> agree - as said; my only concern is breaking existing PRs; i just think its benefit is very minimal
269 2014-12-11 14:31:14 <wumpus> what PRs are you especially concerned about?
270 2014-12-11 14:31:21 <wumpus> do we maybe need to merge those first?
271 2014-12-11 14:31:51 <sipa> they all need rebasing now anyway, so perhaps it doesn't matter anymore
272 2014-12-11 14:32:04 <sipa> i was thinking about the threadmessage condition variable, askfor management, ...
273 2014-12-11 14:32:26 <wumpus> askfor management should be easy to rebase
274 2014-12-11 14:33:14 <wumpus> but sure, rebasing over code moves can be annoying
275 2014-12-11 14:34:19 <hearn> remember the people who have patches that you aren't going to merge or rebase
276 2014-12-11 14:34:34 <hearn> if there's real value in a refactoring, fine, if it's just code motion for the sake of looking busy - that makes work for other people
277 2014-12-11 14:34:54 <wumpus> it's not for the sake of looking busy
278 2014-12-11 14:36:17 <jtimon> separating the messages in main first without correcting the indentation shouldn't break that many PRs, it may be doable with an identical build using inline functions
279 2014-12-11 14:36:46 <jtimon> but at some point you will want to move the messages out of main as well
280 2014-12-11 14:36:52 <wumpus> we're never going to reach a more modular code base if people are afraid to change things or move them around
281 2014-12-11 14:37:16 <hearn> right, that's why i said if there's real value in it. modularity doesn't come from making smaller files though, it's more about architectural changes.
282 2014-12-11 14:37:22 <sipa> my preference would be to do things like #4831, and for every set of messages independently
283 2014-12-11 14:37:31 <sipa> until there are none left
284 2014-12-11 14:37:35 <wumpus> sigh, this is not about making smaller files
285 2014-12-11 14:38:18 <wumpus> no one is talking about just making smaller files, that would be silly
286 2014-12-11 14:39:25 <sipa> right; i don't really care about whether files or small or large; just about having logical separationg between pieces of code (and if that separation matches the file structure, so much the better)
287 2014-12-11 14:39:47 <wumpus> the point is that main has both network code and consensus-critical block handling
288 2014-12-11 14:40:03 <jgarzik> procmsg was a logical separation that paved the way for additional logical separations, while reducing future PR/patch breakage
289 2014-12-11 14:40:08 <wumpus> no matter how large or small the file is, that shouldn't be the case
290 2014-12-11 14:40:17 <sipa> procmsg is not a logical separation at all, sorry
291 2014-12-11 14:40:29 <sipa> it just moves stuff to another file, without separating
292 2014-12-11 14:41:16 <sipa> it may or may not make it easier to do separation later, but imho that's something that needs to be done for every group of messages independently anyway, and moving *everything* to one file does not help with that even
293 2014-12-11 14:41:17 <jgarzik> disagree. it also changes calling patterns in a way to opens door to more modularity with less future patch breakage
294 2014-12-11 14:42:17 <sipa> that changing of calling patterns can be done in main, without huge code movement and for the same benefit
295 2014-12-11 14:42:39 <sipa> ACTION just hates circular dependencies, sorry
296 2014-12-11 14:42:41 <jgarzik> In the kernel we have massive 50+ patch series that perform step by step transformations that result in true modularity, logical, source code separation... while at the same time, during the transition, aiming for ease of review, low patch breakage. It is about working with developer bandwidth in the midst of transformation.
297 2014-12-11 14:42:53 <jgarzik> If we logjam at step 1 we will never be able to clean up this codebase
298 2014-12-11 14:43:04 <jgarzik> I'm starting to smell "perfect is the enemy of good"
299 2014-12-11 14:43:09 <sipa> the code movement can be done at any time during the process
300 2014-12-11 14:43:13 <jgarzik> you will never have a perfect step #1
301 2014-12-11 14:43:18 <sipa> it's completely independent from everything else (at least in C++)
302 2014-12-11 14:43:22 <jgarzik> wrong
303 2014-12-11 14:43:32 <jgarzik> it is not independent of developers and other changes
304 2014-12-11 14:43:41 <jgarzik> code movement first means less headache later
305 2014-12-11 14:43:57 <sipa> meh
306 2014-12-11 14:44:20 <wumpus> I think sipa's point is that nothing will remain of procmsg when everything is moved to a separate module, so introducing it as intermediate may not be useful
307 2014-12-11 14:44:23 <sipa> if you do it after actually disentangling things, you can do it from smaller pieces of a code at a time
308 2014-12-11 14:44:32 <sipa> right, that's what i mean
309 2014-12-11 14:45:01 <jgarzik> The past couple months of code movement has been a bunch of "oops, rebase against, your branch broke again, because of a tiny trickle of things randomly disappearing from where you thought they were"
310 2014-12-11 14:45:01 <sipa> you don't want one fat do-everything module anyway, so introducing one as an intermediate step is just code movement that needs to be redone later anyway
311 2014-12-11 14:46:05 <jgarzik> IME the current method leads to slow progress, Waiting For Ideal at the expense of Good, and more patch breakage & rebasing
312 2014-12-11 14:46:57 <sipa> anyway, i'm very much in favor of splitting up ProcessMessage in smaller pieces (wherever it is located), and I won't NACK a move to a different file either (but i think it has nearly no benefit, and breaks existing patches gratuitously)
313 2014-12-11 14:47:09 <wumpus> I don't think it makes sense to complain about that, the only codebase that has no changes you have to rebase against once in a while is a dead project
314 2014-12-11 14:48:18 <sipa> and i'm actually waiting for 0.10 to be forked off, to work on some of that :)
315 2014-12-11 14:48:28 <wumpus> well, let's fork off 0.10
316 2014-12-11 14:50:00 <jtimon> is there still many pending issues for 0.10?
317 2014-12-11 14:50:19 <wumpus> * [new branch] 0.10 -> 0.10
318 2014-12-11 14:50:26 <sipa> WHIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
319 2014-12-11 14:50:43 <wumpus> jtimon: just merged the last one
320 2014-12-11 14:52:10 <jtimon> did we clang before forking?
321 2014-12-11 14:52:16 <wumpus> no, we're not going to do that
322 2014-12-11 14:52:26 <jtimon> ok, next time
323 2014-12-11 14:52:29 <wumpus> yes
324 2014-12-11 14:52:59 <wumpus> too many version differences between versions of clang-format, so people could hardly reproduce each other's results
325 2014-12-11 14:53:15 <wumpus> hopefully that will stabilize, but not yet
326 2014-12-11 14:54:30 <jtimon> yes, it should become less painful as more code gets in with the new style too
327 2014-12-11 14:58:21 <Luke-Jr> are we tagging yet?
328 2014-12-11 14:58:37 <wumpus> Luke-Jr: just branching
329 2014-12-11 14:58:50 <sipa> tagging probably after gitian issues are resolved?
330 2014-12-11 14:59:12 <wumpus> sipa: yes,let's wait for that
331 2014-12-11 15:00:06 <wumpus> going to bump master to version 0.10.99
332 2014-12-11 15:00:27 <sipa> ack
333 2014-12-11 15:09:24 <paveljanik> wumpus: #5461
334 2014-12-11 15:10:03 <paveljanik> ACTION thinks: it would be nice that some robot could translate #1234 to the title of the bug/PR and print it here...
335 2014-12-11 15:10:30 <paveljanik> #5461: signrawtransaction: validate private key
336 2014-12-11 16:01:42 <hearn> does anyone know why gitian build would fail due to inability to resolve hostnames inside the build environment?
337 2014-12-11 16:01:58 <hearn> build.log says at the bottom:
338 2014-12-11 16:01:58 <hearn> Fetching native_ccache...
339 2014-12-11 16:01:58 <hearn> make: Entering directory `/home/ubuntu/build/bitcoin/depends'
340 2014-12-11 16:01:58 <hearn> make: *** [/home/ubuntu/build/bitcoin/depends/work/build/i686-pc-linux-gnu/native_ccache/3.1.9-54d4010bcb5/.stamp_fetched] Error 4
341 2014-12-11 16:01:58 <hearn> wget: unable to resolve host address `bitcoincore.org'
342 2014-12-11 16:01:58 <hearn> wget: unable to resolve host address `samba.org'
343 2014-12-11 16:02:07 <hearn> however i can resolve these domains just fine in the gitian-build virtualbox vm
344 2014-12-11 16:02:28 <sipa> hearn: the gitian vm intentionally can't access the network
345 2014-12-11 16:02:39 <sipa> i think
346 2014-12-11 16:03:01 <sipa> the problem is that 1) the instructions don't tell you how to fetch sources outside of the VM 2) it doesn't actually work for everything
347 2014-12-11 16:03:10 <sipa> so that's a blocker for 0.10rc1
348 2014-12-11 16:06:33 <hearn> oh
349 2014-12-11 16:06:41 <hearn> so the gitian build process is just broke, right now?
350 2014-12-11 16:06:57 <sipa> it seems so, yes
351 2014-12-11 16:07:11 <hearn> ok. i'll wait for it to get fixed before trying again
352 2014-12-11 16:07:35 <sipa> you can fetch most sources manually (by running make download in depends/, and then copying to the gitian cache dir), but it doesn't work for a few
353 2014-12-11 16:10:35 <wumpus> hearn: yes, is a known issue https://github.com/bitcoin/bitcoin/issues/5428
354 2014-12-11 16:15:21 <hearn> cool
355 2014-12-11 16:15:28 <wumpus> as workaround you could give the build environment access to the internet, although it shouldn't really be required
356 2014-12-11 16:16:18 <wumpus> my gitian builder (KVM) has that, so I never noticed this problem
357 2014-12-11 16:20:50 <cfields> working on it today, sorry for that
358 2014-12-11 16:40:10 <cfields> sipa: btw, my gitian vm accesses the net no problem, so seems it's only broken in some cases
359 2014-12-11 16:40:27 <cfields> maybe it's a problem with lxc only?
360 2014-12-11 16:40:43 <sipa> that's possible; i was using lxc
361 2014-12-11 16:41:15 <wumpus> lxc can also access the net when configured for it
362 2014-12-11 16:41:26 <sipa> the question is do we want that?
363 2014-12-11 16:42:03 <cfields> sipa: either way we need a supported way of adding the sources without net access, i'm not arguing that. working on it now
364 2014-12-11 16:42:03 <wumpus> I think it's a bit of a abstraction failure to require it, though, I'd expect the building to do building
365 2014-12-11 16:42:21 <sipa> agree
366 2014-12-11 16:48:53 <tdlfbx> I was just looking at http://en.wikipedia.org/wiki/Trusted_timestamping
367 2014-12-11 16:49:58 <tdlfbx> The finance world is generally heavily tied to clocks. Bills are due at a particular time. Contracts are enforceable with time constraints. Has there been much discussion in bitcoin about time constraints? I'd think the statistical nature and unpredictable block times would be very undesirable for lots of kinds of financial uses.
368 2014-12-11 16:50:26 <tdlfbx> Bitcoin has gone to great length to eschew the use of clocks entirely.
369 2014-12-11 16:51:24 <sipa> bitcoin has a clock, one with ~hours precision, though
370 2014-12-11 16:51:37 <sipa> how often do you need higher precision?
371 2014-12-11 16:52:54 <tdlfbx> Well for instance, couldn't bailing-in and bailing-out of sidechains, and using ntimelocks be made much faster?
372 2014-12-11 16:54:02 <sipa> if you want fast inter-chain transfers, you need atomic swap, which are very fast as long as someone is offering to trade
373 2014-12-11 16:54:54 <tdlfbx> Does that require replace-by-fee?
374 2014-12-11 16:55:16 <sipa> no
375 2014-12-11 16:55:53 <sipa> it means you're not actually transferring coins from one side to the other, just doing one transaction on each side
376 2014-12-11 16:56:04 <sipa> but i'm not sure why you bring this up, or what your point is
377 2014-12-11 16:56:46 <tdlfbx> I'm just generally surprised that a financial system with a horrible clock is not having more discussion about its horrible clock.
378 2014-12-11 16:56:54 <tdlfbx> Just trying to wrap my head around why that might be okay. Or not.
379 2014-12-11 16:57:05 <sipa> i think you have to see it in perspective
380 2014-12-11 16:57:16 <sipa> pretty much all of the financial system works in the order of days
381 2014-12-11 16:57:58 <tdlfbx> If you're in the US. SWIFT/SEPA is pretty much instant.
382 2014-12-11 16:58:13 <tdlfbx> The US is a horrible backwater of ancient financial systems though.
383 2014-12-11 16:58:27 <sipa> SWIFT/SEPA is next business day at best
384 2014-12-11 16:58:47 <tdlfbx> In my opinion, waiting "days" to know that you've spent money (or not) is not acceptable in the 21st century.
385 2014-12-11 16:59:04 <tdlfbx> Burn ACH, burn.
386 2014-12-11 16:59:08 <sipa> bitcoin is instant; you can instantly spend money you received
387 2014-12-11 16:59:17 <sipa> it's only the confirmation that takes time
388 2014-12-11 16:59:19 <tdlfbx> No you can spend it an hour later.
389 2014-12-11 16:59:25 <sipa> which you need if you're not trusting the receiver
390 2014-12-11 16:59:28 <tdlfbx> Or two. ;-)
391 2014-12-11 16:59:38 <wumpus> please move discussion about what is acceptable or not to #bitcoin
392 2014-12-11 16:59:55 <wumpus> we try to build actual software here, not philosophize
393 2014-12-11 17:00:34 <tdlfbx> #bitcoin is full of idiots. Sorry wumpus.
394 2014-12-11 18:12:31 <huma_> sipa: phew. blockchain is up to date. thank you (and others) for your help.
395 2014-12-11 18:40:27 <gavinandresen> I havenât been keeping track⦠does current git HEAD use libsecp256k1 for verification? If not, how do I turn that on?
396 2014-12-11 18:41:10 <sipa> gavinandresen: it does not
397 2014-12-11 18:41:12 <wumpus> gavinandresen: it doesn't, not sure how to turn it on either
398 2014-12-11 18:41:49 <sipa> compiling with USE_SECP256K1 may work, but i think it's very unlikely that will work
399 2014-12-11 18:48:53 <wumpus> doesn't seem to work
400 2014-12-11 18:49:34 <wumpus> "error: âsecp256k1_ecdsa_pubkey_verifyâ was not declared in this scope" in pubkey.cpp, at least
401 2014-12-11 18:50:26 <gavinandresen> wumpus sipa: same error for me, looks like code rot....
402 2014-12-11 18:50:32 <wumpus> interface drift
403 2014-12-11 18:50:35 <wumpus> or that
404 2014-12-11 18:50:41 <sipa> we should just remove that secp256k1 verification code
405 2014-12-11 18:51:01 <gavinandresen> not critical to fix, Iâm just doing some benchmarking and was curious to test
406 2014-12-11 18:51:12 <sipa> should be trivial to fix for just testing
407 2014-12-11 18:51:28 <sipa> but it's silly to keep code in master around and trying to rebase it without anything exercising it
408 2014-12-11 18:51:52 <gavinandresen> clang tells me: use of undeclared identifier 'secp256k1_ecdsa_pubkey_verify'; did you mean 'secp256k1_ec_pubkey_verify'?
409 2014-12-11 18:51:56 <gavinandresen> Is that what I mean?
410 2014-12-11 18:52:00 <sipa> it is
411 2014-12-11 18:52:13 <sipa> clang is smart
412 2014-12-11 19:02:38 <Luke-Jr> âº
413 2014-12-11 19:03:05 <Luke-Jr> it would be nice if there was an unsupported-but-compiles-and-works way to do that
414 2014-12-11 19:05:25 <wumpus> I'd also prefer fixing the code to removing it again
415 2014-12-11 19:05:33 <felipelalli> what are the main news on 0.10?
416 2014-12-11 19:06:20 <wumpus> I wouldn't go as far as having an actual configure switch to enable it, but an obscure -DSOMETHING where it's clear that it's extremely experimental would be fine
417 2014-12-11 19:39:25 <nelisky> s
418 2014-12-11 19:42:29 <wumpus> cfields: I just realize that most of the people that reach the lxc-without-network problem are probably following https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md ; it used to work, but it may be that it no longer properly sets up network within lxc for newer debian versions
419 2014-12-11 19:43:00 <cfields> wumpus: thanks, i'll look into that as well
420 2014-12-11 19:44:09 <cfields> wumpus: i agree that offline downloading should work for sure, but it'd be nice to assume that downloading will work for the common case. so imo it's worth tracking down/fixing that issue.
421 2014-12-11 19:44:42 <cfields> getting ready to push up fixes for the offline case, then i'll have a look there.
422 2014-12-11 20:35:05 <StephenM347> I've been working through the bitcoin code base, trying to understand it, and I have a few questions. Anyone have a sec to help me out?
423 2014-12-11 20:41:07 <BlueMatt> rusty: havent had a chance to look, and it'll probably be a few days before I can, feel free to set something up yourself, otherwise I'll dig into it a bit later
424 2014-12-11 20:46:03 <rubensayshi> StephenM347, you're best off just asking and most of the time you'll get a reply ;-)
425 2014-12-11 20:51:12 <StephenM347> @rubensayshi, thanks. Well, the first question I have is that when a node receives a new block, it calls ProcessBlockI() but that doesn't check the inputs with CheckInputs. So what is the flow here, how do the inputs get checked when a new block comes in?
426 2014-12-11 21:00:38 <lechuga_> StephenM347: ConnectBlock will check the inputs
427 2014-12-11 21:01:28 <lechuga_> by way of ActivateBestChain
428 2014-12-11 21:03:35 <StephenM347> lechuga, but ConnectBlock() isn't called from ProcessBlock(), so where is it called from when a peer gives a new block?
429 2014-12-11 21:04:47 <lechuga_> ProcessNewBlock
430 2014-12-11 21:06:29 <lechuga_> do you have an IDE or ctags?
431 2014-12-11 21:06:48 <lechuga_> might make life easier for you
432 2014-12-11 21:07:05 <StephenM347> Oh, so is it ProcesBlock() -> AcceptBlock() -> AddToBlockIndex() -> ActivateBestChain() -> ConnectTip() ?
433 2014-12-11 21:07:19 <StephenM347> I don't have either of those, just text editor
434 2014-12-11 21:07:51 <lechuga_> people r going to be annoyed at us walking through callstacks lets take this offline
435 2014-12-11 21:33:34 <michagogo> 07:56:17 <gmaxwell> op_null: you could go one further and write a patch that let you disable all transaction transmission, which we were musing about being very useful. e.g. lets you use the wallet like normal but then submit your transactions over some more private method.
436 2014-12-11 21:33:49 <michagogo> I did that once when I wanted to mine a huge-fee transaction on testnet, just for fun
437 2014-12-11 21:34:05 <michagogo> It was just a "return" or something like that
438 2014-12-11 21:34:33 <michagogo> I remember being very surprised that I had (sort of) managed to write a line of c++ :P
439 2014-12-11 22:08:47 <michagogo> ccache ftw \o/
440 2014-12-11 22:08:49 <michagogo> cache hit (direct) 102
441 2014-12-11 22:08:49 <michagogo> cache hit (preprocessed) 0
442 2014-12-11 22:08:49 <michagogo> cache miss 88
443 2014-12-11 22:47:03 <gribble> Request successful for user notplato, hostmask notplato!ad3a5ff8@gateway/web/freenode/ip.173.58.95.248. Your challenge string is: freenode:#bitcoin-otc:edadbb3abd5cb83c3c2012695b4ecdd3950916ec6e86b60b95557ddd
444 2014-12-11 22:47:03 <notplato> ;;bcauth notplato
445 2014-12-11 22:47:49 <gribble> Error: This nick is not registered. Please register.
446 2014-12-11 22:47:49 <notplato> ;;bcauth H8irH+HdhMgzoa2pCcJKtbi02nhZdpE7bqb2U5NuWbta+RjO0XjQahJR8/kPTxMsgGCgHF48vp1UktBkUCO3JJo=
447 2014-12-11 22:49:49 <notplato> ;;ns register CHpRBZQkey dscotese@litmocracy.com
448 2014-12-11 22:49:50 <gribble> Error: "ns" is not a valid command.
449 2014-12-11 22:50:34 <gribble> (bcauth <nick>) -- Initiate authentication for user <nick>. You must have registered with the bot with a bitcoin address for this to work. You will be given a random passphrase to sign with your address, and submit to the bot with the 'bcverify' command. Your passphrase will expire within 10 minutes.
450 2014-12-11 22:50:34 <notplato> ;;bcauth notplato H8irH+HdhMgzoa2pCcJKtbi02nhZdpE7bqb2U5NuWbta+RjO0XjQahJR8/kPTxMsgGCgHF48vp1UktBkUCO3JJo=
451 2014-12-11 22:50:52 <arubi> notplato, are you aware of what you're doing on a public channel?
452 2014-12-11 22:51:12 <notplato> Thanks, I thought commands were hidden.
453 2014-12-11 22:51:31 <helo> it's offtopic, but perfectly safe
454 2014-12-11 22:51:54 <arubi> helo, his email is right there
455 2014-12-11 22:52:32 <helo> shrug
456 2014-12-11 22:58:13 <notplato> Has anyone discussed using maidsafe/bittorrent algorithms to spread the full blockchain over many nodes so that there are many copies and only miners need a full copy (and can get it quickly)?
457 2014-12-11 22:59:03 <helo> notplato: #bitcoin for non-development stuff please
458 2014-12-11 23:00:28 <notplato> Isn't solving the storage problem part of development?
459 2014-12-11 23:01:10 <helo> short answer is "yes, it already has been done"
460 2014-12-11 23:02:30 <helo> see https://bitcoin.org/bin/blockchain/bootstrap.dat.torrent
461 2014-12-11 23:32:20 <cfields> sipa: opposed to disabling bench by default for secp256k1 ?
462 2014-12-11 23:34:23 <XPLZ> https://cryptospell.com/ is giving out bitcoin in the chat room!
463 2014-12-11 23:35:07 <lewellyn> that doesn't come across as at all spammy :P
464 2014-12-11 23:35:19 <XPLZ> lewellyn i just launched :D
465 2014-12-11 23:35:28 <XPLZ> I have to shout it out at least one time hehe :D
466 2014-12-11 23:35:37 <XPLZ> Join me i send you some BTC :D
467 2014-12-11 23:36:05 <lewellyn> ACTION bets "some BTC" means "BTC with lots of zeros after a decimal" :P
468 2014-12-11 23:36:17 <XPLZ> like mBTC
469 2014-12-11 23:36:25 <cfields> XPLZ: this is a dev channel. Please take that elsewhere.
470 2014-12-11 23:36:37 <XPLZ> but this is my development
471 2014-12-11 23:36:41 <XPLZ> or does that not count maybe?
472 2014-12-11 23:37:44 <cfields> XPLZ: see topic. bitcoin network and core
473 2014-12-11 23:37:54 <lewellyn> XPLZ: how is whatever you're doing (i didn't click the link) improve the bitcoin network or reference software?
474 2014-12-11 23:38:11 <XPLZ> Sorry i will not write about this more
475 2014-12-11 23:39:08 <lewellyn> actually, it might be perfectly on-topic, if you're somehow affecting the network. (postively or negatively)