1 2014-05-04 00:34:06 <amiller-> what are the nodes with empty version strings?
  2 2014-05-04 00:34:14 <amiller-> that don't relay anything?
  3 2014-05-04 00:34:27 <amiller-> is that a well known thing
  4 2014-05-04 00:37:02 <gmaxwell> amiller-: I wasn't aware of them. Do they make outbound connections?
  5 2014-05-04 00:37:33 <amiller-> i'm not sure
  6 2014-05-04 00:45:04 <amiller-> nvm i'm doing something wrong
  7 2014-05-04 00:45:39 <t3ssa> any debian users here?
  8 2014-05-04 01:02:29 <amiller-> meh, 193.14.106.80 is one
  9 2014-05-04 01:02:43 <amiller-> version number = 32300 hrm
 10 2014-05-04 01:03:52 <amiller-> it shows up as unreachable in getaddr.bitnodes.io which i guess makes sense because of the old version number
 11 2014-05-04 01:10:17 <amiller-> there aren't very many of them, so never mind
 12 2014-05-04 02:09:38 <dexX7> gmaxwell, sipa: problem of too many open files fixed by deleting the leveldb iterator after usage in ReadAddrIndex :)
 13 2014-05-04 02:11:35 <maaku> dexX7: pull request please :)
 14 2014-05-04 02:12:44 <dexX7> this is related to the addr indexed branch
 15 2014-05-04 02:24:11 <jcorgan> dexX7: are you using #3652?
 16 2014-05-04 02:25:30 <jcorgan> if so, send me a pull request, i'll take care of it and update the PR.  I need to do work on the branch anyway, a very recent update on master in txdb.cpp breaks it so i'll be digging around and rebasing anyway.
 17 2014-05-04 02:26:15 <FastOb> Bitcoin going to fall hard today to around 350$ or less look at CoinDesk signals app wtf is going...  http://bit.ly/1hnHeso
 18 2014-05-04 02:28:25 <gmaxwell> (and probably a malware link)
 19 2014-05-04 04:35:41 <amiller-> uh, how do i compile my node to never prune
 20 2014-05-04 04:35:44 <amiller-> so that getrawtransaction always works
 21 2014-05-04 04:37:05 <Luke-Jr> amiller-: txindex=1 bitcoin.conf
 22 2014-05-04 04:37:20 <amiller-> i see
 23 2014-05-04 04:37:23 <amiller-> thanks
 24 2014-05-04 05:09:42 <arowser> arowser tiange
 25 2014-05-04 06:04:27 <sipa> amiller-: the utxo set is always a utxo set and not an index (it is just a copy of all unspent outputs, it never has full transactions, and it doesn't know where on disk to find a transaction)
 26 2014-05-04 06:04:44 <amiller-> oh.
 27 2014-05-04 06:05:15 <sipa> amiller-: txindex=1 just adds an additional transaction index to the block chain database (not to the utxo set)
 28 2014-05-04 06:05:36 <amiller-> got it
 29 2014-05-04 06:13:20 <jgarzik> amiller-, if you are running queries, http://insight.is/ might be useful to you
 30 2014-05-04 06:13:42 <jgarzik> amiller-, but yes, at the end of the day, txindex=1 makes getrawtransaction work for all transactions, spent or not
 31 2014-05-04 06:20:42 <wumpus> sipa: it would be possible to compile a module without stack checking, if performance is really important, AFAIK it's not possible to disable it for single functions
 32 2014-05-04 06:29:03 <gmaxwell> wumpus: it should be using pragma push_options, though I've never tried.
 33 2014-05-04 06:30:02 <wumpus> gmaxwell: okay
 34 2014-05-04 06:37:28 <wumpus> gmaxwell: btw about non-contiguous ip ranges, we could map the ips to a space-filling curve in 2D or 3D then do range queries :p
 35 2014-05-04 06:40:40 <wumpus> something like https://xkcd.com/195/
 36 2014-05-04 06:54:33 <gmaxwell> wumpus: hah, well it was a dump question the calling code already takes multiple options.
 37 2014-05-04 07:02:04 <gmaxwell> wumpus: you might have missed it earlier: 14:48 < gmaxwell> wumpus: sorry about the misclick on 4102 (I accidentally closed it, I instantly reopened it... I started to ask a question then went and read the  code and realized the question was stupid and clicked the wrong button to cancel)
 38 2014-05-04 07:04:35 <wumpus> gmaxwell: ah, yes I missed that
 39 2014-05-04 07:09:15 <gmaxwell> (interestingly, if you type a comment and hit close instead of submit it both submits and closes)
 40 2014-05-04 07:14:52 <wumpus> I've noticed, it's quite easy to accidentally close an issue
 41 2014-05-04 07:37:23 <sipa> wumpus: not worth it probably, but if we do need that at some point, it's useful that all the crypto code ends up in a separate subdir too
 42 2014-05-04 07:37:41 <wumpus> sipa: yep!
 43 2014-05-04 07:49:45 <HaltingState> wumpus, dont worry about stack checking
 44 2014-05-04 07:49:49 <HaltingState> 10% performance is not big deal
 45 2014-05-04 07:57:21 <gmaxwell> HaltingState: if it really were 10% performance, you're talking about adding say 20 minutes to a sync. That would be a big deal. But fortunately its not 10% there.
 46 2014-05-04 07:57:36 <HaltingState> gmaxwell, less?
 47 2014-05-04 07:58:00 <HaltingState> signature checks and other things can probably be threaded
 48 2014-05-04 07:58:26 <wumpus> HaltingState: I'm not worrying about it; it's just that having the stack smashing protection throw a spanner into the works of a tighly, manually optimized inner loop would be a pity
 49 2014-05-04 07:59:57 <wumpus> although in that case the inner function should probably be force-inlined instead, that would also avoid stack-smashing detection (I'd hope...)
 50 2014-05-04 07:59:59 <HaltingState> i would enable all security flags and stack smashing protection and non-write to executable pages and just have that as baseline and default'
 51 2014-05-04 08:00:10 <wumpus> HaltingState: that's already the case
 52 2014-05-04 08:00:24 <gmaxwell> HaltingState: they already were threaded a long time ago, and it's already the case that the hardening stuff is all enable.d
 53 2014-05-04 08:00:43 <HaltingState> that is what i would do and what seems most sensible; the risk of a buffer overflow attack or other attack is greater than performance issue
 54 2014-05-04 08:01:36 <gmaxwell> The only thing being addressed here is that some assembly code was replaced in a library with straight C which is slightly slower, and sipa mentioned that since it has an additional function call there may be a new stack check. There is no risk of buffer overflow in the sha256 compression function. There are no dynamic indexes in it at all.
 55 2014-05-04 08:01:44 <wumpus> but in inner crypto code working with fixed buffers there is very little worry about a buffer overflow
 56 2014-05-04 08:01:56 <wumpus> right
 57 2014-05-04 08:02:03 <gmaxwell> (which might even cause the compiler to not emit the stack checking there at all, if its sufficiently smart)
 58 2014-05-04 08:02:20 <wumpus> 'sufficiently smart' compilers, hah
 59 2014-05-04 08:03:41 <gmaxwell> hey, they're often quite smart! (at finding ways to make things fail in surprising ways…)
 60 2014-05-04 08:04:50 <wumpus> they're incredibly smart these days, compiler code is some of the craziest code I've seen
 61 2014-05-04 08:05:35 <aburan28> random question but if one were to acquire a large block of ipv6 addresses could they potentially perform a sybil attack?
 62 2014-05-04 08:06:20 <gmaxwell> aburan28: Bitcoin does not trust its peers, generally doing things like that are only DOS attacks.
 63 2014-05-04 08:07:07 <gmaxwell> wumpus: wrt your comment on the memory usage issue: the huge memory spikes were worked around by sipa's change to limit orphan blocks. Most of the spiking was storing orphan blocks in memory.
 64 2014-05-04 08:07:13 <wumpus> aburan28: the network code does some grouping of addresses by subnet ranges to avoid that, though indeed at most it could result in a DoS attack
 65 2014-05-04 08:08:41 <gmaxwell> well, not quite at most. since if you really have a huge number of nodes relative to the honest network you could potentially partition new nodes, and if you managed to get a large miner in your partitioning network you could have some fun beyond dos attacks.
 66 2014-05-04 08:09:06 <gmaxwell> But Bitcoin is not trivally insecure to sybil attacks like most p2p systems are.
 67 2014-05-04 08:10:17 <wumpus> gmaxwell: right, it looks like limiting the orphans (as well as the earlier changes in leveldb to not mmap everything) indeed helped
 68 2014-05-04 08:13:07 <wumpus> partitioning the network is possible, although it only takes one non-coorporating node to 'bridge' the partition
 69 2014-05-04 08:17:32 <gmaxwell> wumpus: yea, its the sort of thing where if you somehow manage to have an apparent 500,000 nodes to the honest network's 10,000 reachable nodes, then— with those figures— there is a 85% chance ((500k/510k)^8) a new peer with that view of the network will pick all 8 nodes as from the attacker. This is usually just a dos attack and kinda boring.
 70 2014-05-04 08:18:05 <gmaxwell> But if the attacker nabbed a new big miner it would be somewhat interesting... though large miners tend to also have manually configured peering
 71 2014-05-04 08:18:18 <gmaxwell> (thus making any such attack completely impossible against them)
 72 2014-05-04 08:18:58 <gmaxwell> also, as wumpus noted earlier the peer selection avoids picking multiple hosts from the same netgroup (/32 for IPv6 IIRC). So just a single block doesn't help you.
 73 2014-05-04 08:19:38 <gmaxwell> (e.g. you need to have at least 8 blocks, and then split your zillion fake hosts across them)
 74 2014-05-04 08:20:33 <gmaxwell> and then you end up with much lower odds for a given number of fake hosts.
 75 2014-05-04 08:21:53 <gmaxwell> If we someday add authenticated peers and addr messages in coinbases partitioning will become even harder, not to mention Jgarzik's bitcoinsat project.
 76 2014-05-04 08:31:07 <sipa> gmaxwell, jgarzik: will the sattelite relay full blocks?
 77 2014-05-04 08:33:24 <aburan28> another question i have is whether or not there are any plans to try and change the p2p network in a way to try and obfuscate the ip address of initial node that broadcasts a tx
 78 2014-05-04 08:34:01 <gmaxwell> aburan28: uh? Why do you believe it isn't already?
 79 2014-05-04 08:35:19 <aburan28> because if someone were to place nodes at certain vantage points in the network they could observe propagation patterns
 80 2014-05-04 08:35:30 <sipa> only your direct peers can reasonably guess that you are the original author
 81 2014-05-04 08:35:39 <sipa> if you don't want even that, use tor
 82 2014-05-04 08:36:38 <aburan28> even with tor its not a guarantee because there are only a few thousand ip addresses running the tor network
 83 2014-05-04 08:37:58 <sipa> yup
 84 2014-05-04 08:38:20 <sipa> you can always sign the transaction offline, and broadcast it from elseahere
 85 2014-05-04 08:38:38 <sipa> there are probably a dozen interfaces/websites where you can paste a transaction
 86 2014-05-04 08:39:45 <gmaxwell> aburan28: okay, sometimes people showing up thinking transactions contain IP addresses and I couldn't tell if thats what you were thinking from what you initially said. :)
 87 2014-05-04 09:12:57 <wumpus> aburan28: at least with tor your traffic gets mixed with non-bitcoin traffic
 88 2014-05-04 09:18:51 <wumpus> and the tor entry node doesn't know what you're connecting to or what you're sending, so it makes timing correlation difficult (not impossible, but that's inherent in a low-latency anonymity network)
 89 2014-05-04 09:23:57 <wumpus> ie, an observer watching the entire internet may see you submitting a bitcoin-transaction-sized packet to TOR just before it appears on the P2P network
 90 2014-05-04 09:31:34 <wumpus> a high-latency onion/mix network would be more suited than tor, but, it would have to have other uses than bitcoin, otherwise there is nothing to 'hide in'
 91 2014-05-04 09:34:55 <wumpus> anyway, people can get creative with submitting, forwarding, grouping, ungrouping, dead-dropping and picking up transactions in all kinds of ways like any other data, there is no reason to 'plan any changes to the p2p network'
 92 2014-05-04 09:37:18 <survic> wumpus: that could be extended in a way, not having some forms of transactions relayed in standard ways. a "shell" message around a normal transaction that instructs the peer to wait, or send some junk data back as a fake response, that sort of thing. stripped off at that hop it wouldn't have any effect on the rest of the network. not sure how well that would work, and even if it's desirable though.
 93 2014-05-04 09:37:53 <wumpus> survic: there's just no motivation to make it part of the bitcoin P2P network... it's *better* to hide among other data and messages
 94 2014-05-04 09:40:38 <wumpus> I'm not very much at home in the matter, or whether any high-latency mixing networks are in common use
 95 2014-05-04 09:41:00 <penny> anyone seen the testnet blockchain, it's getting loads of confirmations, haven't seen that kind of thing before
 96 2014-05-04 09:41:44 <survic> I seem to remember there was a Usenet one that pretty much failed entirely because people used extremely bad crypto. passwords instead of gpg keys, weak gpg keys, almost all of it was broken in some way.
 97 2014-05-04 09:43:04 <wumpus> if one exists, it'd only need a forwarder to the bitcoin network
 98 2014-05-04 09:43:07 <wumpus> survic: hah
 99 2014-05-04 09:44:21 <survic> wumpus: it was alt.anonymous. the interesting crypto stuff comes around page 20 and onwards. http://ritter.vg/p/AAM-defcon13.pdf
100 2014-05-04 09:45:17 <wumpus> anyhow, for those that don't pick fights against omnipotent adversaries, tor works well enough for actual usable transaction privacy
101 2014-05-04 09:46:38 <survic> I don't plan to pick any fights with any adversaries, but it's an interesting problem to think about.
102 2014-05-04 09:46:49 <survic> and those defcon slides are extremely interesting.
103 2014-05-04 10:12:35 <shesek> did someone just point an ASIC at testnet?
104 2014-05-04 10:13:16 <shesek> 13:12:50 2014-05-04 [INF] BMGR: Processed 12 blocks in the last 10.34s
105 2014-05-04 10:13:48 <penny> I was wondering about that on testnet
106 2014-05-04 10:14:00 <penny> seems to have stopped now
107 2014-05-04 10:14:32 <penny> seems to be identical 25BTC transactions as well
108 2014-05-04 10:15:11 <shesek> seems like almost all of them are blocks with nothing but the block reward
109 2014-05-04 10:15:14 <shesek> and I'm still seeing those here
110 2014-05-04 10:17:27 <shesek> I'm also getting some forks, probably someone running some experiment?
111 2014-05-04 10:17:53 <penny> oh yeah true.. I'm still getting them although the block explorer seems to have stopped
112 2014-05-04 10:18:04 <penny> annoying I'm trying to test something and it's going nuts
113 2014-05-04 10:18:27 <penny> maybe someone wants a lot of testnet coins
114 2014-05-04 10:18:33 <shesek> its quite okay for me, my transactions are getting confirmed faster :P
115 2014-05-04 10:18:47 <shesek> and I get a chance to test my code for handling reorgs
116 2014-05-04 10:19:16 <penny> haha true
117 2014-05-04 10:19:17 <shesek> though those blocks are sent so fast that the forks don't really cause a reorg
118 2014-05-04 10:20:33 <shesek> the annoying part is that after the difficulty adjustment we'll be stuck with blocks 20 minutes apart
119 2014-05-04 10:24:22 <wumpus> penny: testnet is usually a very wild and unpredictable environment (whichi is good for testing) but if you want reliable testing, use a local regtest network
120 2014-05-04 10:26:26 <shesek> looks like someone is definitely testing out forking the network
121 2014-05-04 10:26:51 <shesek> they're causing a fork every 10-30 blocks (which is roughly ever 10-30 seconds)
122 2014-05-04 10:41:07 <penny> wumpus: thanks for the info
123 2014-05-04 11:32:21 <timmit> I am running bitcoind (full) on my vserver. its running and has downloaded the complete blockchain, also says it has ~10 connections. however getaddr.bitnodes.io claims its not reachable. is there any other way to test my node?
124 2014-05-04 11:33:36 <survic> timmit: having more than 10 connections means you're accepting at least 2 incoming peers, I assume your listening port is fine in that case. would you like me to connect back to you just to be sure?
125 2014-05-04 11:34:01 <survic> (the client only makes a maximum of 8 outgoing connections by itself, this isn't an option that can be changed)
126 2014-05-04 11:34:14 <timmit> 178.254.9.135:8333
127 2014-05-04 11:35:13 <survic> timmit: yes, I can see that port is listening.
128 2014-05-04 11:36:04 <survic> you'll gain more incoming peers over time as your address is distributed to more peers in need of connections.
129 2014-05-04 11:37:17 <timmit> ok but why does bitnodes.io claim its not reachable?
130 2014-05-04 11:40:41 <survic> timmit: bug on their end? who knows. it's not an authoritative source of information at any rate.
131 2014-05-04 11:40:54 <timmit> ok
132 2014-05-04 11:41:13 <survic> I can connect and handshake, so it's a false negative.
133 2014-05-04 11:41:40 <timmit> can i see somehow that its doing actual work?
134 2014-05-04 11:42:19 <timmit> getinfo gives me the same output all the time
135 2014-05-04 11:42:37 <survic> work?
136 2014-05-04 11:42:44 <survic> what do you expect it to be doing?
137 2014-05-04 11:43:49 <timmit> uhm stuff that a full node should be ding. isnt it supposed to check signatures in the blockchain?
138 2014-05-04 11:44:01 <timmit> validating transactions?
139 2014-05-04 11:44:15 <timmit> or am i misled here?
140 2014-05-04 11:45:20 <survic> no, it'll be doing that all behind the scenes. you won't see any output of this.
141 2014-05-04 11:46:29 <survic> you'll be validating blocks, relaying them, all the good stuff. your incoming connections are good.
142 2014-05-04 13:21:40 <jgarzik> sipa, gmaxwell:  Yes, my BitSat project will receive full blocks from authenticated, hardened ground stations, and broadcast worldwide for free.  You always get the latest block(s) from the sat.
143 2014-05-04 13:42:44 <skinnkavaj> Testnet block explorer?
144 2014-05-04 14:21:37 <netg_> https://blockexplorer.com/testnet
145 2014-05-04 15:01:58 <tyrick> When you connect to one of the DNS seeds in chainparams.cpp, is your ip added to the lest of known nodes?
146 2014-05-04 15:02:07 <tyrick> list*
147 2014-05-04 15:02:51 <jgarzik> tyrick, no
148 2014-05-04 15:04:04 <tyrick> jgarzik, hm, so how would the network learn about my node?
149 2014-05-04 15:05:58 <jgarzik> sipa, gmaxwell: the specific BitSat algorithm endlessly transmits a buffer.  The buffer contains N latest blocks (and transactions too, if budget/tech permits, which is unlikely).  Buffer is transmitted in chrono order, with most recent block first, as you would expect.
150 2014-05-04 15:06:59 <jgarzik> I am open to other algorithm suggestions, though.  The hardware is basically a buffer.  Uplink sends data.  Cubesat authenticates data via public key auth, then adds to buffer.  gmaxwell has suggested performing header verification on sat, which seems possible.
151 2014-05-04 15:08:02 <jgarzik> The transmitter transmits the parts of the buffer software tells it to transmit.  (current algo for broadcast-to-earth just described)
152 2014-05-04 15:09:02 <jgarzik> So you have RAM sufficient for software + several 1MB blocks buffers, and a sub-1Ghz RISC processor (let's say 400 Mhz)
153 2014-05-04 15:10:00 <jgarzik> still trying to nail down uplink and downlink speeds -- that's one of the deliverables of the current design contract with builder Deep Space Industries
154 2014-05-04 15:10:35 <tyrick> Excuse my interrupt, but is the sat really happening?
155 2014-05-04 15:10:37 <jgarzik> Picking a frequency/radio impacts the entire system design, from cubesat hardware & power to uplink/downlink costs and complexity
156 2014-05-04 15:10:42 <jgarzik> tyrick, yes
157 2014-05-04 15:11:21 <jgarzik> tyrick, RE "how would the network learn about my node?" <<---  to use bittorrent language, peer exchange.  the DNS seeds independently crawl the network.
158 2014-05-04 15:11:55 <jgarzik> tyrick, your bitcoin node's address will be shared among peers, and eventually discovered by a DNS seed, if the bitcoin node is up long enough
159 2014-05-04 15:19:27 <tyrick> jgarzik, is the software going to be open source as well?  Shoot me as much info on this as your can.  I am pretty interested
160 2014-05-04 15:38:23 <jgarzik> tyrick, "default: open source"
161 2014-05-04 15:38:44 <jgarzik> tyrick, US ITAR regulations impose some pretty stupid limitations, even if your project is open source.
162 2014-05-04 15:39:01 <michagogo> cloud|ITAR?
163 2014-05-04 15:39:28 <jgarzik> tyrick, software, I would _think_, would be OK to open source, but that's one of many things gotta run by the ITAR advisor :/
164 2014-05-04 15:40:36 <jgarzik> michagogo|cloud, technology-transfer-outside-the-US regulations.  Initially targeting people exporting US military tech to foreign nations (ok), but "dual use" technology which has both benign and military technology, can be restricted too.
165 2014-05-04 15:41:10 <michagogo> cloud|Well
166 2014-05-04 15:41:13 <jgarzik> The latter ropes in a lot of (IMO) collateral damage, especially to firms and projects that prefer open source / open hardware.
167 2014-05-04 15:41:25 <michagogo> cloud|I guess space is out of the is
168 2014-05-04 15:41:28 <michagogo> cloud|US*
169 2014-05-04 15:41:48 <jgarzik> michagogo|cloud, Sure.  It's the getting-to-space part that roadblocks you :)
170 2014-05-04 15:42:08 <jgarzik> michagogo|cloud, Getting to space requires the capability to launch an ICBM
171 2014-05-04 15:42:12 <michagogo> cloud|Can't you ship the hardware blank, and then give them the link to download the software? :P
172 2014-05-04 15:42:27 <jgarzik> and that capability is necessarily restricted...
173 2014-05-04 15:43:33 <jgarzik> Like I said, I am pretty sure software in general is OK to open source, but e.g. there might be certain software techniques (missile guidance?) that gets restricted for odd reasons.
174 2014-05-04 15:43:43 <jgarzik> ITAR is mainly on the hardware side these days
175 2014-05-04 15:43:56 <jgarzik> Restricting PlayStation 2's to Saddam Hussein, that sort of thing.
176 2014-05-04 15:53:25 <Einewton> HI
177 2014-05-04 16:47:27 <michagogo> cloud|14:34:26 <survic> (the client only makes a maximum of 8 outgoing connections by itself, this isn't an option that can be changed) <-- it's not that it's impossible to change
178 2014-05-04 16:47:53 <michagogo> cloud|You just need to manually change a line in (I think) net.cpp and recompile
179 2014-05-04 16:47:55 <maaku> jgarzik: open-source or not doesn't affect ITAR rules ... which make absolutely no sense at all
180 2014-05-04 16:51:55 <tf2honeybadger> Hey, quick question. Will using the noatime mount option break the bitcoin daemon at all?
181 2014-05-04 16:52:12 <tf2honeybadger> Does it need to use last access time for anything?
182 2014-05-04 16:52:43 <maaku> tf2honeybadger: no
183 2014-05-04 16:52:53 <tf2honeybadger> excellent, thank you.
184 2014-05-04 16:53:00 <michagogo> cloud|tf2honeybadger: not that I can think of, no
185 2014-05-04 16:53:24 <michagogo> cloud|I can't tell you it won't break anything, but I can't think of any possible reason it would
186 2014-05-04 16:53:37 <tf2honeybadger> I'll test it before putting it into productoin
187 2014-05-04 16:53:39 <maaku> i run all my servers with noatime, never experienced anything out of the ordinary
188 2014-05-04 16:53:45 <tf2honeybadger> oh, great maaku
189 2014-05-04 17:03:48 <maaku> tf2honeybadger: i'm not sure anyone except backup services use atime for anything
190 2014-05-04 17:32:14 <tyrick> can you mine using the QT client?
191 2014-05-04 17:34:38 <gmaxwell> yes, though you need some additional things too.
192 2014-05-04 17:37:06 <tyrick> additional parameters?
193 2014-05-04 17:38:16 <gmaxwell> tyrick: e.g. it's not interesting or economical to mine without specialized hardware.
194 2014-05-04 17:40:09 <tyrick> gmaxwell, agreed, but I just swapped out the genesis block and was going to play around on this new chain
195 2014-05-04 17:40:27 <tyrick> I just thought there was a miner within QT, though I don't see it
196 2014-05-04 17:41:13 <PK> iirc, you can start it over the built in console?
197 2014-05-04 17:41:29 <PK> something like /setgenerate true or so
198 2014-05-04 17:41:47 <PK> maybe without the slash.
199 2014-05-04 17:42:02 <PK> 
ACTION only remember vaguely.

200 2014-05-04 17:43:45 <gmaxwell> tyrick: please don't ask any further altcoin questions in here.
201 2014-05-04 17:48:34 <PK> gmaxwell: btw, you were quoted in a local newspaper about two months ago. I was reading the paper printed version and was surprised to see your name there. :) Here's the online version if you care: http://www.20min.ch/finance/news/story/Dubioses-Geschaeft-mit-Bitcoin-Rechnern-18031481
202 2014-05-04 17:50:11 <tyrick> gmaxwell: I'm not making an alt; thought technically it is,  I have bitcoin in mind.
203 2014-05-04 17:59:18 <donvino> hi swiss friends!
204 2014-05-04 18:31:21 <jgarzik> maaku, Somewhat.  ITAR rules were updated in the 1990s so that crypto software was no longer classified as weapons grade munitions, in part because of open source + Internet making borders irrelevant (and as a result, jobs and crypto work started moving outside the US)
205 2014-05-04 18:32:01 <jgarzik> No direct connection.  Ideally, ITAR rules should take into account open licensed hardware and software, but it doesn't
206 2014-05-04 18:45:54 <hearn> hello
207 2014-05-04 19:53:10 <aburan28> Has anyone seen this new paper regarding sybil attack defense in p2p networks? http://www.eecs.harvard.edu/econcs/pubs/Seuken_aamas14.pdf
208 2014-05-04 19:59:15 <gmaxwell> I've not seen it, the title doesn't inspire me with confidence though (transitive trust has been an orgy of failure in reputation systems; usually it elimiates one attack mode while making the system extremely vulnerable to others).  We generally don't want to be connected to our peers peers (the bitcoin network should approximately be an expander graph).
209 2014-05-04 19:59:28 <gmaxwell> Have you read it? is it worth reading?
210 2014-05-04 20:01:05 <Eliel_> I thought I'd upgrade to bitcoin core 9.1 and decided to finally try to verify it too before installing. However, I hit a wall at figuring out how to get the public key you'd need to verify the signed sha256sums.asc file. What ways are there to get it and how would I know it's the real one?
211 2014-05-04 20:04:23 <gmaxwell> Eliel_: it's signed by gavin's code signing key which is on the bitcoin.org site and in the pgp key servers, I believe. This key is connected to the larger pgp web of trust. If you've ever validated some strongly connected pgp keys you can find a path to it.
212 2014-05-04 20:04:31 <gmaxwell> e.g. http://pgp.cs.uu.nl/mk_path.cgi?FROM=B0413BFA&TO=1FC730C1&PATHS=trust+paths
213 2014-05-04 20:06:07 <gmaxwell> (or better to use the longer fingerprint, 32 bits is too easy to forge: http://pgp.cs.uu.nl/mk_path.cgi?FROM=B0413BFA&TO=26646D99CBAEC9B81982EF6029D9EE6B1FC730C1&PATHS=trust+paths )
214 2014-05-04 20:06:58 <gmaxwell> hearn: Hey, I was told that someone sometime sent you code implementing threshold RSA signing.  Do you still have it?
215 2014-05-04 20:07:10 <hearn> let me rummage around and check
216 2014-05-04 20:07:47 <gmaxwell> (I'd like to move us to using threshold RSA for the pgp signing key for releases)
217 2014-05-04 20:07:47 <hearn> yeah i do
218 2014-05-04 20:07:51 <hearn> hmmm
219 2014-05-04 20:08:05 <hearn> why? is it worth the complexity? i got it for Android where we can’t upgrade the OS to just count signatures
220 2014-05-04 20:08:35 <hearn> https://drive.google.com/file/d/0B4t9VJLm_PWhX2ZralFGR2dJVXM/edit?usp=sharing
221 2014-05-04 20:08:40 <hearn> it can be downloaded there
222 2014-05-04 20:08:47 <hearn> it’s in the opentc subfolder
223 2014-05-04 20:09:31 <gmaxwell> Becuase of norms mostly. We could implement our own signing thing for releases or tell people they must look for multiple keys, but already few enough people check the signatures. I have some friends who want an openpgp project and I thought I'd give a shot at getting them to go integrate it.
224 2014-05-04 20:09:51 <hearn> ok. the code is pretty ugly and rather academic, and i never got around to trying it
225 2014-05-04 20:09:58 <hearn> if they can whip it into shape that’d be fantastic
226 2014-05-04 20:10:20 <gmaxwell> for the android signing what format are the signatures? Is it x509?
227 2014-05-04 20:10:42 <Eliel_> if you want more people to do it, it needs to be made somewhat easier to figure out how to do it.
228 2014-05-04 20:11:11 <Eliel_> if I could use the previous release to verify the new release somehow, it'd make it much simpler.
229 2014-05-04 20:11:36 <gmaxwell> Eliel_: I know. There are a bunch of annoying things about it. Part of it is just documentation, but since the whole process needs to be improved I haven't thought it was important write good docs yet.
230 2014-05-04 20:12:16 <hearn> i am not sure. i haven’t looked. but the signatures the library creates are regular RSA so it should be irrelevant
231 2014-05-04 20:12:47 <Eliel_> for example, if could do something like "bitcoind verifyupgrade /tmp/bitcoin-0.9.1-linux.tar.gz", I'd most likely use it.
232 2014-05-04 20:13:08 <hearn> BlueMatt once implemented auto update for bitcoin core
233 2014-05-04 20:13:12 <hearn> but it was never merged
234 2014-05-04 20:13:34 <gmaxwell> It wasn't mergable.
235 2014-05-04 20:13:42 <gmaxwell> (and matt will tell you this too)
236 2014-05-04 20:15:59 <gmaxwell> Eliel_: this is what gitian downloader is ultimately to do. Needs work. we wouldn't merge it into the bitcoin(d) binary itself, but we could certantly ship an update checker.
237 2014-05-04 20:17:42 <Eliel_> gmaxwell: just make sure "bitcoind help" has information on how to use it. I'd expect most people working with bitcoind to read that at some point.
238 2014-05-04 20:25:22 <hearn> gmaxwell: yeah i know. was just observing for Eliel_
239 2014-05-04 20:32:32 <BlueMatt> essentially the issue was how to ship the update checker
240 2014-05-04 20:32:40 <BlueMatt> (its a python program, but you want to ship it for windows as well)
241 2014-05-04 20:33:04 <BlueMatt> so you need to ship a compiled-to-binary python program and any necessary interpreters, etc as well as eg a gpg binary
242 2014-05-04 20:33:15 <BlueMatt> so it gets gross to try to build it deterministically
243 2014-05-04 20:33:42 <BlueMatt> but someone should totally solve this problem
244 2014-05-04 20:33:46 <BlueMatt> its probably only a few weeks of work
245 2014-05-04 20:34:15 <BlueMatt> still, could be easily shipped for linux in a day of work, essentially
246 2014-05-04 20:37:27 <sipa> jgarzik: so how are frequency available to such sattelites allocated?
247 2014-05-04 20:39:47 <hearn> hey BlueMatt
248 2014-05-04 20:39:53 <BlueMatt> hi
249 2014-05-04 20:40:15 <BlueMatt> 
ACTION has two more days of exams, then BITCOIN (and graduation, but mostly BITCOIN)

250 2014-05-04 20:40:40 <sipa> BlueMatt: woohoo!
251 2014-05-04 20:41:07 <hearn> woooot
252 2014-05-04 20:41:23 <hearn> looking forward to having you back
253 2014-05-04 20:41:28 <BlueMatt> indeed
254 2014-05-04 20:43:07 <jgarzik> sipa, depends on $$ and whether or not the project is non-commercial, transmitter power, and other factors
255 2014-05-04 20:43:27 <jgarzik> sipa, part of the design phase (ongoing contract, ends in August) is to scope that out precisely
256 2014-05-04 20:48:05 <hearn> ye gods. chrome finally implementing origin chips about 3 years after i proposed it
257 2014-05-04 20:49:11 <BlueMatt> origin chips?
258 2014-05-04 20:51:26 <hearn> actually make that 4 years
259 2014-05-04 20:51:32 <hearn> no sorry. 5 years ago.
260 2014-05-04 20:51:33 <hearn> https://groups.google.com/forum/#!topic/chromium-dev/ygbwcSE8lZ8
261 2014-05-04 20:51:39 <hearn> http://jakearchibald.com/2014/improving-the-url-bar/
262 2014-05-04 20:51:48 <hearn> basically only show domain name in the URL bar
263 2014-05-04 20:52:05 <BlueMatt> ahh, that stuff
264 2014-05-04 20:52:22 <hearn> i wrote a longer argument for it somewhere. not sure if it was internal or public though
265 2014-05-04 22:17:46 <zone117x> I need to setup a LOCAL testnet. which involves spawning two coin daemons and pointing them at each other
266 2014-05-04 22:17:58 <zone117x> which lets you start at block height 1
267 2014-05-04 22:18:09 <zone117x> which is very useful for th testing I'm doing for my software
268 2014-05-04 22:18:12 <sipa> you probably want regtest :)
269 2014-05-04 22:18:15 <GAit> zone117x: are you sure you don't want to use regtest?
270 2014-05-04 22:18:38 <zone117x> the problem is, bitcoin has a testnet network it automatically tries to connect to
271 2014-05-04 22:18:44 <zone117x> even if I use the "connect" options
272 2014-05-04 22:18:54 <sipa> it shouldn't
273 2014-05-04 22:18:55 <zone117x> for both daemons and point them at each other, it creates 0 connections
274 2014-05-04 22:19:06 <sipa> with -connect, -listen is disabled
275 2014-05-04 22:19:09 <zone117x> using "addnode" to connect to eachother doesnt work because it ends up connecting to the global testnet
276 2014-05-04 22:19:25 <sipa> so you need one to use -connect, and the other -listen
277 2014-05-04 22:19:39 <zone117x> so could some brielfy explain the options I would use with two testnet daemons running local to get them to ONLY connnect to each other?
278 2014-05-04 22:19:45 <sipa> i just told you
279 2014-05-04 22:19:54 <zone117x> kk let me try to parse and apply that - thanks sipa
280 2014-05-04 22:19:57 <sipa> and you still want regtest probably, which is intended for such purposes
281 2014-05-04 22:20:01 <zone117x> where have I seen your nick before?
282 2014-05-04 22:20:05 <sipa> here?
283 2014-05-04 22:20:10 <zone117x> huh maybe
284 2014-05-04 22:20:19 <zone117x> Im developer of NOMP. heard of it yet?
285 2014-05-04 22:20:21 <sipa> no
286 2014-05-04 22:20:32 <zone117x> sipa are you BTC only?
287 2014-05-04 22:20:35 <zone117x> no altcoin
288 2014-05-04 22:20:40 <sipa> yes
289 2014-05-04 22:20:41 <zone117x> or anti-altcoin ?
290 2014-05-04 22:20:49 <sipa> mostly dontcare-about-altcoin
291 2014-05-04 22:20:54 <zone117x> makes sense
292 2014-05-04 22:21:03 <zone117x> I dont think any altcoins so far have long term value
293 2014-05-04 22:21:20 <zone117x> however I've done a ton of work to support the various altcoins in NOMP because thats what people want right now
294 2014-05-04 22:21:28 <zone117x> any donations I get in various coins I convert to btc
295 2014-05-04 22:21:40 <zone117x> https://github.com/zone117x/node-open-mining-portal
296 2014-05-04 22:21:43 <zone117x> this is NOMP
297 2014-05-04 22:21:47 <zone117x> it works well for BTC too
298 2014-05-04 22:21:50 <sipa> k
299 2014-05-04 22:22:11 <zone117x> whats the most popular startum pool server used for btc?
300 2014-05-04 22:22:14 <zone117x> eloipool ?
301 2014-05-04 22:22:23 <sipa> no clue; i don't know anything about mining these days
302 2014-05-04 22:22:27 <zone117x> ah okay
303 2014-05-04 22:22:35 <zone117x> well I have yet to do some solid benchmarking
304 2014-05-04 22:22:56 <zone117x> but I wouldnt be suprised if NOMP was the most efficient/scalable pool server in existence today
305 2014-05-04 22:23:04 <zone117x> eloipool is great - but its limited to python
306 2014-05-04 22:23:21 <zone117x> while NOMP uses node.js which is the child of decades long browser wards :p
307 2014-05-04 22:23:37 <sipa> let's not get into language discussions
308 2014-05-04 22:24:13 <zone117x> agreed, wrong channel. I digressed.
309 2014-05-04 22:24:19 <zone117x> anyway, let me try your suggestions
310 2014-05-04 22:24:26 <zone117x> for this testnet crap
311 2014-05-04 22:24:42 <zone117x> what order do you recommend?
312 2014-05-04 22:24:46 <sipa> -regtest is sort of a testnet that has no actual network, and won't connect out by default
313 2014-05-04 22:24:56 <sipa> it's mostly intended for regression tests against bitcoind
314 2014-05-04 22:25:02 <sipa> but it's fully functional
315 2014-05-04 22:25:20 <zone117x> when was this implemented in btc?
316 2014-05-04 22:25:41 <sipa> (and has a base difficulty of 0.000000000466, so mining against it is trivial)
317 2014-05-04 22:25:44 <sipa> 0.8 or so
318 2014-05-04 22:25:49 <zone117x> also I need my testing to mimick orphaned blocks
319 2014-05-04 22:26:59 <sipa> it was introduced in 0.9, sorry
320 2014-05-04 22:27:25 <hearn> 0.9
321 2014-05-04 22:27:33 <hearn> it might feel like 0.8 because i wrote it back in, like, april :)
322 2014-05-04 22:27:35 <sipa> for testnet: run one with -listen -connect=0.0.0.0, run the other with -connect=IP
323 2014-05-04 22:27:58 <sipa> yeah. 0.8 is ancient history by now
324 2014-05-04 22:28:17 <sipa> 1.25 years ago
325 2014-05-04 22:32:19 <GAit> do you know if some block/transaction sites (bc.i) are having issues displaying p2sh tx in mempool?
326 2014-05-04 22:32:55 <sipa> if in doubt whether b.i is correct: yes
327 2014-05-04 22:34:03 <GAit> yeah, checked against blockr.io, insight.is, few webwallets. but the issue is especially with p2sh transactions
328 2014-05-04 22:34:20 <GAit> and yes only bc.i
329 2014-05-04 22:36:10 <GAit> maybe a stupid question but i'd like to know more about the payment protocol. How do you envision the multioutput to work?Why would a merchant ask to get paid a bit here and a bit there? taxes obligations could be such a case?
330 2014-05-04 22:37:33 <GAit> is there an obvious use case i'm missing?
331 2014-05-04 22:40:40 <sipa> if as a sender if you have some coins you'd rather not see linked
332 2014-05-04 22:40:47 <sipa> it may be useful to send them separately
333 2014-05-04 22:41:26 <hearn> GAit: https://medium.com/bitcoin-banter/7f95a386692f
334 2014-05-04 22:41:42 <hearn> that article explains it
335 2014-05-04 22:42:24 <hearn> GAit: btw i also wrote one today on BIP70 and stealth addresses. feedback welcome. i didn’t publicise it much yet: https://medium.com/p/cb2f81962c1b
336 2014-05-04 22:43:38 <GAit> hearn: interesting. I like it. A bit complicated for users to configure but good defaults could split incoming funds in various denominations as best as it matches your spending habits
337 2014-05-04 22:43:49 <hearn> the idea is wallets do it all automatically
338 2014-05-04 22:44:00 <GAit> yeah and can learn to do it better
339 2014-05-04 22:44:10 <hearn> right. i forsee/hope that wallets compete on this aspect
340 2014-05-04 22:44:22 <hearn> though to some extent you’re at the mercy of the wallet *sending* you money.
341 2014-05-04 22:44:32 <hearn> currently no wallets do merge avoidance
342 2014-05-04 22:44:33 <GAit> thanks for the pointer!
343 2014-05-04 22:45:24 <GAit> sipa: as a sender yes but then you would need a way to negotiate wit the other side how many in each address
344 2014-05-04 22:46:53 <hearn> GAit: that’s the idea of bip70 - the receiver asks for a spread of denominations as it wishes, and the sender then tries to satisfy that with minimal merging
345 2014-05-04 22:46:58 <hearn> so they work together to preserve privacy
346 2014-05-04 22:47:57 <GAit> yeah i agree to that but the sender of money can't decide to how many addresses he is going to pay or how much per each address
347 2014-05-04 22:49:11 <GAit> the cooperation about non correlation can just be best effort
348 2014-05-04 22:49:41 <hearn> that’s the idea
349 2014-05-04 22:49:47 <GAit> you are not guaranteed you won't receive funds on these two or n addresses from one input
350 2014-05-04 22:49:58 <hearn> i designed this aspect of BIP 70 so it could be developed and rolled out incrementally
351 2014-05-04 22:50:27 <GAit> ok. i was just windering, the sender has a better idea of how many addresses the funds will come from, so it is in a better capacity to offer or suggest the amount of addresses
352 2014-05-04 22:50:35 <GAit> s/windering/wondering
353 2014-05-04 22:55:35 <hearn> GAit: in v1.0 of the payment protocol you cannot ask the sender to spread value over outputs as it sees fit, but that might be a nice enhancement for future. however the recipient knows what kind of sizes of coins it wants, so i’m also not totally sure it’d be useful
354 2014-05-04 23:36:36 <tyrick> How common are Orphan blocks?