1 2014-08-26 01:14:46 <gubatron> i'll be broadcasting live OpenBazaar hacking, http://youtu.be/EfV585sNcsQ (could use another pair of eyes to yell when I'm about to make a mistake)
2 2014-08-26 01:36:42 <BlueMatt> lol, due to lack of ntp one of the relay servers received a block before the other had sent it according to logs...
3 2014-08-26 01:44:55 <BlueMatt> sooo......now that we're switching to travis, what are we gonna do with the pull-tester server?
4 2014-08-26 01:45:02 <BlueMatt> sipa/gmaxwell?
5 2014-08-26 01:45:15 <BlueMatt> wumpus:
6 2014-08-26 01:48:37 <Luke-Jr> BlueMatt: doesn't travis need to run on some server?
7 2014-08-26 01:48:49 <BlueMatt> travis runs on travis
8 2014-08-26 01:48:54 <BlueMatt> its a hosted solution thingg
9 2014-08-26 01:48:55 <BlueMatt> y
10 2014-08-26 01:50:02 <Luke-Jr> ew
11 2014-08-26 01:50:24 <Luke-Jr> so now someone injecting a backdoor just has to have access to some hosted service to hide it?
12 2014-08-26 01:50:35 <BlueMatt> for those builds, ye
13 2014-08-26 01:50:36 <BlueMatt> s
14 2014-08-26 01:51:21 <Luke-Jr> I mean, hopefully peer review would catch it still, but still
15 2014-08-26 01:51:34 <BlueMatt> hmm?
16 2014-08-26 01:51:43 <BlueMatt> no one peer reviews the travis infrastructure
17 2014-08-26 01:51:55 <BlueMatt> and its just a pull-tester replacement, its not taking over scm
18 2014-08-26 01:51:56 <Luke-Jr> BlueMatt: of modifications to BCCore
19 2014-08-26 01:52:07 <BlueMatt> oh, you mean of test-case passing?
20 2014-08-26 01:52:08 <BlueMatt> yea
21 2014-08-26 02:30:45 <ben_vulpes> hey gpg users: when you want to get your keyid, how do you go about doing so?
22 2014-08-26 02:30:56 <ben_vulpes> (note, i'm not asking *how*, but rather how *you* do it)
23 2014-08-26 02:34:40 <LoRez> gpg --list-secret-keys
24 2014-08-26 02:35:16 <ben_vulpes> LoRez: and then copy/paste?
25 2014-08-26 02:37:28 <LoRez> if necessary
26 2014-08-26 05:07:46 <mrebola> anybody here?
27 2014-08-26 06:07:31 <wumpus> Luke-Jr: I'd hope there are stil some people that run tests locally.
28 2014-08-26 06:08:12 <wumpus> (I do, at least)
29 2014-08-26 06:11:13 <wumpus> BlueMatt: good question re: the server, I think it makes sense to keep it running for a while still at least to see if Travis really replaces it
30 2014-08-26 06:12:10 <BlueMatt> wumpus: sure, sure
31 2014-08-26 06:12:25 <BlueMatt> wumpus: I was just wondering if anyone had ideas for something they'd been meaning to run that we could use it for
32 2014-08-26 06:12:38 <BlueMatt> we'd need to move bitcoincore.org, but thats not hard
33 2014-08-26 06:48:57 <alfacent> what does the f in fCheckInputs mean?
34 2014-08-26 06:50:28 <wumpus> flag
35 2014-08-26 06:51:57 <alfacent> and the pf in pfMissingInputs ?
36 2014-08-26 06:53:27 <wumpus> "People use bittorrent all the time, even though to download 60KB of data you end up having to upload about 60KB of data..." I've never seen anyone use a torrent for a 60KB file
37 2014-08-26 06:54:13 <wumpus> alfacent: probably a pointer
38 2014-08-26 06:54:33 <wumpus> alfacent: satoshi had this weird naming convention, we avoid it in new code
39 2014-08-26 06:55:21 <alfacent> ok
40 2014-08-26 06:55:36 <BlueMatt> forrestv: ping
41 2014-08-26 06:55:51 <forrestv> BlueMatt, pong
42 2014-08-26 06:55:59 <alfacent> what about the v in vtx and vin...
43 2014-08-26 06:56:12 <BlueMatt> forrestv: any interest in adding relay network support for p2pool (the protocol is dead simple and it should be an optional flag)?
44 2014-08-26 06:57:33 <alfacent> ?
45 2014-08-26 06:58:13 <BlueMatt> forrestv: (a) if I hacked it together, would you consider merging it, (b) for someone who rarely writes python and has never read the p2pool code, would you suggest a way to go about doing that?
46 2014-08-26 06:58:35 <forrestv> BlueMatt, /me is looking for a spec for the relay network protocol
47 2014-08-26 06:58:43 <BlueMatt> forrestv: none, only code
48 2014-08-26 06:58:56 <forrestv> ACTION is looking at RelayNode
49 2014-08-26 06:58:59 <BlueMatt> https://github.com/TheBlueMatt/RelayNode/blob/master/src/main/java/com/mattcorallo/relaynode/RelayConnection.java
50 2014-08-26 06:59:41 <BlueMatt> essentially, 3-byte header per-message, keep X transactions around in a circular buffer, get blocks that are (header),txids-in-buffer (2 bytes each, or full tx if its not pre-relayed)
51 2014-08-26 07:00:05 <alfacent> Ok I got it
52 2014-08-26 07:00:49 <alfacent> it's vector. I got it
53 2014-08-26 07:01:40 <alfacent> Does txes stand for transactions??? Cos' there is no "e" in that word...
54 2014-08-26 07:03:01 <alfacent> or does it stand for taxes?
55 2014-08-26 07:09:34 <edcba> there is no x either
56 2014-08-26 07:10:20 <wumpus> well, given that bitcoin doesn't compute any taxes, what makes sense in the context...
57 2014-08-26 07:11:24 <edcba> toxines maybe ?
58 2014-08-26 07:11:27 <alfacent> ok, just one more question: what does the w in wtx may mean?
59 2014-08-26 07:11:42 <wumpus> it doesn't matter, it's just a variable name
60 2014-08-26 07:11:53 <wumpus> edcba: that would be dangerous!
61 2014-08-26 07:12:17 <edcba> variable names ought to be descriptive...
62 2014-08-26 07:12:33 <alfacent> I find it a bit odd. Look at these two lines of comments:
63 2014-08-26 07:12:42 <forrestv> BlueMatt, would having it in p2pool have any advantage that running RelayNode alongside wouldn't? i don't really see it - maybe the relay network would get the block a tiny bit faster without it passing through bitcoind first
64 2014-08-26 07:12:46 <alfacent> ///// are we sure this is ok when loading transactions or restoring block txes
65 2014-08-26 07:12:57 <edcba> w is for wallet i think
66 2014-08-26 07:13:37 <alfacent> and right after it: // If updated, erase old tx from wallet
67 2014-08-26 07:13:52 <wumpus> edcba: they are descriptive, you just have to ignore the prefixes
68 2014-08-26 07:13:55 <alfacent> anyway...
69 2014-08-26 07:14:13 <edcba> wumpus: maybe we should ignore comments too ?
70 2014-08-26 07:14:27 <wumpus> edcba: only sometimes
71 2014-08-26 07:14:36 <edcba> ACTION take his dice
72 2014-08-26 07:14:36 <sipa> wtx = wallet transaction
73 2014-08-26 07:14:41 <BlueMatt> forrestv: the main advantage would be lack of need to run a second daemon side-by-side
74 2014-08-26 07:14:57 <BlueMatt> forrestv: (the relay network would have to be considered untrusted, so would have to go through bitcoind anyway)
75 2014-08-26 07:15:16 <BlueMatt> forrestv: its really just a way to make it a first-class feature as it pretty directly helps p2pool miners
76 2014-08-26 07:17:02 <alfacent> there are a lot of printf() calls in Messages section. Where are these messages printed? In the consolde??
77 2014-08-26 07:17:27 <sipa> messages section?
78 2014-08-26 07:18:03 <wumpus> alfacent: what version are you looking at? Nowaday these should be LogPrintf calls
79 2014-08-26 07:18:21 <wumpus> which helpfully indicate the destination of the print in the name
80 2014-08-26 07:18:33 <alfacent> yes, in main.cpp, in the section regarding the messages
81 2014-08-26 07:18:41 <sipa> if you mean LogPrintf, and don't know what it does, go look up its definition
82 2014-08-26 07:18:44 <alfacent> I'm looking at the first version
83 2014-08-26 07:18:55 <sipa> please, do some basicbinvestigation before asking questions
84 2014-08-26 07:19:05 <sipa> *basic investigation
85 2014-08-26 07:19:11 <edcba> yeah use google it helps
86 2014-08-26 07:21:57 <wumpus> alfacent: that explains why the comment you pasted exits nowhere in the current source code
87 2014-08-26 07:22:41 <alfacent> Well, I'm used to printf to write the results to stdout in a console program...
88 2014-08-26 07:23:15 <sipa> then keep looking, maybe he redefined it to mean something else :)
89 2014-08-26 07:23:25 <alfacent> ok
90 2014-08-26 07:23:28 <forrestv> BlueMatt, ah, i see. well, the way i'd go about it is (since it doesn't really need to be very directly coupled to p2pool) by writing a standalone python implementation of RelayNode that p2pool could easily run within itself as a thread or subprocess
91 2014-08-26 07:24:24 <alfacent> this is the version I'm studying: https://github.com/bitcoin/bitcoin/blob/4405b78d6059e536c36974088a8ed4d9f0f29898/main.cpp
92 2014-08-26 07:24:33 <BlueMatt> forrestv: yes, would you consider a rather simple implementation that p2pool just calls out to launch a thread and passes the bitcoind p2p address to?
93 2014-08-26 07:24:52 <BlueMatt> or, lets it call-back to get new blocks to pass bitcoind, to avoid a second connection
94 2014-08-26 07:26:34 <sipa> alfacent: not really the first version, but close
95 2014-08-26 07:26:40 <forrestv> either, i suppose
96 2014-08-26 07:27:24 <alfacent> right
97 2014-08-26 07:29:02 <alfacent> first version, I think is this: https://bitcointalk.org/index.php?topic=382374.0
98 2014-08-26 07:32:07 <sipa> that's incomplete and pre-release
99 2014-08-26 07:34:03 <sipa> the sourcr code for 0.1.5 is in git iirc, just not as first commit
100 2014-08-26 07:35:35 <sipa> oh, i'm wrong; the first commit is approximately that
101 2014-08-26 07:45:46 <alfacent> yes, it is incomplete. It doesn't even compile because is missing some files
102 2014-08-26 10:01:10 <gribble> 317539
103 2014-08-26 10:01:10 <michagogo> ;;blocks
104 2014-08-26 10:06:29 <gribble> Error: "price" is not a valid command.
105 2014-08-26 10:06:29 <jacob___> ;;price
106 2014-08-26 10:06:33 <jacob___> ;;help
107 2014-08-26 10:06:34 <gribble> The bot responds when you start a line with the ! character. A good starting point for exploring the bot is the !facts command. You can also visit the bot's website for a list of help topics and documentation: http://gribble.sourceforge.net/
108 2014-08-26 10:06:44 <gribble> To see a nice sortable web view of all factoids, click here: http://gribble.dreamhosters.com/viewfactoids.php?db=%23bitcoin-dev || To see a list of the most popular factoids, run !rank || To search factoids, run !factoids search <yoursearchterm>
109 2014-08-26 10:06:44 <jacob___> !facts
110 2014-08-26 10:44:14 <chichov> what happens when the number of inputs or outputs (#vin or #vout) is smaller than the actual number of entries?
111 2014-08-26 10:44:26 <chichov> does anybody know what happens during parsing then?
112 2014-08-26 10:52:38 <wumpus> it just fails
113 2014-08-26 10:53:05 <wumpus> the transaction is invalid due to a deserialization error
114 2014-08-26 10:55:37 <chichov> hm, and the transaction standardness rules are only enforced apriori, which means that for a mined block these rules are not checked, right?
115 2014-08-26 11:00:23 <wumpus> you should not confuse isStandard with validity rules
116 2014-08-26 11:00:37 <wumpus> isStandard is only checked before relaying/storing in the mempool
117 2014-08-26 11:00:50 <wumpus> hard validity rules are checked for blocks before accepting them
118 2014-08-26 11:01:13 <wumpus> a block that doesn't even deserialize correctly would never be accepted by nodes
119 2014-08-26 11:06:21 <chichov> yep, that I know
120 2014-08-26 11:06:36 <chichov> I was just checking that part for a different scenario
121 2014-08-26 11:07:02 <chichov> one where nLockTime is not final and neither are the tx sequence numbers
122 2014-08-26 11:07:55 <chichov> in my understanding when a block with such a transaction is mined the transaction standardness rules are not enforced and thus it will be accepted
123 2014-08-26 11:10:40 <sipa> non-final transactions are nit allowed in a block
124 2014-08-26 11:11:39 <sipa> *not
125 2014-08-26 11:15:35 <chichov> sipa: they are not?
126 2014-08-26 11:15:52 <chichov> sipa: I though that standardness rules are not enforced on mined transactions
127 2014-08-26 11:16:13 <michagogo> chichov: a non-final transaction is invalid
128 2014-08-26 11:16:17 <michagogo> Not just non-standard
129 2014-08-26 11:16:23 <sipa> indeed
130 2014-08-26 11:16:31 <chichov> okay, that's something else then
131 2014-08-26 11:17:19 <sipa> what made you think they are only standardness?
132 2014-08-26 11:17:58 <chichov> I think the "IsStandardTx" method in the code
133 2014-08-26 11:18:38 <chichov> yep, there it is
134 2014-08-26 11:18:41 <sipa> finality is also used to determine what to accept in the mempool
135 2014-08-26 11:18:47 <chichov> IsStandardTx checks for IsFinalTx
136 2014-08-26 11:18:56 <sipa> sure
137 2014-08-26 11:19:26 <chichov> okay then, to clarify this completely
138 2014-08-26 11:19:30 <sipa> but there is also a rule that makes blocks with nonfinal transactions invalid
139 2014-08-26 11:19:41 <chichov> a mined block with a non-final transaction is considered invalid?
140 2014-08-26 11:19:48 <chichov> bingo
141 2014-08-26 11:19:48 <sipa> yes
142 2014-08-26 11:19:57 <chichov> thank you!
143 2014-08-26 12:09:06 <wumpus> all: please rebase your pulls to master, then travis CI can test them
144 2014-08-26 12:09:44 <wumpus> that way you get a green tick next to your pull :-)
145 2014-08-26 12:31:05 <michagogo> I'm guessing it uses the block timestamp, rather than the actual time?
146 2014-08-26 12:53:59 <sipa> michagogo: yes
147 2014-08-26 12:58:37 <wumpus> it can either use a block timestamp or a block height
148 2014-08-26 13:07:11 <michagogo> wumpus: of course -- I meant, when using a timestamp
149 2014-08-26 13:09:57 <wumpus> ok
150 2014-08-26 13:13:35 <robbak> Just had a glitch I thought I should report. Probably related to a qt library update, bitcoin-qt Sig11'd on startup. Backtrace pointed to a failure in free() inside libcrypto/ssl, so I rebuilt that with debug to dig further. The problem went away. Rebuilt w/o debug, and all is still good.
151 2014-08-26 13:38:20 <Luke-Jr> wumpus: I used to as part of every 'make', but automake broke my GNUmakefile that did that for me :x
152 2014-08-26 13:38:39 <Luke-Jr> wumpus: and those tests didn't run *everything* pulltester did
153 2014-08-26 13:38:49 <Luke-Jr> not sure if the travis stuff means 100% of tests are in-tree now?
154 2014-08-26 13:39:12 <wumpus> @cfields probably knows
155 2014-08-26 13:39:29 <wumpus> I mean, not all tests are in-tree, but I'm not sure travis does the out-of-tree tests right now
156 2014-08-26 13:39:45 <wumpus> in the meantime we have both pulltester and travis enabled
157 2014-08-26 13:39:51 <Luke-Jr> I think with automake I can just change my habit to 'make check' for testing every build
158 2014-08-26 13:45:55 <sipa> yes, i just use make check
159 2014-08-26 15:39:30 <cfields> Luke-Jr: they're not all in-tree now, but the tests have been added to the depends as a compromise
160 2014-08-26 15:39:39 <cfields> so travis ends up testing them
161 2014-08-26 15:40:04 <cfields> wumpus: that's weird about the symbols showing up in gitian, i tesed that for sure with the visibility changes...
162 2014-08-26 15:40:20 <cfields> i must've forgotten to commit some small fix. will track it down.
163 2014-08-26 15:43:33 <wumpus> yes all the boost symbols being exported is strange
164 2014-08-26 15:43:49 <cfields> ah, well that one I can explain
165 2014-08-26 15:44:02 <cfields> i forgot to add the gold package to the descriptor
166 2014-08-26 15:44:08 <cfields> it's the glibc symbols that are weird
167 2014-08-26 15:44:35 <wumpus> ah yes that was the problem
168 2014-08-26 15:44:42 <wumpus> we've seen this one before :)
169 2014-08-26 16:05:48 <dhill> is there a max length of a pkscript?
170 2014-08-26 16:15:04 <cfields> wumpus: ah right, I didn't enable --enable-glibc-back-compat in the descriptor. I was hoping to get that enabled by default
171 2014-08-26 16:15:19 <cfields> but that didn't go well. Seems it can't be reliably detected
172 2014-08-26 16:15:29 <cfields> updating the descriptors for those 2 things now.
173 2014-08-26 16:21:13 <elichai2> hey, looking for a working way to fix unconfirmed tx without a fee(past more than a day)
174 2014-08-26 16:25:38 <jgarzik> elichai2, Not sure what is meant by "fix" Typically you respend the same transaction with a higher fee, perhaps directly submitting it to a miner or two.
175 2014-08-26 16:26:04 <elichai2> jgarzik, yeah, that what i meant, does double spending will work?
176 2014-08-26 16:26:18 <elichai2> there is any links to specific miners that i can use for that?
177 2014-08-26 16:26:23 <jgarzik> elichai2, transactions cannot be undone, but they can be double spent. You must create a new transaction, then try to get it to one or more miners.
178 2014-08-26 16:26:34 <dhill> so getutxos makes bitcoind send mesages larger than the max 32MB
179 2014-08-26 16:27:20 <jgarzik> *facepalm*
180 2014-08-26 16:28:43 <elichai2> jgarzik, ok, how can i get that tx to miners?
181 2014-08-26 16:28:54 <elichai2> (the client isn't accepting double spend txs)
182 2014-08-26 16:33:38 <dhill> ReadMessage: message payload is too large - header indicates 2892934254 bytes, but max message payload is 33554432 bytes.
183 2014-08-26 16:34:47 <sipa> dhill: thanks for reporting that
184 2014-08-26 16:35:49 <dhill> i found a big unspent tx on testnet.. and if i send a getutxo with 50000 entries for it, bitcoind attempts to send me 2892934254 bytes
185 2014-08-26 16:36:37 <dhill> shouldn't bitcoind not even attempt to send a message if it is over the max message payload size?
186 2014-08-26 16:38:34 <sipa> it shouldn't even bither constructing something of that size
187 2014-08-26 16:38:39 <sipa> let alone trying to send it
188 2014-08-26 16:40:17 <jrick> do duplicate txout queries in the same getutxos request even make sense?
189 2014-08-26 16:42:44 <sipa> no, but i'm not sure that trying to detect duplicates makes sense
190 2014-08-26 16:43:10 <sipa> we should just keep track of the size of the constructed response, and fail if it is too large
191 2014-08-26 16:43:26 <sipa> ... or even beyter, get rid of the full txout results and just return spentness
192 2014-08-26 16:43:30 <jrick> well if you look them up in order, you can keep an unordered set of ones you've already found, and if there's a duplicate, ignore it
193 2014-08-26 16:43:37 <sipa> ... or not have that message at all
194 2014-08-26 16:43:41 <jrick> hehe
195 2014-08-26 16:43:43 <gmaxwell> more considerations that wouldn't exist if it didn't return the data.
196 2014-08-26 16:44:02 <Jouke> are these p2p messages or rpc?
197 2014-08-26 16:44:07 <sipa> jrick: yes, but what do you gain?
198 2014-08-26 16:44:10 <davec> sadly p2p
199 2014-08-26 16:44:11 <sipa> Jouke: p2p
200 2014-08-26 16:44:20 <Jouke> ok
201 2014-08-26 16:44:22 <jrick> I do like proving spentness better than claiming unspentness
202 2014-08-26 16:44:38 <sipa> that requires a much more extensive database
203 2014-08-26 16:44:47 <sipa> in particular, just a utxo set does not suffive
204 2014-08-26 16:44:49 <gmaxwell> which isn't required for anything else.
205 2014-08-26 16:44:52 <jrick> right
206 2014-08-26 16:45:21 <jrick> sipa: you'd presumably save another db lookup, or could just throw the request away for being dumb
207 2014-08-26 16:45:24 <gmaxwell> and would be completely pruning incompatible, so a marginal cost of tens of gigabytes on top of the basic full verifying node requirements.
208 2014-08-26 16:45:50 <jrick> hmm true
209 2014-08-26 16:48:57 <sipa> yeah, if that is the requested functionality, i have no problems with it, but it should definitely be some external database, not standard network node
210 2014-08-26 16:58:07 <elichai2> jgarzik, ?
211 2014-08-26 17:08:33 <denisx> jgarzik: did you ever think about using bittorrent sync for the bootstrap.dat file?
212 2014-08-26 18:23:00 <super3> amiller: can i get into that channel again?
213 2014-08-26 20:29:52 <ayansh> what is in data/bitcoin/cached_payout_address i can see one addr which is not on stats(hour/day)
214 2014-08-26 20:31:29 <ayansh> sorry wrong channel.
215 2014-08-26 21:19:36 <jrick> so the peer handling code sends messages using CDataStream, and I don't see any sort of way to limit the total amount written to the stream
216 2014-08-26 21:20:16 <jrick> and it acts as a buffer (has to, it needs to calculate a checksum), so for large responses like the getutxos ones dhill was getting, it can end up creating 200+ MB buffers in mem
217 2014-08-26 21:20:38 <jrick> sounds like a great way to OOM any bitcoind on the network
218 2014-08-26 21:21:05 <gmaxwell> jrick: it's limited by virtue of none of the past message types being willing or able to generate superlarge outputs.
219 2014-08-26 21:21:22 <jrick> yeah that assumption isn't true anymore :p
220 2014-08-26 21:21:28 <gmaxwell> It will be. :)
221 2014-08-26 21:22:05 <jrick> I still think CDataStream should check for too much data written
222 2014-08-26 21:22:15 <gmaxwell> (The getutxos change has obviously been inadequately reviewed; but thats okay, thats why stuff doesn't go from patch to shipping instantly)
223 2014-08-26 21:22:40 <gmaxwell> jrick: perhapsâ it could. Belt-and-suspenders.
224 2014-08-26 21:23:58 <davec> even with adequate review, which I agree will likely be resolved before it is in a release version
225 2014-08-26 21:24:15 <davec> the feature is still fundamentally flawed with the current state
226 2014-08-26 21:24:33 <gmaxwell> I am unhappy with it, and was making some effort to resolve it privately before.
227 2014-08-26 21:24:37 <davec> after some of the infrastructure is in place to do it properly, it makes sense
228 2014-08-26 23:56:15 <sipa> gmaxwell: editing github comments considered harmful
229 2014-08-26 23:58:25 <gmaxwell> haha are we managing to repeadily moot each other's comments?
230 2014-08-26 23:58:34 <sipa> yup
231 2014-08-26 23:58:58 <sipa> not that just adding comments would improve that situation
232 2014-08-26 23:59:07 <sipa> but it would make it more readable for others :)
233 2014-08-26 23:59:10 <Luke-Jr> lol
234 2014-08-26 23:59:25 <gmaxwell> yea, right now you need to read that subthread in an interleaved pattern for it to make sense.
235 2014-08-26 23:59:56 <sipa> [expand the comments dag]