1 2012-07-02 00:05:27 <jgarzik> doublec: no, it fails to make provisions for 64-bit integers
  2 2012-07-02 00:07:55 <jrmithdobbs> gmaxwell: what gen cpus was that 24x box you used?
  3 2012-07-02 00:08:34 <jrmithdobbs> gmaxwell: cause i'm thinking about doing some hardware 'testing' with a 4x6x core2 era box i need to diagnose some issues with later this week ;p
  4 2012-07-02 00:10:44 <gmaxwell> jrmithdobbs: 32 core actually. older opteron 83xx (quad core) cpus.
  5 2012-07-02 00:11:37 <jrmithdobbs> gmaxwell: for similar difficulty
  6 2012-07-02 00:11:50 <gmaxwell> probably.
  7 2012-07-02 00:12:09 <BlueMatt> if you're compiling: consider compiling on multiple pcs...its really not bad if you're using gnu make-based stuff
  8 2012-07-02 00:12:18 <jrmithdobbs> i'm just gonna start it up on everything in my house and see if anything gets lucky, at least, i didn't look at the code, it starts fairly randomly right wont be the same progression on each box?
  9 2012-07-02 00:12:34 <jrmithdobbs> BlueMatt: nah, brute forcing rsa keys for vanity .onion, lol
 10 2012-07-02 00:12:35 <BlueMatt> (took me like 10-20 minutes to set up (and that was all installing packages and making the system's compiler setups identical))
 11 2012-07-02 00:12:44 <gmaxwell> BlueMatt: parallel compiling doesn't help bitcoin.. not when it takes minutes on a single file! :)
 12 2012-07-02 00:12:44 <jrmithdobbs> BlueMatt: i do use distcc ;p
 13 2012-07-02 00:13:15 <BlueMatt> gmaxwell: minutes? Ive never seen a file take longer than like 10 seconds...
 14 2012-07-02 00:13:20 <jrmithdobbs> gmaxwell: ya seriously, what happened to the build times all of a sudden, they've gotten BAD
 15 2012-07-02 00:13:49 <jrmithdobbs> i have on my i686-running p4 2 way box
 16 2012-07-02 00:14:11 <jrmithdobbs> like, it takes almost as long to build bitcoin as libreadline, and that's not a good thing
 17 2012-07-02 00:14:19 <BlueMatt> gmaxwell: distributed compiling helps for bitcoin quite a bit...as long as you have changed more than one file...
 18 2012-07-02 00:14:19 <gmaxwell> "I have multiple symlink links one for the wallet.dat, which is encrypted and inside of a true crypt container. I have a symlink for the rest of the files which are on a separate partition that is unencrypted so it isn't too bad on I/O."
 19 2012-07-02 00:14:23 <gmaxwell> sigh
 20 2012-07-02 00:14:27 <jrmithdobbs> readline spends most of it's time doing m4/autotools crap ;p
 21 2012-07-02 00:15:03 <BlueMatt> jrmithdobbs: but...yea bitcoin's compile times suck
 22 2012-07-02 00:15:46 <gmaxwell> BlueMatt: it takes a long time on my laptop, presumably because its pushing me into swap.
 23 2012-07-02 00:16:03 <BlueMatt> ahh...yea having no swap and plenty of memory always helps
 24 2012-07-02 00:16:18 <BlueMatt> yea, yea living on the edge, no swap...meh
 25 2012-07-02 00:16:36 <BlueMatt> better cache...meh
 26 2012-07-02 00:17:23 <BlueMatt> gmaxwell: upgrade your laptop?
 27 2012-07-02 00:20:42 <gmaxwell> meh. I rarely run anything but terminals on it. And you can't currently get good displays on anything.  In any case, bitcoin is a rather small program, there is no reason it should be so burdensom to compile.
 28 2012-07-02 00:20:55 <BlueMatt> yep
 29 2012-07-02 00:38:44 <jrmithdobbs> gmaxwell: new macbook ... in two years when the screen isn't making it a loss (most likely) ha
 30 2012-07-02 00:39:38 <gmaxwell> jrmithdobbs: I figure that N months after it ships lenovo will have something with the same panel.
 31 2012-07-02 00:42:11 <galambo> is there some innovation in display technology im not aware of?
 32 2012-07-02 00:42:27 <gmaxwell> galambo: >200 ppi 15" laptop display.
 33 2012-07-02 00:43:03 <galambo> no comment
 34 2012-07-02 00:54:21 <Ferroh> Okay, so,
 35 2012-07-02 00:54:33 <Ferroh> I need you guys to check your browser cache to see if you have this page:
 36 2012-07-02 00:54:43 <Ferroh> http://people.scs.carleton.ca/~clark/commitcoin/
 37 2012-07-02 00:54:47 <Ferroh> dont visit that link.
 38 2012-07-02 00:54:56 <Ferroh> the page is no longer available
 39 2012-07-02 00:54:59 <Ferroh> and I want to read the article
 40 2012-07-02 00:55:02 <Ferroh> can anyone help me out?
 41 2012-07-02 00:55:10 <galambo> why
 42 2012-07-02 00:55:22 <Ferroh> If you have firefox then it is easy to view your cache of the page, if you've visited it:
 43 2012-07-02 00:55:25 <Ferroh> http://www.mydigitallife.info/display-and-view-firefox-cache-files-without-browser-cache-viewer/
 44 2012-07-02 00:55:43 <Ferroh> why? because it explains a practical way to use his "commitcoin" idea
 45 2012-07-02 00:55:49 <Ferroh> with linux commands
 46 2012-07-02 00:55:50 <Ferroh> right now
 47 2012-07-02 00:55:56 <copumpkin> http://eprint.iacr.org/2011/677.pdf doesn't work?
 48 2012-07-02 00:56:05 <Ferroh> That is the abstract.
 49 2012-07-02 00:56:22 <Ferroh> the link I gave has explicit instructions for how to sign a document into the blockchain
 50 2012-07-02 00:56:31 <galambo> go to the library of your local university
 51 2012-07-02 00:56:40 <galambo> and ask about "interlibrary loan"
 52 2012-07-02 00:56:50 <galambo> but as with most academic papers
 53 2012-07-02 00:56:56 <galambo> expect to be greatly disappointed
 54 2012-07-02 00:57:00 <Ferroh> galambo, I am not looking for an academic paper.
 55 2012-07-02 00:57:06 <Ferroh> copumpkin just linked the paper
 56 2012-07-02 00:57:15 <Ferroh> I want the article at the link I gave specifically
 57 2012-07-02 00:57:16 <copumpkin> you want the actual implementation?
 58 2012-07-02 00:57:19 <Ferroh> which is NOT an academic paper
 59 2012-07-02 00:57:20 <copumpkin> oh
 60 2012-07-02 00:57:25 <doublec> what was at the link?
 61 2012-07-02 00:57:26 <Ferroh> yes, it was available there for months
 62 2012-07-02 00:57:27 <copumpkin> have you tried just emailing the author?
 63 2012-07-02 00:57:31 <Ferroh> copumpkin, yes.
 64 2012-07-02 00:57:38 <doublec> there's a commitcoin repository and source on github
 65 2012-07-02 00:57:38 <Ferroh> I havent heard back yet
 66 2012-07-02 00:57:42 <doublec> is it the same thing?
 67 2012-07-02 00:57:57 <Ferroh> checking
 68 2012-07-02 00:58:11 <gmaxwell> Ferroh: the commitcoin signed stuff in the blockchain is poorly done and rather paracitic.
 69 2012-07-02 00:58:22 <gmaxwell> parasitic*
 70 2012-07-02 00:58:30 <Ferroh> gmaxwell, oh?
 71 2012-07-02 00:58:47 <gmaxwell> This thing is a better design: https://github.com/goblin/chronobit
 72 2012-07-02 00:58:51 <Ferroh> doublec, It appears to be the same concept yet.
 73 2012-07-02 00:58:55 <Ferroh> gmaxwell, ah excellent, thankyou
 74 2012-07-02 00:59:07 <gmaxwell> Because it has O(1) scaling.. you can commit infinite data in the blockchain without increasing its size.
 75 2012-07-02 00:59:21 <gmaxwell> It also potentially gives you better time resolution for your commitments.
 76 2012-07-02 00:59:39 <Ferroh> gmaxwell, Oh, I thought the idea was just to store essentially a hash of your document in the chain (which would be O(1))
 77 2012-07-02 00:59:51 <Ferroh> I obviously haven't explored this idea in detail though.
 78 2012-07-02 00:59:52 <gmaxwell> Ferroh: Thats O(N) not O(1)
 79 2012-07-02 01:00:13 <Ferroh> gmaxwell, the memory footprint in the chain would be O(1)... no?
 80 2012-07-02 01:00:20 <gmaxwell> Meaning the more people use it the more burden it places on bitcoin which is unrelated to validating and securing the currency.
 81 2012-07-02 01:00:34 <Ferroh> O(1) with respect to the size of the document, I mean.
 82 2012-07-02 01:00:45 <Ferroh> Wait,
 83 2012-07-02 01:01:07 <gmaxwell> Ferroh: its one hash per committed document. Whereas UukGoblin's system is O(1) worst case per block for any number of documents.
 84 2012-07-02 01:01:18 <Ferroh> Oh okay, I see.
 85 2012-07-02 07:36:32 <jrmithdobbs> wow, got two usable onion addresses with this pattern after like ~7 hours (so, like 80-90ish cpu hours) and didn't even have to come up with an excuse to use something from work instead of my own boxes, ha
 86 2012-07-02 07:36:46 <jrmithdobbs> pattern: '^deez.*btc$'
 87 2012-07-02 08:17:41 <Cubox> Hi :)
 88 2012-07-02 08:19:34 <Cubox> I'm trying to fork bitcoin (it's litecoin, but the system is the same), and I have done some commits (https://github.com/Cubox-/BBQCoin) but, I saw that I need the genesis block, which is the first one. The problem is, I can't run bbqcoind or BBQCoin.app (the GUI) so i can't mine and generate it :( How can forks do for solve this problem ?
 89 2012-07-02 08:20:13 <sipa> small tip: the genesis block is never actually verified in the source code
 90 2012-07-02 08:20:23 <Cubox> hmm
 91 2012-07-02 08:20:33 <Cubox> so, just remove the assets ?
 92 2012-07-02 08:20:40 <sipa> assets?
 93 2012-07-02 08:20:44 <Cubox> asserts*
 94 2012-07-02 08:20:55 <Cubox> assert(block.GetHash() == hashGenesisBlock);
 95 2012-07-02 08:21:06 <Cubox> this is here the code fail.
 96 2012-07-02 08:21:07 <sipa> that, or don't touch the genesis block in the first place
 97 2012-07-02 08:21:17 <Cubox> hmm, yes...
 98 2012-07-02 08:21:23 <Cubox> sipa: thanks
 99 2012-07-02 08:21:50 <Cubox> So, what is this code for if the genesis block is not verified ?
100 2012-07-02 08:22:31 <sipa> by verified i mean it is not processed by the normal block-connection logic that checks transactions
101 2012-07-02 08:22:43 <Cubox> okey
102 2012-07-02 08:22:45 <sipa> there is an assert that the created genesis block is correct
103 2012-07-02 08:25:52 <sipa> and what great innovations will bbqcoin bring?
104 2012-07-02 08:27:05 <Cubox> sipa: nothing
105 2012-07-02 08:27:12 <Cubox> It's just a fork for fun
106 2012-07-02 08:27:30 <sipa> ok
107 2012-07-02 08:28:03 <Cubox> sipa: gui starts, but when i ask to mine, it's don't mine :(
108 2012-07-02 08:28:17 <Cubox> 0khash/s and no output log (just that mining started)
109 2012-07-02 08:28:22 <khalahan> hi
110 2012-07-02 08:28:42 <khalahan> sipa, do you know if bitcoin 0.3.x still receive security fixes ?
111 2012-07-02 08:28:52 <sipa> khalahan: it doesn't
112 2012-07-02 08:29:26 <sipa> luke-jr maintains branches with backported fixes for 0.4.x and 0.5.x
113 2012-07-02 08:30:37 <epscy> Cubox: i assume you need two clients running in order to mine
114 2012-07-02 08:30:39 <khalahan> ok, thanks... I guess I need to find someone to help porting namecoin to 0.6 :p
115 2012-07-02 08:31:30 <Cubox> epscy: okey
116 2012-07-02 08:38:42 <Cubox> hmm
117 2012-07-02 08:39:02 <Cubox> I have this PUBKEY_ADDRESS = 10 but it seems that addresses starts by 5 on my code. Did i miss something ?
118 2012-07-02 09:42:24 <TD> anyone here familiar with the mingw cross compile?
119 2012-07-02 09:44:57 <sipa> TD: i only execute gitian scripts, but that works
120 2012-07-02 09:45:12 <TD> yeah, i was just starting to conclude that using gitian seems to be the way to go
121 2012-07-02 09:45:47 <TD> there appear to be no docs on how all this works
122 2012-07-02 09:45:52 <TD> except release-process.txt
123 2012-07-02 09:46:08 <sipa> after much trial and error i wrote a bash script that does everything :)
124 2012-07-02 09:46:23 <sipa> checkout / build / package / sign
125 2012-07-02 09:47:18 <TD> oh wow. it wants to use a qemu vm
126 2012-07-02 09:47:21 <TD> darn
127 2012-07-02 09:47:33 <TD> i just want to fix the makefiles for leveldb :)
128 2012-07-02 09:48:00 <sipa> poke BlueMatt
129 2012-07-02 10:03:12 <TD> sipa: git question. how can i reset the branch i'm on to be a copy of a remote branch? i thought i had this figured out but nothing i do works
130 2012-07-02 10:03:46 <TD> i want something like "git reset --hard mikehearn/leveldb" to get my local copy on a different machine back to the code i just uploaded, but no cigar
131 2012-07-02 10:04:35 <sipa> that should do it
132 2012-07-02 10:04:49 <sipa> unless you're not on a branch now
133 2012-07-02 10:05:05 <TD> fatal: ambiguous argument 'mikehearn/leveldb': unknown revision or path not in the working tree.
134 2012-07-02 10:05:27 <TD> i'm not sure how to specify the remote branch, i guess
135 2012-07-02 10:05:34 <TD> maybe i want FETCH_HEAD?
136 2012-07-02 10:05:42 <sipa> you need to setup a remote first
137 2012-07-02 10:05:45 <TD> i have one
138 2012-07-02 10:05:50 <TD> i have pushed from this branch before
139 2012-07-02 10:06:12 <sipa> to that branch, you mean?
140 2012-07-02 10:06:34 <TD> yes
141 2012-07-02 10:06:36 <TD> no
142 2012-07-02 10:06:40 <TD> i mean from this local branch to the remote branch
143 2012-07-02 10:06:45 <sipa> try fetching it again? git fetch mikehearn
144 2012-07-02 10:06:50 <TD> i've been working on the same (remote) branch from two machines
145 2012-07-02 10:07:04 <TD> oh, hm
146 2012-07-02 10:07:05 <TD> that works
147 2012-07-02 10:07:17 <TD> odd. i wonder why. i guess i pushed to github but that isn't the same as fetching from it
148 2012-07-02 10:07:19 <TD> or something weird like that
149 2012-07-02 10:07:38 <sipa> 'mikehearn/leveldb' actually refers to a local branch you have that reflects the known state of a remote branch
150 2012-07-02 10:07:53 <sipa> you need to pull or fetch to sync that local branch with the actual remote
151 2012-07-02 10:08:07 <TD> right
152 2012-07-02 10:15:16 <BlueMatt> TD: yea...the mingw stuff is somewhat a pain...though I can set up jenkins.bluematt.me to point to one of your branches and it will test the build (including the mingw xcompile) after each new push
153 2012-07-02 10:15:33 <TD> that might be useful, thanks
154 2012-07-02 10:15:41 <TD> working on the non-qt OSX makefile at the moment
155 2012-07-02 10:16:37 <BlueMatt> it didnt really take /that/ long to set up, if you follow the gitian scripts, but if its more of a one-off thing, its not worth it
156 2012-07-02 11:57:36 <TD> BlueMatt: could you repoint jenkins at https://github.com/mikehearn/bitcoin/tree/leveldb please? if this turns out to be too slow/awkward i'll set up the cross-compiled environment myself
157 2012-07-02 11:57:40 <TD> but hopefully this won't be too tricky
158 2012-07-02 12:06:01 <BlueMatt> TD: http://jenkins.bluematt.me/job/Bitcoin-Testing-Build/30/console also follow http://jenkins.bluematt.me/job/Bitcoin-Testing-Testsuite/ for testsuite runs
159 2012-07-02 12:06:25 <TD> thanks. i'm expecting it to fail at the moment
160 2012-07-02 12:06:26 <BlueMatt> (it should build once every time a new update is pushed to github, just increment the 30
161 2012-07-02 12:15:58 <TD> BlueMatt: huh
162 2012-07-02 12:16:03 <TD> I was expecting the leveldb build to fail
163 2012-07-02 12:16:15 <TD> it's linking against POSIX emulation libraries on Windows, when built this way?
164 2012-07-02 12:17:05 <TD> "g++ -I. -I./include -fno-builtin-memcmp -pthread -DOS_LINUX -DLEVELDB_PLATFORM_POSIX"
165 2012-07-02 12:17:09 <TD> it thinks it's building on linux :(
166 2012-07-02 12:17:21 <sipa> TD: i think it builds for several platforms
167 2012-07-02 12:17:27 <sipa> and it's not done yet
168 2012-07-02 12:17:29 <TD> oh, right
169 2012-07-02 12:17:35 <TD> i thought it was only doing windows
170 2012-07-02 12:17:55 <sipa> now it's building bitcoin-qt for linux, it seems
171 2012-07-02 12:18:35 <TD> yeah
172 2012-07-02 12:20:21 <BlueMatt> TD: yea look for i586-mingw32msvc-g++ instead of g++ on the compile lines
173 2012-07-02 12:20:29 <TD> right
174 2012-07-02 12:20:31 <BlueMatt> TD: sorry, I can switch win32 to build first if you want
175 2012-07-02 12:20:51 <TD> is this the global bitcoin jenkins? i just realized i'm missing a file that i probably need to acquire from somebody else
176 2012-07-02 12:20:53 <TD> (or reimplement)
177 2012-07-02 12:21:03 <TD> so i don't want to keep it pointed at my branch for too long if it'll inconvenience others
178 2012-07-02 12:21:15 <BlueMatt> its a duplicate project that I point to whatever anyone wants tested
179 2012-07-02 12:22:17 <TD> ok, thanks
180 2012-07-02 12:22:25 <BlueMatt> it only rarely gets used, so, no you arent inconveniencing anyone
181 2012-07-02 12:23:24 <TD> thanks
182 2012-07-02 12:24:19 <sipa> it's mainly useful for complaining in this channel when someone breaks git head :)
183 2012-07-02 12:28:53 <gmaxwell> sipa: Did you see the comment I made on coblee's pull, where I suggested that perhaps we ought to be using something like size = max(tx_size/2 , 2*tx_size - size_of_redeemed_txouts) as the size metric for priority?
184 2012-07-02 12:29:28 <jgarzik> it's a TD!
185 2012-07-02 12:29:48 <sipa> gmaxwell: no?
186 2012-07-02 12:30:35 <BlueMatt> and TD leaves in 3...2...1
187 2012-07-02 12:30:43 <jgarzik> TD: any chance BitcoinJ could look into, at least, absorbing 'addr' message data?  Speaking as the operator of several public nodes listed in DNS seeds, it would be nice to spread the load.
188 2012-07-02 12:31:03 <jgarzik> TD: And as gmaxwell pointed out, BitcoinJ is more vulnerable in its current state, too
189 2012-07-02 12:31:08 <TD> yes
190 2012-07-02 12:31:31 <TD> do you see significant numbers of bitcoinj clients ?
191 2012-07-02 12:31:56 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 1548 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1548>
192 2012-07-02 12:32:37 <TD> if it's a real load issue right now i can re-prioritize things. otherwise i still need to do proper fees support and a bunch of other things ....
193 2012-07-02 12:33:41 <jgarzik> TD: 38/78 connections to my public node are BitcoinJ.  It's definitely noticeable.
194 2012-07-02 12:33:45 <TD> ok
195 2012-07-02 12:33:57 <jgarzik> TD: other public nodes not listed in DNS seeds do not see nearly so many
196 2012-07-02 12:34:02 <TD> i can bring up a couple of extra nodes on dedicated VMs if you want some more sockets temporarily
197 2012-07-02 12:34:51 <gmaxwell> sipa: coblee opened a pull request related to dust spamming attacks that are happening on litecoin, basically he wants to increase the fee by minfee by base for each dust output. I made an aside commenting that this fits into generally changing the fees to discourage txout bloat.
198 2012-07-02 12:35:29 <sipa> gmaxwell: i think i suggested something similar over a year ago somewhere on the forum, and others have too iirc
199 2012-07-02 12:35:31 <jgarzik> TD: If I was running out of resources, I would just stop running bitcoind.  My main point was to illustrate how hard bitcoinj hits the nodes returned from DNS seeds.
200 2012-07-02 12:35:35 <TD> ok
201 2012-07-02 12:35:50 <TD> like i said, it's definitely on the todo  list
202 2012-07-02 12:35:55 <TD> it's just a matter of figuring out the right ordering of work
203 2012-07-02 12:36:15 <TD> currently i'm 100% on leveldb because it's no good that nodes are starting to bottleneck on IO, so i'm not even changing bitcoinj.
204 2012-07-02 12:36:34 <gmaxwell> sipa: yea, I think I have too previously. It seemed more relevant now that you've been working on pruning.
205 2012-07-02 12:36:42 <jgarzik> TD: this is part of my "backbone" project which runs public nodes, so would definitely prefer to leave them up and running, and fix the issues I see (#1: BitcoinJ hits it hard, #2: bitcoin-qt always downloads blocks from seeds)
206 2012-07-02 12:36:51 <jgarzik> those are the two top problems I see
207 2012-07-02 12:37:24 <sipa> gmaxwell: in extremis, the network cost of a transaction is transmission proportional to the txsize, and storage proportional to (created txouts - consumed txouts)
208 2012-07-02 12:37:52 <sipa> and it seems right to me base priority calculations on how much they impact the network in the long term
209 2012-07-02 12:38:13 <TD> ok
210 2012-07-02 12:38:30 <gmaxwell> sipa: unfortunately I don't think there is an obvious tradeoff coefficent for network cost vs storage cost.
211 2012-07-02 12:38:48 <TD> does anyone know why qmake prints such confusing messages
212 2012-07-02 12:38:53 <TD> it seems to evaluate all branches of conditionals or something
213 2012-07-02 12:38:59 <gmaxwell> Though generally I think its correct to significantly priortize storage cost (the future is a long time).
214 2012-07-02 12:41:52 <sipa> jgarzik: what was the address of your backbone nodes?
215 2012-07-02 12:43:55 <jgarzik> sipa: at present: us[24].exmulti.net, eu3.exmulti.net
216 2012-07-02 12:44:23 <jgarzik> gmaxwell: agree strongly
217 2012-07-02 12:44:57 <jgarzik> sipa: they are also listed on the wiki as fallback nodes
218 2012-07-02 12:47:32 <TD> BlueMatt: how often does jenkins check to see if there are changes
219 2012-07-02 12:50:45 <gavinandresen> gmaxwell: RE: pull 1526 and coding a "point of no return" .... are you thinking a specific block height/date or something else?
220 2012-07-02 12:53:30 <gmaxwell> gavinandresen: I'm thinking that the first height where a particular density is reached (perhaps 100% in your window of 1000 ... though realistically it could be the activation point, as no node enforcing this code will go back) then that height becomes the point of no return. After it's happened in the next release it just becomes part of a checkpoint (which would effectively make it a height and date threshold, since dates can't go back pas
221 2012-07-02 12:54:29 <TD> BlueMatt: seems you are starting them manually .... could I get a login on this jenkins so I can do that ?
222 2012-07-02 12:55:47 <sipa> TD: afaik it happens automatically
223 2012-07-02 12:55:52 <gmaxwell> I wish jenkins gave people without logins access to the configs so you could answer questions like how often it polls.
224 2012-07-02 12:56:26 <gavinandresen> gmaxwell: ok, so it wouldn't require code changes to the pull, just a note to ourselves to check for 100% acceptance at some future checkpoint
225 2012-07-02 12:57:50 <gmaxwell> Hm. Well I was more thinking that it would temporarily record the height in this commit, but that would later be replaced with a checkpoint. But now that you mention it right,  I think it would be safe to make it no return later without that.
226 2012-07-02 12:58:35 <gmaxwell> The rationale is that someone would have to mine 250 v1 blocks... while all of nodes with this code would be totally rejecting them until they did. Thats unlikely enough that the rule change to make this irreversable would be reasonable safe.
227 2012-07-02 13:00:25 <gavinandresen> gmaxwell: there is a small window of vulnerability between when we write the code that locks in the checkpoint and that release rolls out, but it seems like it would be basically impossible for support to go from 100% down to under-75% in that time.
228 2012-07-02 13:01:53 <gmaxwell> it _should_ be impossible to go down from 100% from the moment it hits 75%.  The 75% with your code will reject all blocks without the height.
229 2012-07-02 13:02:23 <gmaxwell> (well go down from wherever it is once it hits 75%)
230 2012-07-02 13:02:28 <gavinandresen> gmaxwell: no, the if (nVersion > 1) means the rule is only enforced for version=2+ blocks
231 2012-07-02 13:02:32 <TD> sipa: apparently not at the moment
232 2012-07-02 13:02:41 <TD> sipa: the last build says it was started by BlueMatt manually
233 2012-07-02 13:02:48 <jgarzik> version=2 TXs make more sense than blocks
234 2012-07-02 13:03:14 <jgarzik> even with p2sh, the only blocks we would actually reject are ones with entirely invalid p2sh transactions
235 2012-07-02 13:03:31 <sipa> but we're not changing transaction validation rules now
236 2012-07-02 13:03:35 <sipa> only block validation rules
237 2012-07-02 13:03:38 <gmaxwell> gavinandresen: ah, okay, I misunderstood that.
238 2012-07-02 13:03:39 <gavinandresen> jgarzik: this is block-height-in-the-coinbase
239 2012-07-02 13:04:21 <jgarzik> Yes, I'm aware of that.  Drawing an analogy.  Getting to 100% acceptance of ver=2 blocks will be a chore, and locking in will hurt older miners if it kicks in at 75%, yes?
240 2012-07-02 13:04:34 <gavinandresen> yes, that's why it's not locked in at 75%
241 2012-07-02 13:04:54 <gavinandresen> The thing that is locked in at 75% is "If you produce a block with nVersion=2, then you MUST follow this new rule"
242 2012-07-02 13:05:17 <jgarzik> as long as older miners are not hurt, life is good
243 2012-07-02 13:05:23 <gmaxwell> gavinandresen: well darn. Then I do think we should force v2 blocks to at some point. And there is an advantage to putting that rule in at the start.
244 2012-07-02 13:05:51 <gmaxwell> (If we don't have the rule at the start then we need to use some other signaling mechinism to signal that a node is going to start forcing the rule)
245 2012-07-02 13:05:59 <gavinandresen> Old miners can continue producing nVersion=1 blocks until "we" decide they can't any more....
246 2012-07-02 13:06:34 <jgarzik> yeah, already ACK'd the "if block ver=2, height in coinbase must be correct" change
247 2012-07-02 13:06:36 <sipa> i think that point of no-v1-allowed-anymore should be decided and coded in advance
248 2012-07-02 13:06:42 <jgarzik> that clearly does not kill older miners
249 2012-07-02 13:07:01 <gmaxwell> jgarzik: I'm not especially concerned about the old miners so long as the switch criteria is tall enough. The same miners who will get orphaned because they didn't update are too disconnected from bitcoin to raise a fuss.
250 2012-07-02 13:07:12 <gavinandresen> sipa: I agree it should be decided in advance, I'm not sure it makes sense to decide it right now.
251 2012-07-02 13:07:31 <sipa> the rule can be "one year after the v2-active code kicks in" or so
252 2012-07-02 13:07:47 <jgarzik> gmaxwell: hmmm... while technically true, I think following that train of logic may lead us dev'ers to cathedral-ism
253 2012-07-02 13:07:52 <gmaxwell> I like switches on height rather than time.
254 2012-07-02 13:07:57 <sipa> gmaxwell: ack
255 2012-07-02 13:08:25 <jgarzik> gavinandresen: ack
256 2012-07-02 13:08:42 <gmaxwell> jgarzik: if the code doesn't eventually enforce it then this rule change doesn't have protective power.
257 2012-07-02 13:08:58 <gmaxwell> Yea, I don't feel strongly about deciding now except the aformentioned problem of coordiating the lock point.
258 2012-07-02 13:09:00 <jgarzik> go ahead and push the ver=2 checking, sure
259 2012-07-02 13:09:25 <gmaxwell> jgarzik: because you can still choose to mine duplicate coinbases using v1 blocks.
260 2012-07-02 13:09:43 <jgarzik> yep
261 2012-07-02 13:09:54 <jgarzik> nice to fix, butthe world isn't ending
262 2012-07-02 13:10:05 <gmaxwell> Well maybe. :)
263 2012-07-02 13:10:48 <gavinandresen> I'd like to roll out 1526, then talk about rolling out a version=2 mandatory when 80+% of the blocks are version=2
264 2012-07-02 13:11:25 <gmaxwell> We will then need a coordination mechenism for activating the v=2 lock.
265 2012-07-02 13:11:39 <gmaxwell> (vs being able to use the v2 blocks themselves as that mechenism)
266 2012-07-02 13:12:32 <gavinandresen> gmaxwell: good point
267 2012-07-02 13:13:16 <gmaxwell> Thats why I prefer to figure that out now, though I certantly understand you reason for not wanting to do that it would be sad to delay the height stuff as a result of disagreement over the lock-in rule.
268 2012-07-02 13:13:39 <gmaxwell> Though I think it should be easy to decide on a lock in rule that no one participating in the discussion objects to.  (Ha. Famous last words)
269 2012-07-02 13:19:55 <TD> sipa: are you planning on multi-threading tx verification at some point, post your refactor?
270 2012-07-02 13:23:24 <sipa> TD: not immediately, though it's certainly a nice potential improvement
271 2012-07-02 13:23:50 <TD> ok
272 2012-07-02 13:27:24 <TD> right. the issue is leveldb doesn't know it's supposed to be x-compiled
273 2012-07-02 13:27:28 <TD> hrmph
274 2012-07-02 14:02:34 <BlueMatt> TD: sorry, was mowing the lawn...sorry I tried the other automatic setting...guess it doesnt work, Ill set it to poll
275 2012-07-02 14:03:50 <TD> ok, thanks
276 2012-07-02 14:22:13 <jgarzik> BlueMatt: your mower has an automatic setting?  I want one.
277 2012-07-02 14:22:27 <luke-jr> khalahan: I'd start with "git merge" :p
278 2012-07-02 14:22:57 <luke-jr> khalahan: probably most importantly, you don't want to accidentally fork namecoin with P2SH
279 2012-07-02 14:24:53 <BlueMatt> jgarzik: I wish, though one of the neighbors has a roomba-style mower
280 2012-07-02 14:25:21 <jgarzik> BlueMatt: heh, I hope it zig-zags all over the lawn and bounces off trees like a roomba, too
281 2012-07-02 14:26:00 <BlueMatt> dunno, never paid attention, though he has said hes very happy with it
282 2012-07-02 15:06:58 <jgarzik> hrm
283 2012-07-02 15:07:08 <jgarzik> bitcoind should log who sends orphan TXs
284 2012-07-02 15:07:49 <gmaxwell> jgarzik: you get orphans on every newly restarted node though they aren't unusual if your node doesn't have quite high uptimes.
285 2012-07-02 15:08:20 <jgarzik> once you're caught up, it is an unusual event
286 2012-07-02 15:09:25 <gmaxwell> jgarzik: dunno why you say that what I suggested is highly unlikely. Miners would have a clear profit motive: Step 1. don't run the new code, step 2. wait for 40% of the miners to run the new code (easily measured). Step 3. make your next block broken v2, = profit.
287 2012-07-02 15:10:17 <gmaxwell> I wouldn't _personally_ do that, but I'm pretty sure there are people who would just like someone pretty quickly started with the invalid p2sh txn after bip16 took effect.
288 2012-07-02 15:10:53 <jgarzik> gmaxwell: it is anti-social, and would simply motivate the other side to ignore the nutter miners.  end result would be acceleration of the ver-2-required rule.
289 2012-07-02 15:11:39 <jgarzik> not impossible, but there are definite counter-incentives
290 2012-07-02 15:12:02 <gmaxwell> And then we take a hundred block reorg with double spends in it when people do wake up and quickly deploy the code after the fork has formed?
291 2012-07-02 15:12:51 <gmaxwell> It would in fact be _bad_ in that case to get more nodes to deploy the v2 code once the split had grown longer than 6 blocks or so.
292 2012-07-02 15:13:34 <gmaxwell> (because as soon as it was noticed jerkwads would show up and start trying to get conflicting txn in the split components)
293 2012-07-02 15:22:39 <jgarzik> gmaxwell: <shrug> philosophical difference.  nevertheless, gavinandresen's change is fine as-is, as I noted.  we don't have to be as aggressive as I suggested in the comment; it's an option.
294 2012-07-02 15:23:00 <jgarzik> gmaxwell: you just have a different risk calculus :)
295 2012-07-02 15:23:28 <gavinandresen> I'm with gmaxwell, too dangerous to start enforcing "v=2 means blah"
296 2012-07-02 15:23:48 <gavinandresen> Rational miners would just never validate v=2 blocks.
297 2012-07-02 15:24:25 <gavinandresen> I'm still thinking about the "when to start rejecting v=1 blocks" ....
298 2012-07-02 15:24:39 <gavinandresen> sipa : you writing a versioning BIP?
299 2012-07-02 15:25:22 <gmaxwell> jgarzik: yea, I'm only belaboring it because I wanted to make sure you were at least aware of how I reason about fork risks.
300 2012-07-02 15:27:07 <gavinandresen> gmaxwell: what "reject v=1" rule were you imagining would be non-controversial?
301 2012-07-02 15:30:16 <gmaxwell> Anything which is 'sufficiently close' to 100% will be uncontroversial, assuming that the change itself is uncontroversal (I expect it to be).  Ignoring the complexity of updating it, I'd just do something like 'stop accepting v1 when 95% of the last 1000 are v2' or something like that. There is a slight tradeoff  setting it too close to 100% has the risk that it won't be hit until the far future and we'll have forgotten about that change
302 2012-07-02 15:31:19 <BlueMatt> how long did it take to get to various high values for bip16?
303 2012-07-02 15:31:45 <sipa> gavinandresen: long time ago, i'm sure you've seen it
304 2012-07-02 15:31:51 <gmaxwell> bbl
305 2012-07-02 15:32:09 <BlueMatt> hmm...looks like we still arent at 75% p2sh
306 2012-07-02 15:32:53 <sipa> gavinandresen: https://gist.github.com/1728493
307 2012-07-02 15:33:51 <sipa> gavinandresen: though i think there were issues with it that i never addressed
308 2012-07-02 15:34:29 <luke-jr> BlueMatt: backports don't put it in the coinbase, even though they enforce it, FWIW
309 2012-07-02 15:35:52 <BlueMatt> luke-jr: you dont happen to have a p2sh % based on version number in those graphs you had been making based on seeds.txt?
310 2012-07-02 15:36:14 <luke-jr> BlueMatt: sure, but that's nodes, not mined blocks
311 2012-07-02 15:36:30 <luke-jr> http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?16
312 2012-07-02 15:37:53 <BlueMatt> luke-jr: you dont happen to know any major pools other than eligius that use backport-based bitcoinds?
313 2012-07-02 15:38:39 <luke-jr> BlueMatt: specifically, probably just TripleMining and EclipseMC
314 2012-07-02 15:38:48 <luke-jr> AFAIK they run my next-eligius branch (0.6.0.x)
315 2012-07-02 15:39:00 <BlueMatt> wont 0.6.0.x put it in coinbase?
316 2012-07-02 15:39:03 <luke-jr> probably
317 2012-07-02 15:39:13 <luke-jr> but Eloipool probably doesn't.
318 2012-07-02 15:39:39 <luke-jr> partly since bitcoind isn't using BIP22 compliant getmemorypool for it <.<
319 2012-07-02 15:39:44 <BlueMatt> mmm...well whatever, I doubt there is more than a few % of mining power in such nodes, at least not significant enough to get up to 80%
320 2012-07-02 15:40:32 <luke-jr> thing is
321 2012-07-02 15:40:41 <luke-jr> that invalid P2SH a while ago should have wiped out any that aren't enforcing
322 2012-07-02 15:41:01 <luke-jr> I suppose someone could do the same thing again and see if it gets anywhere
323 2012-07-02 16:10:23 <kinlo> luke-jr: actually, I run stock bitcoind, no changes for the pool
324 2012-07-02 16:10:39 <kinlo> and for the wallet I run custom patches
325 2012-07-02 16:11:21 <luke-jr> kinlo: you don't use bitcoind for wallet?
326 2012-07-02 16:11:40 <kinlo> ofcourse I do
327 2012-07-02 16:12:40 <kinlo> just only my own patches
328 2012-07-02 16:18:24 <gmaxwell> http://blockchain.info/tx-index/3618498/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2  < mined as recently as 06/18
329 2012-07-02 16:19:48 <Matt_von_Mises> What's the purpose of having network addresses in the version message?
330 2012-07-02 16:19:59 <Matt_von_Mises> What are they used for from the version messages?
331 2012-07-02 16:20:33 <gmaxwell> Matt_von_Mises: they could be used to remove the insane external dependency for address discovery, but they are not currently.
332 2012-07-02 16:21:45 <BlueMatt> gmaxwell: heh, nice
333 2012-07-02 16:23:01 <Matt_von_Mises> How would that work?
334 2012-07-02 16:23:16 <Matt_von_Mises> gmaxwell
335 2012-07-02 16:25:40 <kinlo> gmaxwell: which versions accept that tx as valid/invalid?
336 2012-07-02 16:26:13 <gmaxwell> Matt_von_Mises: your peers all tell you that you are 1.2.3.4, without knowing anything better than that.. you assume its true.
337 2012-07-02 16:26:45 <Matt_von_Mises> Oh, you mean discovering your own address.
338 2012-07-02 16:26:47 <Matt_von_Mises> I see
339 2012-07-02 16:26:50 <gmaxwell> kinlo: pre-BIP16, so prior to 0.6 (excluding luke's backports)
340 2012-07-02 16:27:12 <gmaxwell> Matt_von_Mises: right now the client software does something so horrible I shudder to speak of it.
341 2012-07-02 16:27:32 <kinlo> mmmz, so it get's orphaned because the network isn't suffisantly upgraded?
342 2012-07-02 16:28:27 <gmaxwell> kinlo: it gets created because there are a few miners that aren't upgraded.
343 2012-07-02 16:28:33 <gavinandresen> no, it gets orphaned because the network IS sufficiently upgraded
344 2012-07-02 16:28:40 <gmaxwell> ^ and that.
345 2012-07-02 16:36:10 <Matt_von_Mises> I might be a stupid question but why does a bitcoin node even need to know the IP address of itself?
346 2012-07-02 16:39:06 <gmaxwell> Matt_von_Mises: in order to advertise its existance to other peers.
347 2012-07-02 16:39:53 <Matt_von_Mises> Why does it need it's own IP to do that?
348 2012-07-02 16:40:01 <gmaxwell> ...
349 2012-07-02 16:40:30 <gmaxwell> If I'm going to write an announcement to tell other nodes to connect to me I need to know my address, so I can put it in the announcement.
350 2012-07-02 16:40:42 <Matt_von_Mises> Oh wait, you mean on the IRC channel method?
351 2012-07-02 16:40:47 <gmaxwell> No.
352 2012-07-02 16:40:52 <gmaxwell> We no longer use IRC.
353 2012-07-02 16:41:11 <gmaxwell> (although that needs to know its IP too, though the IRC server tells it)
354 2012-07-02 16:41:55 <Matt_von_Mises> So when you connect directly to an address via DNS or whatever, can't the peer you connect to find your IP address without you needing to send it?
355 2012-07-02 16:43:09 <gmaxwell> Matt_von_Mises: Nodes announce themselves, rather than others announcing on their behalf because nodes may not wish to announce for varrious reasons. (e.g. because they won't actually accept, or because they are trying to be a bit more covert, or because they are not currently in sync with the network)
356 2012-07-02 16:43:50 <gmaxwell> Also, the address I connected to you from may not be the one I accept connections on. (I have nodes run like that)
357 2012-07-02 16:45:12 <gmaxwell> Right now the reference client doesn't announce if it's not in sync, or if it has listening disabled. (it may still announce if listening is enabled but it can't be reached due to firewalling it can't tell)
358 2012-07-02 16:49:18 <Matt_von_Mises> So it's so that you can connect to a node on behalf of another address? Because that's what I mean, nodes could assume incoming connections to be for the address of the connection if IP addresses weren't included in the bitcoin messages.
359 2012-07-02 16:49:45 <Cubox> Hi
360 2012-07-02 16:49:56 <Cubox> I have some problems putting the genesis block on the code
361 2012-07-02 16:50:26 <Matt_von_Mises> Though I've not done loads on networking before so I need to make sure I know what I'm doing.
362 2012-07-02 16:50:38 <gmaxwell> Matt_von_Mises: Can you try stating that another way, because I'm not following you.
363 2012-07-02 16:51:12 <Cubox> http://pastebin.com/sJvvyFbg
364 2012-07-02 16:51:33 <Cubox> There is some part in code where i don't know what to put
365 2012-07-02 16:51:36 <jrmithdobbs> Matt_von_Mises: i think i get what you're saying but you don't solve anything with it because now you have to make sure the intermediary proxies don't modify the messages
366 2012-07-02 16:51:46 <Cubox> txNew.vin[0].scriptSig = CScript() << 486604799 << CBigNum(4) << vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));
367 2012-07-02 16:51:55 <Cubox> txNew.vout[0].scriptPubKey = CScript() << ParseHex("040184710fa689ad5023690c80f3a49c8f13f8d45b8c857fbcbc8bc4a8e4d3eb4b10f4d4604fa08dce601aaf0f470216fe1b51850b4acf21b179c45070ac7b03a9") << OP_CHECKSIG;
368 2012-07-02 16:53:42 <D34TH> cubox please use pastebin
369 2012-07-02 16:53:50 <gmaxwell> Cubox: what is your actual problem?  In the form of "I try to do X, I expect Y, I get Z instead"?
370 2012-07-02 16:54:07 <Matt_von_Mises> jrmithdobbs: I thought bitcoin doesn't use TLS/SSL or whatever so that messages can be modified anyway?
371 2012-07-02 16:54:21 <gmaxwell> Matt_von_Mises: can you try again on what you were saying for me?
372 2012-07-02 16:54:31 <Cubox> I try to make a genesis block for puting it in the code of my work, i expect that i knew what to put in the two lignes of code i pasted, but i diden't
373 2012-07-02 16:54:34 <D34TH> gmaxwell: he is trying to fork but failing at getting new genesis
374 2012-07-02 16:54:46 <Cubox> s/work/fork/
375 2012-07-02 16:55:01 <Cubox> http://github.com/Cubox-/BBQCoin/
376 2012-07-02 16:55:02 <gmaxwell> Cubox: what you pasted looked successful to me.
377 2012-07-02 16:55:12 <gavinandresen> Part of me feels like saying if you can't figure out how to write some code to generate a new genesis block, then you don't know enough to create your own fork.....
378 2012-07-02 16:55:16 <Matt_von_Mises> gmaxwell: I'm saying that when connecting to a node that node could tell your IP from the connection but then you are saying that you could connect on a different IP than the node you want to use to communicate.
379 2012-07-02 16:55:55 <Cubox> gmaxwell: yes, but what is pasted is the real block, not my crafted one :)
380 2012-07-02 16:56:08 <gmaxwell> Matt_von_Mises: It can see an IP. It may or may not be yours. It may be yours but it may or may not be the one you accept incoming connections on.
381 2012-07-02 16:56:15 <jrmithdobbs> Matt_von_Mises: yes but when you're dealing with one node to one node communication that's not a big deal (you verify across multiple different peers so as long as your direct upstream isn't fucked you're ok), but if you allow other people to "speak" for you it complicates things and you almost have to start using tls/etc to ensure you're getting the answers to the questions you actually asked
382 2012-07-02 16:56:18 <Cubox> I mined this block with the litecoin genesis block, and now, i'm putting it in the code
383 2012-07-02 16:56:39 <gmaxwell> Matt_von_Mises: Lets just assume it actually sees yours, and ignore the corner cases like you having multiple addresses. Now what?
384 2012-07-02 16:57:20 <jrmithdobbs> Matt_von_Mises: i think there's some fundamentaly ip or tcp misunderstanding causing confusion here (I do not mean that as an insult)
385 2012-07-02 16:57:27 <jrmithdobbs> s/fundamentaly/fundamental/
386 2012-07-02 16:57:35 <Matt_von_Mises> jrmithdobbs: But someone can still place a fake IP in a bitcoin message.
387 2012-07-02 16:57:43 <gmaxwell> Yes? and?
388 2012-07-02 16:57:54 <jrmithdobbs> so?
389 2012-07-02 16:58:05 <gmaxwell> jrmithdobbs: you're breaking my effort to be somewhat socratic here.
390 2012-07-02 16:58:08 <jrmithdobbs> they can't do anything particularly interesting with it because of the POW system
391 2012-07-02 16:58:15 <gmaxwell> 0_o
392 2012-07-02 16:58:27 <jrmithdobbs> gmaxwell: sorry, do continue ;p
393 2012-07-02 16:58:55 <gmaxwell> Matt_von_Mises: would you please answer my query above?  Assume a peer has correctly pulled out your real IP on inbound. So what?
394 2012-07-02 16:58:57 <Matt_von_Mises> So why does the IP information in the bitcoin messages prevent other nodes "speaking" for you then?
395 2012-07-02 16:59:06 <jrmithdobbs> gmaxwell: i need to go check if my car's dry from the shampoo'ing yet anyways. stupid ants. :(
396 2012-07-02 16:59:25 <Matt_von_Mises> gmaxwell: Exactly, so what?
397 2012-07-02 16:59:56 <Cubox> any ideas for my problem ? :/
398 2012-07-02 16:59:58 <gmaxwell> Matt_von_Mises: er. I'm saying that a peer has discovered your correct IP by looking at the inbound address on the socket, not from the inbound protocol.
399 2012-07-02 17:00:45 <jrmithdobbs> Matt_von_Mises: because they can deliver arbitrary responses to any messages by mangling your request before sending to the "real" intended peeer, so you may ask "give me block at height XXXXYYYY" but actually get as a response 500 blocks at height YYYYZZZ, that should illustrate one of the problems (it becomes a bigger issue within the protocol because participants have an incentive to cheat whereas typically the internet as a whole has no i
400 2012-07-02 17:02:03 <Matt_von_Mises> That's what I'm saying. What is wrong with that? But I accept that nodes might want to advertise an alternative address.
401 2012-07-02 17:02:15 <Matt_von_Mises> That was for gmaxwell sorry.
402 2012-07-02 17:02:38 <gmaxwell> Matt_von_Mises: Because it would be not good at all if all peers were advertising your address instead of you.
403 2012-07-02 17:02:40 <Cubox> should i come back later ?
404 2012-07-02 17:03:25 <gmaxwell> Cubox: I think that no one in here is likely to help you. None of us have genesis block creation fresh in our memory and we all have too much else to deal with right now.  Part of the fun is figuring this out anyways. You can do it. :)
405 2012-07-02 17:03:53 <Cubox> gmaxwell: :(
406 2012-07-02 17:04:24 <gavinandresen> Cubox : look at it from our point of view:  "Hey, I want to spend a bunch of time on this other thing instead of helping with Bitcoin.  And I want YOU to help me!"
407 2012-07-02 17:04:37 <gmaxwell> Matt_von_Mises: A peer you connect to does not (1) know if you'll accept incoming connections at all, (2) know if you are healty or overloaded, (3) know what your preferred addresses are.
408 2012-07-02 17:05:09 <Cubox> hmm, okey :)
409 2012-07-02 17:05:24 <gmaxwell> Matt_von_Mises: and so while a peer _could_ announce your address without your consent based on just the connection he saw coming in. ... That wouldn't be good for the system and so normal peers don't do that.
410 2012-07-02 17:05:59 <gmaxwell> Matt_von_Mises: the addresses in the version message are so he can tell you what he observes about your address, and so you can  at your option choose to use that information.
411 2012-07-02 17:23:05 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 1549 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1549>
412 2012-07-02 17:29:10 <Matt_von_Mises> "the addresses in the version message are so he can tell you what he observes about your address" If you want to gather your IP from querying this way, would you send a version message with a version less than 106 to avoid sending an address for yourself you do not know. Or do you send a dummy IP address?
413 2012-07-02 17:29:36 <Matt_von_Mises> Because the idea is you don't know your IP address yet and want to know.
414 2012-07-02 17:31:08 <phantomcircuit> you send 0.0.0.0
415 2012-07-02 17:31:18 <phantomcircuit> iirc the client already does that if you're using a proxy
416 2012-07-02 17:31:23 <jgarzik> yep
417 2012-07-02 17:31:33 <jgarzik> though TD's BitcoinJ seems to send 127.0.0.1
418 2012-07-02 17:35:29 <gmaxwell> Matt_von_Mises: What you send doesn't matter. Your peer tells you what it sees always.
419 2012-07-02 17:36:55 <Matt_von_Mises> gmaxwell: The source IP you send in the version message does what then if it doesn't matter?
420 2012-07-02 17:37:31 <gmaxwell> Matt_von_Mises: It does nothing. It's just informative.
421 2012-07-02 17:40:54 <BlueMatt> gmaxwell: didnt you say you wanted this at some point? https://github.com/bitcoin/bitcoin/pull/1549
422 2012-07-02 17:41:02 <Matt_von_Mises> gmaxwell: Sounds like a waste of space then& This is all very confusing...
423 2012-07-02 17:42:19 <gmaxwell> Matt_von_Mises: 'waste of space' you mean .. like the version and the subversion identifiers?
424 2012-07-02 17:47:15 <Matt_von_Mises> The version information is used and where not used may be used in the future but what conceivable use does this second address field have?
425 2012-07-02 17:49:29 <Matt_von_Mises> This is so confusing, I need to make a topic on the forums I think...
426 2012-07-02 18:00:38 <gmaxwell> Matt_von_Mises: the version information is mostly not used. The full version information is expressly forbidden from being used, if you care what the BIP says.
427 2012-07-02 18:12:56 <Matt_von_Mises> https://bitcointalk.org/index.php?topic=91231.0 Really it comes down to "Why not trust TCP/IP?".
428 2012-07-02 18:30:03 <gmaxwell> Matt_von_Mises: are you just going to keep answering until someone tells you what you're expecting to hear? :(
429 2012-07-02 18:30:29 <Matt_von_Mises> gmaxwell: Until I'm no longer confused hopefully. :P
430 2012-07-02 18:31:23 <gmaxwell> You seem to have totally ignored that I said about it being important that nodes only announce themselves voluntarily and not be involuntarily announced by nodes they connect to. :(
431 2012-07-02 18:32:58 <Matt_von_Mises> That doesn't answer my question. If that was the case then you could just have a flag when connecting that says "OK share my address".
432 2012-07-02 18:34:31 <Diapolo> Can someone give me a testnet addr? I need to send some coins for testing.
433 2012-07-02 18:36:14 <Matt_von_Mises> Any valid address?
434 2012-07-02 18:36:33 <Diapolo> http://testnet.freebitcoins.appspot.com/ I forgot that one ^^ don't need one then
435 2012-07-02 18:47:45 <BlueMatt> Matt_von_Mises: the reason we dont have a flag for that, is because thats not the way satoshi did it
436 2012-07-02 18:48:33 <Matt_von_Mises> BlueMatt: Do you mean I'm correct that the way bitcoin shares socket information is silly?
437 2012-07-02 18:51:04 <BlueMatt> no, its not silly, its just different
438 2012-07-02 18:51:28 <BlueMatt> it does avoid some issues where you may connect to a node using a non-public ip, and then that non-public ip (in a public range) gets announced
439 2012-07-02 18:51:38 <BlueMatt> admittedly very rare, but...
440 2012-07-02 18:53:24 <gmaxwell> BlueMatt: thats how my nodes work. ::shrugs::
441 2012-07-02 18:53:43 <gmaxwell> BlueMatt: I have multiple internet connections but only one gets announced.
442 2012-07-02 18:54:00 <gmaxwell> (because I don't want @#$@# dos attackers hitting all of them)
443 2012-07-02 18:54:30 <gmaxwell> Also means you can do things like connect out on v4 and tell people your onion for inbound.
444 2012-07-02 18:55:20 <BlueMatt> yep
445 2012-07-02 18:55:51 <BlueMatt> Matt_von_Mises: it adds options that weren't there before, even if they arent really common uses, its just the way satoshi chose to do it
446 2012-07-02 18:55:58 <BlueMatt> and there is absolutely no reason to change it
447 2012-07-02 18:57:33 <Matt_von_Mises> I'm just trying to think about how internally redundant data can be removed. I'll come back to this. For now I've got other stuff to do. So thanks, I'm off.
448 2012-07-02 18:58:38 <gmaxwell> Matt_von_Mises: "internally redundant data can be removed"  thats like polishing grains of sand on the beach.
449 2012-07-02 18:59:08 <gmaxwell> :)
450 2012-07-02 18:59:35 <Diapolo> I like such a passion ^^
451 2012-07-02 19:02:37 <Diapolo> Can someone help, I think there is something wrong here:
452 2012-07-02 19:03:12 <Diapolo> int64 nChange = wtx.GetChange();
453 2012-07-02 19:03:12 <Diapolo> // Payment to self
454 2012-07-02 19:03:31 <Diapolo> Why is -nValue the Debit and nValue the Credit?
455 2012-07-02 19:11:33 <BlueMatt> I havent looked at where the code is, but Id guess its because either Debit or Credit is hidden based on the tx type somehow
456 2012-07-02 19:11:41 <BlueMatt> otherwise we have a bug and are showing both in some txes?
457 2012-07-02 19:12:30 <Diapolo> wait I'll point you to the code
458 2012-07-02 19:13:04 <Diapolo> https://github.com/bitcoin/bitcoin/blob/master/src/qt/transactiondesc.cpp#L191
459 2012-07-02 19:13:21 <Diapolo> I'm working on the strings and stumbled uppon that part.
460 2012-07-02 19:14:25 <BlueMatt> oh...if its a payment from self to self and all inputs and all outputs are to/from self, then its both a credit and debit
461 2012-07-02 19:14:29 <BlueMatt> and they are both the same value
462 2012-07-02 19:15:04 <Diapolo> ah darn of course same out same in
463 2012-07-02 19:17:08 <Diapolo> sorry and thanks :)
464 2012-07-02 19:17:51 <BlueMatt> np, I sure as hell miss more obvious things than that
465 2012-07-02 21:15:19 <jrmithdobbs> so, there's lots of smart people here, maybe you'll have ideas
466 2012-07-02 21:15:24 <jrmithdobbs> how do i get ants out of my fuckin car
467 2012-07-02 21:15:53 <jrmithdobbs> (i shampooed everything this morning even though it wasn't really dirty in the first place, not like the floor was covered in soda or something)
468 2012-07-02 21:16:12 <bonks> ant poison
469 2012-07-02 21:16:32 <jrmithdobbs> where? and I have dogs so that's a bitch because that means another $100 detailing before they can get in :(
470 2012-07-02 21:16:46 <jrmithdobbs> they're fire ants so they're that much harder to bait/kill too :(
471 2012-07-02 21:17:20 <bonks> use granules which you place directly on their trail, wait til it's all consumed or vacuum it up before letting dogs/children in
472 2012-07-02 21:18:40 <bonks> they'll consume it within 2 days and i do this about every 1-2 months , but i guess it depends on the type of ants (i dont have fire ants)
473 2012-07-02 21:18:44 <jrmithdobbs> that wont work
474 2012-07-02 21:18:56 <gmaxwell> disassemble everything?
475 2012-07-02 21:18:56 <jrmithdobbs> the trails are on unsecured areas and will get knocked off if the car moves
476 2012-07-02 21:19:20 <bonks> just pay a pest control dude a few bucks to take away the stress
477 2012-07-02 21:19:29 <jrmithdobbs> gmaxwell: i pulled up the panel i thought they were under only to find out they're not there but using it as an access point to somewhere up under the dash/engine compartment
478 2012-07-02 21:19:43 <jrmithdobbs> so tearing out any more to get more specific gets expensive/hard to store since in an apartment :(
479 2012-07-02 21:19:59 <gmaxwell> can you seal off their path there?
480 2012-07-02 21:20:12 <jrmithdobbs> maybe
481 2012-07-02 21:20:23 <jrmithdobbs> i'll have to look a little closer but i think so
482 2012-07-02 21:20:38 <bonks> silicone works
483 2012-07-02 21:20:45 <jrmithdobbs> think covering the tires (for exit point from the vehicle) in raid or similar would help so they either starve or get poisoned?
484 2012-07-02 21:22:08 <gmaxwell> if they're realy coming from outside and not nesting in the engine compartment someplace... just change where you park.
485 2012-07-02 21:23:29 <jrmithdobbs> gmaxwell: ya, done all the simple stuff, shappoo'ed everything, parking across the parking lot (annoying), not putting matts back in until after it's figured out (since they're clean now), i was just able to roll windows back up since fabric dried
486 2012-07-02 21:23:52 <jrmithdobbs> I'm thinking leave it how it is over night parked somewhere different with the windows rolled up and hope it gets back up to 95ish tonight like it might and kill the bitches
487 2012-07-02 21:24:37 <jrmithdobbs> s/shappoo'ed/shampoo'ed/
488 2012-07-02 21:25:03 <jrmithdobbs> also parked it in direct sunlight to help some
489 2012-07-02 21:25:14 <jrmithdobbs> like, that spot has direct sunlight 80% of the day
490 2012-07-02 21:49:26 <nanotube> jrmithdobbs: that panel that you pulled out - put some slow acting ant poison there, put panel back. ants eat it, take back to nest, nest dies, profit.
491 2012-07-02 21:50:00 <nanotube> and since it's behind the panel, animals can't get in and eat it themselves.
492 2012-07-02 21:50:26 <jrmithdobbs> nanotube: good thinking.
493 2012-07-02 21:50:39 <nanotube> the best poison i find is the liquid-gel stuff that comes in a syringe
494 2012-07-02 21:50:50 <nanotube> iirc called 'combat'
495 2012-07-02 21:51:06 <jrmithdobbs> ya nothing else works on fire ants except some of the liquid/gel ones anyways
496 2012-07-02 21:51:08 <nanotube> just put a bead of that down behind the panel where they walk.
497 2012-07-02 21:51:19 <jrmithdobbs> they say it does, but it doesn't, those things are evil.
498 2012-07-02 21:51:44 <nanotube> hehe dunno about fire ants specifically, but it works on other ants that we've had around here.
499 2012-07-02 21:52:28 <jrmithdobbs> think of the most agressive ant/most painful ant bite you've had, they're about 10x more agressive/painful and much much harder to kill :(
500 2012-07-02 21:52:45 <jrmithdobbs> not as bad as like the bullet ants and stuff in the amazon, but they're tiny and spread like fire
501 2012-07-02 21:53:40 <jrmithdobbs> it was 'wtf?!' when i saw ants in the car, it was 'WTF?!?!WTF?!?!' when i saw they were fire ants :(
502 2012-07-02 21:53:48 <nanotube> heh
503 2012-07-02 21:57:14 <nanotube> if the fire ants are that much different in poison susceptibility than other ants, you might do better to look specifically for fire-ant products. this is where google comes in handy. :)
504 2012-07-02 21:57:29 <jrmithdobbs> nanotube: oh i know what products to use
505 2012-07-02 21:57:43 <jrmithdobbs> nanotube: it was more how/where to apply/etc
506 2012-07-02 21:58:21 <jrmithdobbs> nanotube: i think between yours and gmaxwell's suggestion to strangle the pass, so to speak, i've got a plan of action
507 2012-07-02 21:58:27 <nanotube> ah ic. well, behind the panel is it, i think. :)
508 2012-07-02 21:58:41 <jrmithdobbs> noone i've been asking all day came up with anything as simple/effective ;p
509 2012-07-02 21:58:56 <jrmithdobbs> exterminator told me they'd want to spray the whole thing and make me clean it again :(
510 2012-07-02 21:58:58 <nanotube> you don't want to strangle the pass /and/ put poison there - because if strangling is effective, they'll find another way in and miss the poison.
511 2012-07-02 21:59:18 <sipa> this is certainly not the most common type of discussion here :)
512 2012-07-02 21:59:36 <nanotube> try the poison first and give it a few days, if that has no effect, then you can try resorting to physical barriers.
513 2012-07-02 21:59:38 <jrmithdobbs> nanotube: yes, but i can narrow it so it's only an exit from where they're going instead of to the rest of the frame of the car and put the bait in the narrowed section
514 2012-07-02 21:59:44 <sipa> maybe they're talking about some ant colony optimization algorithm for improving network connectivity?
515 2012-07-02 21:59:49 <nanotube> sipa: er... i mean... try installing bdb 4.8 :)
516 2012-07-02 22:00:04 <sipa> nanotube: i'm not complaining :)
517 2012-07-02 22:00:09 <nanotube> heh
518 2012-07-02 22:00:30 <jrmithdobbs> sipa: heh, sorry, frustrated and running out of people to ask, everyone seems to find it an interesting topic, this is the first time anyone's had helpful ideas though ;p
519 2012-07-02 22:01:01 <jrmithdobbs> sipa: there's ants in my (fuckin) car if you missed that part, lol
520 2012-07-02 22:01:06 <sipa> meh, as long as nobody has real dev talk to do here, i don't really care :)
521 2012-07-02 22:02:11 <jrmithdobbs> sipa: setting up an onion-accessible node has taught me that i have way too many personal cpus
522 2012-07-02 22:02:22 <sipa> heh
523 2012-07-02 22:02:40 <jrmithdobbs> Found matching domain after 41971237735 tries: deezbtcqqbzngaee.onion
524 2012-07-02 22:02:48 <jrmithdobbs> (not up right this second)
525 2012-07-02 22:03:22 <jrmithdobbs> (was running on ~10 boxes so the search domain is 20x too, ha)
526 2012-07-02 23:39:14 <gribble> New news from bitcoinrss: TheBlueMatt opened issue 1550 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1550>