1 2012-05-08 02:29:18 <Joric> this is... beautiful http://www.sdtimes.com/blog/post/2012/05/07/Google-gets-smacked.aspx
  2 2012-05-08 02:29:23 <Joric> 1 billion dorrars!
  3 2012-05-08 02:30:02 <luke-jr> Joric: nowhere near
  4 2012-05-08 02:30:05 <Joric> 'Oracle was asking for $1bn in compensation in one of the biggest such technology lawsuits to date.'
  5 2012-05-08 02:30:15 <luke-jr> Joric: Oracle hasn't won.
  6 2012-05-08 02:30:26 <DiabloD3> they havent lost either
  7 2012-05-08 02:31:07 <neofutur> 10 lines of code . . .
  8 2012-05-08 02:31:12 <luke-jr> neofutur: not even that
  9 2012-05-08 02:31:28 <luke-jr> how the *%#)%* did Google overlook the fact that OpenJDK (where it was copied from) *is GPL'd*?
 10 2012-05-08 02:31:32 <neofutur> yup could be 3 lines
 11 2012-05-08 02:31:45 <Joric> i wrote that function too! in the primary school, using pascal
 12 2012-05-08 02:32:12 <DiabloD3> those 10 lines, however
 13 2012-05-08 02:32:19 <DiabloD3> was written by the guy who originally wrote them
 14 2012-05-08 02:32:39 <DiabloD3> since google hired him and the guy never worked for sun
 15 2012-05-08 02:33:24 <luke-jr> actually
 16 2012-05-08 02:33:26 <luke-jr> that's another thing
 17 2012-05-08 02:33:36 <luke-jr> can Oracle prove they didn't copy the code from Google?
 18 2012-05-08 02:33:43 <DiabloD3> yes
 19 2012-05-08 02:35:08 <Joric> normally, those cases has to be rejected, it's pure crazyness
 20 2012-05-08 02:37:29 <Joric> maybe google will make a precedent allowing copying such blocks of code without consequences
 21 2012-05-08 02:40:08 <Joric> i hate patent trolls since z-fail
 22 2012-05-08 02:41:01 <luke-jr> this has nothing to do with patents fyi
 23 2012-05-08 02:59:53 <dwon> Joric: That link is full of BS.  The lawsuit is actually going reasonably well for Google:  http://www.groklaw.net/article.php?story=20120507122749740
 24 2012-05-08 03:03:18 <dwon> Could someone sanity-check my commit message here, before I send a pull request to BitcoinArmory?  https://github.com/dlitz/BitcoinArmory/commit/39e102326ae318c56724da285fbc15d22b9a3f6b
 25 2012-05-08 03:21:44 <wump> BlueMatt: I haven't, I see only Qt functions in there though... strange place to crash
 26 2012-05-08 03:23:22 <BlueMatt> wump: thats what I was thinking, but google turned up nothing, and the only similar crash was a bug in vlc...
 27 2012-05-08 03:23:55 <wump> how do you cause it?
 28 2012-05-08 03:25:00 <BlueMatt> Ive seen it a few times at shutdown on cblockstore
 29 2012-05-08 03:25:39 <BlueMatt> havent spent enough time with master to know
 30 2012-05-08 03:26:25 <wump> weird
 31 2012-05-08 03:26:34 <BlueMatt> yea...
 32 2012-05-08 03:27:41 <wump> the QueueShutdown() function was introduced to prevent crashes on shutdown by first shutting down the UI before bitcoin core... but this doesn't even seem bitcoin related
 33 2012-05-08 03:28:26 <BlueMatt> that was my though too, well Ill look up the vlc bug a bit more closely later, just wondered if you had any clue on that one...
 34 2012-05-08 03:35:26 <wump> it happens in the empty QBrush constructor.. from what I see: qt.gitorious.org/qt/qt/blobs/4.7/src/gui/painting/qbrush.cpp  ; all it does is initialize its internal pointer with the "null brush" singleton and increase the number of references
 35 2012-05-08 04:08:20 <anand> Hi, is there any system monitoring tool which provides auto register of agent in monitoring server?
 36 2012-05-08 04:15:54 <dusty_> hi all
 37 2012-05-08 04:16:35 <dusty_> does anyone has any clue on why a transaction with version 971503818 has been accepted in testnet blockchain?
 38 2012-05-08 04:16:36 <dusty_> http://blockexplorer.com/testnet/rawtx/362bbbf21f6d0b47ee2e45f975b4c2bd81ed49ba371cbd618835e91b00a66006
 39 2012-05-08 04:17:01 <dusty_> and this one has version 369576415 : http://blockexplorer.com/testnet/rawtx/8a59d89496b8c0eef5ad7c3ed4b966a7e696fba0f0592cfa3736384e7a4a68b7
 40 2012-05-08 04:17:51 <dusty_> has this been happened as error? can this happen in prodnet too?
 41 2012-05-08 05:39:26 <gribble> New news from bitcoinrss: Diapolo opened pull request 1221 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1221>
 42 2012-05-08 08:41:18 <gribble> New news from bitcoinrss: ssokolow opened issue 1222 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1222>
 43 2012-05-08 08:47:43 <t7> new news
 44 2012-05-08 08:57:21 <sipa> posting old news here would be rather silly, no? ;)
 45 2012-05-08 09:18:47 <gmaxwell> sipa: I have that stuck nodes data dir now.
 46 2012-05-08 09:26:51 <sipa> gmaxwell: going to try to run my branch on it yourself?
 47 2012-05-08 09:31:46 <gmaxwell> I'm first trying 0.6.1 to make sure it's stuck for me too.
 48 2012-05-08 09:32:03 <gmaxwell> about to start that in a moment. Assuming it is, then I'll try your branch.
 49 2012-05-08 09:32:29 <gmaxwell> The other user I had that was stuck unstuck on their own before getting the build you did. :-/
 50 2012-05-08 09:33:48 <gmaxwell> .... and .... it's not stuck for me.
 51 2012-05-08 09:34:36 <gmaxwell> It started at 176947 alright but instantly started pulling the chain.  And the user sent me their whole datadir.
 52 2012-05-08 09:36:56 <sipa> And he was stuck for days already, you say?
 53 2012-05-08 09:37:48 <gmaxwell> Yes.
 54 2012-05-08 09:38:03 <sipa> Maybe he just tried a few times, never opening the client more than a few minutes?
 55 2012-05-08 09:40:44 <gmaxwell> He said he left it running 0.6.1 for 'many hours'.
 56 2012-05-08 13:39:38 <Eliel> Is there a patch for bitcoind that allows checking for transaction history for any address (especially addresses not in local wallet)?
 57 2012-05-08 13:39:49 <Eliel> that is, with an RPC call
 58 2012-05-08 13:39:55 <sipa> no
 59 2012-05-08 13:40:42 <sipa> there's a patch scheduled for 0.7.0 that extends gettransaction to non-wallet transactions
 60 2012-05-08 13:41:05 <sipa> but for any address it would require either a full rescan or an index
 61 2012-05-08 13:41:11 <sipa> i believe armory can do that, though
 62 2012-05-08 13:42:37 <Eliel> basically, what I want to do is run a bitcoin node that can track certain addresses and then trigger an activity when there's enough bitcoins transfered into the address with 6 confirmations.
 63 2012-05-08 13:43:43 <drizztbsd> Eliel: you can use some public service api
 64 2012-05-08 13:44:19 <Eliel> drizztbsd: while that would work, for now, it's liable to break due to circumstances out of my control.
 65 2012-05-08 13:45:05 <drizztbsd> use 2+ services :)
 66 2012-05-08 13:45:16 <drizztbsd> like blockchain and blockexplorer
 67 2012-05-08 13:45:51 <neofutur> Eliel: you could be interested in abe + bitping
 68 2012-05-08 13:46:01 <neofutur> ( https://github.com/MORA99/BitPing.Net )
 69 2012-05-08 13:47:22 <kakobrekla> umm
 70 2012-05-08 13:47:39 <kakobrekla> QR code creatin is buggy, there is no char limit
 71 2012-05-08 13:47:48 <kakobrekla> if i make BTC message long enough
 72 2012-05-08 13:47:56 <kakobrekla> it will crash bitcoin client
 73 2012-05-08 13:49:49 <sipa> kakobrekla: which version are you using?
 74 2012-05-08 13:50:02 <kakobrekla> 474
 75 2012-05-08 13:50:12 <sipa> that's a plane
 76 2012-05-08 13:50:13 <kakobrekla> ah no
 77 2012-05-08 13:50:18 <sipa> oh no, 747
 78 2012-05-08 13:50:25 <kakobrekla> 0606
 79 2012-05-08 13:50:28 <sipa> ok
 80 2012-05-08 13:50:35 <sipa> can you try upgrading to 0.6.1?
 81 2012-05-08 13:50:48 <sipa> i remember a bug involving the QR code being fixed in 0.6.1
 82 2012-05-08 13:50:57 <kakobrekla> aha will try
 83 2012-05-08 13:55:16 <Eliel> neofutur: that looks the closest to what I'm looking for, thank you.
 84 2012-05-08 13:55:23 <neofutur> my pleasure
 85 2012-05-08 13:55:39 <neofutur> + its pretty well coded and secure, and they accepted my pull requests ;)
 86 2012-05-08 13:56:10 <neofutur> you can probably make it do what you need with very little modifications/coding
 87 2012-05-08 13:56:36 <neofutur> I hope you ll fork and send pull requests, to make it better / add features for everyone ;)
 88 2012-05-08 13:58:00 <Eliel> neofutur: I'm still considering to patch bitcoind. All it would really need is a way to dynamically add more addresses to the list of addresses it tracks.
 89 2012-05-08 13:59:57 <jgarzik> Eliel: importprivkey
 90 2012-05-08 14:00:17 <Eliel> jgarzik: no privkey to import available in this case.
 91 2012-05-08 14:00:32 <jgarzik> ah
 92 2012-05-08 14:00:39 <Eliel> only the address
 93 2012-05-08 14:01:17 <sipa> watch-only wallets would be useful
 94 2012-05-08 14:01:29 <sipa> but i think we first need multi-wallets in the first place
 95 2012-05-08 14:02:02 <drizztbsd> you can use offline wallets :P
 96 2012-05-08 14:02:41 <jgarzik> well then you'll need the privacy enhanced service I'm building, that allows a merchant to process payments and monitor payments without ever sending my service a privkey
 97 2012-05-08 14:03:46 <sipa> jgarzik: like a watch-only deterministic wallet?
 98 2012-05-08 14:08:06 <jgarzik> sipa: yes
 99 2012-05-08 14:08:22 <jgarzik> sipa: pretty much the services provided by bitcoind... in a distributed fashion, where any component may fail
100 2012-05-08 14:08:32 <jgarzik> and no privkeys necessary
101 2012-05-08 14:08:50 <jgarzik> so the wallet is implemented as a distributed database
102 2012-05-08 14:09:15 <sipa> right, but if the wallet is deterministic, you don't need any distribution
103 2012-05-08 14:10:27 <jgarzik> sipa: not sure what you mean
104 2012-05-08 14:11:06 <sipa> you mentioned a distributed database would be used to insert new keys into the system
105 2012-05-08 14:12:03 <sipa> so i wonder whether those need to be randomly generated, or whether they can be derived from a determinstic seed
106 2012-05-08 14:12:36 <jgarzik> sipa: no, the customer generates and provides keys to my service.  the service stores all data in a distributed db, which then feeds bitcoind's downstream
107 2012-05-08 14:12:55 <jgarzik> so nothing is being generated
108 2012-05-08 14:13:22 <jgarzik> sipa: no privkeys are involved in this service.  that stays entirely on the customer side.
109 2012-05-08 14:13:47 <sipa> why would you want the customer to keep sending you keys, instead of just sending a watch-only seed once?
110 2012-05-08 14:14:36 <jgarzik> sipa: so that the customer never exposes their privkeys to my service
111 2012-05-08 14:14:49 <Eliel> jgarzik: so, you're building an auxiliary p2p network for this purpose? did I understand it correctly?
112 2012-05-08 14:14:50 <sipa> i think you need to read up on type-2 deterministic wallets :)
113 2012-05-08 14:15:18 <jgarzik> Eliel: no p2p network, this is a business
114 2012-05-08 14:15:25 <sipa> jgarzik: it's perfectly possible to have a seed that allows you to generate all corresponding public keys, but not the private ones
115 2012-05-08 14:15:43 <sipa> the HD wallet idea (BIP 32) is based on that
116 2012-05-08 14:15:51 <Eliel> jgarzik: so, a distributed network of systems run by you?
117 2012-05-08 14:15:56 <jgarzik> Eliel: correct
118 2012-05-08 14:16:42 <jgarzik> sipa: that imposes restrictions on the keys the customer might use
119 2012-05-08 14:16:46 <Eliel> the selling point, then, is that customers don't need to run bitcoin at all themselves?
120 2012-05-08 14:17:07 <jgarzik> sipa: I would rather customers be able to use any address/key
121 2012-05-08 14:17:14 <sipa> jgarzik: of course
122 2012-05-08 14:17:40 <jgarzik> Eliel: correct
123 2012-05-08 14:17:52 <jgarzik> Eliel: though there is more to it than just that :)
124 2012-05-08 14:17:55 <sipa> jgarzik: but i hope in the future recurring business transactions can be done by using a serialized deterministic chain as address, instead of one referring to a single key
125 2012-05-08 14:18:55 <jgarzik> Eliel: customers would not need to run a reliable infrastructure in general.  even just one bitcoind is prone to failure or DoS attack
126 2012-05-08 14:20:22 <Eliel> jgarzik: when would your service be up and running? Also, have you decided on pricing?
127 2012-05-08 14:20:50 <jgarzik> Eliel: 2 weeks.  not yet...  pricing is tough, and looking for feedback
128 2012-05-08 14:21:10 <jgarzik> sipa: that sounds overly optimistic
129 2012-05-08 14:21:55 <sipa> (i'm working on implemented it for bitcoind, and etotheipi is doing the same in armory)
130 2012-05-08 14:22:01 <sipa> *implementing
131 2012-05-08 14:22:12 <Eliel> jgarzik: I'll need something up&running faster than that unfortunately.
132 2012-05-08 14:22:35 <jgarzik> sipa: I meant it's overly optimistic that that will be the dominant form of merchant use
133 2012-05-08 14:22:52 <jgarzik> sipa: as there remains value in randomness
134 2012-05-08 14:23:18 <sipa> you can always generate a new chain if you believe the old one was compromised
135 2012-05-08 14:23:29 <sipa> and there is certainly value in random keys, of course
136 2012-05-08 14:24:05 <sipa> but in many (if not most) i think deterministic keys have other benefits that may outweigh, such as ease of backups of sharing of wallets
137 2012-05-08 14:24:13 <sipa> +cases
138 2012-05-08 14:24:21 <sipa> anyway, que sera, sera
139 2012-05-08 14:37:44 <jgarzik> sipa: so a single chain compromise compromises a wide swath of keys, yes?
140 2012-05-08 14:39:50 <sipa> obviously, yes
141 2012-05-08 14:40:13 <sipa> but if someone has access to your private key, he has access to your wallet in unencrypted form
142 2012-05-08 14:40:22 <sipa> the security consequence is the same
143 2012-05-08 14:40:53 <sipa> except for the fact that random wallets with a keypool become "unstolen" after time, as the copy an attacker may have (without being known) will become outdated
144 2012-05-08 14:41:09 <sipa> so yes, that is a certain advantage of random wallets
145 2012-05-08 14:44:04 <jgarzik> well, more simply, a stolen chain implies greater theft than stolen [random] keys, IMO
146 2012-05-08 14:45:17 <jgarzik> especially if you do not know at that instant that theft occurred
147 2012-05-08 14:45:22 <sipa> agree
148 2012-05-08 14:45:38 <gavinandresen> changing master keys every once in a while should be encouraged
149 2012-05-08 14:46:01 <sipa> maybe they should be time-limited by default
150 2012-05-08 14:46:11 <jgarzik> sipa: that would help, yes
151 2012-05-08 14:46:29 <gavinandresen> time limit on the order of a year or three seems about right to me.
152 2012-05-08 14:47:02 <sipa> lianj: what kind of pattern do you mean, cryptographic, or transaction-graph-analysis?
153 2012-05-08 14:47:09 <sipa> eh, luke-jr
154 2012-05-08 14:47:38 <jgarzik> it's the gift that keeps on giving :)  if you manage to steal a seed from RAM now, you have plenty of access to future transactions, and may pick and choose which to target.  stealing just privkeys limits your future access greatly.
155 2012-05-08 14:47:44 <gavinandresen> I wonder if I just broke the law reading this:  http://www.scribd.com/doc/92797476/FBI-Bitcoin-Report-April-2012
156 2012-05-08 14:47:59 <sipa> gavinandresen: it's not classified
157 2012-05-08 14:48:02 <gavinandresen> (popped up in my google bitcoin alert)
158 2012-05-08 14:48:16 <jgarzik> gavinandresen: <shrug>  it's out in the open at this point, just like reading Pentagon Papers in the NYT
159 2012-05-08 14:48:45 <gavinandresen> maybe it's just a very elaborate troll.
160 2012-05-08 14:49:00 <sipa> an extremely bored troll, in that case
161 2012-05-08 14:49:13 <sipa> i'd rather call it a prankster than a troll in that case
162 2012-05-08 14:49:23 <gavinandresen> speaking of trolls... wait, no, I have nothing to say about trolls.
163 2012-05-08 14:49:30 <jgarzik> gavinandresen: it doesn't say anything damning or relevatory, really.  I don't think it's a fake, but it doesn't really matter if it is [based on content]
164 2012-05-08 14:49:49 <luke-jr> sipa: cryptographic
165 2012-05-08 14:49:52 <gavinandresen> jgarzik: yes, it's nice working for a project where there are no secrets
166 2012-05-08 14:50:30 <sipa> luke-jr: i've ask ByteCoin for comments already, but so far i haven't had much reply yet
167 2012-05-08 14:50:57 <gavinandresen> sipa:  what's the status of the stuck chain bug?  Any luck getting an actually stuck chain?
168 2012-05-08 14:51:26 <sipa> luke-jr: so do i, i have some intuition, but i know that everyone is smart enough to design something he can't crack himself
169 2012-05-08 14:51:54 <sipa> gavinandresen: not yet; both victims gmaxwell found don't seem actually stuck
170 2012-05-08 14:52:22 <gavinandresen> ok, good actually.  I was worried the stuck chain problem was more widespread than we thought
171 2012-05-08 14:52:38 <sipa> still, these are people that reported being stuck for hours or days
172 2012-05-08 14:53:08 <sipa> which at least is a problem in user experience
173 2012-05-08 14:53:18 <gavinandresen> somebody running a sybil DoS maybe?
174 2012-05-08 14:53:18 <sipa> whether or not it's an actual fully-stuck bug
175 2012-05-08 14:54:06 <gavinandresen> in any case, not a showstopper for a 0.6.2 release-- I want to tag and build and release
176 2012-05-08 14:55:47 <sipa> in that case, either revert the unstuck patch in it, or wait until we have more certainty that the new patch actually works
177 2012-05-08 14:55:48 <sipa> i've been sloppy...
178 2012-05-08 14:56:54 <sipa> luke-jr: i've put BIP32 on the wiki, by the way
179 2012-05-08 14:56:56 <ageis> nice, all the sources are at the bottom
180 2012-05-08 14:57:16 <gavinandresen> sipa: ok, I'll back out the unstuck patch.
181 2012-05-08 14:57:19 <gavinandresen> ... and then tag
182 2012-05-08 14:57:52 <sipa> actually, i'd prefer reverting it entirely, but that's probably too much a change at this point
183 2012-05-08 14:59:36 <gavinandresen> I reverted it entirely on the 0.6.2 branch
184 2012-05-08 14:59:58 <gavinandresen> ... now I'll tag
185 2012-05-08 15:02:00 <gavinandresen> * [new tag]         v0.6.2
186 2012-05-08 15:02:25 <luke-jr> building
187 2012-05-08 15:04:22 <gavinandresen> building also.
188 2012-05-08 15:05:05 <sipa> gavinandresen: i've updated my build script a bit by the way, it now produces some extra text files along with the build: http://bitcoin.sipa.be/builds/0.6.1-35-g1ec1702/
189 2012-05-08 15:05:37 <gmaxwell> luke-jr: We've (sipa mostly) at least made an effort to have a design which is very conservative and uses a minimal amount of novelty. Obviously it will need more widespread review before its adopted.
190 2012-05-08 15:05:39 <gavinandresen> sipa: cool, where can I get your build script from?
191 2012-05-08 15:06:42 <gmaxwell> jgarzik: if you really want unstealing you can make the backup function start a new master chain right before a backup is made. This would give you somewhat better unstealing than our current keypool usage has... but more safty.
192 2012-05-08 15:08:12 <sipa> gavinandresen: let me polish it a bit
193 2012-05-08 15:08:33 <gavinandresen> I don't read Polish.
194 2012-05-08 15:08:40 <gavinandresen> (sorry, couldn't resist, you can all groan)
195 2012-05-08 15:10:29 <gavinandresen> gmaxwell: you might reach out to Matthew Green, he seems like a likely expert who might be willing to tell us if we're being idiots:  http://blog.cryptographyengineering.com/2012/05/future-of-electronic-currency.html
196 2012-05-08 15:11:06 <gavinandresen> (gmaxwell or sipa ...  )
197 2012-05-08 15:11:28 <DiabloD3> gavinandresen: who is on what?
198 2012-05-08 15:12:10 <luke-jr> gavinandresen: M??j poduszkowiec jest peBen wgorzy
199 2012-05-08 15:12:30 <gavinandresen> ok, luke's in charge of the polish.
200 2012-05-08 15:13:07 <sipa> gavinandresen: http://bitcoin.sipa.be/builds/bitcoin-build.sh.txt
201 2012-05-08 15:13:12 <luke-jr> noooooooooo :p
202 2012-05-08 15:13:20 <DiabloD3> gavinandresen: didnt poland get enough shit already?
203 2012-05-08 15:13:36 <gavinandresen> be nice or I'll ignore you again
204 2012-05-08 15:13:43 <gavinandresen> (ooooh!!!!!!)
205 2012-05-08 15:13:54 <gavinandresen> (like you care)
206 2012-05-08 15:13:54 <luke-jr> I don't really know polish, I stole it from http://www.omniglot.com/language/phrases/hovercraft.htm
207 2012-05-08 15:13:55 <luke-jr> <.<
208 2012-05-08 15:14:26 <DiabloD3> wait, gavin had me on ignore? wtf
209 2012-05-08 15:14:56 <copumpkin> lol
210 2012-05-08 15:15:11 <gavinandresen> mental note: poduszkowiec is hovercraft in polish.....
211 2012-05-08 15:15:21 <DiabloD3> gavinandresen: what about eels?
212 2012-05-08 15:15:29 <gavinandresen> I never talk about eels, don't need that one.
213 2012-05-08 15:15:49 <luke-jr> lol
214 2012-05-08 15:16:46 <DiabloD3> but what else are you going to put in your hovercraft?
215 2012-05-08 15:16:49 <gavinandresen> away for a bit for lunch...
216 2012-05-08 15:17:20 <sipa> gavinandresen: oh, just realized, it requires a patched gitian
217 2012-05-08 15:37:24 <luke-jr> 0.6.2-win32 sig pushed
218 2012-05-08 15:37:47 <drizztbsd> luke-jr: windows-only?
219 2012-05-08 15:37:53 <drizztbsd> or should I rebuild bitcoin on archlinux?
220 2012-05-08 15:38:23 <luke-jr> drizztbsd: ?
221 2012-05-08 15:38:42 <drizztbsd> I maintain bitcoin-qt and bitcoin-daemon
222 2012-05-08 15:39:52 <luke-jr> drizztbsd: the latter's name is bitcoind fwiw :P
223 2012-05-08 15:40:04 <luke-jr> drizztbsd: v0.6.2 was tagged in git earlier
224 2012-05-08 15:40:11 <luke-jr> I just pushed the win32 build signature
225 2012-05-08 15:40:26 <sipa> i'm building as well now
226 2012-05-08 15:40:41 <drizztbsd> which bug does it fix?
227 2012-05-08 15:40:52 <sipa> addrman crashes
228 2012-05-08 15:40:55 <luke-jr> drizztbsd: git shortlog v0.6.1..v0.6.2
229 2012-05-08 15:41:39 <luke-jr> the only functional change for v0.6.2 was that SSL JSON-RPC support is mandatory now, right?
230 2012-05-08 15:41:57 <luke-jr> actually, that was v0.6.1*
231 2012-05-08 15:42:26 <sipa> yes, 0.6.2 is really only addrman fix
232 2012-05-08 15:43:42 <Joric> could somebody please explain merged mining in layman's terms? i don't get how you can reuse a hash of totally independent data (well, excluding nonce)
233 2012-05-08 15:44:16 <sipa> Joric: both chains have their own hash, but you put the block hash of the auxiliary chain in the coinbase of the master chain
234 2012-05-08 15:44:23 <guruvan> since the 2 networks use the same algorithm, we simply submit hashes to both networks
235 2012-05-08 15:44:28 <sipa> no
236 2012-05-08 15:44:43 <gmaxwell> Actually you put the root hash of a hash tree of auxiliary chain hashes in.. same difference.
237 2012-05-08 15:44:49 <sipa> gavinandresen: true
238 2012-05-08 15:44:53 <sipa> eh, gmaxwell: true
239 2012-05-08 15:45:36 <luke-jr> Joric: basically, namecoin accepts a bitcoin POW
240 2012-05-08 15:45:36 <sipa> guruvan: both networks expect a differ block header, no way one hash could match both
241 2012-05-08 15:45:53 <sipa> *different
242 2012-05-08 15:45:55 <guruvan> ah ok
243 2012-05-08 15:47:39 <luke-jr> speaking of block hashing algorithms, it'd be nice if Bitcoin accepted a preimage in place of zeros, for hash comparison
244 2012-05-08 15:48:12 <luke-jr> ie, if a miner could say "ok, I'm searching for 00000000abcdef prefix" and have it treated like "00000000000000" is now
245 2012-05-08 15:48:20 <Joric> was namecoin client altered specially for supporting merged mining?
246 2012-05-08 15:48:24 <luke-jr> Joric: yes
247 2012-05-08 15:48:38 <Joric> ah, that explains everything
248 2012-05-08 15:54:07 <dlb76> the blkindex.dat file is no longer portable to different data directories by default
249 2012-05-08 15:54:17 <dlb76> can someone explain it in more details ?
250 2012-05-08 15:54:25 <dlb76> if you need a portable blkindex.dat file then run with the new -detachdb=1 option or the "Detach databases at shutdown" GUI preference
251 2012-05-08 15:54:26 <dlb76> ...
252 2012-05-08 15:54:48 <dlb76> if i use -datadir=".\\data\\"
253 2012-05-08 15:54:56 <dlb76> do i need to add new -detachdb=1 option ?
254 2012-05-08 15:55:55 <sipa> dlb76: no
255 2012-05-08 15:56:02 <dlb76> ok
256 2012-05-08 15:56:06 <sipa> only if you want to copy/move the blkindex.dat file around
257 2012-05-08 15:56:12 <dlb76> but what it does then ?
258 2012-05-08 15:56:19 <dlb76> ah
259 2012-05-08 15:56:23 <dlb76> thanks
260 2012-05-08 15:57:45 <gavinandresen> luke-jr: my win32 gitian build matches yours
261 2012-05-08 15:57:58 <luke-jr> gavinandresen: that's a good thing.
262 2012-05-08 15:58:27 <gavinandresen> aye.  I just pushed win32 and linux gitian.sigs
263 2012-05-08 16:01:47 <drizztbsd> it should be portable by default
264 2012-05-08 16:02:48 <luke-jr> drizztbsd: except we're talking about binaries
265 2012-05-08 16:03:40 <midnightmagic> that FBI doc is so excellent..
266 2012-05-08 16:04:16 <copumpkin> as opposed to just a tad excellent?
267 2012-05-08 16:04:37 <drizztbsd> luke-jr: I mean blkindex.dat
268 2012-05-08 16:05:19 <midnightmagic> copumpkin: as opposed to the typical forbes tripe. :)
269 2012-05-08 16:05:38 <copumpkin> :P
270 2012-05-08 16:16:10 <BTC_Bear> midnightmagic: Do you think it is real? or at least altered?
271 2012-05-08 16:16:37 <midnightmagic> i'm almost of the opinion that the "Unclassified" part is the altered part.
272 2012-05-08 16:18:31 <BTC_Bear> Well to find out someone needs to make a FOIA request since it's "Unclassified"
273 2012-05-08 16:18:39 <gmaxwell> I've never seen a document that consisted of unclassified material bother with the per paragraph tagging... but then again I've not looked at non-public fbi documents before.
274 2012-05-08 16:19:04 <BTC_Bear> The logo is wrong also. It shouldn't be there.
275 2012-05-08 16:19:21 <gmaxwell> The document seems generally pretty reasonable, at least the part I read and obviously took a lot of work to create, more work than makese sense for a hoax.
276 2012-05-08 16:19:41 <midnightmagic> BTC_Bear: It might be a sneaky advertisement for WebMoney.
277 2012-05-08 16:20:37 <BTC_Bear> lol, yea. Or it is a Real 'Fake' document to deter people from getting involved.
278 2012-05-08 16:20:51 <graingert> bitcoin-qt could have done with being gpl
279 2012-05-08 16:20:56 <graingert> would slow this stuff down
280 2012-05-08 16:22:35 <gmaxwell> sipa: but this isn't funny!
281 2012-05-08 16:23:57 <sipa> gmaxwell: no, i assume it's real, actually
282 2012-05-08 16:24:25 <midnightmagic> BTC_Bear: I've often intuitively felt that a number of news releases and events were calculated specifically to dampen enthusiasm for bitcoin. That "huge" (relatively) sell-off to curb the $30/btc price that happened last June seemed like one. The quotes from Senators felt like calculated measures to slow adoption and buy government/law enforcement time to evaluate it more closely. The deliberate price manipulation down to $2
283 2012-05-08 16:24:32 <midnightmagic> seemed like a way to curb the mining activities..
284 2012-05-08 16:24:52 <midnightmagic> gmaxwell: If I had more time on my hands, I would find releasing that document to the public very funny. :)
285 2012-05-08 16:25:19 <BTC_Bear> midnightmagic: Then we agree and you are aware of tactics that get deployed.
286 2012-05-08 16:27:04 <gavinandresen> All righty, uploaded binaries to https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.2/
287 2012-05-08 16:27:22 <gavinandresen> I'll announce as soon as somebody gitian-builds linux and can confirm that the checksums match
288 2012-05-08 16:27:39 <midnightmagic> BTC_Bear: I think I spotted a mistake on page 7. They use the term gold farmers without introducing it first..
289 2012-05-08 16:27:55 <gavinandresen> (unless gmaxwell or sipa wants to volunteer to announce, I don't have to be Mr. Announcer Person all the time)
290 2012-05-08 16:28:18 <gavinandresen> (or jgarzik or wumpus or tcatm)
291 2012-05-08 16:28:28 <sipa> gavinandresen: but you're good at it!
292 2012-05-08 16:29:08 <gavinandresen> I can copy and paste with the best of 'em!
293 2012-05-08 16:29:37 <sipa> ok, after many improvements to my build script, it should now work!
294 2012-05-08 16:34:47 <graingert> gavinandresen: you should probably call blkindex.dat something different
295 2012-05-08 16:34:51 <graingert> if it can't be moved
296 2012-05-08 16:35:35 <gavinandresen> it can be moved, just run with -detachdb=1
297 2012-05-08 16:36:35 <sipa> or just -detachdb
298 2012-05-08 16:36:46 <sipa> or put detachdb=1 in bitcoin.conf
299 2012-05-08 16:49:46 <sipa> gavinandresen: pushed my sigs for linux; they match
300 2012-05-08 16:50:40 <gavinandresen> sipa: great, thanks, I'll be Mr. Announcer Person now
301 2012-05-08 16:50:52 <graingert> sipa: but I think it should be in the filename
302 2012-05-08 16:51:00 <graingert> whether or not the file is portable
303 2012-05-08 16:51:22 <graingert> also shouldn't it be in .cache
304 2012-05-08 16:51:29 <sipa> ?
305 2012-05-08 16:51:40 <gmaxwell> In the filename??
306 2012-05-08 16:51:41 <graingert> all the blockchain and blkindex stuff
307 2012-05-08 16:51:58 <graingert> gmaxwell: well some indicator to stop people trying to copy it and making support requests
308 2012-05-08 16:52:12 <gmaxwell> graingert: it's allways been uncopyable in some cases.
309 2012-05-08 16:52:18 <graingert> ic
310 2012-05-08 16:52:23 <gmaxwell> s/allways/always/
311 2012-05-08 16:52:46 <gmaxwell> (e.g. if you unclealy shutdown pretty common because the shutdowns were taking a while it's uncopyable)
312 2012-05-08 16:53:55 <graingert> okay
313 2012-05-08 16:54:26 <graingert> alert message
314 2012-05-08 16:55:15 <gmaxwell> Alert message?
315 2012-05-08 16:59:12 <luke-jr> let's alert for every minor bugfix release so people learn to ignore alerts!
316 2012-05-08 17:01:06 <graingert> yes
317 2012-05-08 17:01:07 <graingert> lets
318 2012-05-08 17:01:44 <gmaxwell> graingert: yea, thats _not_ what alerts are for.
319 2012-05-08 17:02:12 <graingert> in that case I think there should be a separate semantic for info
320 2012-05-08 17:02:21 <graingert> maybe not in the chain
321 2012-05-08 17:02:27 <sipa> you mean... release notes?
322 2012-05-08 17:02:39 <graingert> sorry let me make myself clearer
323 2012-05-08 17:02:48 <gmaxwell> well someday when gitian builder is mature we'll have something for that.
324 2012-05-08 17:02:52 <graingert> for OS that don't support a nice update mechanism
325 2012-05-08 17:03:04 <helo> it would be nice if the gui client allowed you to mark your own addresses as "trustworthy"
326 2012-05-08 17:03:05 <graingert> there should be some system for informing users of new releases
327 2012-05-08 17:03:06 <sipa> oh, you mean gitian-updater?
328 2012-05-08 17:03:21 <sipa> not sure about the progress on that
329 2012-05-08 17:03:32 <graingert> even if it's just an rss feed signed with the alert key
330 2012-05-08 17:03:33 <helo> i.e. you generate an address and give it to someone you trust to not double spend
331 2012-05-08 17:03:35 <graingert> or some other key
332 2012-05-08 17:03:50 <graingert> I like the idea of friendly clients
333 2012-05-08 17:04:01 <graingert> so that only one of the clients has to verify each block
334 2012-05-08 17:04:13 <gavinandresen> can somebody update the forum topic here and in #bitcoin (0.6.1 --> 0.6.2)
335 2012-05-08 17:04:17 <sipa> graingert: verifying is not much work, updating the index is
336 2012-05-08 17:04:37 <graingert> sipa: fair enough
337 2012-05-08 17:04:48 <graingert> but a problem I do have is one block chain per user
338 2012-05-08 17:04:53 <graingert> per os
339 2012-05-08 17:05:09 <graingert> I know it can be done with symlinks
340 2012-05-08 17:05:17 <graingert> but I'd like a zero trust system
341 2012-05-08 17:05:35 <graingert> assuming everyone trusts root that it
342 2012-05-08 17:05:36 <graingert> is*
343 2012-05-08 17:05:50 <gmaxwell> Has someone already prodded the website?
344 2012-05-08 17:06:18 <gmaxwell> seems not
345 2012-05-08 17:06:39 <sipa> graingert: the intention is to (one day...) use gitian-updater, where gitian signatures for builds from several people are necessary to initiate a message "New version available!"
346 2012-05-08 17:06:51 <graingert> sipa: nice but
347 2012-05-08 17:06:53 <graingert> ooh
348 2012-05-08 17:06:58 <graingert> reddit just crashed my browser
349 2012-05-08 17:07:44 <graingert> !later tell theymos poke website
350 2012-05-08 17:07:44 <gribble> The operation succeeded.
351 2012-05-08 17:08:05 <gmaxwell> graingert: what are you doing?
352 2012-05-08 17:08:19 <graingert> currently/
353 2012-05-08 17:08:21 <graingert> ?*
354 2012-05-08 17:08:35 <gmaxwell> Why did you tell theymos? I'll have it updated in a second.
355 2012-05-08 17:08:43 <graingert> I thought it was just theymos
356 2012-05-08 17:08:45 <luke-jr> lol
357 2012-05-08 17:08:51 <graingert> !later tell theymos don't poke website
358 2012-05-08 17:08:52 <gribble> The operation succeeded.
359 2012-05-08 17:08:57 <gmaxwell> hah
360 2012-05-08 17:09:50 <sipa> graingert: you never said what comes after "nice but"
361 2012-05-08 17:10:05 <sipa> i hope the answer to that question isn't "t"
362 2012-05-08 17:10:14 <graingert> sipa: nice but, it would be good to get a system that worked
363 2012-05-08 17:10:27 <graingert> before one that was the best possible
364 2012-05-08 17:10:36 <sipa> well, someone will have to implement it
365 2012-05-08 17:11:18 <sipa> not sure how far we are from that
366 2012-05-08 17:11:23 <gmaxwell> okay. Website should be updated in a moment.
367 2012-05-08 17:11:28 <jgarzik> sipa gmaxwell gavinandresen: is 0.7 merge window open?  :)
368 2012-05-08 17:11:49 <gmaxwell> I think so.
369 2012-05-08 17:12:07 <sipa> let's start with pushing the version number to 0.6.99
370 2012-05-08 17:12:16 <sipa> gmaxwell: website is updated
371 2012-05-08 17:12:34 <gmaxwell> woops, I started pulling before bumping the version.
372 2012-05-08 17:12:59 <graingert> gnome have a nice way of doing this
373 2012-05-08 17:13:09 <graingert> even numbers are release and odd are dev
374 2012-05-08 17:13:13 <graingert> or visa versa
375 2012-05-08 17:13:23 <sipa> graingert: all our versions are dev :)
376 2012-05-08 17:13:37 <graingert> yeah well
377 2012-05-08 17:13:45 <graingert> testing
378 2012-05-08 17:13:48 <graingert> then
379 2012-05-08 17:16:01 <DiabloD3> http://blog.dwolla.com/ach-goes-real-time-with-fisync-free-for-banks-and-credit-unions/
380 2012-05-08 17:17:41 <dusty_> Hi all
381 2012-05-08 17:18:01 <dusty_> I'm studying the problem arisen from duplicate coinbase transaction here : http://blockexplorer.com/testnet/block/0000000013aa9f67da178005f9ced61c7064dd6e8464b35f6a8ca8fabc1ca2cf
382 2012-05-08 17:18:37 <dusty_> I've read a post by Pieter Wuille that, if I understand correctly, duplicate transaction will not ever be allowed again
383 2012-05-08 17:18:57 <sipa> dusty_: only in the case that they are fully spent
384 2012-05-08 17:18:58 <dusty_> I would like to be sure that's the case, starting with bitcoin version 0.6
385 2012-05-08 17:19:31 <sipa> you could test it on the testnet
386 2012-05-08 17:19:38 <dusty_> sipa: you mean that if transactions are fully spent a new one with the same hash can be re-created and accepted?
387 2012-05-08 17:19:40 <sipa> (roconnor and i did an experiment to verify that)
388 2012-05-08 17:19:42 <luke-jr> dusty_: enforced by 0.4.4, 0.5.3, and 0.6.0
389 2012-05-08 17:19:57 <sipa> dusty_: yes
390 2012-05-08 17:19:59 <sipa> for now
391 2012-05-08 17:20:18 <sipa> gavinandresen: how are the plans for deploying the block-height-in-coinbase idea?
392 2012-05-08 17:20:38 <dusty_> so, how it's possible that block #45653 and #45550 both includes a transaction spending the same transaction, twice?
393 2012-05-08 17:20:51 <dusty_> (in testnet)
394 2012-05-08 17:21:17 <sipa> i think blockexplorer still uses an old version of bitcoin
395 2012-05-08 17:21:27 <sipa> and the chain forked on that transaction
396 2012-05-08 17:21:57 <dusty_> because the code I'm working on is unable to validate block 0000000000DB2E24D532668F71351A23808720D08B4F29A06FA35B204FCF39E9 since it has a transaction that double-spends the duplicate tx
397 2012-05-08 17:23:28 <sipa> dusty_: actually, no, not that one
398 2012-05-08 17:23:40 <sipa> BIP30 was enabled on testnet on febrary 20
399 2012-05-08 17:23:43 <dusty_> sipa: can you please elaborate? I'm not following
400 2012-05-08 17:24:07 <sipa> since the duplicate transaction is before that date, it was allowed and it simply overwrote the previous one
401 2012-05-08 17:24:40 <dusty_> and that's ok, but how come that at a later date two blocks spend it?
402 2012-05-08 17:25:03 <dusty_> if it's been wrote as only one transaction, it should be spent only once
403 2012-05-08 17:25:31 <sipa> the rule is this: the last transaction with a given hash is the only one that exists in a chain
404 2012-05-08 17:25:36 <sipa> it can be spent normally
405 2012-05-08 17:25:54 <gmaxwell> Bumped to 0.6.99
406 2012-05-08 17:26:11 <sipa> dusty_: whether the older one was already spent, is irrelevant after the duplicate
407 2012-05-08 17:26:56 <sipa> and after feb20 on testnet, or after mar15 on realnet, the duplicate itself is not allowed unless the previous instance of the transaction was already fully spent before said block
408 2012-05-08 17:27:33 <dusty_> sipa: what I mean is that the duplicate appeared *before* being spent
409 2012-05-08 17:27:47 <gavinandresen> jgarzik: yeah, 0.7 merge window open I suppose.
410 2012-05-08 17:28:16 <sipa> dusty_: as i said, the older one is irrelevant after the duplicate
411 2012-05-08 17:28:41 <gavinandresen> sipa: blockheight-in-coinbase would be a great 0.7 rollout, using the process i sketch out in https://gist.github.com/2355445
412 2012-05-08 17:28:43 <gmaxwell> sipa: ready to merge the proxy changes / ipv6 / tor support or are you still working on the details of the tor stuff?
413 2012-05-08 17:28:59 <sipa> dusty_: this is allowed: tx - spend - tx - spend
414 2012-05-08 17:29:09 <sipa> dusty_: this too: tx - tx - spend
415 2012-05-08 17:29:18 <sipa> dusty_: but this isn't: tx - tx - spend - spend
416 2012-05-08 17:29:54 <sipa> dusty_: and after the deployment date, tx - tx is not allowed anymore
417 2012-05-08 17:30:36 <sipa> gmaxwell: let me think; i want to change the command-line arguments to tor still, but maybe ipv6 can be merged
418 2012-05-08 17:30:49 <gavinandresen> my 0.7 TODO list looks like:  testnet reset (I still need to write some code to embed Script unit tests into a testnet chain), then code to support https://gist.github.com/2355445, then the blockheight-in-coinbase change
419 2012-05-08 17:30:53 <dusty_> when you say that tx tx spend spend is not allowed you mean after or before bip30 (or never)?
420 2012-05-08 17:30:59 <sipa> dusty_: never
421 2012-05-08 17:32:00 <gavinandresen> oh, and another 0.7 TODO: I really want to detect non-DER-encoded signatures and treat them as non-standard
422 2012-05-08 17:32:15 <gmaxwell> gavinandresen: thats a great idea, we could premine the testnet flush so that the first N blocks contain a bunch of unit tests, and then then the resulting coin balace there is then sent to a black hole, one block higher.. then test-net-in-a-box can then split off one block before that.
423 2012-05-08 17:32:50 <gmaxwell> sipa: was anything more going to happen on https://github.com/bitcoin/bitcoin/pull/1159  (Use block time for wallet transactions found in rescan) or should I yank it as is?
424 2012-05-08 17:32:52 <dusty_> sipa: ok, I did'nt notice that the tx was redeemd before being mined again
425 2012-05-08 17:32:56 <dusty_> sipa: thanks
426 2012-05-08 17:33:27 <gmaxwell> (I'm going through pulls that I've already tested indivigually and pulling them now)
427 2012-05-08 17:33:28 <sipa> gmaxwell: i don't think there's consensus on that yet
428 2012-05-08 17:33:57 <gmaxwell> yea, I wasn't sure if it was in "something must be done! Is this it?" state.
429 2012-05-08 17:34:09 <gmaxwell> Loadblock?
430 2012-05-08 17:34:14 <dusty_> I've another question if someone is so kind to enlighten me: I've seen that bitcoin 0.6 and later are very, very fast to download the blockchain when starting from scratch, how it does it?
431 2012-05-08 17:34:36 <gmaxwell> dusty_: some stupidity in the database settings was fixed.
432 2012-05-08 17:34:43 <sipa> dusty_: it uses an in-RAM cache of 25 MiB, instead of the crappy default of a few kilobytes
433 2012-05-08 17:34:57 <luke-jr> gmaxwell: that's a problematic pull
434 2012-05-08 17:35:05 <gmaxwell> luke-jr: loadblocks?
435 2012-05-08 17:35:08 <luke-jr> gmaxwell: no, #1159
436 2012-05-08 17:35:20 <dusty_> sipa: ah ok. But every block downloaded is being validate anyway? Or just checked for integrity?
437 2012-05-08 17:35:22 <gmaxwell> luke-jr: well thats why I asked.
438 2012-05-08 17:35:33 <sipa> dusty_: before the last checkpoint, signatures aren't verified
439 2012-05-08 17:35:41 <sipa> but except for that, all checks are being done
440 2012-05-08 17:35:48 <gmaxwell> ^ though that wasn't something changed in 0.6.0.
441 2012-05-08 17:35:58 <gavinandresen> ... we should do another checkpoint when 0.7 is close to baked, too....
442 2012-05-08 17:36:01 <dusty_> sipa: thanks, that was I was thinking
443 2012-05-08 17:36:22 <sipa> gmaxwell: if nobody objects, i'd pull loadblocks
444 2012-05-08 17:36:23 <gavinandresen> ... and update the seed nodes... (time to open a couple of github issues)
445 2012-05-08 17:36:25 <gmaxwell> Whatever happened to bluematt's attempt to thread validation.
446 2012-05-08 17:36:32 <dusty_> also, I would like to know how a checkpoint is being determined (decided)
447 2012-05-08 17:36:38 <gavinandresen> loadblocks ++
448 2012-05-08 17:36:51 <dusty_> because I'm thinking to rely on a date instead of a checkpoint
449 2012-05-08 17:36:57 <sipa> gavinandresen: nanotube and me are running a crawler, and i have a script to combine the results into a seed list
450 2012-05-08 17:36:58 <luke-jr> dusty_: &
451 2012-05-08 17:37:06 <gavinandresen> sipa: spiffy
452 2012-05-08 17:37:20 <gmaxwell> dusty_: it's just set prior to major releases at a height thousands of blocks back to make sure that it doesn't have any influence in the selection of the longest chain.
453 2012-05-08 17:37:24 <dusty_> for example: everything older than 1 week does not need validation , while catching up the blockchain
454 2012-05-08 17:37:43 <dusty_> gmaxwell: so a date would work anyway
455 2012-05-08 17:37:51 <dusty_> and it needs no hardcoded value
456 2012-05-08 17:37:53 <gmaxwell> dusty_: Thats not a good idea.
457 2012-05-08 17:38:01 <dusty_> gmaxwell: why?
458 2012-05-08 17:38:19 <gmaxwell> I mean it's a fine idea for a SPV node, since they can't do otherwise.
459 2012-05-08 17:38:24 <sipa> if someone sybil attacks you, they can get you to trust a chain with invalid signatures
460 2012-05-08 17:39:07 <gmaxwell> Which spends anyone elses money... so they didn't even need to have money of their own involved in the attack.
461 2012-05-08 17:39:13 <topi`_> I guess this isn't normal:
462 2012-05-08 17:39:14 <topi`_> InvalidChainFound: invalid block=000000000000020bd6f6  height=179311  work=317793108775545536672
463 2012-05-08 17:39:30 <gribble> 179311
464 2012-05-08 17:39:30 <sipa> ;;bc,blocks
465 2012-05-08 17:39:38 <dusty_> sipa: ok, I get it. You mean a sybil attack from the very first run of my client
466 2012-05-08 17:39:38 <topi`_> a lot of invalid chains... and my block count stays at 178500
467 2012-05-08 17:39:55 <sipa> yes, while you are downloading the chain
468 2012-05-08 17:39:58 <topi`_> ERROR: AcceptToMemoryPool() : FetchInputs failed 2ea938d12b
469 2012-05-08 17:40:16 <luke-jr> topi`_: can you post your full debug.log on pastebin or something?
470 2012-05-08 17:40:19 <topi`_> is this an error from the database? maybe my disk is broken
471 2012-05-08 17:40:26 <gribble> New news from bitcoinrss: gavinandresen opened issue 1224 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1224> || gavinandresen opened issue 1223 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1223>
472 2012-05-08 17:40:44 <luke-jr> topi`_: either your db is corrupt, or you're encountering a bug sipa is trying to fix
473 2012-05-08 17:40:56 <sipa> topi`_: my node didn't even see that block yet
474 2012-05-08 17:40:56 <topi`_> well it's 33 megs
475 2012-05-08 17:40:59 <gmaxwell> dusty_: thats one reason why we have checkpoints. To prevent sybil attacks that start at client start... checkpoints mean if you can get the software securely you're good at least up to the current height of the chain, which is difficult to forge.
476 2012-05-08 17:41:04 <topi`_> any string I should search for?
477 2012-05-08 17:41:07 <dusty_> sipa: last question :) does DNS seeding exists for testnet? or we still use only IRC for it?
478 2012-05-08 17:41:14 <sipa> dusty_: only IRC there
479 2012-05-08 17:41:22 <gmaxwell> luke-jr: hm? or someone just mined another crap BIP16 failing block.
480 2012-05-08 17:41:31 <luke-jr> gmaxwell: he's stuck at 178500
481 2012-05-08 17:41:35 <dusty_> gmaxwell: yes, that's now clear to me, thanks
482 2012-05-08 17:41:40 <gmaxwell> luke-jr: oh. okay.
483 2012-05-08 17:41:45 <sipa> luke-jr: oh, missed that as well
484 2012-05-08 17:42:02 <BlueMatt> gmaxwell: you mean my parallelcheck branch?
485 2012-05-08 17:42:16 <luke-jr> topi`_: lines around REORGANIZE
486 2012-05-08 17:42:20 <BlueMatt> (its based on cblockstore, and Ive been rebasing it recently)
487 2012-05-08 17:42:34 <BlueMatt> broke it on the last rebase, but its coming back...
488 2012-05-08 17:43:23 <topi`_> I also find this , albeit infrequently: ERROR: AcceptToMemoryPool() : CheckTransaction failed
489 2012-05-08 17:43:28 <gmaxwell> luke-jr: I think we want https://github.com/bitcoin/bitcoin/pull/886 sometime soon, but there are no comments on the pull and it needs rebasing.  If you rebase I'll review/test and ack (assuming I find no issues)
490 2012-05-08 17:44:05 <topi`_> received block 000000000000020bd6f6
491 2012-05-08 17:44:40 <gmaxwell> topi`_: welp 000000000000020bd6f6 is valid, so your database is corrupt.
492 2012-05-08 17:44:43 <sipa> topi`_: can you shutdown and restart your client with -checklevel=6
493 2012-05-08 17:44:54 <gmaxwell> topi`_: any idea how it could have become corrupt?
494 2012-05-08 17:45:10 <topi`_> gmaxwell: no idea, except mass storage failure
495 2012-05-08 17:45:27 <gmaxwell> sipa: shouldn't that also have a -checkblocks=0
496 2012-05-08 17:45:52 <sipa> gmaxwell: his split is less than 2500 blocks back
497 2012-05-08 17:46:18 <gmaxwell> sipa: but if the missing index enery is further?
498 2012-05-08 17:46:29 <sipa> true
499 2012-05-08 17:46:40 <sipa> topi`_: -checkblocks -checklevel=6
500 2012-05-08 17:47:02 <topi`_> topi@uni:~$ bitcoind getblockcount
501 2012-05-08 17:47:12 <topi`_> I think  this is where my split is
502 2012-05-08 17:47:18 <sipa> which version, by the way?
503 2012-05-08 17:48:50 <topi`_> 0.5.99beta, from git HEAD 2e55523
504 2012-05-08 17:49:10 <topi`_> Merge pull request #746 from laanwj/tdesc_ro
505 2012-05-08 17:49:30 <sipa> topi`_: please update first
506 2012-05-08 17:49:47 <topi`_> ok. what about -checkblocks ?
507 2012-05-08 17:50:04 <sipa> update first; -checklevel was added in 0.6.0
508 2012-05-08 17:50:05 <luke-jr> gmaxwell: rebased
509 2012-05-08 17:51:01 <luke-jr> topi`_: 0.5.99 has known bugs
510 2012-05-08 17:52:16 <topi`_> would this be a valid reason for the hiccups?
511 2012-05-08 17:52:28 <sipa> yes
512 2012-05-08 17:53:14 <topi`_> to me, this looks just database corruption, but can it be something else?
513 2012-05-08 17:53:35 <sipa> no
514 2012-05-08 17:53:43 <luke-jr> sipa: early BIP16?
515 2012-05-08 17:54:04 <topi`_> damn. so I need to zap my db and load all blks from the beginning...
516 2012-05-08 17:54:09 <sipa> luke-jr: that wouldn't be caught by CheckBlocks
517 2012-05-08 17:54:30 <gmaxwell> topi`_: 0.6 syncs much faster than later...
518 2012-05-08 17:54:48 <gmaxwell> topi`_: or you could take the bleeding edge 0.6.99 from git and use -loadblocks
519 2012-05-08 17:55:20 <sipa> topi`_: if you update to git HEAD now, you can move your existing blk0001.dat to somewhere else, delete the datadir (except wallet.dat), and use -loadblock=<location_of_old_blk00001.dat>
520 2012-05-08 17:57:58 <topi`_> I had to reboot the machine 15 days ago, maybe that coincides with this bad block
521 2012-05-08 17:58:07 <sipa> gmaxwell: you want to pull proxy/ipv6/tor already? i'm unsure about the command-line options now, but those are relatively easy changes that can be done later, to get the core changes tested already
522 2012-05-08 17:58:26 <topi`_> since most often the bitcoind process takes longer to clean up than the debian rc scripts wait until reboot
523 2012-05-08 17:58:44 <sipa> topi`_: 0.6.1 and later shutdown much faster
524 2012-05-08 17:59:04 <gmaxwell> sipa: I basically want to pull everything merge ready now to avoid further rebasing mess later... plus to get more people to try it out and provide feedback.  Though there is no rush. I know you and I talked about some cli changes.
525 2012-05-08 18:00:24 <topi`_> sipa: what kind of changes boost the shutdown so much?
526 2012-05-08 18:00:43 <sipa> topi`_: not detaching the block database from the db env
527 2012-05-08 18:00:53 <topi`_> EXCEPTION: 11DbException
528 2012-05-08 18:00:59 <topi`_> ok, I have other issues as well
529 2012-05-08 18:01:37 <topi`_> I compiled my kernel to use 2G/2G user/kernel space instead of the usual 3/1 split, so maybe the Db wants to use more than 2G virtual adderssing and boom
530 2012-05-08 18:01:51 <gmaxwell> topi`_: were you running 0.5.99 with any special date related arguments by any chance?
531 2012-05-08 18:02:00 <topi`_> this is complicated.. I was forced to do that because of a stupid kernel alloc map :)
532 2012-05-08 18:02:32 <sipa> gmaxwell: there will almost certainly be several changes that need to be done anyway, like ipv6 dns seeding, changes to command-line defaults, maybe extra listening code for old windows nodes (i heard they cannot listen to both v4 and v6)
533 2012-05-08 18:02:36 <topi`_> gmaxwell: no... I'm not aware of any date-related args
534 2012-05-08 18:03:09 <sipa> gmaxwell: but most of those will be easier when they get tested, so the question is whether that testing needs to be done before or after merging
535 2012-05-08 18:04:16 <gmaxwell> sipa: I think we should hold off for a few days in any case, just incase the pile of stuff being pulled at the moment destablizes anything.
536 2012-05-08 18:04:25 <sipa> ok
537 2012-05-08 18:06:52 <sipa> we currently have two command-line options that are GUI specific
538 2012-05-08 18:07:00 <sipa> (-server and -lang)
539 2012-05-08 18:07:10 <sipa> i think they should be moved to the gui config file
540 2012-05-08 18:07:17 <sipa> s/file/settings/
541 2012-05-08 18:07:56 <sipa> wump: ^
542 2012-05-08 18:09:34 <topi`_> any ideas if berkeley DB actually mmap()s that blk0001.dat? then it cannot grow bigger than 2 GB (for me) or 3G for most linux installations
543 2012-05-08 18:10:03 <topi`_> at least on 32bit kernels
544 2012-05-08 18:10:09 <gmaxwell> topi`_: the system will intentionally not grow it that big in any case due to some FS limitations.
545 2012-05-08 18:10:17 <gmaxwell> (though no, we don't mmap it)
546 2012-05-08 18:10:39 <topi`_> ok. so what will happen? a blk0002.dat will be created?
547 2012-05-08 18:10:53 <sipa> yes
548 2012-05-08 18:11:09 <sipa> topi`_: blk0001.dat is not a BDB file, by the way
549 2012-05-08 18:11:34 <topi`_> then what is BDB used for, anyway?
550 2012-05-08 18:11:54 <BlueMatt> blkindex.dat
551 2012-05-08 18:12:07 <BlueMatt> (and wallet, addr...)
552 2012-05-08 18:12:18 <topi`_> of course
553 2012-05-08 18:13:20 <BlueMatt> yep
554 2012-05-08 18:13:20 <gavinandresen> yup, append-only
555 2012-05-08 18:13:20 <topi`_> so blk0001.dat just holds raw block data? no fancy structures.
556 2012-05-08 18:13:30 <gmaxwell> topi`_: what exactly are you trying right now?
557 2012-05-08 18:13:35 <topi`_> when running with -checkblocks
558 2012-05-08 18:13:43 <gmaxwell> Are you still running that 0.5.99 code?
559 2012-05-08 18:14:15 <topi`_> yes
560 2012-05-08 18:14:19 <gmaxwell> _STOP_ You're hitting the issues with bdb and large reorgs.
561 2012-05-08 18:15:21 <topi`_> well I guess my best course of action would be downloading the blkchain from scratch (aside from compiling the new client)?
562 2012-05-08 18:15:25 <gmaxwell> Upgrade to 0.6.2 or cross-grade to one of luke's stable releases and checkblocks may fix you. Or alternatively to the current git and you can use loadblock.
563 2012-05-08 18:15:39 <gmaxwell> No. thats not a good coarse of action at all.
564 2012-05-08 18:15:44 <sipa> topi`_: no you first upgrade, then try again, and if it persists, then you can redownload
565 2012-05-08 18:15:46 <gmaxwell> You will just get stuck again at some other point in time.
566 2012-05-08 18:15:51 <topi`_> ok
567 2012-05-08 18:16:26 <topi`_> what's the perceived state of git HEAD now? any showstopper bugs?
568 2012-05-08 18:16:37 <luke-jr> topi`_: probably.
569 2012-05-08 18:16:42 <luke-jr> topi`_: get v0.6.2
570 2012-05-08 18:16:49 <jgarzik> I assume wumpus will pull GUI stuff
571 2012-05-08 18:16:51 <BlueMatt> anyone testing cblockstore yet?
572 2012-05-08 18:16:52 <jgarzik> for bitcoin-qt
573 2012-05-08 18:17:01 <jgarzik> BlueMatt: is the cblockstore pull req up to date?
574 2012-05-08 18:17:09 <BlueMatt> its back like 2 days now, but mostly
575 2012-05-08 18:17:17 <luke-jr> jgarzik: threads/keepalive?
576 2012-05-08 18:18:43 <sipa> topi`_: no known issues with git head right now, but we've just started pulling for 0.7.0, so there are several untested things in
577 2012-05-08 18:18:56 <sipa> i you want something usable, i'd advise 0.6.2
578 2012-05-08 18:19:37 <gmaxwell> pretty cool that you can walk a txn back to its origin from the CLI easily now, e.g.
579 2012-05-08 18:19:40 <gmaxwell> LAST=d583a9e58d93d54b93226bb97b668f30ce8a95a85ddc6faac15729d0b29f0824 ; while true ; do export LAST=`./bitcoind -rpcuser=greg -rpcpassword=greg1 gettransaction $LAST | grep -A 1 'prevout' | head -2 | tail -1 | cut -d'"' -f4` ; echo $LAST ; done
580 2012-05-08 18:20:07 <BlueMatt> nice
581 2012-05-08 18:21:02 <topi`_> sipa: agreed, I stayed on the safe side and did git checkout v0.6.2 :)
582 2012-05-08 18:21:25 <sipa> but you kept running an old pre-release-candidate for months?
583 2012-05-08 18:21:32 <gmaxwell> haha
584 2012-05-08 18:22:50 <sipa> BlueMatt: that relaymessage thing looks ugly, sure there's no neater way?
585 2012-05-08 18:23:43 <sipa> i'll have a look at it later
586 2012-05-08 18:24:11 <BlueMatt> its pretty ugly, yea, the other options is to move ResendWalletTransactions to a CBlockStore function and call it back in SendMessages
587 2012-05-08 18:24:18 <BlueMatt> which, imho, is even uglier...
588 2012-05-08 18:24:33 <topi`_> sipa: well, I was having issues with my machine so my attention was diverted to more mundane tasks than recompiling new bitcoind's :/
589 2012-05-08 18:24:40 <sipa> haha
590 2012-05-08 18:24:44 <BlueMatt> (thats how it used to be done)
591 2012-05-08 18:25:24 <topi`_> and no btc services running (yet) on my host
592 2012-05-08 18:25:34 <topi`_> but am planning on something anyways :)
593 2012-05-08 18:25:38 <gmaxwell> sipa: the broken stuck fix is still in master.  Should we at least pull in the current best hope version of that?
594 2012-05-08 18:25:57 <jgarzik> luke-jr: you raised a valid point I must investigate, before pulling #1101
595 2012-05-08 18:26:04 <gmaxwell> sipa: I'm thinking of trying to fix it by removing the difficulty check then mining forks ...
596 2012-05-08 18:26:24 <jgarzik> or, more correctly, you raised a point I must investigate, in order to determine if it is a valid criticism ;-)
597 2012-05-08 18:26:30 <sipa> gmaxwell: that'd be very useful
598 2012-05-08 18:26:35 <sipa> jgarzik: which?
599 2012-05-08 18:26:40 <sipa> gmaxwell: but a lot of work...
600 2012-05-08 18:26:42 <jgarzik> sipa: #1101
601 2012-05-08 18:26:49 <BlueMatt> anyone wanna send me a copy of some large reorg chains, and Ill set up a jenkins test-case for them?
602 2012-05-08 18:26:50 <jgarzik> sipa: http 1.1/threading
603 2012-05-08 18:26:51 <sipa> jgarzik: yes, but which criticism?
604 2012-05-08 18:27:04 <gmaxwell> sipa: I can't think of any other way to make sure we've got this right.
605 2012-05-08 18:27:06 <jgarzik> sipa: loop exit states/conditions
606 2012-05-08 18:27:34 <jgarzik> sipa: I would like to encourage you to pull ipv6 very soon, before most other changes
607 2012-05-08 18:27:38 <topi`_> I get this odd warning:
608 2012-05-08 18:27:43 <jgarzik> sipa: are there any ipv6 blockers?
609 2012-05-08 18:27:52 <topi`_> maybe a 32bit/64bit integer issue
610 2012-05-08 18:28:28 <gmaxwell> BlueMatt: there are no valid large reorgs though... I suppose we could raise some money to create ones... otherwise the alternative is providing a hidden option to let through some invalid one we can use as a test case.
611 2012-05-08 18:28:39 <sipa> jgarzik: probably several command-line things to change (i've been discussing with gmaxwell about it), support for binding to particular (and several) listen addresses, ...
612 2012-05-08 18:28:57 <gmaxwell> BlueMatt: I think the better solution is to setup testnet to test this.
613 2012-05-08 18:28:58 <BlueMatt> gmaxwell: or testnet-in-a-box ones, with a lot of blocks, but low diff
614 2012-05-08 18:29:48 <sipa> i wouldn't mind pulling already though
615 2012-05-08 18:29:55 <jgarzik> sipa: such binding support isn't a blocker, IMO.
616 2012-05-08 18:30:21 <sipa> jgarzik: it may be on windows XP, as i heard that it can't listen to IPv6 and IPv4 at once
617 2012-05-08 18:30:28 <jgarzik> sipa: let's do it.  any remaining problems will get flushed out.  we need to maximize the upstream bitcoin.git testing period for ipv6, IMO
618 2012-05-08 18:30:32 <sipa> so it may end up listening to IPv6 only
619 2012-05-08 18:30:55 <sipa> gmaxwell: your opinion?
620 2012-05-08 18:30:56 <jgarzik> sipa: I dunno about Windows, but it -is- true that some OS's will not bind to IPv4+IPv6 in a single bind, yes.
621 2012-05-08 18:31:00 <jgarzik> hpux might do it
622 2012-05-08 18:31:14 <jgarzik> but there is also ipv4-mapped support in those, enabled with an ioctl
623 2012-05-08 18:32:10 <jgarzik> ipv6 is the sort of feature where we need to find the "bumps in the road" and the best way to do that is start deploying at this point
624 2012-05-08 18:32:24 <sipa> my proxystuff, ipv6 and torhs branches all build further upon eachother, so we could decide to pull only the first or the second already
625 2012-05-08 18:33:32 <gmaxwell> Ha. Well, I was just calling for that earler. I'm fine either way. I do want to pull soon. But soon could be in a couple days when sipa has had a chance to do the latest commandline spins too
626 2012-05-08 18:34:14 <jgarzik> gmaxwell: that sort of thing should not block upstream commits.  merge early, merge often.
627 2012-05-08 18:36:41 <gmaxwell> https://github.com/bitcoin/bitcoin/pull/936  < still has the RPC bloat,  do we really want the seperate submitblock call?
628 2012-05-08 18:37:45 <BlueMatt> can we close https://github.com/bitcoin/bitcoin/pull/932
629 2012-05-08 18:38:42 <luke-jr> gmaxwell: what bloat? and yes
630 2012-05-08 18:39:02 <gmaxwell> luke-jr: why?
631 2012-05-08 18:39:28 <luke-jr> gmaxwell: because there's no better way to do it, and it's part of the spec?
632 2012-05-08 18:39:34 <gmaxwell> (or direct me to a discussion?)
633 2012-05-08 18:39:46 <gmaxwell> luke-jr: you can submit blocks directly to getmemorypool
634 2012-05-08 18:39:59 <luke-jr> gmaxwell: there was a thread on the ML, not sure if that came up in it
635 2012-05-08 18:40:10 <sipa> luke-jr: the spec can be adapted, nobody is using it yet
636 2012-05-08 18:40:12 <luke-jr> gmaxwell: getmemorypool submission is deprecated, and doesn't give reasons for rejection
637 2012-05-08 18:40:16 <luke-jr> sipa: not true
638 2012-05-08 18:40:58 <gmaxwell> luke-jr: Thats the 'better way' to do it. I think?
639 2012-05-08 18:41:04 <luke-jr> gmaxwell: no, I don't.
640 2012-05-08 18:41:50 <sipa> the only reason for rejection is "rejected" ?
641 2012-05-08 18:42:00 <luke-jr> sipa: no?
642 2012-05-08 18:42:11 <luke-jr> well, that's all bitcoind supports in that pullreq
643 2012-05-08 18:42:37 <sipa> ic
644 2012-05-08 18:42:58 <jgarzik> we need a special github label for "luke-jr's opinion requires outside confirmation"
645 2012-05-08 18:43:36 <luke-jr> jgarzik: except there's already outside confirmation?
646 2012-05-08 18:43:39 <luke-jr> troll
647 2012-05-08 18:43:49 <gmaxwell> I don't see any reason that getmemorypool can't just do the same thing?  Sorry to be a pest.. we currently have a lot of RPC calls.. and I'll like to avoid adding additional ones unless they're propertly different functions rather than variations on ones we have.
648 2012-05-08 18:44:25 <luke-jr> gmaxwell: there's no reason a *get* should be expected to act
649 2012-05-08 18:44:44 <luke-jr> gmaxwell: getmemorypool can't reasonably do the same thing without adding flags
650 2012-05-08 18:44:47 <jgarzik> blinks
651 2012-05-08 18:44:52 <luke-jr> which might be desired anyway, for the noncerange thing I suppose
652 2012-05-08 18:45:06 <jgarzik> hrm, I clicked "merge" on github, to do sign comparison warnings
653 2012-05-08 18:45:10 <jgarzik> but no update
654 2012-05-08 18:45:23 <gmaxwell> jgarzik: yea, it does that sometimes you need to merge fast after loading the page for some reason.
655 2012-05-08 18:45:28 <luke-jr> gmaxwell: remember there was objection to makign the spec require HTTP (for headers)
656 2012-05-08 18:46:14 <jgarzik> wtf
657 2012-05-08 18:46:32 <jgarzik> gmaxwell: well now there are closed pull requests... where I clicked 'merge', but they did not merge.
658 2012-05-08 18:46:41 <gmaxwell> woah.
659 2012-05-08 18:46:43 <gmaxwell> :-/
660 2012-05-08 18:47:02 <sipa> luke-jr: i agree with that criticism actually, you don't need to do split communication over two protocol layers
661 2012-05-08 18:47:26 <jgarzik> fsck
662 2012-05-08 18:47:32 <jgarzik> now some shit is lost
663 2012-05-08 18:47:40 <sipa> my concern with BIP22 is that it is too complicated, defines too many things implementors need to deal with
664 2012-05-08 18:47:46 <jgarzik> well, not lost, but gotta troll manually through 'closed' pull reqs
665 2012-05-08 18:47:57 <sipa> but i am no such implementor, and forrestv ACKed it
666 2012-05-08 18:48:36 <gmaxwell> jgarzik: sort by updated.
667 2012-05-08 18:48:39 <topi`_> sipa: I got a new message now, after -checking with the 0.6.2 client...
668 2012-05-08 18:48:41 <gmaxwell> jgarzik: at least that should help.
669 2012-05-08 18:48:48 <topi`_> LoadBlockIndex() : *** found bad block at 177844, hash=0000000000000324047bbbd7f320fb650000489eafa30f5b295d2672de040f4b
670 2012-05-08 18:48:51 <topi`_> LoadBlockIndex(): *** spending transaction of 6d71ebaaef63f3940c0ff8d90625255a19e88760f005d23d2a136cd58fc1b205:1 does not spend it
671 2012-05-08 18:49:13 <gmaxwell> Thats a riddle of an error message.
672 2012-05-08 18:49:23 <topi`_> is this because of the log level 6?
673 2012-05-08 18:49:27 <gmaxwell> Tree in forest falls with great sound but no sound at all.
674 2012-05-08 18:50:11 <sipa> gmaxwell: the transaction marked to be the spender of that txout, does not actually spend it
675 2012-05-08 18:50:48 <sipa> topi`_: but the block is already bad, so you can expect almost any error message afterwards
676 2012-05-08 18:50:57 <topi`_> but does that sound like a db corruption? evidently there's a "sane" tx marked for that txout ...
677 2012-05-08 18:51:24 <sipa> it sounds like db corruption yes
678 2012-05-08 18:51:43 <topi`_> so no checksums in any fields?
679 2012-05-08 18:52:01 <topi`_> so that it would immediately see that such transaction was nonexistent
680 2012-05-08 18:52:26 <sipa> topi`_: the best checksum available, namely the block itself, already failed
681 2012-05-08 18:52:38 <sipa> that means it's possible the block contains arbitrary data
682 2012-05-08 18:52:38 <topi`_> good point
683 2012-05-08 18:52:45 <sipa> there's no point in looking further
684 2012-05-08 18:52:47 <BlueMatt> anyone else pissed that OO has forked...cant apache just drop OO...
685 2012-05-08 18:52:57 <sipa> openoffice?
686 2012-05-08 18:53:04 <gmaxwell> BlueMatt: yea, it's annoying. Libreoffice is really great though.
687 2012-05-08 18:53:11 <BlueMatt> sipa: yea
688 2012-05-08 18:53:20 <sipa> haven't used it in years
689 2012-05-08 18:53:21 <BlueMatt> gmaxwell: agreed, so why does apache bother with OO...
690 2012-05-08 18:53:28 <luke-jr> sipa: reworked getblock_full with enums
691 2012-05-08 18:53:28 <topi`_> why pissed? so just use libreoffice :)
692 2012-05-08 18:53:38 <gmaxwell> Of course I wonder if libreoffice will go away when oracle continues step two in their quest to sue everyone. :-/
693 2012-05-08 18:54:29 <luke-jr> jgarzik: LOL @ https://github.com/bitcoin/bitcoin/pull/979#issuecomment-5585453 - wumpus already merged it in another commit :p
694 2012-05-08 18:55:25 <gmaxwell> What better reaso no nak it then?
695 2012-05-08 18:56:41 <sipa> haha!
696 2012-05-08 18:57:51 <BlueMatt> gmaxwell: well, yea...
697 2012-05-08 18:57:51 <jgarzik> ok, pull #209 (use cwd in 'backupwallet' RPC, if 127.0.0.1):  (a) close, (b) merge, (c) close, but update code to require full pathname, (d) other
698 2012-05-08 18:57:53 <jgarzik> I vote (c)
699 2012-05-08 18:58:18 <sipa> (c) or (d): send over RPC
700 2012-05-08 18:59:04 <sipa> (but that's really a rewrite anyway)
701 2012-05-08 18:59:41 <gmaxwell> sipa +1
702 2012-05-08 19:01:08 <luke-jr> sipa: what's the plan for this failed block-unstuck fix?
703 2012-05-08 19:01:17 <luke-jr> sipa: revert, leave till fixed?
704 2012-05-08 19:01:55 <sipa> gmaxwell wanted to set up an elaborate test to verify whether my last (no pullreq yet) fix worked
705 2012-05-08 19:02:06 <gmaxwell> luke-jr: you rebased https://github.com/bitcoin/bitcoin/pull/886 too fast for me, and I pulled sipa's part of it out from under you.
706 2012-05-08 19:02:22 <gmaxwell> sipa: its going to take me a couple days to do that.
707 2012-05-08 19:02:22 <luke-jr> I thought it was verified non-working
708 2012-05-08 19:02:33 <gmaxwell> we should probably fix the clearly broken part of the current code at least.
709 2012-05-08 19:02:36 <luke-jr> gmaxwell: is it a problem?
710 2012-05-08 19:03:07 <sipa> luke-jr: nah, we haven't found a real test case yet
711 2012-05-08 19:03:52 <luke-jr> gmaxwell: I mean, do you want me to rebase again?
712 2012-05-08 19:03:54 <gmaxwell> luke-jr: rebase again so I can actually merge.
713 2012-05-08 19:04:11 <gmaxwell> it did for some reason.
714 2012-05-08 19:04:16 <sipa> luke-jr: https://github.com/sipa/bitcoin/commit/1ec1702ad6831078f767068e55200abc59cb6d5e
715 2012-05-08 19:04:18 <luke-jr> weird
716 2012-05-08 19:04:19 <gmaxwell> at least via the webui.
717 2012-05-08 19:04:25 <sipa> that's the hopefully-fix
718 2012-05-08 19:04:49 <gmaxwell> sipa: by " clearly broken" I mean the missing break;
719 2012-05-08 19:05:15 <luke-jr> gmaxwell: rebased
720 2012-05-08 19:05:21 <sipa> right, that may at least make it solve stuck nodes
721 2012-05-08 19:05:30 <sipa> but it will keep re-requesting old blocks too
722 2012-05-08 19:05:59 <gmaxwell> Can someone point me to a bip16 txn in the main chain?
723 2012-05-08 19:06:26 <gribble> New news from bitcoinrss: Diapolo opened pull request 1225 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1225>
724 2012-05-08 19:09:18 <jgarzik> sipa: is #829 the lowest dependency in the ipv6/tor/etc. pull req chain?
725 2012-05-08 19:09:44 <jgarzik> heh
726 2012-05-08 19:10:55 <sipa> jgarzik: oh, i actually forgot that one existed as well
727 2012-05-08 19:11:02 <gmaxwell> I guess we're still missing a transactions-by-address.. but that would need an extra index.
728 2012-05-08 19:11:30 <sipa> jgarzik: actually, no, superceded, as proxystuff was moved to before that point
729 2012-05-08 19:11:33 <sipa> i'll close
730 2012-05-08 19:12:19 <sipa> jgarzik: #1141 -> #1021 -> #1174
731 2012-05-08 19:26:39 <gribble> New news from bitcoinrss: Diapolo opened pull request 1226 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1226>
732 2012-05-08 19:46:48 <gmaxwell> luke-jr: okay luke, I give up how the @#$@# am I supposted to specify the decompositions in this stuff?
733 2012-05-08 19:46:49 <gribble> New news from bitcoinrss: Diapolo opened issue 1227 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1227> || Diapolo opened pull request 1226 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1226>
734 2012-05-08 19:49:06 <sipa> gmaxwell: ./bitcoind gettransaction '{"optionname":"value", ...}'
735 2012-05-08 19:49:14 <sipa> i suppose
736 2012-05-08 19:50:32 <gmaxwell> I tried that.
737 2012-05-08 19:51:23 <gmaxwell> oh crap what I tried was "{'script':'hex'}"
738 2012-05-08 19:51:27 <gmaxwell> damn you json.
739 2012-05-08 19:53:21 <sipa> haha
740 2012-05-08 19:57:03 <gribble> New news from bitcoinrss: burger2 opened issue 1228 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1228>