1 2012-05-20 00:01:43 <BlueMatt> the chain can be the bug itself either way?
  2 2012-05-20 00:01:59 <BlueMatt> s/bug/hub/
  3 2012-05-20 00:02:14 <sipa> yeah, true
  4 2012-05-20 00:02:50 <sipa> except if you want to have nodes communicate over an internal network
  5 2012-05-20 00:03:01 <sipa> in that case, those other nodes need to run a blockchainless hub
  6 2012-05-20 00:03:56 <BlueMatt> wait, are you saying 1 p2p client, multiple chains, multiple wallets?
  7 2012-05-20 00:04:04 <sipa> no
  8 2012-05-20 00:04:20 <BlueMatt> define nodes, in this case
  9 2012-05-20 00:04:24 <sipa> any number of p2p clients, one chain, any number of wallets
 10 2012-05-20 00:04:27 <sipa> nodes = machines
 11 2012-05-20 00:04:57 <sipa> each node would have its own hub, and the hubs exchange messages with eachother
 12 2012-05-20 00:05:04 <BlueMatt> why do you need a chainless hub?
 13 2012-05-20 00:05:26 <BlueMatt> or, each node has a proxy hub, which just forwards requests to the real blockstore hub?
 14 2012-05-20 00:05:36 <BlueMatt> ^ the design goal, in the end, is to support that
 15 2012-05-20 00:05:39 <sipa> yes, i call both hubs
 16 2012-05-20 00:05:49 <BlueMatt> oh
 17 2012-05-20 00:05:57 <sipa> and if the chain is a regular hub client, that's trivial
 18 2012-05-20 00:06:11 <sipa> if the chain is special, there is a different between real hub and proxy hub
 19 2012-05-20 00:07:05 <jgarzik> well
 20 2012-05-20 00:07:40 <sipa> but that doesn't really matter right now
 21 2012-05-20 00:07:50 <BlueMatt> that gets significantly messier, though, what if you have two chain clients with different chains? and if you require only one chain-storing hub client, how is that different from a hub that contains a chain?
 22 2012-05-20 00:07:51 <jgarzik> personally I think BlueMatt's idea bout the network is a great one :)  dunno if it is necessarily the best choice for the current client -- though it might be.  long time down the road, though.
 23 2012-05-20 00:08:11 <jgarzik> the reason why I like it in general:  that's how I'm cloud-ifying bitcoin anyway, in a separate project
 24 2012-05-20 00:08:48 <sipa> jgarzik: so, do you now see why you would want to make the p2p service a client to the hub, rather than behind the blockstore?
 25 2012-05-20 00:09:24 <jgarzik> key server is where I store the wallet stuff, though roles are split between generation and storage
 26 2012-05-20 00:09:53 <jgarzik> p2p is based on artforz' half a node, but doesn't do much more than it already does (speak p2p, verify blocks without db assistance)
 27 2012-05-20 00:11:04 <jgarzik> BlueMatt: I would love to see process separation
 28 2012-05-20 00:11:06 <sipa> so, you're against a "kitchen sink", but are building a system where exactly the same services with similar messages all communicate with eachother?
 29 2012-05-20 00:11:46 <luke-jr> jgarzik: where is the main branch to the blockchain upgrade?
 30 2012-05-20 00:11:49 <jgarzik> four little servers each heavily firewalled into their own walled garden is 180 degrees different from a kitchen sink
 31 2012-05-20 00:11:55 <luke-jr> I need to move it after the wallet loading or it crashes
 32 2012-05-20 00:12:59 <jgarzik> luke-jr: the branch chain looks like:  extra-abort -> dbenv -> blockindex.  each is separate pull requests, built on top of one another
 33 2012-05-20 00:13:11 <luke-jr> jgarzik: yes, I mean in the code itself
 34 2012-05-20 00:13:51 <jgarzik> luke-jr: then I am not sure what you mean by "main branch"  the upgrade is initiated in init.cpp, right before -loadblock handling
 35 2012-05-20 00:14:01 <BlueMatt> 
ACTION still fails to see how cblockstore is a kitchen sink, its a chain server + hub to allow wallet/p2p to communicate with the chain server, wallet/p2p never communicate through it (aside from through the chain server part), and the things like callbacks to wallet during chain processing arent there because I like them, they are there because I wanted to keep cblockstore identical to master, for the most part, and then make it clean later
 36 2012-05-20 00:14:39 <luke-jr> aha, found it
 37 2012-05-20 00:14:53 <luke-jr> I was confusing main.cpp with init.cpp somehow, so looking in the wrong file
 38 2012-05-20 00:15:02 <sipa> jgarzik: cblockstore is the chain server; cblockstore's clients will be wallets and p2p nodes - they talk to the chainserver via a very tightly controlled interface
 39 2012-05-20 00:15:39 <sipa> jgarzik: those clients (wallets and p2p nodes) can later potentially be moved to other processes, or other machines
 40 2012-05-20 00:15:47 <jgarzik> cblockstore's clients should be wallet, RPC, UI not P2P
 41 2012-05-20 00:15:56 <jgarzik> if cblockstore == chain server
 42 2012-05-20 00:15:57 <sipa> NO
 43 2012-05-20 00:16:09 <sipa> it is absolutely not about wallet/RPC/UI communication
 44 2012-05-20 00:16:20 <sipa> though a similar design may be useful there
 45 2012-05-20 00:16:21 <moa7> is this something like a block-only node?
 46 2012-05-20 00:16:26 <sipa> but that is another layer entirely
 47 2012-05-20 00:16:52 <luke-jr> http://codepad.org/ZuSdFtUA <-- what i meant, and would prefer to see mainlined @jgarzik @sipa
 48 2012-05-20 00:17:16 <sipa> jgarzik: how can you call it a kitchen sink, but at the same time argue for even more functionality to be routed through it?
 49 2012-05-20 00:18:09 <jgarzik> sipa: I think there are about a dozen parallel sub-arguments at this point
 50 2012-05-20 00:18:10 <BlueMatt> jgarzik: I dont see why p2p cant be a client, it should eventually take no additional api in blockstore.h (though it does currently) to have p2p a client to blockstore, and it takes only a few lines change in p2p code to make it a client, also, making it a client gets rid of some of the ugly global mess, so...
 51 2012-05-20 00:18:26 <jgarzik> luke-jr: why?
 52 2012-05-20 00:19:50 <jgarzik> luke-jr: it makes little sense to put block chain import AFTER functions like wallet rescan, which need a block chain
 53 2012-05-20 00:19:58 <jgarzik> luke-jr: what is the real problem you are seeing?
 54 2012-05-20 00:20:12 <sipa> jgarzik: except for a few things like current block height, i don't see why UI and RPC should be talking to the blockchain at all
 55 2012-05-20 00:20:38 <BlueMatt> jgarzik: thats very unrelated to cblockstore, thats in master, and can be fixed in like 10 minutes...
 56 2012-05-20 00:20:38 <luke-jr> jgarzik: updating the blockchain should update the wallet too
 57 2012-05-20 00:20:55 <luke-jr> jgarzik: the real problem to me, is that my AcceptToMemoryPool accesses my wallet
 58 2012-05-20 00:21:09 <luke-jr> so the first reorg crashes since it isn't loaded
 59 2012-05-20 00:21:25 <jgarzik> sipa: there is no reason why UI and RPC cannot query the block chain for any and all information the user finds useful
 60 2012-05-20 00:21:31 <jgarzik> it's just a database
 61 2012-05-20 00:21:44 <sipa> jgarzik: ok, sure, so connect them to the chain for those
 62 2012-05-20 00:21:56 <sipa> but UI/RPC communication with wallets should not be via the hub
 63 2012-05-20 00:22:24 <sipa> (i assumed that's what you meant by connecting UI and RPC as clients to it, but maybe i misunderstood)
 64 2012-05-20 00:23:02 <sipa> nothing on the hub-network is private, but everything is trusted
 65 2012-05-20 00:23:55 <BlueMatt> Im right behind you, there
 66 2012-05-20 00:24:32 <jgarzik> I think we all do :)  /me was up watching the non-launch at 4:55am local
 67 2012-05-20 00:25:47 <sipa> ok
 68 2012-05-20 00:25:49 <jgarzik> BlueMatt: well at the moment it sounds like I'm outvoted by sipa and gmaxwell...
 69 2012-05-20 00:26:07 <BlueMatt> jgarzik: still, if your code is amazing, votes can change quick ;)
 70 2012-05-20 00:26:28 <sipa> jgarzik: the reason i'm agitated about it, is that it feels like you somehow fail to see the idea behind it
 71 2012-05-20 00:26:39 <luke-jr> XD
 72 2012-05-20 00:27:09 <sipa> while it sounds very much like (the early stage of) the chain server you talk about
 73 2012-05-20 00:27:20 <sipa> but maybe code will clarify :)
 74 2012-05-20 00:27:21 <nanotube> y'all can always sleep on it and reconvene tomorrow. :)
 75 2012-05-20 00:28:15 <BlueMatt> yea...when its starting to get light out, and Im not in bed, I think thats a bad sign
 76 2012-05-20 00:28:36 <sipa> nanotube: good idea!
 77 2012-05-20 00:28:46 <nanotube> :)
 78 2012-05-20 00:51:48 <gmaxwell> I don't think thats splitting the chain and the network will ultimately make sense (what, will you speak the bitcoin p2p network bettween them? :) simply translate protocol to protocol?)   But I don't think thats really a comment on what cblockstore does
 79 2012-05-20 00:52:30 <gmaxwell> You have some hub that splits block and network _internally_ and thats fine. Then only the wallet gets shimmed on a socket.  If later you really do decide that you want to seperate the p2p network, then you're free to or not.
 80 2012-05-20 01:00:10 <gmaxwell> BlueMatt: if you want to have additional security you can run a p2p<->p2p proxy  and in fact I think that the current best practice is to use a node(s) with no coin on it as a bastion host. It's what I do, and I assume everyone doing serious things with bitcoin does too.
 81 2012-05-20 01:00:25 <gmaxwell> doing so strongly insulates you from dos attacks.
 82 2012-05-20 01:05:41 <jgarzik> yes, bastion nodes are standard practice afaik
 83 2012-05-20 01:31:26 <luke-jr> sigh
 84 2012-05-20 01:31:41 <luke-jr> surely there should be a much faster way to upgrade the blockchain than loadblock?
 85 2012-05-20 01:31:49 <luke-jr> ie, skip all verification entirely?
 86 2012-05-20 01:32:22 <luke-jr> maybe even symlink the data file and copy indexes&
 87 2012-05-20 01:34:17 <luke-jr> (in fact, if we save the "last seen position" in blk000x.dat, we can automatically "load" whatever is added by old clients&)
 88 2012-05-20 01:37:02 <gmaxwell> luke-jr: well, we really do want to revalidate it simply because there may be nodes with broken crap in them that we'd like to clean out.
 89 2012-05-20 01:37:34 <gmaxwell> we should however get the validation going as fast as possible.
 90 2012-05-20 01:49:22 <luke-jr> gmaxwell: I think we can revalidate read-only, only building the index&
 91 2012-05-20 01:50:12 <luke-jr> I daresay the best for compatibility is to allow blk0001.dat to be outside the subdirectory, if it already exists, and just put the new index in there
 92 2012-05-20 01:51:11 <gmaxwell> I mean we could just build the index then move it but I don't want to test _two_ sorts of block loading mechenisms.
 93 2012-05-20 01:54:46 <luke-jr> moving it means old versions need to redownload
 94 2012-05-20 01:55:52 <gmaxwell> yes, once the update completes successfully.
 95 2012-05-20 01:55:54 <luke-jr> we could make it so -loadblock simply cat's the file to blk*.dat and uses the load-in-place ;)
 96 2012-05-20 01:56:43 <gmaxwell> load in place would be a very different thing though the purpose of loadblock is to be identical to loading from the network so we can use it to QA and benchmark validation.
 97 2012-05-20 01:56:50 <gmaxwell> a loadblockinplace wouldn't be as good for that.
 98 2012-05-20 01:58:27 <luke-jr> well, loadblock/from-network is almost already load-in-place right now
 99 2012-05-20 01:59:31 <luke-jr> there's just no code to scan data already on disk, rather than data *just written*
100 2012-05-20 01:59:51 <luke-jr> implementing it is pretty much a matter of identifying the position of the block on disk
101 2012-05-20 02:00:24 <luke-jr> (and tolerating blk0001.dat being outside the subdir)
102 2012-05-20 02:02:09 <jgarzik> 05/20/12 03:41:51 InvalidChainFound: invalid block=000000000000050216cd  height=
103 2012-05-20 02:02:10 <jgarzik> 180846  work=329111878961760555018
104 2012-05-20 02:02:19 <jgarzik> something remains screwy in #blockindex
105 2012-05-20 02:03:03 <luke-jr> jgarzik: thoughts on tolerating blk0001.dat in its current location and just reindexing it?
106 2012-05-20 02:05:33 <jgarzik> luke-jr: 3 lines of code to do it this way, or many many untested lines of code to reindex
107 2012-05-20 02:06:42 <luke-jr> shouldn't be that many to reindex, I think
108 2012-05-20 02:08:25 <luke-jr> benefits: much faster upgrade, much less disk space wasted on upgrade, much less having the disk read+write to the same partition, better backward compatibility :p
109 2012-05-20 02:08:56 <jgarzik> luke-jr: some of those benefits exist, yes.  this is known.
110 2012-05-20 02:09:11 <jgarzik> luke-jr: blockchain stuffs are moving to blockchain/ though, including blk????.dat
111 2012-05-20 02:09:34 <luke-jr> jgarzik: no reason not to use blk0001.dat outside that dir, if it already exists&?
112 2012-05-20 02:10:20 <jgarzik> luke-jr: no, we will ONLY use blockchain/blk????.dat
113 2012-05-20 02:10:31 <jgarzik> luke-jr: a proper reindex solution would move said file(s)
114 2012-05-20 02:11:00 <luke-jr> jgarzik: what possible benefit is there that outweighs all the reasons not to?
115 2012-05-20 02:11:08 <luke-jr> afaict, that's just an aesthetic thing
116 2012-05-20 02:12:22 <jgarzik> luke-jr: there are no "all the reasons not to", once file-move is added to equation
117 2012-05-20 02:14:20 <gmaxwell> luke-jr: so what happens if the reindex gets 50% through and fails? should there by 600mb of junk data in the middle of your block file forever?
118 2012-05-20 02:14:27 <luke-jr> file-move completely breaks other versions
119 2012-05-20 02:14:56 <gmaxwell> luke-jr: we're going to delete the old index anyways, I assume, otherise we're going leave many hundreds of megs of junk behind.
120 2012-05-20 02:14:57 <luke-jr> gmaxwell: that's one reason why the block index should keep track of the most recent position it is in the file, so it can scan new data it hasn't seen before
121 2012-05-20 02:15:52 <gmaxwell> luke-jr: we already have a ~bug due to the tracking it already does. ... if you poweroff while syncing you fail on startup because the last block in the index didn't make it onto disk.
122 2012-05-20 02:16:08 <luke-jr> gmaxwell: that's not tracking, it's lack thereof
123 2012-05-20 02:16:31 <gmaxwell> Its tracking just failing to gracefully handle the case when the file is smaller than the 'tracked' size. :)
124 2012-05-20 02:17:24 <gmaxwell> no it's smaller, it tries to seek past the end.
125 2012-05-20 02:17:39 <gmaxwell> It might _also_ have junk, but it doesn't get that far. It seeks and the seek fails.
126 2012-05-20 02:17:57 <luke-jr> gmaxwell: it's smaller in that case;  but what if the filesystem wrote the size/allocation before the new data?
127 2012-05-20 02:18:33 <gmaxwell> We might even handle that case more gracefully.
128 2012-05-20 02:18:53 <luke-jr> anyhow, if moving the block index creates problems switching to older versions, I don't see any reason to do it
129 2012-05-20 02:19:07 <gmaxwell> there is _nothing_ that won't create problems mixing with older versions.
130 2012-05-20 02:19:27 <gmaxwell> even in the most compatible case you're going to waste a ton of diskspace, especially if someone actually starts an older version.
131 2012-05-20 02:19:35 <gmaxwell> (which will then duplicate a bunch of blocks)
132 2012-05-20 02:19:51 <luke-jr> gmaxwell: if the existing index and data is left in place, old versions continue to work&
133 2012-05-20 02:20:26 <gmaxwell> you'll end up with duplicate data any blocks the new downloads will get downloaded again. (even if the new knows to reindex ones the old added)
134 2012-05-20 02:20:50 <luke-jr> not if the new one is using the old index for stuff the old version indexed.
135 2012-05-20 02:20:51 <gmaxwell> better to do the upgrade... and leave the files as an option... and just let new and old have seperate blockchains (don't do the upgrade again if its already done)
136 2012-05-20 02:21:20 <gmaxwell> luke-jr: The old one will append to the end of the blockfile causing duplication. Becuase even if you make the new one smart that doesn't change the old one.
137 2012-05-20 02:21:59 <luke-jr> gmaxwell: the old one will just work with the blocks downloaded by the new one, if the new one continues to use the old index for the same stuff
138 2012-05-20 02:22:46 <luke-jr> is there some problem with the old index itself?
139 2012-05-20 02:22:47 <gmaxwell> luke-jr: it should make the blockchain database faster, by not stuffing everything in one table and making us use a btree index for things that should be hashtables.
140 2012-05-20 02:22:56 <luke-jr> hmm
141 2012-05-20 02:24:30 <luke-jr> OK, yeah, I can't think of a good solution if we really need to abandon the old index and jgarzik is going to do an OS-move on the data file anyway
142 2012-05-20 02:26:01 <jgarzik> luke-jr: no, I was saying only that -if- the solution is import old-bdb to new-bdb directly (it is _not_, currently), then file move would likely be used
143 2012-05-20 02:26:08 <luke-jr> if it takes long, though, we might find users more willing to redownload from scratch than upgrade, since they can still use the client while it downloads
144 2012-05-20 02:26:26 <jgarzik> luke-jr: the current solution works for downgrades as well as upgrades, because the old data is not removed or touched
145 2012-05-20 02:26:46 <jgarzik> luke-jr: any file-move or file-delete scheme kills downgrade
146 2012-05-20 02:27:51 <gmaxwell> jgarzik: have looked to see if the hash table databases are smaller?
147 2012-05-20 02:28:39 <jgarzik> gmaxwell: not yet... still chasing bugs
148 2012-05-20 02:29:43 <luke-jr> hmm
149 2012-05-20 02:29:45 <luke-jr> Reorg failure
150 2012-05-20 02:30:16 <luke-jr> jgarzik: ah, is this stuff not really ready for testing yet?
151 2012-05-20 02:31:05 <jgarzik> luke-jr:  dev testing yes, wide user testing no
152 2012-05-20 02:31:16 <luke-jr> i c
153 2012-05-20 02:31:52 <jgarzik> luke-jr: it would not even be a pull request, except to get review of the general approach ("do we want to do this?")
154 2012-05-20 02:39:36 <jgarzik> Interesting contention about GPUMAX: https://bitcointalk.org/index.php?topic=82560.0
155 2012-05-20 02:40:51 <jgarzik> (I'm not claiming there is -any- evidence, but it has always been theoretical possibility for GPUMAX)
156 2012-05-20 02:51:29 <gmaxwell> jgarzik: well, it's pretty easy to look at the coins that are paid to gpumax users the ones I've seen are old with complicated transaction histories.  I'd just taken that all to be an open secret.
157 2012-05-20 02:52:09 <gmaxwell> What I don't understand is why bitcoin users go along with it. God knows I wouldn't want to be the target of some investigation because I used some coins that had just been run through some undergrouns site.
158 2012-05-20 02:52:39 <gmaxwell> I ... hope ... bitcoin users are smart enough to smell the fishy smell when someone gives you $2 in exchange for giving them $1.
159 2012-05-20 02:58:55 <gmaxwell> interesting: bitcoinica hacker is in #bitcoin giving out 1-2btc to random people.
160 2012-05-20 03:12:21 <jgarzik> gmaxwell: sadly, people seem to feel the need to relearn every in-the-flesh lesson they've ever learn, in the bitcoin virtual-money world
161 2012-05-20 03:12:58 <jgarzik> at least that's my cynical observation over the past couple years...
162 2012-05-20 03:25:43 <gmaxwell> I sense that the need for merging coincontrol has just gone up ten fold.
163 2012-05-20 03:26:06 <copumpkin> lol
164 2012-05-20 04:39:25 <midnightmagic> something that creates a break in the transaction history with an escrow + opentransactions might be able to help with dirty history contamination. it's good in one way that tracking dirty coins is possible, but.. it's not helpful long-term. :-/
165 2012-05-20 05:24:39 <jgarzik> sigh
166 2012-05-20 05:25:21 <jgarzik> block chain download succeeds, continuing past block 173928, on #blockindex
167 2012-05-20 05:25:49 <jgarzik> LoadExternalBlockFile() fails for reasons mentioned previously (blocks after 173928 refuse to connect)
168 2012-05-20 05:25:54 <jgarzik> strange
169 2012-05-20 09:45:01 <sipa> jgarzik: refuse to connect because of what error?
170 2012-05-20 09:46:01 <hazek> anyone in here willing to help out a noob with pgp?
171 2012-05-20 09:46:10 <hazek> well not really a noob
172 2012-05-20 09:46:15 <hazek> but just have 1 small problem
173 2012-05-20 09:48:31 <sipa> hazek: shoot
174 2012-05-20 09:48:45 <hazek> i tried to import a public key
175 2012-05-20 09:48:57 <hazek> I copied the gpg key, made a txt file on my desktop, pasted your key, saved, went into gpg4win, tried to import and it tells me there are no gpg keys in that file
176 2012-05-20 09:49:03 <hazek> did I do something wrong?
177 2012-05-20 09:49:17 <hazek> pasted the pgp key*
178 2012-05-20 09:49:48 <sipa> what is "copied the gpg key" ?
179 2012-05-20 09:50:12 <hazek> someone had it publicly displayed in a thread on the forum
180 2012-05-20 09:50:26 <hazek> so I selected all of it and c/ped it into a txt file
181 2012-05-20 09:50:52 <hazek> isn't that what I'm suppose to do?
182 2012-05-20 09:51:02 <sipa> yes, that should work
183 2012-05-20 09:51:07 <hazek> it doesn't
184 2012-05-20 09:51:20 <hazek> gnu says there was no gpg key found
185 2012-05-20 09:51:41 <sipa> the text file looks like:
186 2012-05-20 09:51:42 <sipa> -----BEGIN PGP PUBLIC KEY BLOCK-----
187 2012-05-20 09:51:44 <sipa> ?
188 2012-05-20 09:51:46 <hazek> yes
189 2012-05-20 10:47:10 <amiller> hey i think i found a good match for bitcoin in the theoretical fault tolerance literature http://courses.csail.mit.edu/6.897/fall04/papers/Dwork/consensus-in-ps.pdf
190 2012-05-20 10:47:40 <amiller> this is the 'partial synchrony' model where there is a fixed upper bound on the delays for messages, but it's not known ahead of time
191 2012-05-20 10:48:22 <amiller> there's a lower bound proof in this paper for 3f+1, or "the 34% attack" in bitcoin speak
192 2012-05-20 10:50:23 <amiller> and bitcoin achieves this bound in this model using only a slight modification, where you store a longest chain for each bit of hash collision (as opposed to having a sliding scale difficulty)
193 2012-05-20 10:59:45 <[Tycho]> What's wrong with sipa's site ?
194 2012-05-20 11:00:50 <sipa> [Tycho]: good question, better ask him!
195 2012-05-20 11:02:28 <BlueMatt> gmaxwell: agreed, whether you use a p2p proxying node (with or without chain) or not, its the same basic idea...but, yea I just dont see the reason to not split up p2p and blockchain in the current system, as they are so easy to split and it makes for cleaner code
196 2012-05-20 11:05:28 <BlueMatt> though, I dont see why a blockstore/hub needs to keep a list of peers, or do any of the 100 other things a p2p client needs to do that a hub/blockstore doesnt
197 2012-05-20 11:08:16 <BlueMatt> anyway, thats far down the road and I dont think its entirely relevant to the current discussion on cblockstore, the split of p2p/blockstore there is more of a "its so easy to do, and makes the code so much cleaner..." kinda thing
198 2012-05-20 11:08:53 <sipa> agree; let's focus in chain-wallets interaction first
199 2012-05-20 11:08:57 <sipa> *on
200 2012-05-20 11:09:51 <sipa> but i don't think it's implementaion-wise hard to make p2p nodes function in almost entirely the same fashion
201 2012-05-20 11:44:16 <Eliel> are there any developments going on about bitcoin foundation?
202 2012-05-20 11:44:53 <BlueMatt> I would ask when gavin is online...
203 2012-05-20 11:44:59 <sipa> gavin started a bitcoin testing fund recently
204 2012-05-20 11:46:01 <BlueMatt> sipa: link?
205 2012-05-20 11:48:31 <sipa> https://bitcointalk.org/index.php?topic=80019
206 2012-05-20 11:56:03 <gribble> New news from bitcoinrss: Diapolo opened pull request 1364 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1364>
207 2012-05-20 12:01:21 <gribble> New news from bitcoinrss: Diapolo opened pull request 1365 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1365>
208 2012-05-20 12:16:36 <BlueMatt> (not using mingw)
209 2012-05-20 12:19:00 <sipa> luke-jr: we have an ugly OFFSETOF macro
210 2012-05-20 12:19:35 <luke-jr> sipa: we do? I don't see one defined
211 2012-05-20 12:19:57 <sipa> hmmm; my memory must be failing me
212 2012-05-20 13:10:02 <Karmaon> /join weechat
213 2012-05-20 13:50:48 <diki> any psj gurus?
214 2012-05-20 13:51:06 <diki> I am trying to make it merge mine, bitcoin as parent, namecoind and ixcoin as child
215 2012-05-20 13:51:30 <diki> but I keep getting stuck at source.local.1.merged.namecoin.chainid and source.local.1.merged.ixcoin.chainid
216 2012-05-20 13:51:39 <diki> No matter what values I put there, I get an error
217 2012-05-20 13:52:03 <diki> it says they must be unique, I make them unique. After that I get an erro saying they must be the same...
218 2012-05-20 14:31:56 <Bigpiggy01Mining> coderrr You around?
219 2012-05-20 14:55:13 <sipa> BlueMatt, jgarzik: i upgraded bitcoin.sipa.be to IPv6; address: [2a02:348:5e:5a29::1]
220 2012-05-20 15:23:08 <jgarzik> sipa: (just to be clear) that means I can add it to bitseed.xf2 long term?
221 2012-05-20 15:25:32 <user> Hi I think the bitcoin gui developer should look at safebit design: https://www.dropbox.com/sh/ckcmvo36bwusfe0/pg7cF3ubsR#/
222 2012-05-20 15:26:04 <Joric> my eyes!
223 2012-05-20 15:26:15 <user> I really liked it. It has left menu and tab
224 2012-05-20 15:26:31 <Joric> i liked first version more
225 2012-05-20 15:27:08 <user> the send coins, receive coins, it's not on menu. it's on window
226 2012-05-20 15:27:10 <Joric> anyway it doesnt fit OS gui guidelines
227 2012-05-20 15:27:17 <t7> safebit to amazon
228 2012-05-20 15:27:18 <user> hum
229 2012-05-20 15:27:20 <t7> thats awesome
230 2012-05-20 15:27:40 <t7> was totally my idea but i dont mind
231 2012-05-20 15:27:54 <user> wow
232 2012-05-20 15:28:34 <user> hope to bitcoin gui follow safebit design
233 2012-05-20 15:28:47 <user> just a suggestion
234 2012-05-20 15:29:38 <user> who is responsibly for bitcoin gui?
235 2012-05-20 15:29:56 <t7> mr bitcoin himself
236 2012-05-20 15:30:25 <user> tcatm, wumpus?
237 2012-05-20 15:31:15 <Joric> whoa https://bitcointalk.org/index.php?topic=77129.0 Safebit is looking for a Javascript Developer for Full Time The payment will be $1,000 every month, paid via Bitcoin or your method of choice (not including PayPal).
238 2012-05-20 15:31:44 <Joric> and i'm working on that https://bitcointalk.org/index.php?topic=80815.0 for 25 btc? fuck that
239 2012-05-20 15:32:49 <Joric> btw safebit could use electrum api to get rid of bitcoind
240 2012-05-20 15:33:09 <sipa> jgarzik: yes
241 2012-05-20 15:36:25 <gmaxwell> user: wumpus is for the most part.
242 2012-05-20 15:37:14 <Joric> not sure why but latest safebit won't connect to daemon anyone confirm
243 2012-05-20 15:37:38 <Joric> have to look into the code
244 2012-05-20 15:37:52 <gmaxwell> user: er, .. it has an integrated webbrowser? sounds like a great way to get robbed.
245 2012-05-20 15:38:04 <gmaxwell> I think it looks pretty attractive though.
246 2012-05-20 15:38:14 <gmaxwell> Tcatm's proposed gui changes would get us closer to that.
247 2012-05-20 15:38:21 <Joric> gmaxwell, it's a google chrome app atm
248 2012-05-20 15:39:09 <user> gmaxwell: I'm just a simple user. just liked the gui of safebit
249 2012-05-20 15:39:10 <Joric> git clone https://github.com/elis/Safebit.git , chrome -> extensions -> developer mode -> load unpacked extension
250 2012-05-20 15:39:38 <gmaxwell> http://188.138.99.157/stuff/qtvert17.png
251 2012-05-20 15:39:53 <user> gmaxwell: where it is tcatm's proposal?
252 2012-05-20 15:40:01 <user> ok
253 2012-05-20 15:40:12 <gmaxwell> Thought personally I think I liked version 14 better, http://188.138.99.157/stuff/qtvert14.png
254 2012-05-20 15:40:20 <Joric> heard mac users hate, even HATE anything that doesn't look like their gayos
255 2012-05-20 15:41:05 <jgarzik> sipa gmaxwell: just updated https://github.com/bitcoin/bitcoin/pull/1303 with a blockchain/*.dat status report.  it includes two pastebins:  (1) disk space usage comparison, and (2) debug.log output for the problems at height 173928 during block import
256 2012-05-20 15:41:24 <jgarzik> you two had requested one or both of those pastebins
257 2012-05-20 15:42:05 <user> gmaxwell: i didn't like it. for me the send coin, receive coin, should be button on window. not on sidebar
258 2012-05-20 15:42:32 <user> gmaxwell: and we should have tabs on top too
259 2012-05-20 15:43:13 <gmaxwell> user: well we do now, and the interface is a bit confusing.
260 2012-05-20 15:43:28 <gmaxwell> (or at least I've had trouble actually directing people to the different tabs.
261 2012-05-20 15:43:31 <gmaxwell> )
262 2012-05-20 15:45:00 <user> each one likes different things. just want to let my opinion here. i really liked safebit interface
263 2012-05-20 15:45:23 <jgarzik> sipa: bitseed.xf2.org updated with its first AAAA record!
264 2012-05-20 15:46:41 <Joric> user, i just used context menu for everything :) http://img33.imageshack.us/img33/8554/screenshot2012052023451.png
265 2012-05-20 15:49:11 <user> joric: crazy thing
266 2012-05-20 15:51:28 <sipa> jgarzik: are you running with a modified P2SH changeover date?
267 2012-05-20 15:55:31 <sipa> jgarzik: wait... that error at 173928; does it continue normally afterwards, or does it get stuck there?
268 2012-05-20 15:55:52 <jgarzik> sipa: it gets stuck there
269 2012-05-20 15:56:05 <jgarzik> sipa: every block afterwards is thought invalid due to connectblock failure
270 2012-05-20 15:56:17 <sipa> also blocks downloaded from the network?
271 2012-05-20 15:56:54 <jgarzik> 05/20/12 16:55:03 ERROR: Reorganize() : ConnectBlock 00000000000008b193b9 failed
272 2012-05-20 15:56:56 <jgarzik> 05/20/12 16:55:03 ERROR: SetBestChain() : Reorganize failed
273 2012-05-20 15:56:58 <jgarzik> 05/20/12 16:55:03 ERROR: AcceptBlock() : AddToBlockIndex failed
274 2012-05-20 15:57:00 <jgarzik> 05/20/12 16:55:03 ERROR: ProcessBlock() : AcceptBlock FAILED
275 2012-05-20 15:57:02 <jgarzik> 05/20/12 16:55:03 Postponing 6988 reconnects
276 2012-05-20 15:57:08 <sipa> outch
277 2012-05-20 15:57:09 <jgarzik> sipa: note "6988" (the number of blocks that failed after 173928)
278 2012-05-20 15:57:14 <jgarzik> sipa: network works!
279 2012-05-20 15:57:17 <sipa> yes, i noticed
280 2012-05-20 15:57:30 <jgarzik> sipa: so this is only load block import
281 2012-05-20 15:57:35 <jgarzik> *local
282 2012-05-20 15:57:37 <sipa> wait... it reconnects afterwards just fine?
283 2012-05-20 15:57:46 <BlueMatt> sipa: thanks, Ill let jgarzik add it to his seed, and leave it off mine (no reason to duplicate), anyway...need to upgrade to your seed thing, Im assuming it supports ipv6?
284 2012-05-20 15:58:01 <jgarzik> sipa: for LoadExternalBlockFile() import, the node is permanently stuck at 173928
285 2012-05-20 15:58:01 <sipa> BlueMatt: not yet, no
286 2012-05-20 15:58:22 <BlueMatt> ah, well it can wait until we release 0.7 anyway...
287 2012-05-20 15:58:29 <jgarzik> sipa: for network import, the node is 100% OK, and continues to stay at correct block height, importing new blocks as they appear on the network
288 2012-05-20 15:58:32 <Tykling> is there a fix for the 100% cpu use on freebsd issue ? running the 0.6.2 release
289 2012-05-20 15:58:57 <sipa> Tykling: yes, use 0.6.2.2, and change the #ifdef MAC_OSX to BSD
290 2012-05-20 15:59:09 <sipa> Tykling: in sync.h
291 2012-05-20 15:59:15 <jgarzik> I'm about to try importing a blk0001.dat from a different source.
292 2012-05-20 15:59:16 <sipa> near class CSemaphore
293 2012-05-20 15:59:17 <Tykling> sipa: okay, thanks
294 2012-05-20 15:59:24 <BlueMatt> sipa: should we apply that to master too?
295 2012-05-20 15:59:39 <sipa> BlueMatt: master has a much better solution already
296 2012-05-20 15:59:49 <BlueMatt> oh, I thought it was the same, nvm
297 2012-05-20 15:59:56 <Tykling> when will the next release be made ? 0.6.3 I assume ?
298 2012-05-20 16:00:12 <sipa> Tykling: most likely, the next will be 0.7.0, but it could still take a while
299 2012-05-20 16:00:31 <sipa> jgarzik: yes, ok, so during loadexternal, you don't make any progress; but does it get fixed if you connect to network after loadexternal?
300 2012-05-20 16:00:35 <Tykling> okay, so waiting for the next release is not an option :>
301 2012-05-20 16:00:47 <jgarzik> sipa: importing the same blk0001.dat on #master does not get stuck
302 2012-05-20 16:01:03 <jgarzik> sipa: no, not fixed following loadexternal
303 2012-05-20 16:01:34 <jgarzik> sipa: node is permanently stuck at 173928.  restart does not cure, either.
304 2012-05-20 16:01:50 <jgarzik> it successfully connects to the network following LoadExternalBlockFile()
305 2012-05-20 16:02:36 <sipa> jgarzik: what does -checkblocks -checklevel=6 reveal?
306 2012-05-20 16:04:29 <jgarzik> sipa: will answer that question after several hours :)
307 2012-05-20 16:04:45 <jgarzik> sipa: just blew away data, to try importing new blk0001.dat
308 2012-05-20 16:05:04 <jgarzik> a fresh network download of blk0001.dat
309 2012-05-20 16:05:45 <jgarzik> I'm also uploading the blk0001.dat that causes problems
310 2012-05-20 16:06:14 <jgarzik> eu1.bitcoincharts.com block chains are full of orphans, because it was a really old version
311 2012-05-20 16:06:25 <jgarzik> good test data, as gmaxwell noted :)
312 2012-05-20 16:06:59 <BlueMatt> Id think tcatm could save some nice bw if he fixed that, though...
313 2012-05-20 16:07:02 <sipa> jgarzik: wait... what?
314 2012-05-20 16:07:23 <sipa> jgarzik: loading that blk0001.dat file works fine on master, but fails on... which branch?
315 2012-05-20 16:09:01 <jgarzik> sipa: #blockindex, the branch that splits blkindex.dat into multiple files.  The branch that I've been working on for several days, and talking about in IRC :)
316 2012-05-20 16:09:02 <gmaxwell> sipa: jeff's crazy database structure change branch.
317 2012-05-20 16:09:32 <sipa> jgarzik: ok, so you clearly didn't only refactor code :)
318 2012-05-20 16:09:42 <sipa> jgarzik: yes, i've already tested it myself too
319 2012-05-20 16:09:55 <sipa> didn't seem faster than master, by the way
320 2012-05-20 16:10:34 <jgarzik> sipa: #dbenv works (encapsulate dbenv), but the #blockindex split does not.  I -thought- it was only a refactor ;-)
321 2012-05-20 16:10:43 <jgarzik> but apparently some bugs snuck in somewhere
322 2012-05-20 16:13:12 <sipa> jgarzik: your cross-db transactions, passed around in that DbTxn* variable
323 2012-05-20 16:13:16 <sipa> do you use it anywhere?
324 2012-05-20 16:14:13 <sipa> jgarzik: i see you creating it, and doing commit and abort on it
325 2012-05-20 16:14:21 <sipa> but are the actual reads and writes done using it?
326 2012-05-20 16:16:42 <sipa> put differently: does that created cross-db DbTxn* ever end up in any activeTxn?
327 2012-05-20 16:17:40 <jgarzik> sipa: hmmm, a good point
328 2012-05-20 16:18:35 <jgarzik> sipa: can't look at code this second, but that does sound like something I failed to change
329 2012-05-20 16:18:52 <sipa> i think you're just doing every single database write as a separate transaction, instead of using the created DbTxn
330 2012-05-20 16:19:11 <sipa> which would mean your database would get corrupted on the first reorganize
331 2012-05-20 16:19:25 <sipa> actually, no, on the first failed block connect
332 2012-05-20 16:25:54 <jgarzik> sipa: yeah
333 2012-05-20 16:26:01 <jgarzik> sipa: good spotting
334 2012-05-20 16:26:43 <jgarzik> that could also impact the fill factor and speed significantly, absent any reorg
335 2012-05-20 16:26:54 <sipa> indeed
336 2012-05-20 16:27:13 <sipa> already have an ipv6 connection
337 2012-05-20 16:35:57 <luke-jr> sipa: https://bitcointalk.org/?topic=82610.msg910815#msg910815
338 2012-05-20 16:41:34 <gavinandresen> hmm
339 2012-05-20 16:41:47 <gavinandresen> I swore this would make nickserv complain at me
340 2012-05-20 16:42:25 <gavinandresen> hm
341 2012-05-20 16:42:29 <luke-jr> gavinandresen: I think NickServ tracks identities across rename
342 2012-05-20 16:42:35 <sipa> it does
343 2012-05-20 16:42:42 <BTC_Bear> Isn't there a 30 sec wait?
344 2012-05-20 16:42:49 <luke-jr> [18:42:32] [Whois] gavinandresen is logged in as Graingert.
345 2012-05-20 16:42:56 <luke-jr> BTC_Bear: only if you set enforce
346 2012-05-20 16:43:04 <BTC_Bear> SET ENFORCE ON ah...
347 2012-05-20 16:43:53 <luke-jr> more annoyingly, I realize I believe he was gavin until I /whois'd
348 2012-05-20 16:44:54 <graingert_> so I'm planing on pushing a new HEAD onto bitcoin/bitcoin
349 2012-05-20 16:45:00 <BlueMatt> sipa: do we use (if available) windows' (very, very terrible) "private" ipv6 feature where it rotates ipv6 addresses every n hours (is it on reboot? or 24 hours?)
350 2012-05-20 16:45:02 <BTC_Bear> Didn't we do that like a year ago? I thought everybody did.
351 2012-05-20 16:45:15 <BlueMatt> sipa: though it shouldnt exist, its probably something we should use
352 2012-05-20 16:45:17 <gavinandresen> so I'm planing on pushing a new HEAD onto bitcoin/bitcoin
353 2012-05-20 16:45:17 <sipa> BlueMatt: you mean teredo?
354 2012-05-20 16:45:21 <BlueMatt> sipa: no
355 2012-05-20 16:45:21 <luke-jr> BlueMatt: err, what? that's standard
356 2012-05-20 16:45:32 <BlueMatt> luke-jr: no, standard is using your mac encoded in an ipv6
357 2012-05-20 16:45:43 <BlueMatt> sipa: windows creates two ipv6 addresses for itself
358 2012-05-20 16:45:55 <BlueMatt> sipa: one is the standard mac-encoded one, one is entirely random
359 2012-05-20 16:45:56 <luke-jr> BlueMatt: RFC 4941
360 2012-05-20 16:46:00 <luke-jr> Privacy Extensions for Stateless Address Autoconfiguration in IPv6
361 2012-05-20 16:46:14 <BlueMatt> ewwww, they made it standard...yuck
362 2012-05-20 16:46:15 <luke-jr> Linux supports it too
363 2012-05-20 16:46:23 <Dagger2> BlueMatt: it adds a new address every 24 hours, and keeps the last 7 addresses. I'm not sure what happens if an address gets to a week old and it's still being used for an active connection (it would be nice if it kept the address until it wasn't needed, but it might just terminate the connection)
364 2012-05-20 16:46:28 <BlueMatt> yea, but doesnt use it by default, I hope
365 2012-05-20 16:46:33 <Dagger2> and Linux supports privacy addresses too, but not by default
366 2012-05-20 16:46:47 <BlueMatt> yea, thought so
367 2012-05-20 16:46:56 <BlueMatt> I mean, ofc linux supports it, it supports everything...
368 2012-05-20 16:47:00 <luke-jr> in any case, IMO, Bitcoin should just let the OS manage that aspect..
369 2012-05-20 16:47:06 <Dagger2> except in recent NetworkManager versions (e.g. latest Ubuntu), which do turn it on by default
370 2012-05-20 16:47:14 <BlueMatt> yuck
371 2012-05-20 16:47:33 <sipa> well, whatever local address is detected, is used
372 2012-05-20 16:47:39 <BlueMatt> hmm...Im on debian testing networkmanager, and its mac-encoded
373 2012-05-20 16:47:53 <sipa> and it tries to listen on [::]:8333, so it would receive incoming connections
374 2012-05-20 16:48:08 <BlueMatt> sipa: I guess my question is, does windows use its private ipv6 crap by default, and if not, we should
375 2012-05-20 16:48:26 <sipa> i don't care, and i don't think we should try to deal with it specially
376 2012-05-20 16:48:35 <sipa> well, i do care
377 2012-05-20 16:49:10 <Xeranos> I'm using private testnet from http://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/, getbalance show 3650 BTC, why my balance is still 0 when I use listreceivedbyaddress ? http://pastebin.com/SB8khwQg
378 2012-05-20 16:49:51 <BlueMatt> sipa: mmm, ok, fair enough
379 2012-05-20 16:50:31 <sipa> i doubt autoconfigured addresses will often be routable to the internet
380 2012-05-20 16:50:48 <BlueMatt> luke-jr: that rfc states that the design is for use when you dont have a mac address or other 64-bit interface identifier
381 2012-05-20 16:50:55 <luke-jr> Xeranos: because mined coins use hidden addresses
382 2012-05-20 16:51:01 <BlueMatt> sipa: huh?
383 2012-05-20 16:51:04 <luke-jr> BlueMatt: interesting
384 2012-05-20 16:51:15 <luke-jr> sipa: wtf?
385 2012-05-20 16:52:16 <sipa> i must be confusing autoconfigured with private
386 2012-05-20 16:52:30 <BlueMatt> luke-jr: well, it says it is designed to address that issue, though it indicates that it can be used with mac addresses
387 2012-05-20 16:52:53 <sipa> windows uses that address-switching technique also in a network when a RA is present?
388 2012-05-20 16:53:18 <BlueMatt> it can only use it in a system where ra is present
389 2012-05-20 16:53:25 <sipa> ah
390 2012-05-20 16:53:28 <BlueMatt> I dont know/think it can in dhcpv6 environments
391 2012-05-20 16:53:28 <luke-jr> sipa: so thoughts on WinXP issue?
392 2012-05-20 16:53:43 <luke-jr> isn't DHCPv6 just to delegate subnets?
393 2012-05-20 16:54:00 <sipa> luke-jr: i think it just complains that it cannot bind to [::]:8333, but the message shouldn't be fatal
394 2012-05-20 16:54:04 <BlueMatt> luke-jr: no that ra
395 2012-05-20 16:54:31 <BlueMatt> dhcpv6 is used because ra doesnt announce dns servers (though I think it can, but afaict its not used, by default...and....)
396 2012-05-20 16:54:34 <luke-jr> sipa: sounds like it is?
397 2012-05-20 16:54:39 <sipa> luke-jr: clearly, it shouldn't complain at all, unless it cannot bind anywhere
398 2012-05-20 16:56:01 <BlueMatt> /kick graingert nick spam
399 2012-05-20 16:56:09 <graingert_> :
400 2012-05-20 16:56:17 <graingert_> I thought this chan had that turned off
401 2012-05-20 16:56:28 <BlueMatt> dont think thats an option
402 2012-05-20 16:56:34 <BlueMatt> its an option in clients to hide it, though
403 2012-05-20 16:56:39 <gribble> Error: "bc,blocka" is not a valid command.
404 2012-05-20 16:56:39 <sipa> ;;bc,blocka
405 2012-05-20 16:56:40 <sipa> ;;bc,blocks
406 2012-05-20 16:56:41 <gribble> 180940
407 2012-05-20 16:56:47 <graingert_> I believe rooms can recomend that option
408 2012-05-20 16:56:51 <BlueMatt> ah
409 2012-05-20 16:56:53 <graingert_> recommend
410 2012-05-20 16:56:56 <graingert_> eg ubuntu
411 2012-05-20 16:57:07 <luke-jr> nope
412 2012-05-20 17:07:23 <graingert> oh really
413 2012-05-20 17:07:31 <graingert> in that case I no longer believe that, luke-jr
414 2012-05-20 17:10:15 <luke-jr> to clarify, I know it isn't part of the standard for the IRC protocol
415 2012-05-20 17:11:41 <Xeranos> [private testnet] hmm, why the confirmation still show as 0 ? how do I raise the number of confirmation ? http://pastebin.com/0qMJM8Pb
416 2012-05-20 17:12:00 <BlueMatt> more blocks?
417 2012-05-20 17:12:08 <BlueMatt> how many blocks do you have?
418 2012-05-20 17:12:22 <graingert> I have many blocks
419 2012-05-20 17:12:24 <luke-jr> sipa: IMO, show an error if: A) the system has at least one globally-routable address, but binding it (or [::]) fails; B) the system only has loopback addresses, or C) only loopback addresses could be bound
420 2012-05-20 17:12:32 <BlueMatt> graingert: not you...
421 2012-05-20 17:12:34 <luke-jr> sipa: and the error shown should be the one from the attempt to bind [::]
422 2012-05-20 17:13:04 <graingert> mgRdSJDFp7pKeQc3yPdmtVf6hL3az2PcjJ ?
423 2012-05-20 17:13:18 <Xeranos> 193 block so far
424 2012-05-20 17:13:20 <graingert> why is that not an address?
425 2012-05-20 17:13:30 <graingert> !bc,blocks
426 2012-05-20 17:13:30 <luke-jr> Xeranos: ouch, why so slow?
427 2012-05-20 17:13:31 <gribble> 180942
428 2012-05-20 17:13:32 <sipa> graingert: it is
429 2012-05-20 17:13:35 <luke-jr> Xeranos: dialup?
430 2012-05-20 17:13:36 <BlueMatt> Xeranos: odd...should have shown up with 120 blocks
431 2012-05-20 17:13:36 <graingert> sipa, ?
432 2012-05-20 17:13:41 <BlueMatt> hes on testnet in a box
433 2012-05-20 17:13:42 <graingert> sipa, what type of block?
434 2012-05-20 17:13:44 <sipa> graingert: testnet addresses don't start with 1
435 2012-05-20 17:13:46 <graingert> ahh
436 2012-05-20 17:13:50 <graingert> drup
437 2012-05-20 17:13:50 <luke-jr> oh!
438 2012-05-20 17:13:53 <luke-jr> missed that
439 2012-05-20 17:14:00 <graingert> yeah testnet
440 2012-05-20 17:14:03 <BlueMatt> sipa: testnet in a box doesnt start at 1?
441 2012-05-20 17:14:10 <sipa> BlueMatt: no
442 2012-05-20 17:14:18 <sipa> BlueMatt: it has some premined blocks
443 2012-05-20 17:14:26 <BlueMatt> how many?
444 2012-05-20 17:14:36 <graingert> #testnet is probably where you want to go for that
445 2012-05-20 17:14:38 <graingert> ;)
446 2012-05-20 17:14:54 <BlueMatt> we have a #testnet?????wtf?
447 2012-05-20 17:15:07 <sipa> luke-jr: i think i'll do this: show an error if both of the default binds ([::]:8333 and 0.0.0.0:8333), or if any explicit -bind= fails
448 2012-05-20 17:15:18 <sipa> +fail
449 2012-05-20 17:15:25 <graingert> BlueMatt, no someone else has regsistered
450 2012-05-20 17:15:26 <graingert> it
451 2012-05-20 17:15:30 <luke-jr> sipa: sounds good
452 2012-05-20 17:16:35 <graingert> sipa, can bitcoin use other ports?
453 2012-05-20 17:16:52 <graingert> UPNP
454 2012-05-20 17:16:59 <graingert> ie if it can't UPNP *
455 2012-05-20 17:17:08 <Xeranos> I'm using the data from http://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/, in the wallet it has 3650 btc and start at 195 blocks.
456 2012-05-20 17:17:20 <luke-jr> sipa: actually, maybe it shouldn't warn even if it fails to listen&
457 2012-05-20 17:17:27 <luke-jr> sipa: since there could always be a firewall interfering
458 2012-05-20 17:17:39 <sipa> luke-jr: firewalls won't prevent you from listening
459 2012-05-20 17:17:42 <luke-jr> (or maybe just for -bind
460 2012-05-20 17:17:43 <graingert> luke-jr, should read some of the torrent client code as they do a bunch of changes
461 2012-05-20 17:17:44 <sipa> just from receiving anything
462 2012-05-20 17:17:49 <luke-jr> sipa: right, but it has the same effect
463 2012-05-20 17:17:52 <graingert> checks*
464 2012-05-20 17:18:15 <sipa> luke-jr: failing to bind either means something else is already listening on that port, or the network layer doesn't exist
465 2012-05-20 17:18:18 <luke-jr> sipa: with that in mind, I suspect it makes more sense to just amend the Connections tooltip thing
466 2012-05-20 17:18:34 <luke-jr> sipa: or the user doesn't have permission to listen on the port?
467 2012-05-20 17:18:40 <graingert> sipa, what happens if another user is using bitcoin on the box?
468 2012-05-20 17:18:48 <graingert> can bitcoin shift to another port
469 2012-05-20 17:18:53 <sipa> sure, -port=
470 2012-05-20 17:19:08 <luke-jr> I think he meant automatically ;P
471 2012-05-20 17:19:10 <graingert> sipa, no dynamically
472 2012-05-20 17:19:11 <graingert> ^
473 2012-05-20 17:19:18 <sipa> maybe later
474 2012-05-20 17:19:55 <sipa> but failing to bind (on 0.0.0.0:8333) has always caused a fatal error; i wouldn't change that right now
475 2012-05-20 17:21:11 <graingert> :(
476 2012-05-20 17:21:29 <luke-jr> sipa: if [::] succeeds, 0.0.0.0 fails sometimes
477 2012-05-20 17:21:39 <graingert> you should probably try dual stack
478 2012-05-20 17:21:49 <graingert> with happy eyeballs
479 2012-05-20 17:22:02 <sipa> luke-jr: yes, therefore it should only complain if both fail
480 2012-05-20 17:22:11 <graingert> sipa, and it should try both
481 2012-05-20 17:22:16 <sipa> graingert: it does
482 2012-05-20 17:22:21 <graingert> and it should maintain both
483 2012-05-20 17:22:45 <sipa> luke-jr: but we use IPV6_V6ONLY on supported systems, and others typically have it as non-configurable property anyway
484 2012-05-20 17:28:26 <copumpkin> gmaxwell: I'm trying to convince Nathan Burney (the lawyer who writes that comic you linked to) to accept bitcoin donations. He says he's considered it and just wants conversion to be a little easier
485 2012-05-20 17:29:33 <nathan7> hrmpf
486 2012-05-20 17:29:43 <nathan7> There are too many nathans on this planet
487 2012-05-20 17:30:13 <sipa> nah, just one too many
488 2012-05-20 17:30:15 <sipa> ;)
489 2012-05-20 17:33:40 <sipa> luke-jr: i don't think i know enough about it to judge
490 2012-05-20 17:34:25 <luke-jr> sipa: eh, it's already ACK'd by jgarzik, you, forrestv, etc <.<
491 2012-05-20 17:43:39 <luke-jr> sipa: 660ff17 Use boost::thread locking instead of interprocess <-- did this fix something?
492 2012-05-20 17:43:54 <gmaxwell> luke-jr: why did the decomposition stuff end up in BIP22?
493 2012-05-20 17:44:11 <luke-jr> gmaxwell: ?
494 2012-05-20 17:44:30 <luke-jr> it's not really decomposition in BIP22 context, but code reuse was handy
495 2012-05-20 17:45:13 <sipa> luke-jr: it's an alternative solution to the 100% issue on OSX and BSD, without workaround code for those
496 2012-05-20 17:45:58 <Diapolo> What are you guys discussing?
497 2012-05-20 17:46:18 <sipa> Diapolo: #936
498 2012-05-20 17:50:07 <gmaxwell> luke-jr: I mean that you can change the format of the responses, seems a bit needlessly complicated to me I don't mind but it might make life harder on other server implementors.
499 2012-05-20 17:50:36 <luke-jr> gmaxwell: see PM
500 2012-05-20 17:52:35 <Diapolo> too much magic for me ;)
501 2012-05-20 17:57:34 <jgarzik> 171,300
502 2012-05-20 18:00:19 <jgarzik> 172,400
503 2012-05-20 18:09:33 <gmaxwell> copumpkin: it's a legit concern but if it brings him funds he wouldn't otherwise get, why would it matter if he takes N months to get around to cashing them out?
504 2012-05-20 18:09:49 <gmaxwell> copumpkin: if it's free money might as well save to use for alpaca socks.
505 2012-05-20 18:13:39 <copumpkin> yup :)
506 2012-05-20 18:18:06 <jgarzik> fixed!
507 2012-05-20 18:18:14 <jgarzik> boy, that was a dumb bug
508 2012-05-20 18:19:54 <gmaxwell> oh?
509 2012-05-20 18:20:24 <Diapolo> nice I'm connected to 6 nodes via IPv6
510 2012-05-20 18:20:56 <luke-jr> gmaxwell: I don't get why Trog is guilty tho - assuming he didn't know when he signed on that they were criminals
511 2012-05-20 18:23:01 <Joric> who's Trog damnit
512 2012-05-20 18:23:14 <luke-jr> http://thecriminallawyer.tumblr.com/post/21826668142/14-duress
513 2012-05-20 18:23:32 <luke-jr> also, I suspect some of these are wrong for Florida
514 2012-05-20 18:25:44 <gmaxwell> luke-jr: I suspect that the assumption there was that he knew or should have known that they were a gang of thugs.
515 2012-05-20 18:26:13 <t7> wall of comic
516 2012-05-20 18:26:15 <t7> tldr
517 2012-05-20 18:26:29 <sipa> jgarzik: looks good; i'll benchmark it again soon
518 2012-05-20 18:26:43 <gmaxwell> e.g. if it was the young ladies sewing club it would be another matter and yes, somethings differ from state to state (though the consistency is pretty good)
519 2012-05-20 18:27:50 <luke-jr> gmaxwell: pretty sure I can kill to protect random strangers here
520 2012-05-20 18:32:10 <andytoshi> does anyone here have experience doing OSS on windows?
521 2012-05-20 18:32:17 <andytoshi> or does everything just use mingw?
522 2012-05-20 18:33:14 <gmaxwell> andytoshi: there are things that target MSVC too..
523 2012-05-20 18:33:24 <gmaxwell> it's certantly easier to use mingw, esp as you can then crosscompile.
524 2012-05-20 18:37:08 <luke-jr> andytoshi: MingW *is* OSS on Windows
525 2012-05-20 18:40:32 <Diapolo> sipa: Can you point me to the file, where the block-chain rescan function is?
526 2012-05-20 18:46:46 <jgarzik> sipa: hash still need tuning, most likely
527 2012-05-20 18:50:45 <jgarzik> sipa gmaxwell: db_stat output for the New Way: http://pastebin.com/LEw3PQbL
528 2012-05-20 19:12:53 <sipa> we should put this on bitcoin.org: http://www.worldipv6launch.org/wp-content/themes/ipv6/downloads/World_IPv6_launch_banner_512.png
529 2012-05-20 19:19:09 <DBordello> Does the latest git tree include https://github.com/bitcoin/bitcoin/pull/841?
530 2012-05-20 19:19:27 <sipa> yes
531 2012-05-20 19:19:38 <DBordello> fantastic
532 2012-05-20 19:20:54 <DBordello> I am trying to compile it, however, I am getting the following error: http://pastebin.com/52AmaNQ2
533 2012-05-20 19:20:55 <DBordello> any ideas?
534 2012-05-20 19:21:12 <DBordello> (i realize that is poorly formatted)
535 2012-05-20 19:22:31 <gmaxwell> DBordello: how are you tryint to compile what? (master? via make -f Makefile.unix bitcoind USE_UPNP= ?)  on what OS?
536 2012-05-20 19:22:58 <sipa> DBordello: looks like you're not compiling addrman.cpp and walletdb.cpp
537 2012-05-20 19:23:03 <sipa> old makefile?
538 2012-05-20 19:23:08 <DBordello> sipa, very likely.
539 2012-05-20 19:23:08 <gmaxwell> My guess is you're using some broken makefile.
540 2012-05-20 19:23:20 <DBordello> let me diff that with Makefile.unix
541 2012-05-20 19:23:22 <gmaxwell> DBordello: Bitcoin includes a makefile. It should work for you. Use it.
542 2012-05-20 19:23:32 <DBordello> gmaxwell, okay, I'll take a look at that
543 2012-05-20 19:25:05 <DBordello> Thanks for the heads up
544 2012-05-20 19:30:41 <DBordello> It is a slow process to debug on a VPS
545 2012-05-20 19:41:57 <theymos> What do you guys think about increasing the rate at which the minimum fee is increased when the blocksize is >250kB? Currently at blocksize=475kB the minimum fee is ~0.01 BTC, which is nothing.
546 2012-05-20 19:43:22 <gmaxwell> I endorse the thought but I don't know if that will be useful.
547 2012-05-20 19:43:35 <theymos> Why?
548 2012-05-20 19:44:17 <BlueMatt> how far did sipa  get on his whole completely redo fee structure stuff?
549 2012-05-20 19:44:29 <sipa> BlueMatt: nowhere
550 2012-05-20 19:44:40 <gmaxwell> ~No one will actually send that larger fee there isn't automation to increase further (and if there was it would make people more nervous about fees).  ... and that just means we'll spread the same load out over more time and further delay non-spammy innocent free txns.
551 2012-05-20 19:45:10 <BlueMatt> sipa: well thats a shame...
552 2012-05-20 19:45:11 <gmaxwell> theymos: the recent increased load is from a gambling site that works pretty much entirely on unconfirmed transactions. It doesn't bother them it it's taking weeks to get a low fee transaction in.
553 2012-05-20 19:46:22 <gmaxwell> I'd think we'd do more to help users to detected repeated address use and put them at the back of the line so at least they don't get in front of as many normal users.
554 2012-05-20 19:46:39 <theymos> gmaxwell: If blocks usually end up in the 250kB+ more-expensive state, people can manually add more fees to their transactions to speed up confirmation.
555 2012-05-20 19:47:21 <gmaxwell> theymos: we could also prioritize on highest fees and let people do the same. But fair point.
556 2012-05-20 19:48:23 <gmaxwell> Also the current fee model in the client makes it hard to do that depending on the composition of your wallet you can easly end up with a 40k transaction... 0.1 BTC/K doesn't sound bad when a normal txn is well under 1k .. but at 40k thats a fair bit of coin.
557 2012-05-20 19:51:46 <theymos> What do you think about discounting fees when many inputs are being sent to only a few outputs? (Since this theoretically decreases the total block size that people need to remember.)
558 2012-05-20 19:54:49 <sipa> jgarzik: still a slight slowdown compared to master
559 2012-05-20 20:02:09 <gmaxwell> sipa: would be interesting to switch them all back to btree and see what it does.
560 2012-05-20 20:05:16 <jgarzik> sipa: looking at db_stat, one sees a ton of wasted space in overflow pages, in txhash.dat
561 2012-05-20 20:05:26 <jgarzik> gmaxwell: I was thinking about running at comparison, indeed
562 2012-05-20 20:16:13 <sipa> if only ecdsa signatures were deterministic
563 2012-05-20 20:16:50 <sipa> gavin's signature cache would speed up block verification, because transactions often use several outputs from the same address
564 2012-05-20 20:26:12 <gmaxwell> sipa: well they sign different data in any case.
565 2012-05-20 20:26:26 <sipa> do they?
566 2012-05-20 20:26:31 <gmaxwell> they include the input no?
567 2012-05-20 20:26:50 <gmaxwell> (otherwise you could input rebinding attacks)
568 2012-05-20 20:27:14 <sipa> right, so it would only work if they spent from the exact same tx
569 2012-05-20 20:27:29 <sipa> which is far less common, i suppose
570 2012-05-20 20:27:39 <BlueMatt> same input, not just same tx, right?
571 2012-05-20 20:27:54 <BlueMatt> s/same input/from same output/
572 2012-05-20 20:27:58 <gmaxwell> it would be better if we could multi-satisify identical input scriptpubkeys, but oh well.
573 2012-05-20 20:28:31 <sipa> BlueMatt: hmm, right
574 2012-05-20 20:28:36 <sipa> never mind my remark :)
575 2012-05-20 20:33:44 <diki> what is the most basic way to generate a random bitcoin address?
576 2012-05-20 20:33:57 <BlueMatt> use the new address button in bitcoin-qt?
577 2012-05-20 20:34:03 <diki> I am looking at vanitygen, but it looks too complex
578 2012-05-20 21:06:08 <Eliel> it's possible it crashed the last time it was running. Could that be it?
579 2012-05-20 21:06:19 <sipa> what's in debug.log?
580 2012-05-20 21:06:33 <sipa> it can be very slow, if blkindex.dat is not cached by the OS
581 2012-05-20 21:07:01 <gmaxwell> 5 _minutes_ ? that sounds odd.
582 2012-05-20 21:07:15 <sipa> on my vps it's even slower i think
583 2012-05-20 21:07:20 <Eliel> debug.log is 5.7 megabytes ... I wonder how to best find the session start for just now
584 2012-05-20 21:07:34 <gmaxwell> Eliel: search backwards for the first line.
585 2012-05-20 21:07:50 <gmaxwell> or just go to the end and scroll up,,, won't be far.
586 2012-05-20 21:07:50 <gribble> Error: "," is not a valid command.
587 2012-05-20 21:07:59 <Eliel> the first line is 7ce8f9c4095f   0
588 2012-05-20 21:08:36 <sipa> Eliel: grep for the last occurrance of 'bitcoin' in the file
589 2012-05-20 21:08:55 <gmaxwell> Eliel: I mean the first line bitcoin puts out, like Bitcoin version v0.6.1-247-g531fb03-beta (2012-05-18 20:56:31 -0400)
590 2012-05-20 21:10:27 <Eliel> interesting version :D Bitcoin version vCLIENT_VERSION_MAJOR.CLIENT_VERSION_MINOR.CLIENT_VERSION_REVISION.CLIENT_VERSION_BUILD-g8ff1873-beta ()
591 2012-05-20 21:11:15 <Eliel> ok, maybe 5 minutes was overestimation :)
592 2012-05-20 21:11:20 <Eliel> but still, half of that
593 2012-05-20 21:11:21 <sipa> Eliel: we've already learnt to recognize that as non-gt build of 0.6.2
594 2012-05-20 21:11:27 <sipa> *non-git
595 2012-05-20 21:11:33 <Eliel> block index          157940ms
596 2012-05-20 21:11:56 <gmaxwell> 15 seconds is a bit more plausable.
597 2012-05-20 21:12:24 <Eliel> that's 158 seconds unless I'm too sleepy to count :)
598 2012-05-20 21:12:35 <sipa> block index          328556ms
599 2012-05-20 21:12:53 <gmaxwell> oh .. I'm too sleepy to count.
600 2012-05-20 21:12:55 <gmaxwell> indeed.
601 2012-05-20 21:12:57 <gmaxwell> thats nuts!
602 2012-05-20 21:13:00 <gmaxwell> :(
603 2012-05-20 21:13:12 <sipa> glad i don't often restart bitcoind on my vps :)
604 2012-05-20 21:13:40 <Eliel> is that due to slow hard drive?
605 2012-05-20 21:13:55 <Eliel> this is a laptop afterall
606 2012-05-20 21:14:08 <sipa> Eliel: how much RAM do you have?
607 2012-05-20 21:14:14 <Eliel> 3GB
608 2012-05-20 21:14:32 <sipa> try cat ~/.bitcoin/blkindex.dat >/dev/null
609 2012-05-20 21:14:37 <sipa> before you start
610 2012-05-20 21:14:42 <Eliel> around 50% of RAM in use
611 2012-05-20 21:14:48 <sipa> it should make startup very fast
612 2012-05-20 21:15:05 <Eliel> if that helps, maybe bitcoin should do it itself :P
613 2012-05-20 21:15:06 <sipa> (of course, that cat command may be slow...)
614 2012-05-20 21:16:32 <Eliel> oh and, the blockchain is on an encrypted partition.
615 2012-05-20 21:16:40 <Eliel> so that probably explains some of the slowness
616 2012-05-20 21:16:54 <sipa> yup
617 2012-05-20 21:19:14 <Eliel> well, I usually keep bitcoin-qt running all the time so this isn't a problem too often.
618 2012-05-20 21:19:28 <Eliel> ... ah, I think I forgot to start it up again after upgrading it.
619 2012-05-20 21:19:56 <gribble> 180968
620 2012-05-20 21:19:56 <sipa> ;;bc,blocks
621 2012-05-20 21:20:37 <Eliel> but it was nice looking at the transactions per day graphs with the ouliers removed :)
622 2012-05-20 21:21:21 <Eliel> looks like it's following exponential growth curve :)
623 2012-05-20 21:22:11 <Eliel> the spike in transactions from a year ago looks like an anomaly though :D
624 2012-05-20 21:35:46 <gribble> New news from bitcoinrss: roques opened pull request 1366 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1366>
625 2012-05-20 21:49:35 <gmaxwell> PROCESSMESSAGE SKIPPED 20 BYTES
626 2012-05-20 21:50:11 <sipa> gmaxwell: same saw too, a short while ago
627 2012-05-20 21:50:37 <gmaxwell> I wish it were a little easier to grep out the normal stuff from our logs.
628 2012-05-20 21:51:34 <luke-jr> I saw that a lot when I was trying to make Eloipool work with the stupid pre-Feb20 crap
629 2012-05-20 21:54:57 <phantomcircuit> gmaxwell, 20 bytes is weird 4 bytes is bad system time
630 2012-05-20 21:56:12 <gmaxwell> I actually have 4 of them on my public node log today.
631 2012-05-20 21:57:05 <gmaxwell> and they don't appear to be right after a new connection started.
632 2012-05-20 22:43:49 <Karmaon> someone alert theymos blkeplr is down
633 2012-05-20 22:51:49 <gmaxwell> ;;tell theymos < Karmaon> someone alert theymos blkeplr is down
634 2012-05-20 22:51:49 <gribble> Error: I haven't seen theymos, I'll let you do the telling.
635 2012-05-20 22:53:55 <gribble> The operation succeeded.
636 2012-05-20 22:53:55 <sipa> ;;later tell theymos < gmaxwell> ;;tell theymos < Karmaon> someone alert theymos blkeplr is down
637 2012-05-20 22:54:54 <BlueMatt> quotes inception-style
638 2012-05-20 22:55:49 <gmaxwell> ;;tell sipa thank you
639 2012-05-20 22:56:10 <gmaxwell> (who knows why it has that feature!)
640 2012-05-20 22:56:29 <sipa> ;;tell gmaxwell that he is welcome
641 2012-05-20 22:58:02 <Karmaon> middleman talk
642 2012-05-20 22:58:13 <luke-jr> ;;tell gmaxwell it's for bypassing ignores
643 2012-05-20 22:58:30 <Karmaon> ;;tell luke-jr nice to know
644 2012-05-20 22:59:07 <sipa> clearly i'll be forced to ignore gribble now...
645 2012-05-20 23:14:47 <gribble> New news from bitcoinrss: jgarzik opened pull request 1367 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1367>
646 2012-05-20 23:15:11 <gmaxwell> http://blockchain.info/charts/n-transactions  vs http://blockchain.info/charts/n-transactions-excluding-popular
647 2012-05-20 23:15:22 <gmaxwell> I think this supported my off the cuff suggestion of depriortizing repeated addresses.
648 2012-05-20 23:16:48 <gmaxwell> s/supported/supoorts/
649 2012-05-20 23:36:00 <BlueMatt> gmaxwell: dunno, would discourage green addressing (which should be discouraged) but wouldnt really discourage idiots who still refuse to use multisend
650 2012-05-20 23:36:17 <BlueMatt> or otherwise sanely limit their txes
651 2012-05-20 23:36:23 <gmaxwell> I don't even mean to discourage them in fact.
652 2012-05-20 23:37:13 <gmaxwell> My concern is that no simple fee rule change we'd put in could distinguish between joe blow's free txn, and dice spam / deepspam. The latter classes don't matter if they don't get mined for a couple blocks.
653 2012-05-20 23:37:24 <gmaxwell> but we do want joe users txn to go through quickly
654 2012-05-20 23:37:51 <gmaxwell> so not even so much as 'address reuse is discouraged' but 'address reuse is one way you indicate your txn are low priority'
655 2012-05-20 23:38:02 <BlueMatt> has anyone talked to the dice runner and asked them to please stop spamming so damn much?
656 2012-05-20 23:38:23 <gmaxwell> in particular because if you're reusing addresses it's either an automatic payment or someone you know.. either case you should be in no big rush to get confirmations.
657 2012-05-20 23:38:36 <BlueMatt> true
658 2012-05-20 23:39:10 <gmaxwell> the dice spam is fundimental to their business they could reduce it a little but I think not that much
659 2012-05-20 23:39:26 <gmaxwell> and they're paying lots in fees, so you'd think thats more incentive than me whining at them could ever be.
660 2012-05-20 23:39:58 <BlueMatt> mmm, still Id like to see them limit and group txes to individuals together instead of paying out instantly
661 2012-05-20 23:58:33 <jgarzik> BlueMatt: instant gratification is key to their business, I thik
662 2012-05-20 23:58:35 <jgarzik> *think