1 2015-01-29 01:08:05 <phantomcircuit> wumpus, so that crash is consistent actually so i'll get the debug.log with the branch you did
2 2015-01-29 01:08:42 <sipa> phantomcircuit: which crach?
3 2015-01-29 01:08:52 <sipa> *crash
4 2015-01-29 01:13:10 <phantomcircuit> sipa, ERROR: ReadBlockFromDisk : OpenBlockFile failed
5 2015-01-29 01:13:23 <phantomcircuit> there's no debug info in master to tell you what failed
6 2015-01-29 01:13:27 <sipa> ok
7 2015-01-29 01:13:41 <phantomcircuit> so wumpus did a branch with debug info
8 2015-01-29 01:14:08 <phantomcircuit> my first guess is it's some extreme edge case
9 2015-01-29 01:21:48 <harding> I had that same OpenBlockFile error/crash on the 15th, but it hasn't recurred since. Where's this extra debugging branch?
10 2015-01-29 01:22:29 <fanquake> harding https://github.com/bitcoin/bitcoin/pull/5710
11 2015-01-29 01:23:05 <harding> fanquake: thanks, I'll switch to that.
12 2015-01-29 01:28:35 <phantomcircuit> i wonder what would happen if you randomly flipped bits in the bitcoind process' memory
13 2015-01-29 01:29:55 <sipa> phantomcircuit: every time you do that, it creates a bitcoin transaction that pays someone to kill a kitten
14 2015-01-29 01:30:06 <fanquake> :(
15 2015-01-29 01:32:03 <phantomcircuit> lulz
16 2015-01-29 01:36:15 <phantomcircuit> sipa, amusingly having another node do ibd is faster than getblockhash -> getblock
17 2015-01-29 01:39:28 <sipa> is that surprising? p2p is handled using separate transmission and processing threads, with a queue of outstanding requests
18 2015-01-29 01:39:41 <sipa> rpc is fully serialized, and taking cs_main the whole time
19 2015-01-29 01:43:18 <phantomcircuit> sipa, no but it's kind of amusing none the less
20 2015-01-29 05:08:35 <phantomcircuit> 2015-01-29 05:05:38 ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large at CBlockDiskPos(nFile=194, nPos=108232042)
21 2015-01-29 06:19:38 <cryptobouncer> mcxnow.com, mtmox.com, collidercoin.com, cryptobetfair.com, altbetfair.com, heatherai, SCAMS
22 2015-01-29 07:38:21 <wumpus> so, now you know where the corrupted block is
23 2015-01-29 07:39:31 <wumpus> you could e.g. modify the scripts in linearize to enumerate and extract the blocks in that blk file, and compare them to the originals to see what the corruption is
24 2015-01-29 08:15:53 <jonasschnelli> wumpus, trivial GUI thing and ready to merge: https://github.com/bitcoin/bitcoin/pull/5720
25 2015-01-29 08:16:03 <jonasschnelli> and needs GUI tag: https://github.com/bitcoin/bitcoin/pull/5720
26 2015-01-29 08:17:09 <jonasschnelli> wumpus, and if you are happy with this: https://github.com/bitcoin/bitcoin/pull/5683 i would also see this merged, because if completes the "retina" HiDPI support.
27 2015-01-29 08:17:20 <jonasschnelli> (as well as the new icon style)
28 2015-01-29 08:19:13 <jonasschnelli> s/if/it
29 2015-01-29 08:24:15 <jonasschnelli> needs GUI tag: https://github.com/bitcoin/bitcoin/issues/5722
30 2015-01-29 08:25:20 <wumpus> looks good to me, although it makes me wonder how that 1 in the column ends up there in the first place, is that some qt default?
31 2015-01-29 08:26:20 <wumpus> e.g. the patch is not removing evidence of some deeper bug? :-)
32 2015-01-29 08:29:38 <wumpus> merged #5683
33 2015-01-29 08:33:25 <jonasschnelli> wumpus, yes. #5720 is kind of a hack. I don't like it. But the "1" as column header is ugly and may confuse people. There are no plans to drop Qt4 compatibility i assume?
34 2015-01-29 08:36:51 <jonasschnelli> wumpus, i assume nobody else will test this: https://github.com/bitcoin/bitcoin/pull/5620 . Looks good IMO and i think it would make sense to merge this.
35 2015-01-29 08:40:54 <Luke-Jr> jonasschnelli: dropping Qt4 compatibility would be stupid and cut off a lot of users including myself
36 2015-01-29 08:41:07 <Luke-Jr> Qt5 is simply not ready for the real world
37 2015-01-29 08:41:19 <jonasschnelli> Luke-Jr, hmm... Agreed.
38 2015-01-29 08:42:06 <jonasschnelli> I think the author of https://github.com/bitcoin/bitcoin/pull/5720 should add a comment that explains the Qt4-empty-string-column-header hack.
39 2015-01-29 09:11:53 <wumpus> jonasschnelli: but any idea where the 1 comes from?
40 2015-01-29 09:12:23 <wumpus> I mean 'drop qt4 compatibility' is not an answer to an obscure bug that introduces a seemingly random symbol somewhere
41 2015-01-29 09:12:35 <jonasschnelli> wumpus, yes. Agreed.
42 2015-01-29 09:13:28 <wumpus> qt4 works very well in general, we don't require any qt5 specific features, hence I see no point in requiring qt5
43 2015-01-29 09:14:01 <jonasschnelli> wumpus, but i didn't look deeper into this because of priorisation. I mean 5720 is not a/the prefect solution... but this (now commented) line makes sense to me.
44 2015-01-29 09:14:35 <jonasschnelli> wumpus, for linux, yes. For osx, Qt5 makes def. sense.
45 2015-01-29 09:15:03 <wumpus> I'm not trying to say that you have to do the analysis, just that it has to be done before covering up symptoms as they could be something much worse (not that I expect that, but I'm paranoid that way)
46 2015-01-29 09:15:56 <wumpus> jonasschnelli: right, that's why we use qt5 on mac
47 2015-01-29 09:16:07 <jonasschnelli> wumpus, agreed. Let's delegate this analysis to the author of 5720 (if he likes to do this).
48 2015-01-29 09:16:35 <wumpus> macosx users always seem to be really happy to drop support for older versions of things, maybe because osx itself is a heap of instability that turns over every api every release...
49 2015-01-29 09:18:02 <wumpus> otoh, apple couldn't be the most profitable company in the world if they didn'tf orce everytone to buy new stuff all the time :-)
50 2015-01-29 09:18:18 <jonasschnelli> wumpus, stability and backward comp. responsibility was never Cupertino main strength. :)
51 2015-01-29 09:18:26 <wumpus> right
52 2015-01-29 09:18:38 <wumpus> anyhow, I'll look into it, I want to know now
53 2015-01-29 09:19:14 <jonasschnelli> wumpus, i mean try to run apples software on a 3 year old iOS device. Won't run anymore!
54 2015-01-29 09:19:31 <jonasschnelli> wumpus, i think @fsb4000 will take a deeper look
55 2015-01-29 09:19:41 <jonasschnelli> wumpus, he's fast responding.
56 2015-01-29 09:22:02 <jonasschnelli> i also need to overhaul the splashscreen. Suddenly font- and window-sizes are different on different platforms.
57 2015-01-29 09:22:34 <Luke-Jr> bitcoin on mac is just asking to lose money anyhow
58 2015-01-29 09:23:19 <jonasschnelli> Luke-Jr, i once have to buy you a nice, stylish mac... to convince you. :)
59 2015-01-29 09:23:25 <jonasschnelli> (but don't install ubuntu on it!)
60 2015-01-29 09:24:01 <Luke-Jr> jonasschnelli: no amount of stylish can ever make something secure
61 2015-01-29 09:24:34 <Luke-Jr> jonasschnelli: also, I've used Macs before, and the UI experience is just terrible, but that's a topic for another channel
62 2015-01-29 09:25:32 <jonasschnelli> Luke-Jr, Yes. Agreed. But my physical wallet looks nice and is convenient and has just some weekly-needs in it. My vault looks bad, is heavy and is secure.
63 2015-01-29 09:27:25 <jonasschnelli> wumpus, strange: https://github.com/bitcoin/bitcoin/pull/5720#issuecomment-71993307 maybe you will find some deeper cause.
64 2015-01-29 09:28:40 <Luke-Jr> jonasschnelli: perhaps, but even Windows is a better UI than Mac, and also more secure. :P
65 2015-01-29 09:29:15 <wumpus> let's not have that discussion here
66 2015-01-29 09:35:04 <wumpus> too much of the tech industry is that subjective nonsense, and fashions and hype of the day, it's hard to see the forest for the trees as it is
67 2015-01-29 09:36:21 <wumpus> ah, I found the reason why there's a '1' there
68 2015-01-29 09:36:37 <Luke-Jr> â
69 2015-01-29 09:37:08 <wumpus> remember this is a table widget (akin to a spreadsheet) by default, the columns are numbered
70 2015-01-29 09:37:29 <Luke-Jr> oh, lol
71 2015-01-29 09:37:57 <Luke-Jr> has it always been there then? :o
72 2015-01-29 09:38:01 <wumpus> yes
73 2015-01-29 09:38:38 <wumpus> the only bug is that setting it to the empty string doesn't override the number, it sets the default behavior to render the number
74 2015-01-29 09:39:18 <wumpus> (well, it could very well be documented behavior and not a bug, but at least it's unexpected)
75 2015-01-29 09:39:21 <Luke-Jr> ok, let me rephrase that:
76 2015-01-29 09:39:30 <Luke-Jr> it was *not* there in 0.8
77 2015-01-29 09:39:45 <wumpus> did 0.8 have coin control?!
78 2015-01-29 09:39:53 <Luke-Jr> mine did at least <.<
79 2015-01-29 09:40:26 <Luke-Jr> * | | | | | | | | | | | | | a652787 Merge pull request #4314
80 2015-01-29 09:40:28 <Luke-Jr> so yes
81 2015-01-29 09:41:07 <wumpus> goddamnit
82 2015-01-29 09:41:30 <jonasschnelli> funny
83 2015-01-29 09:42:05 <wumpus> a space doesn't work, let's go for a ...
84 2015-01-29 09:43:30 <Luke-Jr> ACTION wonders if we should actually have a label for that column
85 2015-01-29 09:43:31 <wumpus> we should just put a PILE OF POO character there, but I guess with the broken unicode on some platforms that isn't an option either
86 2015-01-29 09:43:51 <Luke-Jr> lol
87 2015-01-29 09:45:19 <jonasschnelli> ;)
88 2015-01-29 09:45:39 <Luke-Jr> "Input?"
89 2015-01-29 09:45:40 <wumpus> putting nbsp there works, but appears to resize the column according to the width before entity conversion, or even worse to the UTF8 string length, so that results in a wide column...
90 2015-01-29 09:45:57 <jonasschnelli> Luke-Jr, yes. Maybe this would be a good idea.
91 2015-01-29 09:46:14 <jonasschnelli> Or even add the [ ] checkbox the the beginning of the amount column.
92 2015-01-29 09:46:15 <wumpus> that will also result in a wide column
93 2015-01-29 09:46:36 <Luke-Jr> hmm
94 2015-01-29 09:46:51 <wumpus> the point is to have a narrow column, so no, we can't put text in there
95 2015-01-29 09:46:56 <Luke-Jr> well, how did 0.8 have a blank column? <.<
96 2015-01-29 09:47:24 <wumpus> well, let's ask 0.8
97 2015-01-29 09:48:46 <wumpus> ...building 0.8
98 2015-01-29 09:51:38 <wumpus> I have the feeling this is some ordering issue when setting attributes
99 2015-01-29 09:54:05 <wumpus> no, there is no coin control in 0.8 at all
100 2015-01-29 09:54:34 <Luke-Jr> O.o
101 2015-01-29 09:54:44 <Luke-Jr> oh, I was looking at the wrong git history
102 2015-01-29 09:54:58 <Luke-Jr> sorry
103 2015-01-29 09:58:16 <wumpus> I was also wrong on the ordering hypothesis, it's the state that the uic leaves the dialog in; it's not due to any operations we do afterward
104 2015-01-29 10:00:38 <Luke-Jr> hm
105 2015-01-29 10:00:41 <Luke-Jr> apparently this is my bad
106 2015-01-29 10:00:55 <Luke-Jr> * 4ff81d6 Bugfix: Clarify coin control dialog labels
107 2015-01-29 10:00:57 <Luke-Jr> introduced by ^
108 2015-01-29 10:01:11 <Luke-Jr> maybe this..
109 2015-01-29 10:01:12 <Luke-Jr> - <string notr="true">Label</string>
110 2015-01-29 10:01:14 <Luke-Jr> + <string>Received with label</string>
111 2015-01-29 10:02:32 <Luke-Jr> confirmed adding notr="true" back in fixes it
112 2015-01-29 10:03:20 <Luke-Jr> no clue wtf notr is though
113 2015-01-29 10:04:24 <jonasschnelli> what's the meaning of notr?
114 2015-01-29 10:04:35 <Luke-Jr> apparently "no translate" from googling
115 2015-01-29 10:04:43 <Luke-Jr> but we *do* want that translated� :/
116 2015-01-29 10:05:06 <Luke-Jr> hm, is it possible the '1' is a "translation" of the null string or somethign?
117 2015-01-29 10:05:20 <wumpus> no, the 1 is spreadsheet numbering
118 2015-01-29 10:05:25 <wumpus> I've already explained that
119 2015-01-29 10:05:36 <wumpus> see also my post on #5720
120 2015-01-29 10:05:42 <Luke-Jr> wasn't sure if that was an assumption or confirmed
121 2015-01-29 10:05:55 <wumpus> at least with qt4's uic, no code is generated when you set an empty column label
122 2015-01-29 10:06:25 <wumpus> just adding notr for the empty column didn't solve it for me
123 2015-01-29 10:06:54 <wumpus> I tried that as one of the first things, as translating empty makes no sense
124 2015-01-29 10:08:05 <Luke-Jr> <string notr="true"/> for the empty column worked for me here (Qt 4.8.6)
125 2015-01-29 10:08:34 <wumpus> huh
126 2015-01-29 10:09:34 <Luke-Jr> maybe I should just shut up tonight.
127 2015-01-29 10:09:39 <Luke-Jr> (forgot to save the file)
128 2015-01-29 10:09:52 <wumpus> lol
129 2015-01-29 10:12:35 <wumpus> it does work if you do <string notr="true"> </string>
130 2015-01-29 10:12:50 <wumpus> but I'm just going ahead and merging #5720
131 2015-01-29 10:14:13 <Luke-Jr> hm
132 2015-01-29 10:15:38 <Luke-Jr> I do wonder why the notr trick worked
133 2015-01-29 10:16:07 <wumpus> just wanted to know that this is not some symptom of horrible memory corruption, and it's not, so the straightforward workaround makes sense
134 2015-01-29 10:16:18 <Luke-Jr> right
135 2015-01-29 10:28:54 <wumpus> so if anyone cares about getting to 0.10 final sooner, please help review and test the pulls that are still open https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.10.0
136 2015-01-29 11:50:31 <wumpus> cfields: re: https://github.com/bitcoin/bitcoin/pull/5689 are you going to move the cleanse file?
137 2015-01-29 11:51:22 <wumpus> doesn't really make much sense to hold that up on a trivial comment by me, but I'd expect at least a reply :p
138 2015-01-29 11:58:17 <benjamindees> at three transactions per second, each of the 7 billion people on the planet could perform a Bitcoin transaction once every 73 years
139 2015-01-29 12:03:27 <wumpus> nice, so if you're lucky you can do one bitcoin transaction in your life
140 2015-01-29 12:04:44 <paveljanik> this is nice reason that we do not need wallet at all
141 2015-01-29 12:05:14 <wumpus> 'we'?
142 2015-01-29 12:05:34 <paveljanik> everyone, Bitcoin Core, ...
143 2015-01-29 12:06:11 <wumpus> so for that one transaction in their life, they'd manually write it down in hex, and sign it with a graphical calculator?
144 2015-01-29 12:06:55 <paveljanik> wumpus, you need signing only for the second transaction in your life...
145 2015-01-29 12:06:58 <wumpus> well if they spend all 73 years writing it maybe :-)
146 2015-01-29 12:13:20 <benjamindees> for 7 billion people to perform 1 transaction per month requires a blocksize of *at least* 792 mb
147 2015-01-29 12:16:32 <P4RTYP4T> what i need to learn to dev for bitcoin?
148 2015-01-29 12:19:50 <davout> benjamindees: we've already been over this, haven't we?
149 2015-01-29 12:20:30 <davout> curious to see what the -dev crowd thinks about the whole conundrum
150 2015-01-29 12:25:01 <benjamindees> it's really only a conundrum in your mind, but this isn't the place for that regardless
151 2015-01-29 12:26:28 <davout> looks to me like the exact place for it
152 2015-01-29 12:26:53 <Luke-Jr> I bet that before we have worldwide adoption, blocksize will grow. âº
153 2015-01-29 12:26:54 <davout> if, for the sake of the argument, you work from the assumption that -dev gets to decide
154 2015-01-29 12:27:13 <Luke-Jr> davout: we don't.
155 2015-01-29 12:27:45 <davout> Luke-Jr: i'd say we already have worldwide adoption, as in bitcoin is probably used everywhere, simply not by everyone
156 2015-01-29 12:28:04 <Luke-Jr> davout: ok, I used the wrong word then. I mean everyone everywhere, what benjamindees was talking about.
157 2015-01-29 12:28:40 <benjamindees> davout, I'm working from the assumption that you are opposed philosophically rather than technically
158 2015-01-29 12:29:46 <davout> benjamindees: if bitcoin didn't have philosophical and political implications we'd just stick to fiat
159 2015-01-29 12:30:19 <davout> just because you can write an OS in brainfuck doesn't mean it wouldn't be retarded to do so
160 2015-01-29 12:30:23 <benjamindees> so if you want to argue politics, we can do that in #bitcoin or somewhere else
161 2015-01-29 12:31:16 <davout> "curious to see what the -dev crowd thinks about the whole conundrum"
162 2015-01-29 12:31:30 <davout> when i speak, take notes
163 2015-01-29 12:33:40 <davout> more specifically i'm pretty curious what -dev thinks about infinite block size increase, as opposed to let's-bump-it-once-and-promise-we-won't-touch-it-anymore
164 2015-01-29 12:36:23 <wumpus> a one time increase doesn't make sense, I mean say you double it from 1MB to 2MB, so what
165 2015-01-29 12:37:10 <davout> wumpus: it depends on what the point is exactly
166 2015-01-29 12:37:20 <wumpus> yes, what is the point?
167 2015-01-29 12:37:29 <davout> you tell me
168 2015-01-29 12:38:35 <davout> if you say it doesn't make sense, it's from a certain perspective, which i'm curious about
169 2015-01-29 12:38:35 <wumpus> I suppose the point would be to get rid of 'magic' limit values, to be able to scale over time, but do so in a controlled manner
170 2015-01-29 12:39:03 <davout> the thing that immediately comes to mind is the 21m coins magic value
171 2015-01-29 12:39:06 <wumpus> anything else makes little sense? double the block size, just because we can? what makes 14 transactions so special?
172 2015-01-29 12:39:29 <wumpus> that's an economic property of the system
173 2015-01-29 12:39:50 <davout> some people think the 1mb block limit is one too
174 2015-01-29 12:39:55 <wumpus> to consider changing that is crazy
175 2015-01-29 12:39:59 <wumpus> well, maybe it is
176 2015-01-29 12:40:50 <wumpus> (but only for miners0
177 2015-01-29 12:41:38 <wumpus> basically it would give miners the option to include more transactions
178 2015-01-29 12:41:42 <davout> so if i rephrase i get "changing the block size is ok because it only impacts miners" ?
179 2015-01-29 12:42:44 <davout> it also forces them in a way, if you think about ti
180 2015-01-29 12:42:45 <davout> *it
181 2015-01-29 12:43:06 <wumpus> don't put words into my mouth
182 2015-01-29 12:43:19 <davout> i'm asking, is that what you mean?
183 2015-01-29 12:43:25 <davout> looks like not heh
184 2015-01-29 12:44:18 <davout> see, this "basically it would give miners the option to include more transactions"
185 2015-01-29 12:45:17 <davout> to me it's pretty much equivalent to "see these ice-cube sellers? let's move them all to the north pole where ice-cubes are plentiful, they'll therefore have the option to sell more ice cubes"
186 2015-01-29 12:46:02 <wumpus> what are you trying to argue?
187 2015-01-29 12:46:48 <wumpus> should the block size remain at 1MB forever?
188 2015-01-29 12:47:00 <davout> don't put words in my mouth :-)
189 2015-01-29 12:47:20 <davout> i'm saying that there needs to be some block-space scarcity for mining to make economical sense
190 2015-01-29 12:47:29 <wumpus> obviously
191 2015-01-29 12:48:05 <davout> on one hand, and that the "at some point bandwith will be the limiting factor to fill blocks" is dangerously pushing towards massive centralization
192 2015-01-29 12:48:10 <davout> on the other hand
193 2015-01-29 12:48:18 <wumpus> on the other hand, bigger blocks allows them to include more transactions, thus getting more fees
194 2015-01-29 12:48:41 <davout> let's take an example
195 2015-01-29 12:49:14 <wumpus> there needs to be block space scarcity, but it doesn't need to be a hard magic limit in the protocol that enforces that
196 2015-01-29 12:49:23 <akstunt600> Instead of talking about BS issues for days how about we try to work on mining....
197 2015-01-29 12:49:34 <akstunt600> No, there is no need for it
198 2015-01-29 12:49:48 <akstunt600> HD space is wicked cheap
199 2015-01-29 12:50:04 <akstunt600> and miners will still have near identical incentives
200 2015-01-29 12:50:10 <akstunt600> soooooooooo......
201 2015-01-29 12:50:12 <wumpus> no one is talking about HD space, the point is that miners will bother to do what they do at all
202 2015-01-29 12:50:16 <davout> "and miners will still have near identical incentives" <<< nah
203 2015-01-29 12:50:26 <akstunt600> WHAT?
204 2015-01-29 12:50:30 <akstunt600> How so?
205 2015-01-29 12:50:47 <akstunt600> They will just restrict restric transactions anyway that arent making money
206 2015-01-29 12:50:53 <davout> akstunt600: this isn't bitcoin 101, and i wasn't really talking to you
207 2015-01-29 12:51:03 <wumpus> anyhow - please move this to #bitcoin, this is no longer relevant to direct development discussion
208 2015-01-29 12:51:14 <akstunt600> davout, Nice great way to treat someone
209 2015-01-29 12:51:16 <davout> gauging interest here
210 2015-01-29 12:51:21 <akstunt600> your still wrong...
211 2015-01-29 12:51:38 <davout> so apparently everyone here is in favor of unlimited, ever-expanding block size
212 2015-01-29 12:52:15 <akstunt600> Oh wow, Come on we need hard cap to prevent spam ofc, but maybe by next year or a yea afterwe wont have to cap BS at all
213 2015-01-29 12:52:16 <wumpus> davout: well I think there are two choices: either keep it at 1MB forever, or expand over time, eventually unlimited
214 2015-01-29 12:52:23 <akstunt600> ^^^^
215 2015-01-29 12:52:52 <wumpus> davout: I'm not really decided yet which one makes most sense, but it decides what applications bitcoin is useful for for all the future
216 2015-01-29 12:53:05 <davout> wumpus: there's also the people that think that 1mb forever is too low, but that increasing it forever is folly
217 2015-01-29 12:53:28 <wumpus> davout: I think the only disagreement then is the speed with which to increase it
218 2015-01-29 12:53:31 <akstunt600> davout, I was really concerned about this for all of 3 to 4 days. I do understand. What I would be more focused on personally is the block headers changes....
219 2015-01-29 12:54:37 <wumpus> davout: but how to determine that? what kind of curve to use?
220 2015-01-29 12:54:45 <davout> wumpus: not really, i was referring to people who think a one-time bump is ok but not more, you're saying that everyone here is in favor of unlimited increase, and that only the actual numbers are the subject of disagreement?
221 2015-01-29 12:55:28 <wumpus> davout: a one-time bump is not scaling, the same discussion will then come up again and again
222 2015-01-29 12:56:07 <wumpus> as economical circumstances change, and a committee(?) has to monitor bitcoin and make sure that a bump is done every time when warranted?
223 2015-01-29 12:57:23 <wumpus> so it's coupled to a human decision every time
224 2015-01-29 12:58:21 <wumpus> at leat with a predictable curve, people can take it into account upfront
225 2015-01-29 12:58:31 <davout> i hear that
226 2015-01-29 12:59:04 <davout> i disagree with your premises, but i agree that, given your premises, your point makes sense
227 2015-01-29 12:59:10 <davout> *agree with
228 2015-01-29 12:59:18 <davout> scratch that, derp
229 2015-01-29 12:59:59 <wumpus> so, what then? it's a bit of a '640kB ought to be enough for everyone'. So we can try to fit everything into 640kB forever, or we can keep scaling up memory.
230 2015-01-29 13:00:21 <wumpus> it doesn't make sense to go to '1280kB ought to be enough for everyone' ... that implies you learn nothing
231 2015-01-29 13:00:30 <akstunt600> Anyway like I said it would be better to maybe focus on the block header propagation, and potential optimizations via dropped transactions there
232 2015-01-29 13:00:43 <akstunt600> Its a much bigger issue/change than the BS
233 2015-01-29 13:00:49 <davout> except these aren't the same, it's not like the whole architecture of computing depended on ram being 640k
234 2015-01-29 13:01:03 <jtimon> I don't think there's a uniform vision, personally I think it doesn't make sense to increase the limit at least until the majority of mined blocks are full (at which point transaction actually start competing with fees for block space)
235 2015-01-29 13:01:03 <wumpus> ok, I'm done
236 2015-01-29 13:01:18 <wumpus> jtimon: agreed there
237 2015-01-29 13:01:25 <davout> jtimon: yeah, that's a good point too, don't fix what ain't broken
238 2015-01-29 13:02:15 <akstunt600> Well jtimon we would have to see what percentage of BTC transactions are spam
239 2015-01-29 13:02:16 <wumpus> jtimon: I still think this is the hypothetical case where bitcoin needs to scale at all. Maybe it doesn't. I mean I sometimes compare this to multiplexing all the world's phone calls over one radio channel
240 2015-01-29 13:02:23 <akstunt600> I like how NO ONE seems to mention that
241 2015-01-29 13:02:51 <jtimon> on the higher limit vs no limit...I don't have a conclusion yet to be honest, no limit doesn't seem crazy for me, but maybe it is too much centralization preassure
242 2015-01-29 13:02:54 <akstunt600> yet it is the ENTIRE point, initially of the set BS
243 2015-01-29 13:02:59 <wumpus> jtimon: you can try to increase the bandwidth of the channel, but ultimately, it's just not the right paradigm for that
244 2015-01-29 13:03:23 <jtimon> wumpus: good point we can't know the future about scaling needs
245 2015-01-29 13:03:35 <akstunt600> So maybe if we are at say 50% spam then NO, we should not change the BS.
246 2015-01-29 13:03:42 <wumpus> jtimon: that doesn't make radio any less useful, but trying to imagine all the world's transactions will go over one channel is a quite limited visiion
247 2015-01-29 13:04:02 <akstunt600> If we are at like 3-10% spam, Meh, maybe we can get away with increasing it.
248 2015-01-29 13:04:05 <wumpus> and the block chain, as it is now is one channel
249 2015-01-29 13:04:12 <akstunt600> but then what is spam?
250 2015-01-29 13:04:16 <jtimon> so davout in conclusion I would say, I'm sorry but there's no uniform vision that all developers share about scaling
251 2015-01-29 13:04:22 <akstunt600> people who just dont pay any fee?
252 2015-01-29 13:04:23 <wumpus> jtimon: right
253 2015-01-29 13:04:25 <davout> wumpus: that's kind of forgetting that in your example it's impossible to "build on top of the radio channel"
254 2015-01-29 13:05:02 <wumpus> davout: well it'd be possible to make local channels and take messages there, or just broadcast summaries to the global channel, etc
255 2015-01-29 13:05:17 <davout> pretty much
256 2015-01-29 13:07:11 <Luke-Jr> ACTION notes an unlimited block size growth can be softforked to a limited one at any time
257 2015-01-29 13:07:35 <akstunt600> ACTION nods
258 2015-01-29 13:15:09 <wumpus> Luke-Jr: right - it's also very well possible that even though the max limit is lifted, miners will still continue to produce <1MB blocks. Only if the gain in fees outweights the extra processing needed, propagation delays, etc, they'd consider it.
259 2015-01-29 13:15:43 <wumpus> they don't fill all blocks to 1MB right now, so why would then then?
260 2015-01-29 13:15:56 <akstunt600> ^ Exactly
261 2015-01-29 13:16:12 <akstunt600> I have said this a bunch, miners will have no incentive to change
262 2015-01-29 13:16:23 <akstunt600> It will be like nothing happened... for now.
263 2015-01-29 13:17:09 <wumpus> well they have incentive if people post enough fees, they will not have incentive to e.g. include more free transactions
264 2015-01-29 13:17:15 <Luke-Jr> on the other hand, some miners *do* fill 1 MB, often with spam to pad it out to their own profit
265 2015-01-29 13:17:39 <davout> that's forgetting that the marginal cost for including an extra tx is extremely low, and even more so if there's some 'headers-first' approach implemented for new blocks propagation
266 2015-01-29 13:17:53 <davout> wumpus: ^
267 2015-01-29 13:18:16 <Luke-Jr> "headers first" doesn't make sense in the context of new blocks
268 2015-01-29 13:18:25 <Luke-Jr> it's an optimisation for initial download
269 2015-01-29 13:19:23 <wumpus> davout: right, it's hard to know, it may be that the marginal cost is low but still not worth it
270 2015-01-29 13:21:00 <wumpus> just like now, people have to make it worth it by posting tranactions with enough fee
271 2015-01-29 13:22:46 <wumpus> anyhow, it's clear that views differ, in general people are afraid that increasing the block size will break some fragile balance and break the system
272 2015-01-29 13:24:23 <davout> yup
273 2015-01-29 13:24:27 <wumpus> maybe it's too much of a risk and can thus never happen anymore
274 2015-01-29 13:24:43 <akstunt600> I argue this... Stop worrying about the price LOL
275 2015-01-29 13:25:07 <wumpus> then it's basically: want more space? build another system
276 2015-01-29 13:25:36 <Luke-Jr> personally, I'm hoping sidechains are working before we get pressure on the block size; then we can just try things out and see where they go safely
277 2015-01-29 13:26:01 <wumpus> Luke-Jr: I hope so too, experimenting in sidechains would be so much more bearable
278 2015-01-29 13:26:50 <akstunt600> or we could take an alt and use it for what alts should be used for?
279 2015-01-29 13:27:39 <akstunt600> i mean alts should be able to show us a similar real world model that is much better than testnet
280 2015-01-29 13:27:59 <wumpus> akstunt600: that doesn't scale either due to networking effects; to be able to transact others people, you need to be using the same currency. Hence sidechains which allow the alt ideas but with the same currency.
281 2015-01-29 13:29:36 <akstunt600> I meant use an alt to test this theory and limit and increase BS on that alt and measure impact to the economy
282 2015-01-29 13:29:53 <akstunt600> Should work, or at least provide some fundamentals....
283 2015-01-29 13:30:19 <akstunt600> I mean cmon BTC is not that fragile that couldnt be compared at all to another alt. Its not THAT different.
284 2015-01-29 13:30:24 <wumpus> no, that doesn't work, as bitcoin is the busiest chain, testing scaling anywhere else would mean moving business there
285 2015-01-29 13:30:35 <akstunt600> Yes, true
286 2015-01-29 13:30:55 <akstunt600> One nice pump over there for the testing
287 2015-01-29 13:31:02 <akstunt600> and see how it takes the volume
288 2015-01-29 13:31:04 <wumpus> enough altcoin talk by the way.
289 2015-01-29 13:31:29 <akstunt600> Just saying we have them there, and they can be great testebeds as they are real live economies
290 2015-01-29 13:31:43 <akstunt600> seems absolutely stupid to me to not use these more for testing/dev
291 2015-01-29 13:32:38 <Luke-Jr> akstunt600: read http://blockstream.com/sidechains.pdf
292 2015-01-29 13:33:03 <akstunt600> Luke-Jr, Oh im a fan but many people are going to argue 2 way pegging
293 2015-01-29 13:33:23 <akstunt600> prolly about the same as BS increase. Pffbt
294 2015-01-29 13:40:54 <wumpus> I doubt it; people are really attached to their magic limit numbers, and in a way that's reasonable. Two-way pegging on the other hand doesn't change anything to the fundamentals of the system, and comes with safety guarantees (no more coins can come back from a chain than were sent there)
295 2015-01-29 14:33:43 <jonasschnelli> i hope i don't OO overload the module wallet implementation... *duck*
296 2015-01-29 14:34:09 <jonasschnelli> keyword CModuleManager ...
297 2015-01-29 14:36:10 <jgarzik> jonasschnelli, indeed
298 2015-01-29 14:38:02 <jonasschnelli> i just struggle with this global scope extern c99 style. I mean it's straight forward. But readability is bad IMO. I still struggle with checking which var is in which scope.
299 2015-01-29 14:38:18 <jonasschnelli> maybe i'm to young..
300 2015-01-29 14:39:21 <fanquake> jonasschnelli age is no barrier
301 2015-01-29 14:53:07 <wumpus> using namespaces would make sense in some cases
302 2015-01-29 14:53:18 <gmaxwell> wumpus: 5442 Can we merge this yet?
303 2015-01-29 14:54:54 <wumpus> gmaxwell: as I mention in the issue, I think it makes sense to add a comment why it was done like this
304 2015-01-29 14:55:44 <wumpus> eg a small explanation, or just a link to the issue
305 2015-01-29 14:55:54 <gmaxwell> wumpus: okay, sitting with the author. :)
306 2015-01-29 14:55:59 <gmaxwell> pinging for that.
307 2015-01-29 14:56:15 <gmaxwell> okay, he will.
308 2015-01-29 14:56:17 <wumpus> well I can do it, but yes I was really waiting for the author there, it didn't seem that urgent
309 2015-01-29 14:56:33 <gmaxwell> He was just unclear if the patch was going to be accepted or not.
310 2015-01-29 14:57:13 <gmaxwell> (seems our process was a bit too complex, he didn't want to offend anyone by nagging by updating it.)
311 2015-01-29 14:57:40 <wumpus> well it has enough ACKs so it can just go on
312 2015-01-29 14:57:42 <wumpus> hah okay
313 2015-01-29 15:07:09 <morcos> wumpus: 5575, notating the account stuff as deprecated, is that not meant to be backported to 0.10? are we waiting for 0.11 to announce that?
314 2015-01-29 15:13:51 <hearn> wumpus: side chains are not a replacement for increasing the block size, i hope that wasn't a serious suggestion
315 2015-01-29 15:18:30 <azeteki> hm
316 2015-01-29 15:19:08 <azeteki> sorry, wrong channel :P
317 2015-01-29 15:24:27 <wumpus> hearn: that't not what I'm implying; but experiments with e.g. a larger block size could be done in side chains
318 2015-01-29 15:24:59 <hearn> i think there will be a need to increase block sizes well before side chains ever happens
319 2015-01-29 15:25:14 <wumpus> hearn: if all side chains are limited to 1MB too it's obviously a lousy scaling mechanism
320 2015-01-29 15:25:45 <wumpus> morcos: no, that won't be backported to 0.10, 0.10 is closed
321 2015-01-29 15:26:04 <wumpus> morcos: only bugfixes and BIP66 will still go in
322 2015-01-29 15:34:33 <morcos> wumpus: ok, if you're trying to wrap up 0.10, i do think we should add something to the release notes about the policy change with respect to relaying free tx's. otherwise it'll confuse people. i didn't want to volunteer, because it seems delicate to get just right...
323 2015-01-29 15:37:51 <gmaxwell> I can draft something. One trickyness is that many people believed that was previously the rule (e.g. it was what bitcoin wiki documented it as)
324 2015-01-29 17:19:50 <jtimon> jonasschnelli variables are much more readable when they're access only from one file. Sure singleton it's not that different from global variables but it's still better, it's about encapsulation...
325 2015-01-29 17:30:59 <maraoz> is this the most up-to-date spec for the protocol? https://en.bitcoin.it/wiki/Protocol_specification#version
326 2015-01-29 17:35:16 <maraoz> I noticed the version.user_agent field is called version.subversion in Bitcoin Core
327 2015-01-29 17:58:18 <harding> maraoz: see BIP14 where subver became the user_agent string: https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki
328 2015-01-29 18:17:15 <maraoz> harding: thanks, that clarifies it. Looks like Bitcoin Core code needs a name update. I'll submit a PR
329 2015-01-29 18:56:58 <jonasschnelli> jtimon, yes. i also tend to use singletons for global things. I mean it might end up with things like CModuleManager::sharedInstance()->aSignal(). But IMO its easy readable, flexible and scalable in case of more code.
330 2015-01-29 19:04:27 <jonasschnelli> is there a chance to deeper debug this: "Assertion failed: (this->GetLockedPageCount() == 0), function ~LockedPageManagerBase, file ./allocators.h, line"?
331 2015-01-29 19:06:48 <jonasschnelli> needs GUI tag: https://github.com/bitcoin/bitcoin/issues/5722
332 2015-01-29 19:38:18 <azeteki> gah, project euler is like xkcd's nerd sniping comic realised
333 2015-01-29 19:47:26 <azeteki> i'm sure that knowing how to iterate over 'pandigital' numbers will be useful at some point
334 2015-01-29 20:04:10 <wumpus> jonasschnelli: that happens when something else caused a non-clean shutdown, causing the locked page manager to exit with still locked pages
335 2015-01-29 20:04:43 <jonasschnelli> wumpus, thanks. I found the issue. Was a delete derived constructor issue.
336 2015-01-29 20:04:58 <wumpus> I think it makes sense to remove that assertion at some point, too many false positives
337 2015-01-29 20:05:06 <jonasschnelli> s/constructor/destructor
338 2015-01-29 20:06:06 <maraoz> protocol question: if I send `getdata` to a Bitcoin Core node, will it always respond with a `block` or `notfound` message? or can it ignore and not reply?
339 2015-01-29 20:09:19 <maraoz> (btw: the `getdata` message containing a block hash, with the type field set to 2)
340 2015-01-29 20:16:32 <Derrick> this is just a general answer maraoz, but you don't have any way of knowing if a node is really a core node, even if it claims it is; so I wouldn't never program to rely on anything from a peer.
341 2015-01-29 20:16:42 <Derrick> *ever
342 2015-01-29 20:17:25 <Derrick> I'll leave the question of is it supposed to to someone else though
343 2015-01-29 20:18:46 <Derrick> and even if it is, it could get shutdown before replying
344 2015-01-29 20:19:01 <maraoz> Derrick: thanks. Yeah, in this case, I'm running the node and I know it's a core node :) - it seems to be ignoring my `getdata` for block 154918
345 2015-01-29 20:20:14 <Derrick> ahh. I'm a newb when is comes to bitcoin protocoal beyond what i said above. But I assume you are sure that it has that block?
346 2015-01-29 20:22:49 <Derrick> Just to fill the void of silence while waiting for a more informed answer, a literal interpretation on the notfound message is in response to a transaction getdata
347 2015-01-29 20:22:52 <ajweiss> Derrick: if you run with -debug=net, you'll get a message in the debug.log that will let you see if your getdata is well formed
348 2015-01-29 20:22:53 <Derrick> Not a getblock
349 2015-01-29 20:23:14 <ajweiss> rather, maraoz
350 2015-01-29 20:24:40 <maraoz> ajweiss: awesome! that'll help!!
351 2015-01-29 20:27:50 <hearn> maraoz: i think notfound only applies for transactions
352 2015-01-29 20:27:52 <hearn> maraoz: iirc
353 2015-01-29 20:27:56 <hearn> ACTION wrote it but it was years ago
354 2015-01-29 20:28:06 <hearn> maraoz: check the source to be sure
355 2015-01-29 23:00:11 <Luke-Jr> Core devs who advise against using the Core wallet may wish to comment: http://www.reddit.com/r/Bitcoin/comments/2u3e5a/somebody_working_on_trezor_responded_about_their/co52m5d?context=3
356 2015-01-29 23:19:14 <phantomcircuit> Luke-Jr, who seriously suggests that?
357 2015-01-29 23:19:22 <phantomcircuit> afaik all of the alternatives are worse