1 2014-06-30 00:03:12 <UbuntuBoooost> hi
2 2014-06-30 00:03:50 <UbuntuBoooost> mates, i would like to know if the nodes that i cant connect make impossible to mine the coin ? or not ?
3 2014-06-30 00:07:17 <sipa> which nodes can't you connect to?
4 2014-06-30 00:07:46 <sipa> you can't mine (at least if you're building the blocks yourself and not using a centralized pool) without being connected to at least some other nodes
5 2014-06-30 00:11:12 <UbuntuBoooost> sipa ok
6 2014-06-30 00:11:20 <UbuntuBoooost> I create my own genesis
7 2014-06-30 00:11:32 <UbuntuBoooost> But I can't get ''how do i start mine it''
8 2014-06-30 00:11:44 <UbuntuBoooost> and yes i dotn want mine by a pool.
9 2014-06-30 00:11:55 <UbuntuBoooost> I want to ''build blocks'' solo
10 2014-06-30 00:17:51 <UbuntuBoooost> sipa this looks like whats is happening to me http://bitcoin.stackexchange.com/questions/21541/before-mining-genesis-block
11 2014-06-30 00:18:13 <UbuntuBoooost> it can't start anyhting cause is getting connection refused from many bitcoin nodes ip's
12 2014-06-30 00:18:40 <UbuntuBoooost> I can take it out of the file that got it ? andrun a daemon without any nodes ips ?
13 2014-06-30 00:18:45 <sipa> you're creating your own genesis block, but are connecting to bitcoin?
14 2014-06-30 00:20:30 <gwillen> UbuntuBoooost: this channel is for discussion of bitcoin client development; it's not an appropriate place for getting help starting an altcoin
15 2014-06-30 00:20:45 <gwillen> I defer to sipa, who is a bitcoin dev, if he wants to help you, but this is not the right place to be asking
16 2014-06-30 00:21:13 <gwillen> there is a lightly-populated ##altcoin-dev which may be of use
17 2014-06-30 00:22:26 <SomeoneWeird> That is offtopic here.
18 2014-06-30 00:26:49 <skinnkavaj> Off topic but I get really excited when I read this http://www.coindesk.com/hive-web-wallet-bitcoin-adoption-roadblocks/
19 2014-06-30 00:30:21 <UbuntuBoooost> ok sorry all.
20 2014-06-30 00:35:17 <netg_> /
21 2014-06-30 00:50:34 <Ademan> Anyone know what https://github.com/richardkiss 's irc nick is? is it just richardkiss ?
22 2014-06-30 01:00:35 <sipa> why do you assume he's on irc?
23 2014-06-30 01:01:06 <sipa> sorry, that sounds worse than i intended it; but do you know that he is on irc?
24 2014-06-30 01:02:43 <Ademan> sipa: I had some vague recollection of discussing pycoin with him here, but I might be remembering discussing python-bitcoinlib with peter todd instead
25 2014-06-30 01:03:17 <Ademan> and besides who the heck isn't on irc? /s
26 2014-06-30 01:25:05 <dhill> anyone know how close mainnet has come to end-of-days? ( the 2 hour mark of not being mined)
27 2014-06-30 01:29:50 <dsnrk> dhill: you're talking about the upper end of the distribution of block times? the number I've been told is 1 hour 40 minutes for that, though I don't know what height it was at.
28 2014-06-30 01:31:01 <jcorgan> ;;tblb 6000
29 2014-06-30 01:31:02 <gribble> The expected time between blocks taking 1 hour, 40 minutes, and 0 seconds to generate is 33 weeks, 4 days, 11 hours, 4 minutes, and 53 seconds
30 2014-06-30 01:32:07 <dsnrk> 2
31 2014-06-30 01:32:57 <dhill> if a couple of the big miners went offline for day, that 2 hour mark could be hit.
32 2014-06-30 01:33:08 <gmaxwell> dhill: why are you calling this "end of days"?
33 2014-06-30 01:34:33 <gmaxwell> dhill: it should happen by chance even at constant hashrate on average once per 5 or 6 years in any case.
34 2014-06-30 01:34:39 <dsnrk> I do wonder if large miners have contingency plans for their internet links. you'd think some of the bigger farms would be at risk of being islanded if there were some more ship-anchor type situations.
35 2014-06-30 01:35:23 <gmaxwell> dsnrk: I have a backup link. (at one point I had three links in total, on diverse providers)
36 2014-06-30 01:35:57 <gmaxwell> (now I have 2.5â if I'm disconnected I can bring up my miners via cellphone teather, which I've actually done once, when I only had one link at this location)
37 2014-06-30 01:36:10 <dsnrk> ACTION nods
38 2014-06-30 01:36:22 <gmaxwell> though I am no longer a non-trivial chunk of the network hashrate. :P
39 2014-06-30 01:37:30 <dsnrk> the worst place to put your miners would be Svalbard, in terms of internet connections. looks like there's only one cable linking them to the wider interwebs. easy to cool your miners there though.
40 2014-06-30 01:38:03 <jcorgan> i might be going to Svalbard
41 2014-06-30 01:39:02 <dsnrk> jcorgan: according to wikipedia you'll probably be a tourist, researcher or coal miner?
42 2014-06-30 01:39:03 <gmaxwell> dsnrk: sat links are a perfectly reasonable way to mine for a large farm, though I would bet none of those folks have one setup. The latency is high, so it wouldn't be a first choice, but it's not high enough to increase your orphan rate by more than a percent or so... and the bandwidth is pricy if you use it, but it doesn't take much to justify it.
43 2014-06-30 01:39:22 <jcorgan> working with a research group
44 2014-06-30 01:40:35 <dsnrk> gmaxwell: I guess bandwidth is actually pretty low if you're trying to just limp along. even if you wanted to make work locally with bitcoind all you really need is the block headers from a trusted peer.
45 2014-06-30 01:41:57 <dsnrk> or a local stratum proxy I suppose.
46 2014-06-30 01:45:29 <dhill> i was just thinking if a mainnet block was mined in 2hours 1minute, no one would accept it?
47 2014-06-30 01:45:37 <gmaxwell> That incorrect.
48 2014-06-30 01:45:44 <dhill> ok
49 2014-06-30 01:46:05 <gmaxwell> The time on a block is constrained relative to your local (potentially corrected) clock.
50 2014-06-30 01:47:59 <gmaxwell> (The time must be within 2 hours in the future from your current idea of 'now', or indeed the network would spontaniously fail, obviously even getting close to that limit is not a great idea for a block's survival)
51 2014-06-30 01:49:03 <dsnrk> and the timestamp in the block is updated fairly often, it's not as if the work given when the previous block was found is the same as the work used to solve it 2 hours later.
52 2014-06-30 01:50:14 <gmaxwell> it would be fine if it were, however.
53 2014-06-30 01:50:28 <gmaxwell> (I mean, not so polite to the network, but wouldn't break anything)
54 2014-06-30 11:08:07 <cryptodon> Hi there! I am trying to install bitcoind in OSX Mavericks and it fails with: "Undefined symbols for architecture x86_64: boost::filesystem::detail::copy_file" does anyone else have encountered this issue? I have read this https://github.com/bitcoin/bitcoin/issues/3444 but nothing worked so far :/
55 2014-06-30 11:08:38 <cryptodon> Has anyone any suggestions? I would much appreciate :)
56 2014-06-30 11:10:20 <hearn> are you using brew or macports
57 2014-06-30 11:12:03 <cryptodon> Basically I compiled boost from source using the -std=c++11 -stdlib=libstdc++ flags
58 2014-06-30 11:12:25 <cryptodon> I didn't used neither brew or macports
59 2014-06-30 11:13:16 <cryptodon> do I have to include those flags also to CFLAGS when I compile bitcoind?
60 2014-06-30 11:14:14 <cryptodon> I just included those flags and didn'r worked again :/
61 2014-06-30 11:14:33 <cryptodon> fails with the same error..
62 2014-06-30 11:14:34 <hearn> ok, i don't know then, but it usually indicates a compiler/c++ stdlib mismatch
63 2014-06-30 11:15:47 <cryptodon> Strange thing is that I installed litecoind with success using the same boost :/
64 2014-06-30 11:16:06 <cryptodon> anyways I will keep digging
65 2014-06-30 11:16:37 <cryptodon> thanks hearn :)
66 2014-06-30 11:45:09 <kiddouk> good afternoon.
67 2014-06-30 11:48:00 <hearn> hi
68 2014-06-30 13:24:31 <drizztbsd> hi, why bitcoin-0.9.2.1-linux.tar.gz includes bitcoin-0.9.2.1-linux/src/bitcoin-0.9.2.tar.gz and not bitcoin-0.9.2.1.tar.gz?
69 2014-06-30 13:24:39 <drizztbsd> is still the correct source code?
70 2014-06-30 13:24:50 <drizztbsd> or should you release another tar?
71 2014-06-30 13:27:51 <anton000> of there's new release?
72 2014-06-30 13:34:15 <QRCODEdoubts> Hi all :)
73 2014-06-30 13:34:30 <QRCODEdoubts> I would like to know if the Qr codes are implemented on -qt ..
74 2014-06-30 13:34:46 <QRCODEdoubts> If not, where can I get some tut. to read about it ?
75 2014-06-30 13:34:53 <QRCODEdoubts> And it's implementation ?
76 2014-06-30 13:35:02 <QRCODEdoubts> Thanks for yout ime & patience..
77 2014-06-30 13:41:26 <wumpus> drizztbsd: it's the correct source code, but the naming of files in some places doesn't take the build # into account
78 2014-06-30 13:49:17 <gavinandresen> wumpus: want me to push #define COLOR_HASCONFLICTING QColor(Qt::white); change to fix Qt5 builds?
79 2014-06-30 13:49:29 <wumpus> gavinandresen: I already pushed a fix :)
80 2014-06-30 13:49:36 <gavinandresen> wumpus: cool
81 2014-06-30 13:54:12 <hearn> thanks for fixing the unknown message print correctly
82 2014-06-30 14:11:49 <hearn> is there a quick workaround for the automake breakage? INCLUDES is the old name for ....
83 2014-06-30 14:11:52 <hearn> i tried distclean and got an error
84 2014-06-30 14:12:20 <wumpus> the INCLUDES is... is an harmless message, it's been there for ages
85 2014-06-30 14:12:22 <hearn> error: required file 'src/config/bitcoin-config.h.in' not found
86 2014-06-30 14:12:22 <hearn> oh wait no, sorry, the actual error is
87 2014-06-30 14:12:34 <gavinandresen> hearn: re-run autogen.sh I think
88 2014-06-30 14:12:45 <hearn> thanks, will try
89 2014-06-30 14:12:58 <hearn> yeah seems to be happily building now
90 2014-06-30 14:13:12 <gavinandresen> I asked exactly the same question a couple days agoâ¦.
91 2014-06-30 14:13:23 <gavinandresen> ACTION yearns for the simple days of Makefile yore....
92 2014-06-30 14:14:51 <wumpus> hah, I think you only remember the positive experiences
93 2014-06-30 14:16:35 <hearn> ACTION yearns for the old google build system
94 2014-06-30 14:16:37 <wumpus> and not the annoying ones like having to keep three/four makefiles in sync when a build system change is needed
95 2014-06-30 14:16:52 <hearn> yes, it may have involved a 400mb permanently resident daemon, but it *never* broke. damn that thing was a tank. fast, too.
96 2014-06-30 14:17:27 <hearn> the FATF paper on bitcoin is remarkably intelligent and well researched
97 2014-06-30 14:17:44 <wumpus> 400mb is nothing for google right :)
98 2014-06-30 14:18:14 <hearn> well that ran on your desktop. so it definitely wasn't nothing :) everyone loved to whinge about that
99 2014-06-30 14:18:28 <gavinandresen> hearn: FATF? Find A True Fork?
100 2014-06-30 14:18:29 <hearn> that 400mb got you a frontend to a compile cluster of 5000 machines though, so nobody complained _too_ much :)
101 2014-06-30 14:18:47 <hearn> gavinandresen: financial action task force, the international AML regulators organisation. it uses the term "proof of stake" on the second page
102 2014-06-30 14:18:48 <hearn> http://www.fatf-gafi.org/media/fatf/documents/reports/Virtual-currency-key-definitions-and-potential-aml-cft-risks.pdf
103 2014-06-30 14:18:59 <hearn> it also defines terms like Tor and .... <gulp> Dark Wallet
104 2014-06-30 14:19:26 <hearn> but i'm glad to see they're finally sorting out the "virtual currency" lingo problem. that confusion wasn't helping anyone
105 2014-06-30 14:24:33 <hearn> not a bad paper. optimistic. measured. this is good news.
106 2014-06-30 14:24:43 <hearn> also, very well researched
107 2014-06-30 14:25:20 <gavinandresen> like accounts, at a Bitcoin exchanger or online wallet service."
108 2014-06-30 14:25:20 <gavinandresen> yes, pretty good. Not perfect: "Users can also obtain Bitcoin addresses, which function
109 2014-06-30 14:25:39 <hearn> right. though later they do note the existence of apps like multibit and bitcoin wallet
110 2014-06-30 14:25:45 <hearn> the broad strokes are correct
111 2014-06-30 14:26:11 <hearn> they don't seem to fully grok the distinction between hosted wallets and SPV wallets yet, but that's fine, the distinction is kinda subtle if you aren't interested in the technology
112 2014-06-30 14:28:20 <wumpus> seems they are at least starting to take it serious, and thus doing more serious research
113 2014-06-30 14:30:18 <cbeams> Still working my way through it, but agree it's quite reasonable thus far. Not sure about the equivalence they establish between "fiat currency" and "real currency". When read out of the context of this doc, "real currency" can easily read like the opposite of "fake currency".
114 2014-06-30 14:32:30 <hearn> ACTION shrugs
115 2014-06-30 14:32:39 <hearn> lots of people use those terms, i bet that's especially common in government circles
116 2014-06-30 14:32:51 <hearn> they pick a term, define it and stick with it. conveniently, it's also the term we use.
117 2014-06-30 14:33:45 <wumpus> yes, terms like real, virtual, fake are subjective and even imply a kind of value judgement which makes their use in official documents difficult
118 2014-06-30 14:38:10 <Luke-Jr> nonsense, "real" simply means you can use real numbers with it!
119 2014-06-30 14:38:12 <Luke-Jr> :D
120 2014-06-30 15:06:12 <wumpus> hehe
121 2014-06-30 15:13:35 <hearn> virtonal currency :)
122 2014-06-30 15:15:39 <cdecker> Can't wait until somebody invents imaginary currencies :-)
123 2014-06-30 15:23:34 <jgarzik> gah
124 2014-06-30 15:24:45 <jgarzik> Does 'list transactions" (via OrderedTxItems) really load and sort the entire wallet's worth of transactions... then filter? Yuck.
125 2014-06-30 15:24:56 <maaku> yup
126 2014-06-30 15:25:15 <sipa> _every_ wallet operation goes through the entire tx list, almost :)
127 2014-06-30 15:25:51 <jgarzik> "we need the last 10 transactions... load and sort 1,000,000!" :)
128 2014-06-30 15:30:05 <Luke-Jr> lol
129 2014-06-30 15:30:26 <Luke-Jr> jgarzik: keep in mind that code was written BEFORE I added the defined sort order inde
130 2014-06-30 15:30:31 <Luke-Jr> index
131 2014-06-30 15:31:43 <hearn> wallets need to be databases, really
132 2014-06-30 15:31:46 <hearn> (relational ones)
133 2014-06-30 15:33:47 <drizztbsd> sqlite? :P
134 2014-06-30 15:39:06 <wumpus> jgarzik: heh, that's only one of the many wtfs in bitcoind's wallet implementation
135 2014-06-30 15:39:54 <hearn> drizztbsd: yeah i was looking at that for bitcoinj one day
136 2014-06-30 15:40:01 <hearn> or rather, an abstraction over sql databases
137 2014-06-30 15:40:06 <hearn> with sqlite being the default
138 2014-06-30 15:40:52 <hearn> probably jpa based. not sure. bigger problems to solve
139 2014-06-30 15:41:03 <jcorgan> one nice thing about using sqlite, is that is is easy to substitute sqlcipher, which provides on-the-fly encryption/decryption of the database such that only ciphertext ever hits the disk
140 2014-06-30 15:41:06 <wumpus> it's a reference implementation of a wallet, don't expect it to scale or something
141 2014-06-30 15:42:39 <hearn> as far as i know there aren't any scalable open source wallets, currently. maybe blockchain.info
142 2014-06-30 15:42:57 <hearn> none that are "just" a p2p wlalet though
143 2014-06-30 15:46:30 <wumpus> AFAIK that is the goal of coinvault
144 2014-06-30 15:48:18 <Luke-Jr> hearn: the current plan was to move AWAY from db for the wallet ;)
145 2014-06-30 15:48:29 <Luke-Jr> hearn: sipa was going to do a nice append-only-log format
146 2014-06-30 15:50:15 <wumpus> but there are zillions of things concerning the core infrastructure that need to be done first
147 2014-06-30 15:51:42 <hearn> indeed
148 2014-06-30 15:57:28 <wumpus> bitcoind's wallet should really be regarded like the internal miner, as an example and for purposes of testing functionality like the floating fee mechanism
149 2014-06-30 15:59:45 <AndersAA> wumpus: How do we make this clear to users? I still see newbies trying to mine with bitcoind without a clue why it doesn't work.
150 2014-06-30 16:00:13 <wumpus> AndersAA: it does work
151 2014-06-30 16:00:29 <AndersAA> wumpus: (As they expect it to)
152 2014-06-30 16:01:00 <wumpus> but that's hardly the internal miner's fault, I mean even with an external CPU or GPU miner you won't make a dent in the main network
153 2014-06-30 16:01:39 <hearn> AndersAA: the "Generate coins" menu item was removed a long time ago
154 2014-06-30 16:02:19 <sipa> a loooooong time ago
155 2014-06-30 16:02:28 <AndersAA> hearn: In QT. People still "try" with core config and such.
156 2014-06-30 16:03:12 <hearn> not much we can do about that
157 2014-06-30 16:03:14 <wumpus> they're clueful enough to set up a configuration file, but too clueless to realize that the time of mining without custom hardware is long gone? I doubt that's a very large intersection of the user base
158 2014-06-30 16:03:23 <hearn> i mean, there's stuff we can do. we can make a section of bitcoin.org for miners
159 2014-06-30 16:03:49 <wumpus> and well, it doesn't even hurt, at most you'll waste a few days of CPU time ...
160 2014-06-30 16:04:02 <AndersAA> I just mean - shouldn't it be in the readme that mining og wallet are best regarded as examples rather than practical uses for new users?
161 2014-06-30 16:04:15 <Luke-Jr> sipa: FYI, there is apparently already another project using libsecp256k1
162 2014-06-30 16:04:19 <wumpus> it's not like Bad THings Happen That Users Need To Be Warned Of, which we have many of too
163 2014-06-30 16:05:03 <sipa> Luke-Jr: i see people forking it...
164 2014-06-30 16:05:09 <sipa> well, there's a disclaimer
165 2014-06-30 16:05:22 <Luke-Jr> I just noticed it was added to the bitcoin overlay to satisfy a dependency :P
166 2014-06-30 16:05:23 <wumpus> hah, other projects are using it before bitcoind
167 2014-06-30 16:05:29 <wumpus> I really want to merge that pull...
168 2014-06-30 16:05:44 <wumpus> AndersAA: sure, adding it to the readme would be OK
169 2014-06-30 16:09:08 <hearn> i don't think we want to stop suggesting the wallet is useful just yet
170 2014-06-30 16:09:08 <hearn> otherwise people will say ....... ok. what wallet should i use?
171 2014-06-30 16:09:55 <phillipsjk> ACTION was disappointed when the generate coins menu item was removed
172 2014-06-30 16:10:17 <wumpus> hearn: multibit?
173 2014-06-30 16:10:35 <AndersAA> hearn: Well, https://bitcoin.org/en/choose-your-wallet has lots of suggestions.
174 2014-06-30 16:10:43 <hearn> doesn't support JSON-RPC and ..... please no. i have enough users for now :)
175 2014-06-30 16:10:49 <hearn> but mostly i'm thinking of API users
176 2014-06-30 16:10:53 <phillipsjk> multibit is apparently intended to be a simplified wallet.
177 2014-06-30 16:11:16 <hearn> multibit has not been updated in a long time. they're rewriting it from scratch and unfortunately ran out of funds, so need to do some side work for a while
178 2014-06-30 16:11:16 <wumpus> right, there are lots of GUI wallets these days, but a lack of API wallets
179 2014-06-30 16:11:34 <phillipsjk> Can't import keys, becuase that causes confusion.
180 2014-06-30 16:11:51 <hearn> well, lack of wallets compatible with the Core API
181 2014-06-30 16:12:01 <hearn> phillipsjk: worse it causes people to lose money
182 2014-06-30 16:12:06 <hearn> (or has done in the past)
183 2014-06-30 16:12:49 <phillipsjk> Which means I am forced to use the more risky sx tools :P
184 2014-06-30 16:13:28 <hearn> sx is a command line tool. very different use cases
185 2014-06-30 16:15:11 <phillipsjk> My main concern is that I can't store the block-chain on my signing/day-to-day machine. And I don't have 4+GB of memory for armory.
186 2014-06-30 16:16:02 <phillipsjk> I also don't want to trust my bitcoin node with my private keys.
187 2014-06-30 16:16:48 <phillipsjk> ACTION has a bad habit of doing things just weirdly enough to break things
188 2014-06-30 16:17:01 <hearn> bitcoinj has a command line tool that is a bit like sx
189 2014-06-30 16:17:10 <hearn> though i mostly use it for testing so the command line usability could use a bit of polishing
190 2014-06-30 16:17:22 <hearn> then you can have a command line driven SPV wallets
191 2014-06-30 16:17:35 <wumpus> electrum has a command-line interface as well these days
192 2014-06-30 16:18:19 <phillipsjk> Still can't import keys I assume. With sx if import keys with "cat > keyname.key"
193 2014-06-30 16:18:25 <hearn> yes, wallet-tool lets you import keys
194 2014-06-30 16:18:33 <Luke-Jr> why can't pulltester be like this? https://github.com/conformal/btcd/pull/143
195 2014-06-30 16:18:36 <hearn> the lack of key import in multibit is a UI/support tradeoff, not a limitation of the underlying library
196 2014-06-30 16:18:41 <Luke-Jr> (see " All is well â The Travis CI build passed · Details")
197 2014-06-30 16:18:41 <wumpus> why do you like importing keys so much?
198 2014-06-30 16:18:50 <wumpus> Luke-Jr: cfields is working on that
199 2014-06-30 16:18:56 <Luke-Jr> wumpus: ah, awesome
200 2014-06-30 16:19:17 <hearn> huh. does this mean they want people to start mining on top of btcd?
201 2014-06-30 16:19:20 <phillipsjk> wumpus, my keys are off-line until just before spending.
202 2014-06-30 16:19:32 <AndersAA> wumpus: I'll make a PR for a Usage section of README.md tomorrow or wednesday. Hopefully it'll make sense to people.
203 2014-06-30 16:19:41 <wumpus> AndersAA: cool
204 2014-06-30 16:20:01 <Luke-Jr> hearn: we'll probably deploy it to Eligius sometime not too far in the future.
205 2014-06-30 16:20:13 <hearn> what happens if they disagree?
206 2014-06-30 16:20:24 <Luke-Jr> hearn: then we just mine bitcoind's template instead
207 2014-06-30 16:20:42 <phillipsjk> hearn I may try it with merging my mining income to one output.
208 2014-06-30 16:20:46 <Luke-Jr> hearn: (and send them a bug report0
209 2014-06-30 16:20:52 <wizkid057> but we'd know they disagreed, and be able to provide that feedback
210 2014-06-30 16:21:17 <hearn> so you'd still mine on top of the block Core creates, or you'd just be watching the parent block hash for a fork?
211 2014-06-30 16:21:29 <hearn> or you'd intersect the transactions they select or .... ?
212 2014-06-30 16:21:36 <wumpus> hearn: I don't really see the point either
213 2014-06-30 16:22:16 <hearn> i understand the desire to find incompatibilities. but it seems if actual hash power is directed on top of a different implementations blocks, detecting that this block is not acceptable to Core would require a pile of extra code and complexity
214 2014-06-30 16:22:17 <Luke-Jr> hearn: stage 1 will be simply passing all templates we get from bitcoind to btcd.
215 2014-06-30 16:22:33 <Luke-Jr> hearn: stage 2 will be getting templates from btcd first, and testing them against bitcoind.
216 2014-06-30 16:22:40 <Luke-Jr> stage 3 will be â?
217 2014-06-30 16:23:05 <Luke-Jr> hearn: code that's been implemented for years.
218 2014-06-30 16:23:37 <hearn> ok
219 2014-06-30 16:28:22 <hearn> seems like btcd does indeed advertise support for bloom filtering without actually implementing it. sigh.
220 2014-06-30 16:28:41 <hearn> it's a minor thing, but still
221 2014-06-30 16:30:02 <davec_> hearn: aye. There was no NODE_BLOOM flag to indidicate otherwise and IIRC nodes all stopped talking to pver < 70001 :\ However, bloom filters are about 90% done and will be added next
222 2014-06-30 16:30:18 <hearn> great
223 2014-06-30 16:31:06 <hearn> when did we stop accepting peers < 70001? i must have forgotten about that
224 2014-06-30 16:33:22 <wumpus> huh?
225 2014-06-30 16:33:49 <Luke-Jr> in other news, BFGMiner 4.3 with bitcoind solo mining auto-configured is now in the wild..
226 2014-06-30 16:34:07 <wumpus> MIN_PEER_PROTO_VERSION is 209
227 2014-06-30 16:34:12 <wumpus> in master
228 2014-06-30 16:34:15 <hearn> Luke-Jr: nice! how does that work? is it bundled, or it knows how to auto-discover a local node?
229 2014-06-30 16:34:35 <Luke-Jr> hearn: it finds bitcoin.conf and adds it as a pool
230 2014-06-30 16:34:59 <hearn> great. one more brick in the wall
231 2014-06-30 16:35:21 <Luke-Jr> it also uses it for local block submission for other GBT pools too
232 2014-06-30 16:36:47 <hearn> how do you mean? when mining with a remote GBT-supporting pool, it's actually creating blocks itself? i thought the code didn't support that
233 2014-06-30 16:38:38 <Luke-Jr> hearn: when it finds a block, it submits it to local bitcoind in addition to the pool
234 2014-06-30 16:39:00 <Luke-Jr> what isn't supported yet is combining the transactions from the local bitcoind with the generation from the pool
235 2014-06-30 16:39:18 <davec_> hmmm I'll have to dig through history. I recall at one point right around the 70001 protocol version, there was an alert that was disconnecting us for being < 70001
236 2014-06-30 16:39:43 <hearn> bitcoinj will disconnect from nodes lower than that version, for sure
237 2014-06-30 16:39:46 <hearn> but i didn't think bitcoind did
238 2014-06-30 16:40:03 <hearn> Luke-Jr: hmm, OK, how does that help? just to boost propagation speed?
239 2014-06-30 16:41:03 <Luke-Jr> hearn: right
240 2014-06-30 16:41:08 <Luke-Jr> hearn: also prevents selfish mining
241 2014-06-30 16:42:17 <hearn> ah ha. makes sense. thanks for the explanations once again
242 2014-06-30 16:49:12 <dhill> even when btcd has bloom filtering support, btcd will still disconnect peers that send unsolicited tx messages. not sure on davec_'s thoughts on that yet.
243 2014-06-30 16:54:37 <hearn> right. i think we discussed that before
244 2014-06-30 16:55:07 <wumpus> davec_: where do you have the information from that nodes <70001 are disconnected?
245 2014-06-30 16:55:44 <wumpus> I can't find it in the code, so if that is the case it is a bug
246 2014-06-30 17:00:04 <davec_> wumpus: I just looked through the code and I don't see it doing it either. There was one point where we were getting an alert p2p message back from a non-release version of bitcoind (in between 0.8.6 and 0.9.0 I believe, but I could be wrong on the versions given how long ago it was)
247 2014-06-30 17:00:32 <davec_> the alert said something to the effect of upgrade to 70001 and then disconnected
248 2014-06-30 17:01:10 <hearn> there have been such alerts in the past, but not that should result in disconnection
249 2014-06-30 17:01:48 <hearn> davec_: can you stop disconnecting peers that send unannounced txns?
250 2014-06-30 17:01:59 <davec_> given this info though, I'll definitely lower the pver until bloom filters go in
251 2014-06-30 17:02:31 <hearn> great, thanks
252 2014-06-30 17:21:32 <phillipsjk> I had transactions from sx tools (advertising version 60000 not got trough).
253 2014-06-30 17:23:59 <phillipsjk> Don't see any "upgrade to a newer version" message.
254 2014-06-30 17:41:50 <phillipsjk> <dhill> even when btcd has bloom filtering support, btcd will still disconnect peers that send unsolicited tx messages. <=== is this by design/ a new change? (can't find it in the 0.9.0 release notes)
255 2014-06-30 17:42:44 <jrick> btcd, not bitcoind
256 2014-06-30 17:43:06 <phillipsjk> oh, not an abbreviation then?
257 2014-06-30 17:43:17 <jrick> alt full node
258 2014-06-30 17:43:19 <hearn> no, it's a different project
259 2014-06-30 17:43:31 <ronkrt> wow, i love the world we live in, NOT
260 2014-06-30 17:44:43 <davec_> hearn: overlooked your question on the disconnect. Yeah, part of the bloom filter branches is to modify that behavior to work with BIP0037
261 2014-06-30 17:44:52 <hearn> great, thanks
262 2014-06-30 17:46:13 <davec_> I'll have to see if it's possible to know in advance what to expect so we don't have to completely let just anything through, but I haven't looked closely enough at that part yet. Either way, I'm definitely aware it doesn't work currently according to the BIP
263 2014-06-30 17:49:14 <davec_> I had made a comment on the bitcoind issue in regards to this on why we prefer only receiving requested txns: https://github.com/bitcoin/bitcoin/issues/4338#issuecomment-46442557
264 2014-06-30 18:18:50 <hearn> davec_: i think your proposal risks a race condition. let's say an SPV client picks 5 random peers and writes a new tx out to each one in turn. it knows this is the right thing to do because the tx is fresh, and there's no privacy enhancement for SPV clients to do an inv first. now let's say the app is timesliced off the CPU after writing to two peers with three still to go
265 2014-06-30 18:19:22 <hearn> davec_: meanwhile, it turns out that of the 5 peers selected, the 1st and 5th are connected to each other. so the 1st gets the tx, and announces it to your node with an inv, so you getdata it
266 2014-06-30 18:19:40 <hearn> davec_: now the app is woken up and continues on, writing the tx to the 5th, triggering a pointless DoS ban
267 2014-06-30 18:20:17 <hearn> davec_: hence, I agree with gavin that it's probably not a DoS attack worth worrying about and besides, the right way to solve DoS attacks is to prioritise resources rather than banning peers. in the long run we want to go in that direction for Core and I guess it makes sense for btcd too
268 2014-06-30 18:22:59 <jgarzik> hearn, agree... though it does become a kernel-within-a-kernel problem.
269 2014-06-30 18:23:06 <hearn> yep
270 2014-06-30 18:23:49 <hearn> i hope we can find ways to leverage what the kernel provides to help, probably through smart use of threading. but ultimately it'll always be tough
271 2014-06-30 18:23:57 <hearn> we'll need an in-process equivalent of the OOM killer
272 2014-06-30 18:24:58 <hearn> Tor has done all this by the way
273 2014-06-30 18:25:05 <hearn> we can probably learn by looking at how they implemented it
274 2014-06-30 18:25:43 <jgarzik> Tor doesn't have to worry about scheduling disk or CPU bandwidth
275 2014-06-30 18:25:58 <jgarzik> accounting gets easier, as # of factors reduced
276 2014-06-30 18:25:59 <hearn> I think they do some CPU scheduling actually because setting up a circuit involves a lot of expensive crypto
277 2014-06-30 18:26:06 <hearn> probably not disk
278 2014-06-30 18:52:04 <hearn> http://cacr.uwaterloo.ca/techreports/2010/cacr2010-06.pdf
279 2014-06-30 18:52:04 <hearn> oh, interesting, there's even a paper on it
280 2014-06-30 18:52:30 <hearn> that's bandwidth scheduling though
281 2014-06-30 18:53:03 <davec_> hearn: I agree that DoS isn't the bigger concern and on the DoS front prioritizing transactions makes more sense. I think of this particular case more in terms of a network efficiency optimization.
282 2014-06-30 18:53:05 <jgarzik> yah, bandwidth scheduling is well known. setting up a Tor node involves setting a b/w limit, and various algorithms trickle down from that.
283 2014-06-30 18:53:06 <davec_> hearn: I also agree if they're all sending unsolicited txns you could hit the condition you described.
284 2014-06-30 18:53:10 <davec_> hearn: However, I don't think they would have any issues if they are sent invs instead and responded to getdata requests for the tx.
285 2014-06-30 18:53:13 <davec_> hearn: Let's take those same 5 SPV clients and have them send an inv to their connected peers saying "hey a fresh tx just showed up". Now a receiving peer, call it "peer A", receives invs from its various connected
286 2014-06-30 18:53:17 <davec_> clients.
287 2014-06-30 18:53:19 <davec_> hearn: Perhaps 1 and 5 are the those same SPV clients in your example however it shouldn't matter. So, "peer A" notices it doesn't have the tx. Rather than requesting it from everybody that sent it an inv, it selects only one of them and issues a getdata
288 2014-06-30 18:53:23 <davec_> to it while noting the other clients that know about this transaction in case the in-flight request fails.
289 2014-06-30 18:53:27 <davec_> hearn: Once "peer A" successfully receives the tx, it cleans up the list thereby ignoring the other invs. The tx was only transmitted between "peer A" and all its connected nodes once as opposed to X times and nobody is banned.
290 2014-06-30 18:53:31 <davec_> hearn: When all peers are doing the same thing, it cuts down on the number of transactions that actually have to be sent in favor of smaller inv messages.
291 2014-06-30 18:53:32 <jgarzik> davec_, holistically, network is our biggest weakness (== cheapest attack for maximum bitcoin disruption)
292 2014-06-30 18:53:37 <jgarzik> ROI
293 2014-06-30 18:54:15 <hearn> davec_: yeah, sure, though in the common case of no real disruption each peer will receive their copy of the tx ~almost simultaneously. additionally, SPV consumer wallets are optimised for latency and performance quite heavily
294 2014-06-30 18:54:21 <hearn> or at least as heavily as i can make them :)
295 2014-06-30 18:54:32 <hearn> so avoiding an initial roundtrip can be a win, especially on older 3G networks
296 2014-06-30 18:54:46 <hearn> also even if we made this change now, it'd take months for all the old clients to upgrade
297 2014-06-30 18:54:49 <hearn> so it'd take a long time to roll out
298 2014-06-30 18:55:24 <hearn> davec_: and sure i understand why we use invs normally, just to clarify
299 2014-06-30 18:55:54 <hearn> davec_: it's definitely a big bandwidth win in the relay case. however when you know you're the start of the relay, it's both a latency and bandwidth loss assuming the tx goes out to peers close enough in time that the race i described doesn't happen
300 2014-06-30 18:56:00 <hearn> (which i suspect is the majority of the time
301 2014-06-30 18:56:01 <hearn> )
302 2014-06-30 19:09:21 <davec_> hearn: fair point. I do wonder though if that still holds when the transaction rates get so high the receiver is spending a massive amount of time deserializing the same data X times. I could see it instead requesting X different transactions in parallel from different nodes while the first node is stil serialiing and sending all of the data
303 2014-06-30 19:10:43 <hearn> if we ever reach those kinds of traffic levels, i intend to be comfortably retired on a desert island with a grass-skirted waitress bringing me an ice cold vodka and a cigar
304 2014-06-30 19:11:33 <hearn> but yes, in future if we measure and find having SPV wallets send invs would help, we could adjust their behaviour to do so as an optimisation that'd get rolled out over time
305 2014-06-30 19:11:35 <hearn> :)
306 2014-06-30 19:15:59 <hearn> Luke-Jr: thanks for the extra code review of adam's change. is this a one off or do you plan to do more review of bitcoinj patches in future?
307 2014-06-30 20:24:52 <Genitrust> just curious, once I do (under linux) "sha256sum bitcoin-0.9.2.1-win32-setup.exe",
308 2014-06-30 20:25:08 <Genitrust> is there a way i can just immediately pipe that output into a grep for the SHA256SUMs.asc file?
309 2014-06-30 20:29:26 <kazcw> Genitrust: sha256sum -c SHA256SUMs.asc bitcoin*.exe
310 2014-06-30 20:39:21 <phillipsjk> When does "Send tx relay flag with version" in the 0.9.0 release note mean. I tried searching with the term 'bitcoin "Send tx relay flag" site:github.com"', but that only brings up the release notes.
311 2014-06-30 20:40:02 <phillipsjk> oops third " should not be there.
312 2014-06-30 21:43:27 <kazcw> phillipsjk: that would be fRelayTxes
313 2014-06-30 21:47:09 <phillipsjk> thanks for the search hint.
314 2014-06-30 22:47:25 <phillipsjk> looks like it has some "bike shedding" going on there.
315 2014-06-30 22:47:35 <phillipsjk> ACTION resists urge to comment.